Résumé

  • La RFC 5625, signée par Ray Bellis, part de l'impossibilité pour un proxy DNS simple de connaître les fonctions actuelles et futures. Elle lui demande donc de transmettre les indicateurs, types et classes inconnus, de conserver les réponses complètes, EDNS, TC, TCP et les données sensibles à l'authentification, tout en rendant les refus explicites.
  • Devenue BCP 152 en 2009, elle ne prouve ni la conformité des équipements actuels ni l'adoption universelle. La transparence n'est pas une validation DNSSEC. Elle sépare plutôt les responsabilités : les spécifications et les extrémités possèdent la sémantique ; le proxy possède un état de transfert limité, son exposition et une politique locale déclarée.

Une signature brisée par un intermédiaire serviable

Un client envoie une requête DNS protégée par TSIG. Le serveur la reçoit, mais la vérification échoue. Entre les deux, un équipement de bord a « normalisé » un champ qu'il jugeait inhabituel. Il voulait rendre le message plus propre ; il a modifié des octets dont l'intégrité était précisément la preuve recherchée.

Cette scène révèle la question centrale : de quel droit un intermédiaire interprète-t-il un protocole lorsque les extrémités en savent davantage que lui ?

La RFC 5625, DNS Proxy Implementation Guidelines, a été publiée en août 2009 sous le numéro BCP 152. Son auteur, Ray Bellis, travaillait alors chez Nominet UK. Le document reconnaît la modestie matérielle des routeurs résidentiels, leurs cycles de micrologiciel longs et l'impossibilité de prévoir toutes les extensions futures du DNS.

Il n'en déduit pas que le proxy doit rester figé. Il en déduit que son rôle doit rester mince. Recevoir une requête du LAN, la transmettre telle quelle à un résolveur récursif connu, puis remettre la réponse complète au client d'origine : cette garde limitée évite que la table de codes d'un vieux micrologiciel ne devienne une constitution parallèle du DNS.

Le proxy continue de choisir un résolveur amont, d'associer une réponse à un client et de contrôler ses interfaces. Mais ces fonctions opérationnelles ne lui donnent pas la propriété du sens contenu dans le paquet.

Ce que l'échantillon de 2008 établit

Les tests consignés dans le résumé de SAC035 et le rapport complet expliquent le contexte. En juillet et août 2008, 24 routeurs résidentiels ou pare-feu pour petits bureaux ont été évalués dans un cadre contrôlé.

Tous pouvaient acheminer directement des requêtes DNSSEC vers l'amont. Vingt-deux proposaient aussi un mode proxy. Six de ces proxys rencontraient des difficultés avec des indicateurs liés à DNSSEC ou avec des réponses validées. Dix-huit limitaient les réponses UDP à 512 octets ou à une taille liée au MTU ; quatre seulement renvoyaient jusqu'à 4096 octets, et un seul assurait le relais DNS sur TCP. Six appareils étaient entièrement compatibles dans leur configuration par défaut ; neuf autres permettaient une reconfiguration contournant l'incompatibilité du proxy.

Ce sont des résultats historiques, pour 24 appareils et leurs configurations de 2008. Ils ne mesurent ni le marché actuel ni le comportement d'une marque contemporaine. Leur portée est plus précise : une couche intermédiaire très répandue pouvait empêcher une fonction comprise aux deux extrémités.

La note d'approbation de l'IETF mentionne un fort consensus du groupe DNS Extensions et l'intérêt des fournisseurs comme des acheteurs. Elle renseigne sur la fabrication de la BCP, pas sur son exécution dans les foyers.

L'inconnu n'est pas une erreur de syntaxe

Le mécanisme le plus durable de la RFC tient dans cette distinction. Un indicateur DNS que le proxy ne connaît pas doit être ignoré par son analyseur, mais le paquet doit continuer. Les différentes formes d'étiquettes, les QTYPE, QCLASS, TYPE et CLASS inconnus doivent également franchir le relais.

Une règle ancienne imposant zéro dans un bit réservé ne peut survivre mécaniquement après l'attribution de ce bit. Sinon, chaque nouveau sens doit attendre le remplacement de tous les équipements intermédiaires, même quand le client et le résolveur sont prêts.

La RFC 3597 formule la règle générale pour les types de ressources inconnus : considérer le RDATA comme une suite binaire non structurée, le conserver et le transmettre sans changement. Ne pas comprendre n'oblige pas à inventer une interprétation ; cela oblige à préserver la possibilité qu'un autre composant comprenne.

Un paquet intrinsèquement impossible reste toutefois rejetable. Un pointeur de compression invalide ou des comptes de sections incompatibles avec le contenu ne sont pas une extension future. La RFC 5625 permet l'abandon de tels messages, mais préfère, lorsque c'est sûr, une réponse SERVFAIL au silence. Une erreur déclarée met fin aux retransmissions et aide à localiser le refus.

Une politique active constitue une autre exception. Un opérateur peut filtrer au nom d'une règle de sécurité ou de réseau. La règle doit être intentionnelle, délimitée et attribuable. Un analyseur incomplet qui supprime un champ inconnu n'est pas une politique, même si son effet ressemble à un blocage.

La taille d'une réponse est aussi une information

Lorsqu'un proxy coupe une réponse UDP au-delà de 512 octets sans poser l'indicateur TC, il ne fait pas que perdre des données. Il annonce implicitement au client que l'ensemble reçu est complet. S'il efface un TC venu du serveur, il retire l'instruction de recommencer sur TCP.

La RFC 5625 demande donc de ne pas tronquer uniquement à cause de l'ancien seuil de 512 octets. Une limite locale inévitable doit être signalée par TC, et un TC amont ne doit jamais disparaître. Une limite visible permet la récupération ; une limite cachée fabrique une réponse crédible mais faussement complète.

Le transport doit lui aussi être conservé. Le proxy doit recevoir et transférer du DNS sur TCP. Une requête cliente en TCP devrait rester en TCP vers l'amont, plutôt que de redescendre en UDP pour échouer une première fois. La RFC 7766, cosignée plus tard par Bellis et quatre autres auteurs, a rendu TCP obligatoire pour les implémentations DNS. Cette norme confirme la responsabilité de transport sans garantir la conformité de chaque passerelle.

EDNS matérialise le futur dans un enregistrement OPT. Sa présence ne doit pas provoquer de refus. La RFC 6891 précise ensuite qu'un middlebox conforme ne doit pas imposer 512 octets à l'UDP et qu'un simple relais ne doit ni modifier ni supprimer le contenu OPT. La capacité de 4096 octets recommandée en 2009 décrit une cible de l'époque, pas une limite éternelle.

Transparence, sécurité et voie de sortie

Un proxy transparent conserve néanmoins un état. Il doit apparier requêtes et réponses, limiter la durée de cet état et éventuellement changer l'identifiant de requête sortant. La RFC renvoie aux protections de la RFC 5452, notamment la randomisation des identifiants et des ports source. Ces mesures diminuent le risque de réponse forgée ; elles ne fournissent pas, seules, l'authenticité.

TSIG montre pourquoi la conservation intégrale compte. Modifier un contenu DNS signé, sauf le traitement précisément admis pour l'identifiant, fait échouer l'authentification. Le proxy doit transmettre ou implémenter complètement les règles cryptographiques. Une réécriture partielle ne se situe pas entre les deux : elle détruit la preuve.

La portée des interfaces appartient aussi à l'opérateur. Un service prévu pour le LAN ne devrait pas répondre par défaut côté WAN, où il pourrait participer à une réflexion. La RFC 5358 décrit ce risque pour les serveurs récursifs ouverts. Être transparent envers les clients autorisés n'implique pas d'être public.

Enfin, la possibilité de contourner le proxy limite son pouvoir. Sauf politique explicite, le réseau devrait permettre à un client d'utiliser le résolveur amont qu'il a choisi. Intercepter toutes les alternatives transforme un service de commodité en point de passage sémantique obligatoire.

L'épreuve de l'ignorance conçue par Bellis

Le profil IETF de Ray Bellis recense dix RFC, dont la RFC 5625. La page de l'équipe ISC le présente aujourd'hui comme Director of DNS Operations. Le texte porte la marque de ce travail d'exploitation : il organise les responsabilités avant de dresser une liste de fonctions.

La question de recette n'est pas « combien de codes le proxy connaît-il ? », mais « que fait-il du prochain code ? ». L'indicateur inconnu passe-t-il ? Le type de ressource garde-t-il ses octets ? TC et TCP restent-ils visibles ? L'OPT arrive-t-il intact ? Une décision de politique peut-elle être distinguée d'un défaut du micrologiciel ?

La RFC 8906, cosignée plus tard par Mark Andrews et Bellis, transforme des champs, types, versions et options EDNS inattendus, la troncature et TCP en cas de test. Elle offre des preuves d'exploitation plus fines que l'absence de réponse.

La RFC 5625 ne prétend pas que la transparence valide DNSSEC, garantit la confidentialité ou la disponibilité, ni qu'elle supprime le besoin de politique. Elle empêche une autre confusion : l'intermédiaire ne peut faire de son ignorance une compétence normative. Son autorité s'arrête là où commence le sens qu'il n'a pas reçu mission de définir.

Sources