Bind

Le service de nom : DNS
Bind

Pourquoi Bind et pas un autre ? Parce que !

Bind (Berkeley Internet Name Daemon) est TRES largement utilisé de par le monde, très stable et installé par défaut sous Open. D'autres serveurs DNS existent aussi dans les ports; citons en bref : maraDNS.
Très utilisé et très stable : F.root-servers.net est un des 13 serveurs racine de l'Internet il répond à près de 300 millions de requetes par jour ! Très stable , hein !! Evidemment, il n'est pas récursif. (bon, en fait il est seulement constitué de 2 machines de 4 processeurs Alpha et 8 Go de RAM chacune....une paille ! ) Si vous vouliez monter un petit quatorzième serveur racine, regardez les prérequis.

Quelle version ?
Ce numéro ne représente pas l'évolution classique.

Bind 8 a la plus grande base installée, beaucoup de fonctionnalités, et donc mauvaise réputation en terme de sécurité. On n'en parlera pas ici.

Jusqu'à OpenBSD 3.2, Bind 4 était inclus dans le système installé par défaut et avait donc subi l'audit de sécurité de l'équipe OpenBSD.
Depuis OpenBSD 3.3, c'est Bind 9, qui l'a remplacé; il est désormais installé par défaut, et non plus dans les ports, comme avant. Il a donc subi 'audit de sécurité.
Bind 9 a été complètement réécrit pour le sécuriser au maximum; c'est lui qui apporte le plus de fonctionnalités. Parlons en :
- Bind 9 gère le DNS sécurisé (DNSSEC) dans lequel, les serveurs s'authentifient mutuellement par des échanges de clés.
- Bind 9 est pret pour IPV6.
- La version de Bind 9 fournie par l'équipe d'OPenBSD est quasiment immédiatement utilisable. Vous utilisez le modèle qui vous convient et qques minutes plus tard, vous avez un DNS assez blindé.

Pour quoi faire ?

Nous allons monter ici un serveur DNS primaire faisant autorité sur une zone. Ce serveur fera aussi cache DNS; ça ne coute rien, ça permet d'économiser de la bande passante sur votre couteuse ligne WAN. Ce serveur sera récursif pour vos machines, mais pas pour les machines de l'Internet, à cause des dangers d'attaque que cela représente.

Vocabulaire :

itératif / récursif : Lorsqu'il est interrogé par un client pour une requete sur une zone sur laquelle il ne fait autorité, le serveur DNS peut avoir deux comportements :
En mode itératif, le serveur renvoie au client l'adresse du serveur DNS faisant autorité; le client refait sa requete à ce serveur. C'est le mode le plus sur pour une serveur DNS public.
En mode récursif, le serveur fait lui-meme la requete au DNS faisant autorité et renvoie le résultat au client qui n'a pas eu à contacter le DNS autoritaire. (Susceptible de subir le DNS cache poisonning)

autoritaire : Un serveur fait autorité sur un domaine lorsqu'il en possède les informations complètes soit car il est le serveur primaire de la zone, soit le secondaire.

primaire : C'est celui à partir duquel toutes les informations sont obtenues. Il lit ces informations dans un fichier. Il fait autorité sur la zone.

secondaire : Il possède une copie du fichier de zone du serveur primaire qu'il obtient régulièrement par un transfert de zone. Il fait lui aussi autorité sur la zone et sert de secours, en cas d'indisponibilité ou d'encombrement réseau du primaire. On n'écrit aucune donnée directement sur le secondaire.

cache : Un serveur cache uniquement garde une copie de toutes les requetes effectuées auprès d'autres serveurs DNS. Il pourra répondre directement la prochaine fois. Tous les serveurs DNS font du cache. Un DNS cache-uniquement ne fait autorité sur aucune zone

SOA : Start of Authority : Autorité de la zone. Renseigne dans le fichier de zone, les informations suivantes : email du hostmaster, nomde la zone, fréquence de rafraichissement, numéro de série actuel du fichier de zone.

TLD : Top Level Domain : Domaine de plus haut niveau. Il s'agit de gérer la zone . et toutes ses sous-zones directes. (.fr, .us, .ca, .gov....)

L'arborescence :

/var/named/ +                                                     <-------Par défaut, bind est chrooté (mis en prison) ici
                        |__   /dev
                                 |____log                               Un lien symbolique
                        |__   /etc
                                 |____named-dual.conf     Récursif pour ses clients et itératif pour l'Internet. Pratique.
                                 |____named-simple.conf
                                 |____named.conf                Identique en tout point à named-simple (à la base)
                                 |____rndc.key                    Clé privée de chiffrement pour identifier votre serveur DNS si vous utilisez DNSSEC.
                        |__   /master                                   C'est ici que vous rangez vos fichiers de zone pour lesquelles vous avez un DNS primaire.
                        |__   /slave                                    C'est ici que vous rangez vos fichiers de zone pour lesquelles vous avez un DNS secondaire.
                        |__   /standard
                                 |____localhost                       Pour les résolutions en local
                                 |____loopback                       Pour les résolutions inverse en local
                                   |____loopback6.arpa            idem en IPV6
                                   |____loopback6.int             .
                                 |____root.hint                    La liste des 13 serveurs racines de l'Internet; ceux qui gèrent les TLD.

Réfléchissez à la destination de votre serveur. Selon qu'il sera public ou privé vous choisirez l'un ou l'autre des fichiers de configuration.

Démonstration :
Depuis l'Internet

host   ftp.openbsd-edu.net     Mon_DNS_coté_Internet
ftp.openbsd-edu.net             CNAME         hendrix.openbsd-edu.net
hendrix.openbsd-edu.net     A                     IP_publique_de_la_machine
Jusque là, tout est normal, le serveur fait autorité sur la zone.

host     www.google.fr           Mon_DNS_coté_Internet
Nameserver     Mon_DNS     not     responding
www.google.fr     A     record     not     found     at     Mon_DNS,     try     again.
Le serveur refuse d'etre récursif pour une machine de l'internet. Tant mieux.

Depuis l'Intranet

host   ftp.openbsd-edu.net     Mon_DNS(Quelle qu'en soit le coté..)
ftp.openbsd-edu.net         CNAME     hendrix.openbsd-edu.net
hendrix.openbsd-edu.net     A   IP_publique_de_la_machine
Jusque là, tout est normal, le serveur fait autorité sur la zone.

host     www.google.fr           Mon_DNS_coté_Internet
www.google.fr         CNAME     www.google.com
www.google.com     A                 216.239.39.99
Le serveur est récursif pour une machine de l'intranet.

Les fichiers : Attention, le commentaire est le point-virgule; , pas le dièse # !! C'est un truc à vous faire tourner en bourrique !

Le fichier de configuration:

/var/named/etc/named-simple.conf
acl clients{localnets; ::1;}                                            Définit le réseau local (connecté à une patte) comme des clients (sous entendu; ceux pour qui on sera récursif) et l'adresse locale IPV6 (::1)
options {version"";                                                        Evidemment, on va éviter de donner la version de Bind à tous ceux qui la demandent.
                listen-on {any;};listen-on-v6 {any;};         On écoute depuis toute adresse cliente en IPV4 et en IPV6
                allow-recursion {clients;};                            On n'autorise que les clients précedemment définis à utiliser le serveur de manière récursive.
}

logging {category-lame-servers {null;};}; Un lame-server est un serveur censé faire autorité sur une zone et qui n'en connait rien, en réalité. Il est à la rue et vous mettra le bazar dans vos logs,sinon. "some people never learn, and we don't want to know about them"comme y disent chez OpenBSD...

Puis viennent les zones standards pour lesquelles vous ne devriez rien avoir à changer. Puis viennent vos zones DNS :
// Master zones

zone "openbsd-edu.net" {                                                Nom de la zone DNS
            type master;                                                        Vous etes le DNS primaire
            file "master/etc/openbsd-edu"; }                       Localisation du fichier de zone

Idem, si vous avez une zone DNS secondaire avec la partie slave.

Le fichier de zone : Une bonne nouvelle : Il a exactement le meme format que sous Bind 4.9; pratique quand vous migrez.

Exemple de fichier de zone : openbsd-edu      Attention n'oubliez pas les points terminaux !!! Documentation
@ IN SOA ns.openbsd-edu.net. openbsd-edu. (
2003010901 Numéro du fichier de zone. Doit etre incrémenté à chaque modification pour que les autres serveurs DNS tiennent compte de la modification. Noté sous la forme : Année/4 chiffres Mois/2 Jour/2 Modification de la journée/2
10800
3600
604800
86400 )
IN             NS                ns.openbsd-edu.net .                         N'oubliez pas le point final, il donne le nom absolu de la machine.
IN             MX     10     smtp.openbsd-edu.net.                       ,sinon, celui-ci sera concaténé au nom de domaine.
localhost    IN A            127.0.0.1
hendrix      IN A             Mon_IP
ns             CNAME        hendrix
smtp         CNAME        hendrix

Par défaut, named va se mettre en prison dans /var/named, en tant qu'utilisateur named puis lire le fichier de config /etc/named.conf.
Attention ! Le fichier réel est /var/named/etc/named.conf, mais la prison commençant en /var/named, il faut donner le nouveau nom correspondant à la racine fictive d'où le /etc/named.conf (Merci Daniel Hartmeier)

chmod og+w /var/run

N'oubliez pas d'ouvrir le port UDP/53 en UDP sur le Firewall et TCP/53 si vous voulez permettre les transferts de zone entre le serveur primaire et les secondaires. (Ils ne doivents pas etre sur le meme réseau, donc au moins un secondaire devrait etre à l'extérieur du firewall). TCP/53 aussi pour les «longues » réponses qui ne tiennent pas dans les trames UDP dont la taille maximum est de 512 octets. Personnellement, j'utilise le service DNS secondaire de Gandi

N'oubliez pas de créer un alias de messagerie hostmaster sur votre DNS.

Explications:
Si une machine sert de serveur de messagerie, au sens DNS du terme, (SMTP = hendrix ici )elle sera définie par un enregistrement MX dans cette zone DNS.
Exemple : Pour le domaine DNS openbsd-edu.net, le fichier de zone du serveur DNS faisant autorité contiendra une ligne du type :
IN MX 10 hendrix
Ce qui signifie que le serveur SMTP sera un serveur de messagerie de poids 10 pour le domaine openbsd-edu.net. Ajoutez autant de lignes de ce type que vous avez de serveurs SMTP. Le poids correspond à la priorité du serveur; plus il est bas, plus le serveur est prioritaire pour le traitement des messages.
Le problème est que lorsque vous envoyez un message à user@openbsd-edu.net, il sera adressé à la machine de MX le plus faible, ie, SMTP.openbsd-edu.net. Or, la machine SMTP est incapable de savoir qu'elle représente, pour le domaine, le serveur de messagerie. Ainsi, pour que les messages arrivent, il faudrait les envoyer en fait à user@SMTP.openbsd-edu.net; pas pratique!
Pour corriger ce problème, vous devez créer un fichier dans lequel vous mettez les domaines pour lesquels la machine est censée jouer le rôle de serveur de messagerie ; /etc/mail/local-host-names.

Lancer le démon
Automatiquement dans /etc/rc.conf :
Modifier named_flags=NO en named_flags="-c /etc/named-simple.conf -u named -t /var/named"
Ce qui signifie
Lancer Bind en utilisant ce fichier de config en perdant ses privilèges de root vers l'utilisateur named en se mettant en prison dans /var/named

NB : En effet, sous Unix, pour "binder" s'accrocher à un port <1024, il faut etre root (c'est comme ça!) quite à perdre ensuite ses privilèges devenus inutiles.

Gérer le démon

Le port TCP 127.0.0.1 :953 est le port de communication de rndc, l'interface de controle du démon bind.rndc reload                Relit les fichiers de config et de zone
rndc restart                Relance le démon
rndc status                Donne l'état du serveur

number of zones: 6
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is up and running

Un petit script à mettre dans /bin pour gérer le démon. bin start/stop/reload/restart

Tester la configuration
named-checkconf /var/named/etc/named-simple.conf Tester la validité du fichier de configuration
named-checkzone openbsd-edu.net /var/named/master/openbsd-edu Tester la validité du fichier de configuration
Si vous voulez tester la validité de votre configuration plus en profondeur : zonecheck

Attention en ADSL :
Si vous mettez dans /etc/rc.conf le lancement de Bind, vous aurez ce type de message d'erreur :
named [PiD]: could not listen on UDP socket: permission denied
et plus instructif :
named[PiD] : creating IPv4 interface tun0 failed; interface ignored

Et vous constatez par un netstat -na, qu'effectivement, Bind, n'écoute pas sur tun0 (interface tunnel virtuelle de communication en ADSL), ce qui n'est pas sans poser de réels soucis. (Au hasard : des dysfonctionnements de messagerie, un passage en blacklist pour cause de domaine inconnu).
En fait, rc.conf est lancé avant rc.local, et c'est normal, sauf que rc.conf lance Bind qui tente de se lier (binder..) à une interface qui n'existe pas encore (tun0) puisqu'elle sera créée lors de l'exécution de rc.local lequel lancera /etc/ppp/ppp.linkup.
Solution :
Lancez Bind après avoir créé l'interface tun0, et donc modifier les lignes suivantes :

/etc/rc.conf :
named_flags="-c /etc/named-dual.conf -u named -t /var/named"
en
named_flags=NO

/etc/ppp/ppp.linkup
Ajoutez :
!bg sh -c "named -c /etc/named-dual.conf -u named -t /var/named"