________________________________ From: Michael De Roover <[email protected]>
... > 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. Great! ... > 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. No, that is not the idea. The idea is that when performing connectivity checks against any recursive resolver, you should use this arbitrary QNAME, not some other arbitrary QNAME. > 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. This draft is not proposing anything like that. You're welcome to write a proposal like that, but I think it would be separate from this draft. ... > 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.' That information is exposed to apps via the Android Java API: https://developer.android.com/reference/android/net/LinkProperties#getDnsServers() > This > means that 8.8.8.8 is assumed until changed manually inside such application. This sounds like a choice attributable to the Termux developers. --Ben
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
