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

[Ben Schwartz <[e-mail]>]

________________________________
From: Michael De Roover <[e-mail]>
Sent: Friday, May 23, 2025 5:09 PM

...

> So you join the network, get some parameters from DHCP, and that includes a
> local DNS server but the gateway doesn't function for whatever reason. You
> could ask the local DNS server about names it is locally authoritative for,
> and maybe it can respond to some of them (maybe including
> probe.resolver.arpa). But what gives? It responded, not the SOA or anything
> else more conclusive on the path.

Yes, if you get an NXDOMAIN response, you (only) know that the "immediate DNS server" you are talking to is alive and reachable.

> Meanwhile if the network connectivity does work properly, and perhaps the
> local DNS server does not have this hardcoded in an RPZ or such. So it decides
> to forward that query to whatever it is configured to relay to. Where would
> that query end up?

If nothing handling the query implements the resolver.arpa Locally Served Zone (RFC 9462), it will recurse to the .arpa nameservers, which will return NXDOMAIN.

> Should other entities on the path be configured to respond
> to this query like the local resolver would've done otherwise?

Yes, that's already established by RFC 9462.

> What does that
> say about connectivity? What if it's not just Starbucks or Flixbus or whatever
> that's down, what if it's their upstream ISP being under e.g. DDoS attack?
> What meaning does their ability to serve an ISP-local request serve?

It proves connectivity between you and the DNS server that responds.  It doesn't prove that this server is otherwise usable.  "Usable" isn't a binary value: if that server is the recursive resolver, it may be able to resolve some names but not others due to upstream infrastructure problems.

> Don't get me wrong, I do like the idea of a vendor-neutral name -- even if
> that currently means ambiguity on where those requests would be handled. I'd
> imagine solving that to be the purpose of this here WG.

It sounds like you're imagining a "DNS traceroute" for debugging complex failures.  That's something that has been discussed many times, but it's a much bigger challenge.  This draft is more like a simple "DNS ping".

--Ben