On Friday, May 23, 2025 8:58:49 PM CEST Paul Wouters wrote: > [ speaking only as individual DNS enthousiast ] High five! ^^
> 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 think this is something worth drilling into, with a set scenario (e.g. local network failure), and set configuration styles. Assume for example such public network that uses an internal DNS server. Let's not include captive portals just yet, but something along those lines. 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. 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? Should other entities on the path be configured to respond to this query like the local resolver would've done otherwise? 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? 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. > I see the advantage of this. Response time should be fairly quick > because no further resolving is required on the remote resolver part. So this, completely agreed. But the purpose of the servers on the path should be well-defined. And it should ultimately lead to a full path towards the server that's being actually probed against. If that is 8.8.8.8, then Google should respond with whatever CDN technology they have. And we could have a discussion about whether a CDN says much about connectivity from IXP to other nations, but I'll admit that to be somewhat far-fetched. If it is Cloudflare or Quad9 or anyone else to be probed against meanwhile, same thing. They're being asked the question, that's what the application expects a response from. > 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 -- 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]
