[DNSOP] Re: Deployment tests for "probe.resolver.arpa"

[Paul Wouters <[e-mail]>]

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