On Wed, 21 May 2025, Ben Schwartz wrote: [ speaking only as individual DNS enthousiast ]
> From what I understand about the draft so far, it seems that this would be a > vendor-neutral convergence point to do these connectivity checks against. No, that is not the idea. The idea is that when performing connectivity checks against any recursive resolver, you should use this arbitrary QNAME, not some other arbitrary QNAME.
So this is when the application "knows" it is online, but does not know if its system-overriding nameserver is reachable or not? i.e. you connect to startbucks, it gives you DNS 1.2.3.4, but your application wants to use 8.8.8.8 and so it has to probe for something and you propose this something to be some hardcoded vendor neutral name that hopefully doesn't cause queries beyond the actual resolver targetted, due to the zone being locall served by that remote DNS resolver? I see the advantage of this. Response time should be fairly quick because no further resolving is required on the remote resolver part. But I am bit puzzled by why a DNS probe is even needed when doing DoH or DoT. Since you already build a TLS connection, isn't that in itself already a proof of reachability - without sending a DNS query? Doing this for port 53 seems odd. If unencrypted, you might as well use the local network's DNS server since you are giving them all the data anyway and all the opportunities to falsify the responses. Paul _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
