Durcir l'infrastructure DNS

Le DNS est cru par tout le monde et vérifié par presque rien et c’est pourquoi un résolveur exploité à la légère devient une arme pointée sur autrui et un serveur autoritatif exploité à la légère devient une carte de votre parc et un canal de sortie. Les menaces sont connues, empoisonnement de cache, amplification, tunneling, divulgation de zone et les défenses ne sont pas exotiques. Elles se ramènent à quatre décisions: qui peut demander à votre résolveur de récurser, qui peut tirer vos zones, si vos réponses peuvent être forgées et si vous pouvez voir des données partir dans vos propres requêtes.

Séparer les deux rôles

La première erreur est de faire tourner un seul serveur qui récurse pour les clients internes et répond de façon autoritative pour des zones publiques. Ce sont des postures de confiance opposées et elles appartiennent à des machines différentes. Le serveur autoritatif en DMZ répond pour vos zones publiques et ne récurse pour personne; le résolveur interne répond à vos clients et reste injoignable depuis internet. Les confondre, c’est devenir un résolveur ouvert par accident.

Fermer la récursion ou devenir un amplificateur

Un résolveur ouvert, qui récurse pour n’importe quelle adresse source, est la matière première d’une attaque par amplification: une requête spoofée de 64 octets tire une réponse de plusieurs kilo-octets vers une victime et votre serveur est l’arme. La correction est de ne récurser que pour les réseaux qui sont les vôtres:

// named.conf, le résolveur
acl internal { 10.0.0.0/8; 192.168.0.0/16; 127.0.0.1; };

options {
    allow-query     { internal; };
    allow-recursion { internal; };
    recursion yes;          // un résolveur récurse, mais seulement pour 'internal'
};

Le serveur autoritatif prend la position inverse, récursion coupée entièrement, parce qu’un serveur autoritatif n’a rien à résoudre:

options {
    recursion no;
    allow-query { any; };   // il répond pour ses propres zones, à tout le monde
};

Le Response Rate Limiting émousse l’amplification même pour le serveur autoritatif légitimement public, en plafonnant la fréquence à laquelle une réponse identique est envoyée vers un flot spoofé:

options {
    rate-limit { responses-per-second 10; window 5; };
};

Verrouiller les transferts de zone

Un transfert de zone remet chaque enregistrement que vous détenez, ce qui pour un attaquant est un inventaire fini: chaque hôte, chaque service, toute la forme du réseau en un AXFR. Par défaut, bien trop de serveurs y répondent à quiconque. Les transferts vont vers vos secondaires et personne d’autre, authentifiés par une clé TSIG plutôt que par confiance d’IP, qu’un spoofeur peut forger:

key "xfr-key" { algorithm hmac-sha256; secret "..."; };

zone "company.com" {
    type primary;
    allow-transfer { key "xfr-key"; };   // les secondaires portent la même clé
    notify yes;
};

Toute autre tentative d’AXFR est refusée et l’inventaire reste le vôtre.

DNSSEC : rendre les réponses infalsifiables

Les limites de récursion et TSIG protègent vos serveurs; DNSSEC protège vos réponses, en les signant pour qu’un résolveur qui valide distingue un enregistrement forgé d’un vrai et défasse l’empoisonnement de cache à la source. Il signe, il ne chiffre pas, donc il s’agit d’intégrité et d’authenticité, pas de confidentialité et il vaut mieux être clair là-dessus parce que les gens s’en saisissent en attendant une vie privée qu’il n’a jamais offerte. Le BIND moderne automatise l’essentiel de la gestion de clés:

zone "company.com" {
    type primary;
    dnssec-policy default;    // ZSK/KSK automatiques, signature, rollover
    inline-signing yes;
};

La seule étape manuelle qu’on ne peut sauter est la publication de l’enregistrement DS dans la zone parente, parce que c’est le maillon qui relie vos signatures à la chaîne de confiance depuis la racine. Signez la zone et oubliez le DS et vous avez fait le travail sans en gagner la protection.

Voir ce qui part dans vos propres requêtes

Le DNS est le canal d’exfiltration de choix précisément parce qu’il est autorisé à sortir partout où un pare-feu dit non par ailleurs et parce qu’une requête vers <chunk-base64>.exfil.attacker.com ressemble à n’importe quelle résolution. J’ai construit la version bénigne de cela, de l’IP tunnelée sur DNS, donc je ne me fais aucune illusion sur sa discrétion: les données montent dans les labels sortants, les réponses redescendent dans des enregistrements TXT ou NULL et le volume peut rester sous n’importe quel seuil de débit. Vous ne le bloquerez pas avec une signature. Ce que vous pouvez faire, c’est guetter dans vos propres logs de résolveur la forme de la chose, des labels anormalement longs ou à haute entropie, un client unique générant un flux régulier de sous-domaines uniques sous un même parent, une série soutenue de requêtes TXT et traiter ce motif comme le signal qu’il est. La journalisation des requêtes sur le résolveur est le préalable; sans elle, le canal est tout simplement invisible.

Les Response Policy Zones sont le côté application de la même pièce, transformant un flux de renseignement de domaines connus malveillants en NXDOMAIN ou en sinkhole au moment de la résolution:

response-policy { zone "rpz.local"; };
// dans rpz.local :  malware.example.  CNAME .    (force un NXDOMAIN)

Sur le transport chiffré

DoT et DoH chiffrent le saut client-résolveur, ce qui est un gain réel contre l’écoute et l’altération en chemin et une complication réelle pour une entreprise qui compte sur la vue du DNS pour le défendre. La tension est honnête: le même chiffrement qui empêche un FAI de lire vos résolutions empêche votre propre surveillance de les lire et DoH en particulier laisse un poste contourner entièrement le résolveur d’entreprise et parler à un public sur 443. La posture défendable est de faire tourner votre propre résolveur DoT/DoH, d’y pointer les clients et de bloquer le DNS sortant, en clair comme chiffré, vers tout le reste, de sorte que les requêtes soient protégées sur le fil et passent encore par le résolveur que vous voyez.

Où atterrir

Séparez l’autoritatif du récursif et ne laissez jamais l’un être l’autre. Ne récursez que pour vos propres réseaux pour ne pas être un amplificateur, limitez le débit du serveur autoritatif et restreignez les transferts de zone à des secondaires authentifiés par TSIG pour que votre inventaire reste privé. Signez vos zones avec DNSSEC et publiez le DS pour que les signatures veuillent dire quelque chose. Journalisez les requêtes sur le résolveur, parce que le tunneling est invisible sans les logs et évident avec et appliquez les domaines connus malveillants par RPZ. Chiffrez le saut client avec votre propre résolveur plutôt que de laisser les postes s’égarer vers du DoH public. Rien de tout cela n’est nouveau et tout cela reste défait sur plus de réseaux qu’on ne croit.

[edit: 2026] L’implémentation Ansible de tout ceci: le rôle unbound .