Post by Sara Dickinson
The happy eyeballs reference looks to be the right thing to do.
"A resolver working in opportunistic mode should try ports 53 and 853 in
In addition to the privacy concern that Sara makes below (and with which I
agree), it's actually not what the current specification of Happy Eyballs
says. RFC 8305 says instead:
Once the list of addresses received up to this point has been
constructed, the client will attempt to make connections. In order
to avoid unreasonable network load, connection attempts SHOULD NOT be
Presuming we treat the "address" here as a tuple of IP address and port and
give a preference for 853 in the sorting algorithm, you'd end up starting
with it and then going to 53 only after the default delay expired.
I think that's better than concurrent attempts on several fronts.
Post by Sara Dickinson
I see the obvious latency win here but the downside with this mode (as
currently described) is that it _always_ leaks the query in cleartext so it
seems to defeat the point of using TLS. Unless the should (SHOULD?) here is
allowing for resolver behaviour where it has some cached knowledge of this
authoritative's capabilities and so could choose to probe all addresses
over 853 before falling back to 53? If so I think that should be spelled
out more clearly.
Iâd always seen opportunistic as âtry for the best but be willing to
fallback to the worst caseâ which isnât exactly the same as âhappy
eyeballsâ which I see as try everything in parallel?
If it is a concern that the same authoritative name servers are used
for ordinary DNS and for encrypted DNS,
I don't know that should be, but if so it probably should discuss why
some may find it to be a concern.
Is this related to the monitoring/data retention/privacy policies by the
operator? In other words that the concern is they treat all the data as if
it were unencryptedâŠ.
I think we should discuss whether an EDNS option to signal a successful
authentication or failure really is out of scope, as the draft says.
Interesting yes, but rogue or broken clients could easily send false
responses so Iâm unsure of how useful this is? What would the specific use
One other comment - in RFC8310 there is discussion of the possible attacks
on meta queries (used here to obtain the TLSA records) - it seems the same
concerns apply here too and should be mentioned in the Security
dns-privacy mailing list