Pendant plusieurs décennies, le système de noms de domaine (DNS) a fonctionné en texte clair sur le port UDP 53. L'absence de chiffrement exposait chaque requête aux écoutes passives des opérateurs de télécommunications, des gestionnaires de points d'accès Wi-Fi et des routeurs de transit.

L'émergence des protocoles DNS-over-TLS (DoT, RFC 7858), DNS-over-HTTPS (DoH, RFC 8484) et DNS-over-QUIC (DoQ, RFC 9250) a apporté une protection cryptographique solide au niveau du transport. Toutefois, les premiers déploiements reposaient sur une contrainte opérationnelle majeure : la configuration statique d'adresses IP de résolveurs publics (comme 1.1.1.1 ou 8.8.8.8).

Cette dépendance envers des serveurs publics fixes pose des défis considérables au sein des réseaux privés virtuels (VPN) et des infrastructures d'entreprise. Elle brise le mécanisme de résolution scindée (split-horizon) indispensable aux domaines internes (intranet.internal, répertoires de code source privés), génère des fuites DNS hors du tunnel sécurisé et empêche les passerelles locales d'offrir une résolution chiffrée de confiance.

Pour automatiser la montée en gamme cryptographique sans perturber le routage réseau, le groupe de travail Adaptive DNS Discovery (ADD) de l'IETF a finalisé deux spécifications complémentaires : la RFC 9462 (Discovery of Designated Resolvers, DDR) et la RFC 9463 (Discovery of Network-designated Resolvers, DNR).

+--------------------------------------------------------------------------+
|            FONCTIONNEMENT DE LA DÉCOUVERTE DE RÉSOLVEUR (RFC 9462 DDR)   |
+--------------------------------------------------------------------------+
|                                                                          |
|    +------------+        1. Requête en clair (UDP 53)     +------------+ |
|    |            | --------------------------------------> | Passerelle | |
|    |   Client   |   QNAME: _dns.resolver.arpa (Type SVCB) | DNS locale | |
|    | (OS / Stub | <-------------------------------------- |   ou VPN   | |
|    |  Resolver) |        2. Réponse SVCB structurée       +------------+ |
|    +------------+   TargetName: dns.vpnrice.internal             |       |
|          |          Alpn: "h2,h3", Port: 443                     |       |
|          |          IPv4/IPv6 hints                              |       |
|          |                                                       |       |
|          | 3. Vérification d'adresse IP et poignée de main TLS   |       |
|          |    Connexion sur l'IP passerelle via TCP 443 / UDP 443|       |
|          |    SNI: dns.vpnrice.internal                          |       |
|          v    Validation X.509 contre le magasin racine de l'OS  v       |
|    +----------------------------------------------------------------+    |
|    |             TUNNEL DNS CHIFFRÉ AUTOMATISÉ IN-SITU              |    |
|    |            (DoH / DoT / DoQ sur TLS 1.3 / QUIC)                |    |
|    |         Zéro fuite DNS - Intégrité du Split-Horizon préservée  |    |
|    +----------------------------------------------------------------+    |
|                                                                          |
+--------------------------------------------------------------------------+

Les mécanismes de la RFC 9462 : Discovery of Designated Resolvers (DDR)

DDR est un protocole de découverte intrabande (in-band discovery). Il permet à un résolveur stub client communiquant avec un serveur non chiffré (par exemple l'adresse de passerelle 10.8.0.1 attribuée par un tunnel VPN) de découvrir si cette même entité prend en charge des transports sécurisés.

Le processus repose sur les enregistrements de liaison de service (SVCB) normalisés dans la RFC 9460 :

1. Sondage du nom de domaine réservé

Lors de l'établissement de la liaison réseau, le client émet une requête DNS standard vers son résolveur non chiffré assigné :

  • QNAME : _dns.resolver.arpa
  • QTYPE : SVCB (Type 64)
  • Transport : Port 53 standard en UDP ou TCP

Le domaine _dns.resolver.arpa est une zone à usage spécial attribuée par l'IANA. Les résolveurs récursifs locaux doivent obligatoirement répondre de manière autoritaire à cette requête et ont l'interdiction formelle de la relayer vers les serveurs racines de l'Internet.

2. Structure de la réponse SVCB

Si le résolveur prend en charge le chiffrement, il renvoie un enregistrement SVCB décrivant ses capacités :

_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="dot"
    port=853
    ipv4hint=10.8.0.1
)

Ces attributs fournissent les informations indispensables :

  • TargetName (Authenticated Domain Name, ADN) : le nom de domaine complet utilisé pour l'authentification TLS (dns.vpnrice.internal).
  • alpn : les identifiants de négociation de protocole applicatif (h2 et h3 pour DoH, dot pour DoT, doq pour DoQ).
  • port : le port réseau hébergeant le service chiffré.
  • dohpath : le modèle d'URI pour acheminer les requêtes DoH.

3. Validation cryptographique et prévention des dégradations

Un acteur malveillant situé sur un réseau Wi-Fi public pourrait tenter d'injecter une fausse réponse SVCB pointant vers un serveur frauduleux. La RFC 9462 neutralise ce scénario grâce à une validation stricte :

  1. Correspondance d'adresse IP : le client doit impérativement établir la session TLS vers la même adresse IP que celle interrogée en clair. Si le résolveur était 10.8.0.1, la poignée de main TLS doit s'effectuer vers 10.8.0.1.
  2. Validation du certificat X.509 : le certificat présenté lors de la négociation TLS doit obligatoirement inclure l'ADN dans son extension SAN (Subject Alternative Name) et être validé par le magasin de certificats racine du système d'exploitation.
  3. Vérification d'adresses publiques : pour les résolveurs publics, le certificat doit contenir l'adresse IP dans les extensions SAN ou valider une résolution inverse PTR conforme.

Si la négociation échoue ou si le certificat n'est pas fiable, le client abandonne la mise à niveau, empêchant toute attaque par repli ou interception.

+--------------------------------------------------------------------------+
|                     MATRICE DES PROTOCOLES CHIFFRÉS DDR                  |
+--------------------------------------------------------------------------+
| Protocole          | Jeton ALPN | Port par défaut | Couche de transport  |
+--------------------+------------+-----------------+----------------------+
| 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)

Tandis que DDR opère au sein du protocole DNS, la RFC 9463 (DNR) définit une méthode de découverte hors bande (out-of-band discovery) directement intégrée dans l'autoconfiguration réseau :

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

Lorsqu'un terminal reçoit son bail IP, le serveur DHCP ou le routeur lui transmet simultanément le nom ADN, les priorités de service et les adresses IP du résolveur sécurisé. L'appareil configure ainsi son canal chiffré avant même d'émettre sa première requête DNS, éliminant totalement la sonde initiale en UDP clair.

Mise en œuvre pratique : configuration d'Unbound avec DDR

Sur les passerelles Linux hébergeant un concentrateur VPN, l'activation de DDR dans Unbound se réalise en déclarant la zone spéciale et les certificats TLS :

server:
    interface: 10.8.0.1@53       # Port UDP/TCP d'amorçage en clair
    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

    local-zone: "_dns.resolver.arpa." static
    local-data: '_dns.resolver.arpa. 3600 IN SVCB 1 dns.vpnrice.internal. alpn="h2" port="443" dohpath="/dns-query{?dns}"'
    local-data: '_dns.resolver.arpa. 3600 IN SVCB 2 dns.vpnrice.internal. alpn="dot" port="853"'

    local-zone: "vpnrice.internal." transparent
    local-data: 'dns.vpnrice.internal. 3600 IN A 10.8.0.1'

Validation du bon fonctionnement depuis un terminal client :

delv @10.8.0.1 _dns.resolver.arpa SVCB

Synergies architecturales avec RiceGuard et VPNRice

Au sein du moteur réseau RiceGuard développé pour VPNRice, l'implémentation conjointe des RFC 9462 et 9463 apporte des gains majeurs d'ingénierie :

  1. Suppression définitive des fuites DNS : les systèmes modernes accordent une priorité stricte aux canaux chiffrés DDR, ce qui évite les requêtes parallèles vers les résolveurs non protégés des réseaux locaux Wi-Fi.
  2. Préservation du Split-Horizon d'entreprise : les serveurs internes d'entreprise demeurent accessibles car le résolveur de tunnel exécute la résolution locale tout en chiffrant le transport.
  3. Résilience face aux réseaux filtrés : l'utilisation conjointe des ports 443 et 853 garantit l'acheminement des requêtes même lorsque le port UDP 53 est bloqué.

Considérations opérationnelles et perspectives

L'adoption de DDR et DNR en environnement de production exige une gestion rigoureuse :

  • Cycle de vie des certificats : le certificat du résolveur doit être émis par une autorité reconnue ou déployé via des profils MDM d'entreprise.
  • Politique de basculement : le mode strict (Strict Mode) doit être privilégié afin d'interdire tout repli non sollicité vers du texte clair en cas d'attaque active.

L'avènement de ces normes clôt l'ère du DNS non chiffré par défaut, offrant un modèle robuste qui concilie confidentialité, sécurité et souplesse opérationnelle.