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: [email protected] Web: michael.de.roover.eu.org _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
