For decades, the Domain Name System (DNS) operated over cleartext UDP port 53. Because queries were transmitted unencrypted across local Wi-Fi hotspots, municipal internet exchanges, and transit backbones, network eavesdroppers could catalog every host and service a device attempted to reach.

The arrival of DNS-over-TLS (DoT, RFC 7858), DNS-over-HTTPS (DoH, RFC 8484), and DNS-over-QUIC (DoQ, RFC 9250) provided strong transport encryption. Yet early deployments suffered from a critical operational flaw: discovery and configuration required hardcoded public resolver IP addresses (such as 1.1.1.1 or 8.8.8.8).

This rigid configuration model causes severe complications inside virtual private networks (VPNs) and corporate enterprise deployments. Static public resolver addresses sever split-horizon domain resolution (intranet.internal, local file shares, private git registries), trigger accidental DNS leaks outside secure tunnels, and prevent on-premise gateways from offering authenticated encrypted resolution.

To establish automated, zero-touch encrypted DNS upgrades without breaking local split-routing boundaries, the IETF Adaptive DNS Discovery (ADD) working group finalized two complementary standards: RFC 9462 (Discovery of Designated Resolvers, DDR) and RFC 9463 (Discovery of Network-designated Resolvers, DNR).

+--------------------------------------------------------------------------+
|          RFC 9462 DISCOVERY OF DESIGNATED RESOLVERS (DDR) WORKFLOW       |
+--------------------------------------------------------------------------+
|                                                                          |
|    +------------+        1. Plaintext Query (UDP 53)      +------------+ |
|    |            | --------------------------------------> | Local /    | |
|    |   Client   |   QNAME: _dns.resolver.arpa (Type SVCB) | VPN DNS    | |
|    | (OS / Stub | <-------------------------------------- | Recursive  | |
|    |  Resolver) |        2. SVCB Response                 | Gateway    | |
|    +------------+   TargetName: dns.vpnrice.internal      +------------+ |
|          |          Alpn: "h2,h3", Port: 443                     |       |
|          |          IPv4/IPv6 hints                              |       |
|          |                                                       |       |
|          | 3. Cryptographic Verification & TLS Handshake         |       |
|          |    Connect to Gateway IP on TCP 443 / UDP 443         |       |
|          |    SNI: dns.vpnrice.internal                          |       |
|          v    Validate X.509 Certificate against Public Web PKI  v       |
|    +----------------------------------------------------------------+    |
|    |           AUTOMATICALLY UPGRADED ENCRYPTED DNS TUNNEL          |    |
|    |            (DoH / DoT / DoQ over TLS 1.3 / QUIC)               |    |
|    |      Zero DNS Leaks - Full Split-Horizon Resolution Preserved   |    |
|    +----------------------------------------------------------------+    |
|                                                                          |
+--------------------------------------------------------------------------+

The Mechanics of RFC 9462: Discovery of Designated Resolvers (DDR)

DDR is an in-band discovery protocol. It enables a stub resolver that is currently talking to an unencrypted resolver (such as a local gateway address 10.8.0.1 provided by a VPN tunnel) to discover whether that exact same entity offers an encrypted endpoint.

The discovery process relies on Service Binding (SVCB) records standardized in RFC 9460:

1. Probing the Designated Special-Use Domain Name

Upon establishing a network link, the client issues a standard DNS query to its assigned unencrypted resolver:

  • QNAME: _dns.resolver.arpa
  • QTYPE: SVCB (Type 64)
  • Transport: Standard UDP/TCP port 53

The domain _dns.resolver.arpa is an IANA-allocated special-use domain. Resolvers are strictly forbidden from forwarding this query upstream to authoritative root servers; it must be answered authoritatively by the local recursive resolver itself.

2. The SVCB Response Structure

If the recursive resolver supports encrypted transport, it returns an SVCB record detailing its capabilities:

_dns.resolver.arpa. 3600 IN SVCB 1 dns.vpnrice.internal. (
    alpn="h2,h3"
    port=443
    dohpath="/dns-query{?dns}"
    ipv4hint=10.8.0.1
)
_dns.resolver.arpa. 3600 IN SVCB 2 dns.vpnrice.internal. (
    alpn="doq"
    port=853
    ipv4hint=10.8.0.1
)

The response parameters convey essential parameters:

  • TargetName (Authenticated Domain Name, or ADN): The fully qualified domain name the resolver uses for TLS authentication (dns.vpnrice.internal).
  • alpn: Application-Layer Protocol Negotiation identifiers (e.g. h2 and h3 for DoH, dot for DoT, doq for DoQ).
  • port: The TCP/UDP port hosting the encrypted service.
  • dohpath: The URI template for DoH queries.

3. Cryptographic Verification and Handshake

An attacker on a coffee-shop Wi-Fi network could attempt to forge a fake SVCB answer pointing to a malicious server. DDR neutralizes this vector through strict TLS certificate validation:

  1. IP Matching Verification: The client must establish the TLS connection to the exact same IP address as the unencrypted resolver it probed. If the unencrypted server was 10.8.0.1, the encrypted TLS handshake must connect to 10.8.0.1.
  2. X.509 Certificate Validation: During the TLS handshake, the resolver presents an X.509 server certificate. The certificate must contain the Authenticated Domain Name (ADN) in its Subject Alternative Name (SAN) extension and must validate successfully against the operating system trusted root trust store.
  3. Cross-IP Validation: For public resolvers (such as 149.33.22.1), RFC 9462 requires that either the IP address itself is listed in the certificate SAN (IPAddress entry), or reverse DNS lookup of the IP address matches the ADN.

Once validated, the client seamlessly switches all subsequent DNS queries to the encrypted channel. If the TLS handshake fails or the certificate is invalid, the client refuses the upgrade, preventing man-in-the-middle downgrade attacks.

+--------------------------------------------------------------------------+
|                   DDR UPGRADE MATRIX: PROTOCOL PARAMETERS                |
+--------------------------------------------------------------------------+
| Encrypted Protocol | ALPN Token | Default Port | Transport Layer         |
+--------------------+------------+--------------+-------------------------+
| DNS-over-HTTPS/2   | h2         | 443          | TCP + TLS 1.3           |
| DNS-over-HTTPS/3   | h3         | 443          | UDP + QUIC (RFC 9000)   |
| DNS-over-TLS       | dot        | 853          | TCP + TLS 1.3           |
| DNS-over-QUIC      | doq        | 853          | UDP + QUIC (RFC 9250)   |
+--------------------------------------------------------------------------+

RFC 9463: Discovery of Network-designated Resolvers (DNR)

While DDR operates in-band through DNS queries, RFC 9463 (DNR) establishes out-of-band discovery. DNR incorporates encrypted resolver parameters directly into local network provisioning protocols:

  • DHCPv4 Option 162 (OPTION_V4_DNR)
  • DHCPv6 Option 144 (OPTION_V6_DNR)
  • IPv6 Neighbor Discovery Router Advertisement Option 144

When a device connects to a physical link or receives configuration over an enterprise VPN endpoint, the DHCP or RA server returns the ADN, service priority, and IPv4/IPv6 addresses of the encrypted resolver simultaneously with IP address lease assignment.

The client receives encrypted resolver credentials before issuing its first DNS query, eliminating the initial cleartext UDP probe entirely.

Practical Implementation: Configuring a DDR-Compliant Gateway

For administrators operating Linux-based VPN concentrators or edge gateways using Unbound or BIND, enabling DDR is straightforward. Below is an example Unbound configuration illustrating how to publish _dns.resolver.arpa SVCB records and serve authenticated DoH/DoT:

server:
    interface: 10.8.0.1@53       # Plaintext bootstrap UDP/TCP
    interface: 10.8.0.1@853      # DNS-over-TLS (DoT)
    interface: 10.8.0.1@443      # DNS-over-HTTPS (DoH)
    
    tls-service-key: "/etc/unbound/certs/dns.key"
    tls-service-pem: "/etc/unbound/certs/dns.crt"
    tls-port: 853
    https-port: 443

    # Enable local zone for designated resolver discovery
    local-zone: "_dns.resolver.arpa." static
    
    # SVCB Record for DoH (ALPN h2, port 443)
    local-data: '_dns.resolver.arpa. 3600 IN SVCB 1 dns.vpnrice.internal. alpn="h2" port="443" dohpath="/dns-query{?dns}"'
    
    # SVCB Record for DoT (ALPN dot, port 853)
    local-data: '_dns.resolver.arpa. 3600 IN SVCB 2 dns.vpnrice.internal. alpn="dot" port="853"'

    # Local zone definition for the Authenticated Domain Name (ADN)
    local-zone: "vpnrice.internal." transparent
    local-data: 'dns.vpnrice.internal. 3600 IN A 10.8.0.1'

To test the DDR responder from a client terminal using standard DNS diagnostic utilities:

# Query the designated resolver SVCB record directly over UDP 53
delv @10.8.0.1 _dns.resolver.arpa SVCB

# Inspect the returned parameters
# Expect: TargetName dns.vpnrice.internal, alpn="h2", port=443

Architectural Synergies with RiceGuard and VPNRice

Within high-performance VPN systems such as VPNRice and the RiceGuard kernel tunneling engine, RFC 9462 and RFC 9463 solve long-standing friction points between security and usability:

  1. Deterministic Prevention of DNS Leaks: Traditional split-tunneling configurations often fall victim to race conditions where the operating system sends parallel queries to both VPN and physical interface resolvers. By deploying DDR inside RiceGuard, the tunnel resolver upgrades to a high-priority TLS/QUIC connection that modern operating systems prioritize over insecure physical Wi-Fi links.
  2. Preservation of Enterprise Split-Horizon Zones: Unlike public DoH resolvers that return NXDOMAIN for corporate internal domains, the DDR-upgraded resolver runs directly on the VPN concentrator. It resolves internal cluster hosts (vault.infra, gitlab.corp) while providing encrypted transport.
  3. Resilience on Restricted Networks: On networks where firewalls block UDP 53 or filter outbound DoH to commercial providers, RiceGuard gateways multiplex DoH and DoQ over standard HTTPS ports, preserving encrypted name resolution across challenging network environments.

Deployment Considerations and Future Outlook

Adopting DDR and DNR in production enterprise architectures demands careful planning:

  • Certificate Lifecycle: The designated resolver certificate must be signed by a CA present in standard client trust stores. For private network namespaces, enterprise MDM profiles must pre-install the internal Root CA.
  • Opportunistic vs. Strict Enforcement: RFC 9462 distinguishes between Opportunistic Mode (falling back to UDP 53 if TLS handshake fails) and Strict Mode (blocking all name resolution if the encrypted channel breaks). Enterprise VPN gateways should enforce Strict Mode to prevent on-path downgrade tampering.

The convergence of RFC 9462 (DDR) and RFC 9463 (DNR) marks the end of unencrypted DNS as an acceptable internet baseline. By automating the transition from cleartext UDP to TLS and QUIC, these protocols protect user privacy while preserving the distributed architecture of the global Domain Name System.