________________________________
From: Paul Wouters <[email protected]>
Sent: Friday, May 23, 2025 2:58 PM
To: Ben Schwartz <[email protected]>
...
> So this is when the application "knows" it is online, but does not know
> if its system-overriding nameserver is reachable or not?
The draft notes several use cases in the introduction:
"""
* To determine if the network is working at all.
* To detect if a particular address family is connected to the global internet.
* To check that the client is able to reach the resolver's IP address.
* To assess the reliability and performance of the network path between the
client and the resolver.
* To establish which transport protocols (e.g., UDP, TCP, TLS [RFC7858], QUIC
[RFC9250]) are available.
* To confirm that the DNS resolver itself is operational.
"""
The use case you mention would be #3. Personally, I was inspired by several
instances where my code sent DNS queries to a major public resolver in order to
check:
* Is this VPN tunnel working? (use case #1) Is it working for both TCP and UDP?
* Is this dual-stack infrastructure node actually connected to the internet on
both address families? (use case #2)
* If I can't reach my own DNS server on port 853, is that because port 853 is
blocked on this network or is it because my DNS server is broken? (perhaps #3
or #5)
* etc.
These use cases could all be addressed in other ways, with protocols like ICMP
or ECHO (RFC 862), specialized servers, specialized TLS clients, etc. In
practice, DNS is heavily used for this purpose because it's easy and pragmatic.
("example.com" is in Cloudflare DNS's top 200 most-queried domains [1],
presumably not due to intense user interest).
This draft acknowledges this common practice and documents a simple improvement.
--Ben
[1] https://radar.cloudflare.com/domains/domain/example.com
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
