Des collègues se plaignent que les modifications qu'ils effectuent dans notre IPAM (interface web de gestion des adresses IP et de la conf' DHCP et DNS ‒ quelle IP est utilisée ? À qui est-elle attribuée ? Dans quel VLAN ? Etc. ‒) maison ne deviennent pas effectifs dans le DNS. Un collègue diagnostique l'usage d'un underscore dans le nom d'une machine, caractère qui serait invalide dans le DNS et bloquerait nos serveurs de noms BIND.
Je tique. À l'école Bortzmeyer, on a appris que le DNS impose une seule limitation concernant les noms, c'est leur taille. De plus, de nos jours, l'underscore est utilisé dans plein de noms DNS. DKIM (signature électronique de l'entête des emails afin d'authentifier le domaine d'émission), DANE TLSA (réparer l'énorme faille conceptuelle des certificats x509 utilisés pour authentifier les parties d'un échange chiffré ‒ TLS, par exemple ‒, voir un exemple d'utilisation ici). Jabber (protocole de messagerie instantanée textuelle libre et fédéré). Tous utilisent l'underscore, et ça se passe très bien.
Je regarde le journal de notre serveur DNS (BIND) : « nom-de-machine_a_suppr.mon-organisation.example: bad owner name (check-names) ». C'est donc vrai. Whaaat ?! :O Il y a donc une contradiction entre la théorie et la pratique.
Un essai me montre que, sur un BIND récent (9.10, packagé dans Debian Stretch), on peut ajouter un nom contenant un underscore si son type est SRV ou TXT, mais pas si son type est A ou AAAA. Cela met en exergue un comportement qui va au-delà de la norme, qui est sans doute spécifique à une implémentation.
L'école Bortzmeyer nous a aussi appris qu'il y a une différence entre un nom de machine et un nom de domaine et que les caractères autorisés pour un nom de machine sont beaucoup plus restreints que pour un nom de domaine. Mais… ça ne change rien, BIND manipule bien un nom de domaine, donc il devrait autoriser l'underscore, qui est un caractère valide pour un nom de domaine (mais pas pour un nom de machine).
Il devrait, oui, mais, par défaut, BIND vérifie que les noms associés à un type A ou AAAA respectent la syntaxe d'un nom de machine. L'idée est de dire que, 99 % du temps, l'administrateur voudra associer une IP à un nom de machine, car ce nom sera manipulé par des programmes qui manipulent des noms de machines et l'admin voudra que ça fonctionne. On peut débrayer ce comportement avec les directives de configurations « check-names ».
Un essai avec nsd 4, autre implémentation d'un serveur DNS qui fait autorité, montre aucun problème : il est parfaitement possible d'associer un nom de domaine avec un underscore à une adresse IP.
Si l'on résume : un nom de domaine a bien aucune limite concernant les caractères qui le composent, mais une implémentation de serveur DNS comme une autre, BIND, a fait le choix de bloquer les noms DNS qui ne respectent pas la syntaxe d'un nom de machine (lettres + chiffres + tiret) quand ils sont associés à un type A ou AAAA ou MX. D'après la doc', BIND vérifie également la syntaxe de la valeur d'un nom de domaine (le RDATA) pour les types SOA, NS, MX, SRV et PTR.
Un autre point m'échappe. Avant de pousser en production le fichier de zone généré par notre IPAM, nous utilisons un script de contrôle maison qui se repose, entre autres, sur named-checkzone
. Il s'agit d'un outil livré avec BIND. Pourquoi a-t-il rien détecté ?
Le contrôle de la syntaxe des noms a été introduit dans la version 9.2 de BIND 9, mais il n'est pas activé par défaut. Sur les serveurs DNS maîtres, il est activé par défaut depuis la version 9.3.
named-checkzone
vérifie la syntaxe des noms à partir de la version 9.3 de BIND 9, mais il se contente d'émettre un avertissement. C'est toujours le cas dans la dernière version stable (9.14).
Donc, forcément… Vu qu'il écrit tout sur stdout, si named-checkzone
ne sort pas en erreur, notre script considère que tout est OK et met le fichier de zone en production. Tout s'explique.
Solutions ? Soit débrayer le contrôle de la syntaxe des noms dans la conf' de BIND, soit forcer named-checkzone
à sortir en erreur si le contrôle de la syntaxe des noms échoue en utilisant son option -k fail
, soit utiliser une autre implémentation de serveur DNS (BIND veut assurer les deux grands services distincts du DNS ‒ serveur qui fait autorité et serveur récursif ‒ + il veut implémenter toutes les fonctionnalités à la mode + il est monolithique = il est plus difficile à sécuriser).
Pour moi, ce contrôle de la syntaxe des noms de domaine est illégitime en cela qu'il n'est pas conforme à la norme, même s'il évite des prises de tête aux administrateurs (mais il en donne à d'autres, comme moi…).
C'est dans ce genre de moments que je me réjouis d'avoir une monoculture de serveurs DNS (d'utiliser que du BIND au sein d'une même architecture) : si l'on avait eu une diversité de serveurs de noms, certains auraient accepté le fichier de zones et d'autres non, ce qui aurait causé quelques instabilités sur le réseau et aurait rendu la mise en exergue du problème compliquée (le diagnostic n'aurait pas changé : un coup de check-soa, on aurait vu un numéro de série différent, on aurait analysé les journaux, etc.).