How a device finds encrypted DNS by itself
Encrypted DNS needs more than an IP address: a hostname, port, and protocol. DDR (Discovery of Designated Resolvers) lets a resolver publish these details to any device already talking to it. A device queries `_dns.resolver.arpa` and gets back the encrypted endpoints it offers, along with their IPs. This works for devices already on encrypted DNS (upgrading protocols) and for plain-DNS devices like TVs and consoles. However, upgrades from plain DNS are opportunistic and can be blocked by network operators. Direct configuration remains stronger where possible.
Clients treat this route as opportunistic for that reason, taking the upgrade when it succeeds and continuing on plain DNS when it fails.
- Utilera
A device that only exposes an IP field can use DDR without extra user configuration, but it still has to implement DDR and an encrypted DNS protocol in the first place...
- WarOnPrivacy
a lookup for _dns.resolver.arpa, a name reserved for ... asking whether an encrypted version exists, and where it can be reached
Neat! Let's try: nslookup _dns.resolver.arpa
[mine] unblound.lan can't find _dns.resolver.arpa: Non-existent domain
[1.1.1.1] can't find _dns.resolver.arpa: Non-existent domain
[8.8.8.8] No internal type for both IPv4 and IPv6 Addresses (A+AAAA)
records available for _dns.resolver.arpa
[9.9.9.9] Name: _dns.resolver.arpa
- rdme
running my own resolver as system DNS i can confirm apple devices fire _dns.resolver.arpa on every network join, but since verified DDR needs a TLS cert covering the resolver's IP it's effectively public-resolver-only, so for a LAN resolver the right move is just answering NODATA instead of leaking the query upstream.