>> 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 againstany recursive resolver, you should use this arbitrary QNAME, > not some other arbitrary QNAME.
That’s good to know, thank you for clarifying this. Upon trying to find some more relevant information about what’s currently under resolver.arpa, I came across a thread on the Pi-Hole forums. https://discourse.pi-hole.net/t/implement-dns-resolver-arpa-as-a-special-domain-or-add-block-svcb-as-a-configuration-option/77099 It mentions that SVCB records can be used to upgrade to DoH. Upon trying to resolve _dns.resolver.arpa from Cloudflare, Google, and Quad9, they each return A and AAAA records for their respective DNS servers. Would probe.resolver.arpa work similarly? I’ve tried probing it in similar ways against the aforementioned resolvers, but didn’t get much out of it at the moment. How would that work? > 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. Hmm, wasn’t aware of this. I’ll take it back towards them, thanks for having clarified that. 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]
