Discovery Answers Now Carry Address Hints (One Less Round Trip)

Every DDR designation the resolver returns for _dns.resolver.arpa now includes ipv4hint=194.180.189.33, on DoH, DoT and DoQ alike. A bootstrapping device can open the encrypted handshake immediately instead of first resolving the target name, saving one round trip at the moment latency is most visible.

When a device discovers this resolver through DDR (RFC 9462), the SVCB answer names the designated endpoint, dnsdoh.art. Until now the device then had to resolve that name's A record, over the plain-DNS path it is trying to leave, before it could open the first encrypted connection. As of 10 July every designation carries the address inline:

1 dnsdoh.art. alpn="h2,h3" port=443 ipv4hint=194.180.189.33 key7="/dns-query{?dns}"
1 dnsdoh.art. alpn="dot" port=853 ipv4hint=194.180.189.33
1 dnsdoh.art. alpn="doq" port=853 ipv4hint=194.180.189.33

The ipv4hint parameter (RFC 9460) hands the client the target address inside the discovery answer itself, so the encrypted handshake starts one round trip sooner. Cloudflare's DDR records use the same shape. Hints are non-authoritative: clients still resolve the name and prefer those answers, so the hint cannot go stale in a harmful way.

Implementation

The resolver runs a maintained AdGuard Home fork, and this change is a new option in it, ddr_ipv4_hint, documented publicly with the wire-format detail (SVCB parameters must stay in ascending key order, so the hint is inserted between port and dohpath): AdGuardHome-edge specification, section 7.17.

The guides that show live discovery output have been refreshed to match: Anatomy of a Hardened DNS Zone, How Devices Discover Encrypted DNS and Verified DDR End to End. Anyone can check the live answer: dig +short _dns.resolver.arpa SVCB @194.180.189.33.