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

[Michael De Roover <[e-mail]>]

On Wednesday, May 28, 2025 5:17:45 PM CEST Ben Schwartz wrote:
> Yes, if you get an NXDOMAIN response, you (only) know that the "immediate
> DNS server" you are talking to is alive and reachable.

Hmm, that does seem like it would be useful and sufficiently simple to do. So I 
guess then the difference would be between NXDOMAIN if accessible, and timeout 
if not? I suppose it would be faster than ping (on success), not to mention 
only one round-trip as opposed to (usually) 4 or even indefinite by default. 
And it could also serve as a secondary test to that, if ICMP is blocked for 
some reason.

> > 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.

It's good that it would end up at such a neutral destination, and that some of 
this is already defined in an existing RFC. I'll try to take a look at it 
shortly.

> > 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.

Fair enough. And I suppose those could then be troubleshooted separately, or 
even tested with other domain names queried from that server. But that would, 
admittedly, be out of scope here. I appreciate that you've entertained the 
question, thank you.

> > 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".

Mhm, it does. And for that, tools like traceroute and MTR would be better 
suited. Having something that can just ping a DNS server using its own 
protocol meanwhile, I can see the appeal of that. So yeah, for what it's 
worth, here's my stamp of approval. Let's make this happen.

-- 
Met vriendelijke groet,
Michael De Roover

Mail: [e-mail]
Web: michael.de.roover.eu.org