Résumé

  • Une zone RPZ transporte des déclencheurs et des actions proposées. Un transfert authentifié prouve la provenance de cette version, pas la justesse de chaque entrée ni l’autorisation de l’appliquer à tous les usagers.
  • L’exploitant du résolveur choisit l’ordre des zones, les dérogations, l’action, les groupes de clients, le comportement DNSSEC, la durée du cache et le diagnostic. La réponse réécrite est donc bien une décision locale.

Imaginons le système DNS d’un groupe hospitalier. Un fournisseur ajoute à son flux l’adresse d’un hébergeur compromis. Le même réseau dessert aussi un portail de prise de rendez-vous. Le transfert IXFR est exact et signé ; la liste locale d’exceptions contient le bon préfixe, mais elle est déclarée après le flux externe. Pour les postes concernés, le portail n’existe plus.

Ce cas est fictif, mais le mécanisme est réel. La faute ne se trouve pas dans le transport. Elle se trouve dans la promotion d’un objet externe vers le plan de contrôle local et dans l’ordre retenu pour départager deux règles. L’intégrité du flux et la légitimité de la conséquence appartiennent à deux couches différentes.

La documentation actuelle de BIND 9 présente les Response Policy Zones comme un format ouvert et indépendant d’un fournisseur : les règles d’un pare-feu DNS sont encodées dans une zone ordinaire, puis distribuées avec les mécanismes familiers du DNS. Unbound et PowerDNS Recursor mettent eux aussi en œuvre cette logique.

Le statut documentaire doit rester exact. Le texte draft-vixie-dnsop-dns-rpz-00 est un Internet-Draft individuel expiré, sans valeur de norme IETF. Son historique Datatracker indique qu’il est devenu dormant en juillet 2020. Il décrit utilement le langage commun observé dans les produits, mais ne doit pas être présenté comme un RFC.

Ce texte contient pourtant la phrase opérationnelle décisive : le transfert publie des données de politique ; c’est la configuration du serveur récursif abonné qui élève ces données au rang de contrôle local. Le fournisseur propose. Le résolveur exécute.

Une RPZ peut viser cinq éléments : l’adresse du client, le nom demandé, une adresse qui aurait figuré dans la réponse, le nom d’un serveur faisant autorité ou son adresse. Ces déclencheurs n’apparaissent pas au même moment. QNAME peut agir très tôt ; RPZ-IP suppose que le résolveur ait obtenu une réponse ; NSDNAME et NSIP peuvent couvrir une multitude de domaines sans lien entre eux dès lors qu’ils partagent l’hébergement DNS. BIND avertit expressément que ces deux derniers critères peuvent avoir une portée considérable.

Les actions ne sont pas davantage interchangeables. NXDOMAIN fabrique l’inexistence du nom. NODATA conserve le nom mais supprime le type demandé. DROP ne répond pas. TCP-only force une reprise en TCP. Les données locales peuvent diriger l’usager vers un jardin clos. PASSTHRU constitue une exemption. Réduire tout cela à « bloquer » empêche de voir ce que l’application, le cache et le support vont réellement constater.

L’ordre des zones attribue le pouvoir. La référence de configuration BIND choisit d’abord la première zone déclarée qui contient une règle applicable, puis départage les familles de déclencheurs et leur précision. Unbound consulte lui aussi les zones dans l’ordre ; une action PASSTHRU compte comme une correspondance et arrête les zones suivantes. Le conseil pratique de BIND consiste précisément à placer une RPZ interne avant les flux externes et à y inscrire les partenaires à préserver.

Ce détail transforme une liste d’exceptions en instrument de souveraineté opérationnelle. Si l’organisation possède la première zone, elle peut refuser qu’une entrée future d’un fournisseur coupe un service critique. Si elle place le fournisseur avant, elle lui concède de fait la priorité. Aucun bit du transfert n’enregistre ce choix de gouvernance.

Les remplacements d’action renforcent ce constat. BIND permet d’imposer à toute une zone NXDOMAIN, NODATA, DROP, TCP-only, PASSTHRU ou une destination CNAME locale. Unbound peut garder les déclencheurs externes tout en redirigeant chaque correspondance vers le domaine de l’abonné. PowerDNS expose ses propres politiques par défaut, de NoAction à Custom ou Drop. L’abonné peut donc conserver la liste du fournisseur tout en produisant une tout autre réponse.

Même le mode d’essai est une décision locale et varie. Chez Unbound, disabled journalise sans agir et, contrairement à PASSTHRU, ne bloque pas l’examen de la zone suivante. Chez BIND, l’option DISABLED permet également d’observer ce qui se serait passé, sous réserve des règles de priorité. Copier un terme de configuration d’un produit à l’autre sans tester le chemin complet peut modifier silencieusement l’exception attendue.

DNSSEC interdit ensuite de donner à la réponse fabriquée le prestige de la donnée faisant autorité. Le projet RPZ qualifie ces résultats de réponses volontairement non conformes à la vérité autoritative. BIND n’applique normalement pas la réécriture lorsque le client demande les données DNSSEC et que la zone d’origine en fournit. L’option break-dnssec yes l’autorise, mais la documentation précise que le résultat réécrit ne peut plus être validé.

RFC 4035 définit la donnée Bogus : une chaîne qui devrait pouvoir être établie ne l’est pas, en raison d’une attaque, d’une erreur de configuration ou d’une corruption. Le même RFC rappelle que la réponse d’un serveur récursif dépend fortement de sa politique locale. DNSSEC peut authentifier la donnée de l’autorité. Il ne signe pas le NXDOMAIN synthétique de l’entreprise. TSIG peut protéger le transfert du flux, pas convertir cette synthèse en vérité autoritative.

L’effet peut survivre à la décision. RFC 2308 organise le cache des réponses négatives : NXDOMAIN et NODATA possèdent des portées et des durées distinctes. BIND dérive la durée de la politique tout en appliquant un plafond local ; PowerDNS expose la durée synthétique et l’invalidation du cache. Une entrée retirée chez le fournisseur peut donc continuer à produire des échecs dans le cache du résolveur ou en aval. Le numéro de série, le rafraîchissement, le rechargement et le TTL ne sont pas une seule horloge.

Le diagnostic peut au moins nommer l’auteur de la décision. RFC 8914 distingue Blocked pour la politique de sécurité interne, Censored pour une exigence extérieure, Filtered lorsque le client a demandé ce filtrage et Prohibited pour un client non autorisé. BIND et PowerDNS peuvent ajouter un EDE à une correspondance RPZ. Ces codes empêchent de masquer sous le même mot une décision interne, une obligation légale et un choix du client.

Mais EDE reste un renseignement de diagnostic. Le RFC interdit de lui faire modifier le traitement DNS ; il peut ne pas être authentifié, être supprimé en chemin ou révéler l’existence d’une liste. La preuve exploitable associe donc le code au numéro de série, au nom de la politique, au déclencheur gagnant, à l’action locale et à la classe de clients.

La fraîcheur demande la même discipline. Le projet expiré insiste sur la rapidité des retraits erronés, pas seulement sur l’ajout de nouvelles menaces. PowerDNS peut conserver la dernière version reçue dans un fichier et la réutiliser au redémarrage avant IXFR. BIND peut attendre que les RPZ soient prêtes ou répondre avec celles qui ont effectivement chargé. Sans âge maximal, objectif de retrait et propriétaire de la dérogation, « dernière version connue » devient une ambiguïté dangereuse.

Les textes de Heng Lu sur la primauté du code en fonctionnement, la spécification minimale et la décision future localisée et les couches de réalité offrent ici une méthode sobre. Le format partagé peut rester minimal. La décision future demeure chez l’abonné. La réalité finale se lit dans la réponse effectivement reçue, pas dans l’existence abstraite d’un enregistrement RPZ.

Un audit complet doit donc relier l’éditeur et le serial du flux, la preuve du transfert, l’admission locale, l’ordre effectif, le remplacement éventuel de l’action, le déclencheur gagnant, le TTL et l’EDE, puis une sonde depuis chaque population d’usagers. Tant que cette chaîne manque, l’expression « notre fournisseur l’a bloqué » décrit une dépendance commerciale, pas l’autorité technique qui a réécrit la réponse.