BIND : le DNS qui tient la moitié d'Internet debout

BIND veut dire Berkeley Internet Name Domain. C'est une implémentation du Domain Name System, écrite à l'origine à l'University of California, Berkeley, et maintenue aujourd'hui par l'Internet Systems Consortium. Le paquet fait partie de ces logiciels qu'on ne voit jamais et dont tout dépend.

Le mot « bind » a un autre sens en anglais courant : lier, attacher. Ici, il n'est pas question de ça. Sur Pixzo, quand on parle de bind, on parle du serveur de noms. Pas d'une action, pas d'une commande shell générique. Un démon qui traduit des noms en adresses et inversement.

Deux rôles dans un seul démon

BIND peut tourner en mode autoritatif ou en mode récursif. Les deux ne font pas le même métier.

En autoritatif, il détient la vérité sur une ou plusieurs zones. On lui demande l'adresse de `mail.exemple.be`, il répond, point. Il ne va rien chercher ailleurs : c'est lui la source.

En récursif, il fait le travail inverse. Un client lui pose une question sur un domaine qu'il ne gère pas, et il part interroger les serveurs racine, puis le TLD, puis le serveur autoritatif du domaine, jusqu'à ramener la réponse. Il la met en cache pour la prochaine fois.

Cette dualité est ce qui rend BIND utilisable partout, d'un petit réseau local jusqu'aux résolveurs d'un fournisseur d'accès. C'est aussi ce qui fait qu'une mauvaise configuration peut transformer ton serveur en amplificateur pour attaques par réflexion DNS.

Un résolveur récursif ouvert à tout Internet, c'est une porte grande ouverte. Personne ne le remarque jusqu'au jour où ton uplink sature.

La configuration, là où tout se joue

Le fichier central s'appelle `named.conf`. Il décrit quelles zones le serveur gère, quels clients ont le droit de poser quelles questions, et comment la communication est sécurisée.

À côté, il y a les fichiers de zone. Ce sont eux qui contiennent les données réelles : les enregistrements A pour l'IPv4, AAAA pour l'IPv6, MX pour le routage du courrier, CNAME pour les alias, et une bonne dizaine d'autres types selon les besoins.

Tu peux écrire ces fichiers à la main. Tu peux aussi les générer. La différence se paie le jour où un enregistrement est mal formé et que la zone refuse de charger.

BIND est strict. Un point manquant en fin de nom, un `$TTL` oublié, et `named-checkzone` te le dira avant que le serveur ne tombe. C'est une bonne chose, à condition de lancer la vérification avant le rechargement.

DNSSEC, ou pourquoi signer ses réponses

DNSSEC ajoute des signatures cryptographiques aux réponses DNS. Le client peut alors vérifier que l'information vient bien de la source annoncée et qu'elle n'a pas été modifiée en route.

Sans ça, un attaquant qui intercepte une requête peut renvoyer une fausse adresse. L'utilisateur tape le bon nom de domaine et atterrit sur un site qui n'est pas le bon. C'est le cache poisoning, et ça a causé quelques dégâts célèbres.

Activer DNSSEC demande de gérer des clés, de les faire tourner, de publier les enregistrements DS chez le registraire. Ce n'est pas gratuit en temps. Mais si tu héberges des zones pour d'autres, c'est devenu la norme minimale.

Le démon, le port, et les outils autour

BIND tourne comme démon sous le nom `named`. Il écoute sur le port 53, en UDP et en TCP. UDP pour les requêtes ordinaires, parce que la latence compte. TCP quand la réponse dépasse ce qu'un paquet UDP peut porter, ou pour les transferts de zone entre serveur primaire et secondaire.

Pour piloter `named` sans le redémarrer, il y a `rndc`, Remote Name Daemon Control. Il se connecte en TCP et authentifie ses commandes par signature numérique. Les clés vivent dans `rndc.conf` et `rndc.key`. Sans ces fichiers, `rndc` ne peut rien faire.

Ce que `rndc` permet : recharger une zone, demander des statistiques, arrêter proprement le serveur. Redémarrer `named` à chaque modification de zone est un réflexe de débutant. `rndc reload` fait le travail sans couper le service pour tout le monde.

Pour tester ce que le serveur répond, `dig` reste l'outil de référence. `mdig` en est une variante pipelinée : il envoie plusieurs requêtes en parallèle et affiche les réponses dans l'ordre d'arrivée. Utile pour repérer des latences ou des incohérences quand tu débogues une zone.

Il existe aussi `ldns-testns`, un faux serveur de noms pour les tests. Il renvoie des réponses préprogrammées, y compris invalides. Ça ne sert à rien en production, mais pour vérifier comment un client réagit à des données corrompues, c'est pratique.

Et puis il y a `/etc/hosts`. Ce fichier contient des correspondances statiques entre adresses IP et noms. C'est un DNS local, hors ligne, consulté avant toute requête réseau sur la plupart des systèmes. BIND ne le remplace pas, il vit à côté.

Ce que ça coûte de faire tout soi-même

BIND est disponible dans les dépôts de toutes les distributions sérieuses. Sur Debian et Ubuntu, `apt install bind9`. Sur RHEL et CentOS, `yum install bind`. Le service se gère ensuite avec `systemctl`, comme n'importe quel démon systemd.

L'installation prend deux minutes. La configuration qui tient la route prend plus longtemps.

Il faut penser aux vues, qui permettent de renvoyer des réponses différentes selon l'origine de la requête. Aux transferts de zone, pour que le secondaire reste synchronisé avec le primaire. Aux mises à jour dynamiques, quand un serveur DHCP doit enregistrer ses clients automatiquement. À la limitation de fréquence des requêtes, pour ne pas servir d'amplificateur. Au logging, pour pouvoir reconstituer ce qui s'est passé quand quelque chose casse.

Chaque fonctionnalité ajoute des lignes dans `named.conf` et des façons de se tromper. C'est le prix de la flexibilité.

L'alternative que personne n'aime admettre

Tu peux aussi ne pas gérer de DNS du tout.

Les grands fournisseurs cloud proposent des zones hébergées, avec une interface web, une API, et une facturation à la requête. Tu perds le contrôle fin, tu dépends d'eux, et si leur console tombe, tu regardes. Mais tu ne gères ni les clés DNSSEC à la main, ni les transferts de zone, ni les mises à jour de sécurité de `named` le dimanche soir.

Pour beaucoup d'équipes, c'est le bon compromis. Pour d'autres, héberger soi-même est une obligation réglementaire ou une question de souveraineté.

BIND reste la référence parce qu'il fait tout, qu'il est documenté jusqu'à l'os, et qu'il tourne depuis assez longtemps pour qu'on connaisse ses pièges. Ce n'est pas parce qu'il est simple. C'est parce qu'il est prévisible.

Faire tourner un résolveur récursif chez soi, c'est instructif pendant une semaine. La semaine suivante, tu découvres que la moitié d'Internet te scanne.

Où se situe la vraie question

Le choix ne se joue pas entre BIND et autre chose. Il se joue entre gérer ton DNS et le déléguer.

Si tu as quelqu'un qui comprend les zones, les clés et les logs, BIND te donnera tout ce dont tu as besoin, y compris ce que les interfaces simplifiées cachent. Si tu n'as personne pour surveiller ça, une zone hébergée chez un tiers fera le travail, avec moins de contrôle et moins de surprises à trois heures du matin.

Entre les deux, il y a `dnsmasq` pour les petits réseaux, `Knot DNS` et `PowerDNS` pour ceux qui veulent autre chose que BIND sans changer de métier. Aucun n'est meilleur dans l'absolu. Tout dépend de qui répond quand la zone ne charge plus.