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

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

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: [e-mail]
Web: michael.de.roover.eu.org