Hi Ben, Puneet, John, DNSOP. I've yet to look into the document and repository to form a conclusive opinion on it, but so far I'm really liking what I'm seeing. One of the things that bothers me with connectivity checks is that they are so centralized, notably towards Google's 8.8.8.8 service. It is possible to RPZ our way out of that to some extent, yes, but it's incomplete, a local intervention, and as the draft mentions, it sticks out like sore thumb in traffic logs.
>From what I understand about the draft so far, it seems that this would be a vendor-neutral convergence point to do these connectivity checks against. I like that idea, especially if it is also jointly operated by existing high- reliability service providers. There's no denying that Google's, Meta's, and Quad9's availability is among the best in the industry. I'm curious about how this infrastructure is eventually intended to be shared across various operators, who holds which stakes, to which extent this would be a vendor-neutral endeavor (if that is not a mistake on my end). Additionally, I'm curious about what this might imply for OS implementations of this feature, given the impressive lineup of authors. One of the gripes I've had with Android in particular, is that it's had a pretty hard dependency on Google's Public DNS for quite some time now. While at the network management level, it does allow DNS servers to be advertised by DHCP, that is not forwarded into applications like e.g. Termux by the Bionic C library. This means that 8.8.8.8 is assumed until changed manually inside such application. Not trying to impose any particular work, just something concrete I bumped into before. Consider it curiosity as to the scope of this proposal, and how far this could be taken into its conclusion. On Monday, May 19, 2025 7:44:32 PM CEST Ben Schwartz wrote: > Hi DNSOP, > > A few months ago, Puneet Sood, John Todd, and I proposed > "probe.resolver.arpa" as the standard name for DNS resolver reachability > probes [1]. Since then, my team has done a sizeable test deployment > (several thousand clients), in a situation where we were probing the > reachability of Google Public DNS using IPv4 and IPv6. > > In the old configuration, clients were probing reachability by querying for > "A" records at "www.google.com". In the new configuration, clients were > querying for "A" records at "probe.resolver.arpa". > > The results show that the new reachability probes behave exactly as > expected, or perhaps even better: > > * The success/fail rates and error distributions are identical. > * The response latency is highly correlated, but 8 milliseconds faster on > average. We believe this is due to a "fast path" in Google Public DNS when > synthesizing NXDOMAIN responses under "resolver.arpa". > > I would like to see this draft progress to RFC in order to formally reserve > the target domain. Otherwise, probers that expect NXDOMAIN could be > confounded when records are added. Given the rather trivial scope of this > draft, I think AD sponsorship could be appropriate, but DNSOP adoption > would also be welcome. > > --Ben Schwartz > > [1] https://datatracker.ietf.org/doc/draft-sst-dnsop-probe-name/ -- 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]
