Mon blog

Pour la résilience de l'Internet, sa capacité à survivre aux pannes et aux attaques, il est essentiel qu'il existe un certain pluralisme ; que, pour la plupart des fonctions importantes, il existe plusieurs logiciels. Ainsi, si tous les routeurs de l'Internet étaient des Cisco, une bogue dans le code d'IOS, comme celle de l'attribut BGP 99, pourrait arrêter tout l'Internet. Si tous les serveurs DNS étaient des BIND, une bogue comme celle permettant d'arrêter un serveur par une mise à jour dynamique, et le DNS s'arrête. Il faut donc qu'il y ait des alternatives, non pas qu'elles aient forcément moins de bogues, mais simplement parce qu'elles ne seront pas publiées au même moment.

Cela semble du bon sens mais, en pratique, on constate que la plupart des techniciens se simplifient la vie en n'utilisant qu'un seul logiciel, en général le plus répandu. C'est d'ailleurs un bon test des compétences d'un administrateur systèmes : demandez-lui pourquoi il utilise tel logiciel. S'il répond par une formule passe-partout comme « parce que c'est le standard de l'industrie », c'est probablement qu'il n'a même pas envisagé de décider lui-même, et qu'il n'a sans doute pas les compétences nécessaires pour évaluer les différents logiciels existants.

Ainsi, dans le contexte du DNS, la plupart des administrateurs système Unix qui installent un serveur DNS mettent BIND sans réflechir, non pas qu'ils aient étudié plusieurs serveurs et choisi celui-ci (BIND a des tas de qualités, notamment le record de la richesse fonctionnelle), mais simplement parce que l'idée du choix ne traverse même pas leur cerveau de certifié.

Pourquoi envisager NSD comme alternative ? C'est un logiciel pour serveur faisant autorité, c'est-à-dire le serveur qui distribue directement le contenu des zones (par opposition aux résolveurs qui relaient les requêtes du client final vers les serveurs faisant autorité). Il est utilisé par plusieurs gros TLD comme .FR ou .DE, ainsi que par la racine (à chaque fois, sur une partie seulement des serveurs, pour les raisons indiquées plus haut). NSD a fait le choix de ne pas en faire trop, afin de rester simple et rapide (tous les tests indiquent des performances deux à trois fois meilleures que celles de BIND). Le code source est donc logiquement plus court :

% sloccount nsd-3.2.5
...
Total Physical Source Lines of Code (SLOC)                = 25,542

% sloccount bind-9.7.3
...
Total Physical Source Lines of Code (SLOC)                = 317,497

Bien sûr que la comparaison est injuste, puisque BIND fait beaucoup plus de choses. Mais c'est justement l'un de mes arguments, plus le code est long (et BIND 9 ne permet pas d'exclure du code à la compilation) et plus il y sans doute de bogues et de failles de sécurité dedans.

Comment configure t-on NSD ? D'abord, un fichier de configuration, nsd.conf :

server:
     ip-address: 2001:db8:1::53
     # Toutes les valeurs peuvent avoir une configuration par défaut

...

# Une zone DNS, "bortzmeyer.42" :
zone:
        name: "bortzmeyer.42"
        zonefile: "primary/bortzmeyer.42"
        notify: 2001:db8:43c::1 NOKEY
        provide-xfr: 2001:db8:43c::1 NOKEY
        outgoing-interface: 2001:db8:1::53

Ici, on indique à NSD qu'il est serveur maître pour bortzmeyer.42 et qu'il est donc la source authentique des données. Celles-ci seront trouvées dans le fichier primary/bortzmeyer.42, qui suit la syntaxe standard du RFC 1035, section 5 (la même syntaxe que BIND). Ce serveur a un esclave, 2001:db8:43c::1 et on notifiera cet esclave en cas de mise à jour de la zone (RFC 1996), tout en l'autorisant à transférer la zone depuis chez nous (RFC 5936).

Pour atteindre ses performances élevées, NSD calcule beaucoup de choses à l'avance (ce qui augmente sa consommation mémoire : on n'a rien sans rien). Même si les versions actuelles de NSD sont moins radicales que la version 1 (qui stockait en mêmoire les paquets correspondant à n'importe quelle question possible, il n'y avait plus qu'à en choisir une et à faire un write()), NSD repose beaucoup sur ces pré-calculs. Il est donc nécessaire de compiler la zone d'abord :

% sudo nsdc rebuild
zonec: reading zone "bortzmeyer.42".
zonec: processed 8 RRs in "bortzmeyer.42".
zonec: done with 0 errors.

Le résultat est stocké sur disque (l'endroit dépend des options, disons /var/lib/nsd/nsd.db) et il faut dire à NSD de le recharger :

% sudo nsdc reload

Et voilà, NSD commence à servir la zone.

Si le serveur NSD est un esclave, on doit indiquer quel est le maître avec la directive request-xfr :

request-xfr: AXFR 2001:db8:1::53 NOKEY
allow-notify: 2001:db8:1::53  NOKEY

Il est prudent de forcer l'adresse IP utilisée pour les requêtes sortantes, pour que les demandes de transfert viennent bien de l'adresse qu'attend le maître :

# À mettre pour chaque zone:
outgoing-interface: 2001:db8:43c::1

Une fois le transfert de la zone fait (NSD enregistrera dans le journal quelque chose comme nsd[27250]: info: Zone bortzmeyer.42 serial 0 is updated to 2011050800), NSD modifiera sa base des réponses automatiquement. Notez que NSD, dans sa version 3, peut utiliser les transferts incrémentaux (IXFR, RFC 1995) lorsqu'il est esclave, mais ne peut pas les générer lorsqu'il est maître. Dans ce cas, il faut transférer la zone entière.

On le voit, il est fréquent qu'il y ait des répétitions dans la configuration de NSD. Par exemple, si on est esclave et qu'on sert dix zones ayant toutes le même maître, on va faire beaucoup de copier/coller. Fidèle au principe de ne pas multiplier le code, NSD ne fournit pas de mécanisme de macros. Le mieux est d'utiliser un système externe comme cpp.

Si on compile NSD soi-même, un certain nombre d'options passées à ./configure permettent de retirer complètement du code qu'on n'utilise pas, ce qui est probablement une bonne chose pour la sécurité. Faites un ./configure --help pour voir ces options.

La version 4 de NSD est actuellement en cours de développement. Vous pouvez en savoir plus avec l'exposé fait au RIPE 62. Sinon, il existe un bon article en français sur NSD.

Et, en guise de conclusion, une devise pour l'administrateur systèmes, « Nous vous rappelons qu'il existe d'autres possibilités. »