23.6. Serveurs de noms (DNS)

23.6.1. Généralités

FreeBSD utilise, par défaut, BIND (Berkeley Internet Name Domain), qui est l'implémentation la plus courante du protocole DNS. Le DNS est le protocole qui effectue la correspondance entre noms et adresses IP, et inversement. Par exemple une requête pour www.FreeBSD.org aura pour réponse l'adresse IP du serveur Web du projet FreeBSD, et une requête pour ftp.FreeBSD.org renverra l'adresse IP de la machine FTP correspondante. De même, l'opposé est possible. Une requête pour une adresse IP retourne son nom de machine. Il n'est pas nécessaire de faire tourner un serveur DNS pour effectuer des requêtes DNS sur un système.

Le DNS est coordonné sur l'Internet à travers un système complexe de serveurs de noms racines faisant autorité, et d'autres serveurs de noms de plus petites tailles qui hébergent, directement ou font office de ``cache'', l'information pour des domaines individuels.

Ce document fait référence à BIND 8.x, comme c'est la version stable utilsée dand FreeBSD. BIND 9.x peut être installée à l'aide du logiciel porté net/bind9.

Les RFC1034 et RFC1035 régissent le protocole DNS.

Actuellement, BIND est maintenu par l'Internet Software Consortium http://www.isc.org/.

23.6.2. Terminologie

Pour comprendre ce document, certains termes relatifs au DNS doivent être maîtrisés.

Exemples de zones:

• . est la zone racine

• org. est une zone sous la zone racine

• example.org. est une zone sous la zone org.

• foo.example.org. est un sous-domaine, une zone sous la zone example.org.

• 1.2.3.in-addr.arpa est une zone faisant référence à toutes les adresses IP qui appartiennent l'espace d'adresse 3.2.1.*.

Comme on peut le remarquer, la partie la plus significative d'un nom de machine est à sa gauche. Par exemple, example.org. est plus spécifique que org., comme org. est à son tour plus spécifique que la zone racine. La constitution de chaque partie d'un nom de machine est proche de celle d'un système de fichiers: le répertoire /dev se trouve sous la racine, et ainsi de suite.

23.6.3. Les raisons de faire tourner un serveur de noms

Les serveurs de noms se présentent généralement sous deux formes: un serveur de noms faisant autorité, et un serveur de noms cache.

Un serveur de noms faisant autorité est nécessaire quand:

• on désire fournir des informations DNS au reste du monde, être le serveur faisant autorité lors des réponses aux requêtes.

• un domaine, comme par exemple example.org, est enregistré et des adresses IP doivent être assignées à des noms de machine appartenant à ce domaine.

• un bloc d'adresses IP nécessite des entrées DNS inverses (IP vers nom de machine).

• un serveur de noms de secours, appelé esclave, doit répondre aux requêtes quand le serveur primaire est tombé ou inaccessible.

Un serveur de noms cache est nécessaire quand:

• un serveur de noms local peut faire office de cache et répondre plus rapidement que l'interrogation d'un serveur de noms extérieur.

• une réduction du trafic réseau global est désirée (il a été mesuré que 5% ou plus du trafic Internet total concerne le trafic DNS).

Quand on émet des requêtes pour www.FreeBSD.org, le résolveur interroge généralement le serveur de noms du fournisseur d'accès, et récupère la réponse. Avec un serveur DNS cache local, la requête doit être effectuée qu'une seule fois vers le monde extérieur par le serveur DNS cache. Chaque interrogation suivante n'aura pas à être transmise en dehors du réseau local, puisque l'information est désormais disponible localement dans le cache.

23.6.4. Comment cela fonctionne-t-il?

Sous FreeBSD le ``daemon'' BIND est appelé named pour des raisons évidentes.

Les fichiers de zone sont généralement stockés dans le répertoire /etc/namedb, et contiennent les informations concernant les zones DNS gérées par le serveur de noms.

23.6.5. Lancer BIND

Puisque BIND est installé par défaut, sa configuration est relativement simple.

Pour s'assurer que le ``daemon'' named est lancé au démarrage, ajoutez la ligne suivante dans /etc/rc.conf:

named_enable="YES"

Pour démarrer le ``daemon'' manuellement (après l'avoir configuré):

# ndc start

23.6.6. Fichiers de configuration

# cd /etc/namedb
# sh make-localhost

// $FreeBSD$
//
// Reportez-vous à la page de manuel named(8) pour plus de
// détails.  Si vous devez configurer un serveur primaire
// assurez-vous d'avoir compris les détails épineux du
// fonctionnement du DNS.  Même avec de simples erreurs, vous
// pouvez rompre la connexion entre les parties affectées, ou
// causer un important trafic Internet inutile.

options {
        directory "/etc/namedb";

// En plus de la clause "forwarders", vous pouvez forcer votre serveur
// de noms à ne jamais être à l'origine de
// requêtes, mais plutôt faire suivre les demandes en
// activant la ligne suivante:
//
//      forward only;

// Si vous avez accès à un serveur de noms au niveau de
// votre fournisseur d'accès, ajoutez ici son adresse IP, et
// activez la ligne ci-dessous.  Cela vous permettra de
// bénéficier de son cache, réduisant ainsi le
// trafic Internet.
/*
        forwarders {
                127.0.0.1;
        };
*/

        /*
         * S'il y a un coupe-feu entre vous et les serveurs de noms
         * avec lesquels vous voulez communiquer, vous aurez
         * peut-être besoin de décommenter la directive
         * query-source ci-dessous.  Les versions
         * précédentes de BIND lançaient des
         * requêtes à partir du port 53, mais depuis la
         * version 8.1, BIND utilise
         * par défaut un port quelconque non
         * réservé.
         */
        // query-source address * port 53;

        /*
         * Si exécution dans un "sandbox", vous pourrez avoir
         * à indiquer un emplacement différent pour le
         * fichier de sortie de la base de données.
         */
        // dump-file "s/named_dump.db";
};

// Note: ce qui suit sera supporté dans une future version.
/*
host { any; } {
        topology {
                127.0.0.0/8;
        };
};
*/

// Configurer des serveurs secondaires est plus simple et le principe
// général est présenté plus bas.
//
// Si vous activez un serveur de noms local, n'oubliez pas d'entrer
// 127.0.0.1 dans votre fichier /etc/resolv.conf de sorte que ce
// serveur soit interrogé le premier.  Assurez-vous
// également de l'activer dans /etc/rc.conf.

zone "." {
        type hint;
        file "named.root";
};

zone "0.0.127.IN-ADDR.ARPA" {
        type master;
        file "localhost.rev";
};

zone
"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" {
        type master;
        file "localhost.rev";
};

// NB: N'utilisez pas les adresses IP ci-dessous, elles sont factices,
// et ne servent que pour des besoins de
// démonstration/documentation!
//
// Exemple d'entrées de configuration de serveur secondaire.
// Il peut être pratique de devenir serveur secondaire pour la
// zone à laquelle appartient votre domaine.  Demandez à
// votre administrateur réseau l'adresse IP du serveur primaire
// responsable de la zone.
//
// N'oubliez jamais d'inclure la résolution de la zone inverse
// (IN-ADDR.ARPA)!
// (Ce sont les premiers octets de l'adresse IP, en ordre inverse,
// auxquels ont a ajouté ".IN-ADDR.ARPA".)
//
// Avant de commencer à configurer une zone primaire, il faut
// être sûr que vous avez parfaitement compris comment le
// DNS et BIND fonctionnent.  Il apparait parfois des pièges
// peu évidents à saisir.  En comparaison, configurer un
// serveur secondaire est plus simple.
//
// NB: N'activez pas aveuglément les exemples ci-dessous. :-)
// Utilisez des noms et des adresses réelles.
//
// NOTE!!! FreeBSD exécute BIND dans un "sandbox" (voir l'option
// named_flags dans rc.conf).  Le répertoire contenant les
// zones secondaires doit être accessible à BIND en
// écriture.  La séquence suivante est
// suggérée:
//
//      mkdir /etc/namedb/s
//      chown bind:bind /etc/namedb/s
//      chmod 750 /etc/namedb/s

/*
zone "example.com" {
        type slave;
        file "s/example.com.bak";
        masters {
                192.168.1.1;
        };
};

zone "0.168.192.in-addr.arpa" {
        type slave;
        file "s/0.168.192.in-addr.arpa.bak";
        masters {
                192.168.1.1;
        };
};
*/

zone "example.org" {
    type master;
    file "example.org";
};

zone "example.org" {
    type slave;
    file "example.org";
};

$TTL 3600

example.org. IN SOA ns1.example.org. admin.example.org. (
                        5               ; Serial
                        10800           ; Refresh
                        3600            ; Retry
                        604800          ; Expire
                        86400 )         ; Minimum TTL

; Serveurs DNS
@       IN NS           ns1.example.org.
@       IN NS           ns2.example.org.

; Noms de machine
localhost       IN A    127.0.0.1
ns1             IN A    3.2.1.2
ns2             IN A    3.2.1.3
mail            IN A    3.2.1.10
@               IN A    3.2.1.30

; Alias
www             IN CNAME        @

; Enregistrement MX
@               IN MX   10      mail.example.org.

nom-enregistrement      IN type-enregistrement   valeur

example.org. IN SOA ns1.example.org. admin.example.org. (
                        5               ; Serial
                        10800           ; Refresh after 3 hours
                        3600            ; Retry after 1 hour
                        604800          ; Expire after 1 week
                        86400 )         ; Minimum TTL of 1 day

@       IN NS           ns1.example.org.

localhost       IN A    127.0.0.1
ns1             IN A    3.2.1.2
ns2             IN A    3.2.1.3
mail            IN A    3.2.1.10
@               IN A    3.2.1.30

www             IN CNAME        @

@               IN MX   10      mail.example.org.

$TTL 3600

1.2.3.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. (
                        5               ; Serial
                        10800           ; Refresh
                        3600            ; Retry
                        604800          ; Expire
                        3600 )          ; Minimum

@       IN NS   ns1.example.org.
@       IN NS   ns2.example.org.

2       IN PTR  ns1.example.org.
3       IN PTR  ns2.example.org.
10      IN PTR  mail.example.org.
30      IN PTR  example.org.

23.6.7. Serveur de noms cache

Un serveur de noms cache est un serveur de noms qui ne fait autorité pour aucune zone. Il émet simplement des requêtes, et se souvient du résultat pour une utilisation ultérieure. Pour mettre en place un tel serveur, configurez le serveur de noms comme à l'accoutumé, en prenant bien soin de n'inclure aucune zone.

23.6.8. Exécution named dans un ``sandbox''

Pour plus de sécurité, il peut être préférable d'exécuter named(8) sous un utilisateur sans privilèges, et le configurer pour modifier l'emplacement de la racine du système de fichiers (chroot(8)) vers le répertoire du ``sandbox'' (bac à sable). Ceci rend inaccessible au ``daemon'' named tout ce qui est situé en dehors de l'environnement ``sandbox''. Si named est compromis, cela réduira l'impact des dommages. Par défaut, FreeBSD dispose d'un utilisateur et d'un groupe appelé bind, destiné à cet usage.

Puisque named ne sera pas en mesure d'avoir accès à des éléments extérieur au ``sandbox'' (comme aux bibliothèques partagées, aux ``sockets'' pour l'enregistrements des journaux, etc.), il y a un certain nombre d'étapes à suivre afin de permettre à named un fonctionnement correct. Dans la liste d'opérations qui suit, on suppose que l'emplacement du ``sandbox'' est /etc/namedb et que vous n'avez pas précédemment modifié le contenu de ce répertoire. Effectuez les étapes suivantes en tant que root:

• Créer tous les répertoires que named s'attend à trouver:

  # cd /etc/namedb
  # mkdir -p bin dev etc var/tmp var/run master slave
  # chown bind:bind slave var/*
  

  

  named n'a besoin uniquement que d'un accès en écriture à ces répertoires, c'est tout ce que nous lui donnerons.

• Réarranger les fichiers de configuration et créer la zone:

  # cp /etc/localtime etc
  # mv named.conf etc && ln -sf etc/named.conf
  # mv named.root master
  # sh make-localhost && mv localhost.rev localhost-v6.rev master
  # cat > master/named.localhost
  $ORIGIN localhost.
  $TTL 6h
  @   IN  SOA localhost. postmaster.localhost. (
              1   ; serial
              3600    ; refresh
              1800    ; retry
              604800  ; expiration
              3600 )  ; minimum
      IN  NS  localhost.
      IN  A       127.0.0.1
  ^D
  

  

  Ceci permet à named d'utiliser des dates correctes lors de l'envoie des journaux à syslogd(8).

• Si vous utilisez une version de FreeBSD antérieure à 4.9-RELEASE, compilez une version liée en statique de named-xfer, et copiez-la dans le ``sandbox'':

  # cd /usr/src/lib/libisc
  # make cleandir && make cleandir && make depend && make all
  # cd /usr/src/lib/libbind
  # make cleandir && make cleandir && make depend && make all
  # cd /usr/src/libexec/named-xfer
  # make cleandir && make cleandir && make depend && make NOSHARED=yes all
  # cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer
  

  Après avoir installé votre version statique de named-xfer, un peu de nettoyage est nécessaire pour éviter de conserver des copies inutiles de bibliotèques ou de programmes dans votre arborescence des sources:

  # cd /usr/src/lib/libisc
  # make cleandir
  # cd /usr/src/lib/libbind
  # make cleandir
  # cd /usr/src/libexec/named-xfer
  # make cleandir
  

  

  Il a été signalé que cette étape peut parfois échouer. Si cela vous arrive, tapez alors la commande:

  # cd /usr/src && make cleandir && make cleandir
  

  et effacez votre arborescence /usr/obj:

  # rm -fr /usr/obj && mkdir /usr/obj
  

  Cela devrait supprimer les éventuels ``scories'' de votre arborescence des sources, puis en réessayant les opérations ci-dessus cela devrait enfin fonctionner.

  Si vous utilisez FreeBSD 4.9-RELEASE ou une version suivante, alors la version de named-xfer se trouvant dans le répertoire /usr/libexec est liée en statique par défaut, et vous pouvez tout simplement utiliser la commande cp(1) pour la copier dans l'environnement ``sandbox''.

• Créer un fichier spécial de périphérique dev/null dans lequel named peut lire et écrire:

  # cd /etc/namedb/dev && mknod null c 2 2
  # chmod 666 null
  

• Créer un lien symbolique de /var/run/ndc vers /etc/namedb/var/run/ndc:

  # ln -sf /etc/namedb/var/run/ndc /var/run/ndc
  

  Note : Ceci évite tout simplement d'avoir à spécifier l'option -c à ndc(8) à chaque fois que vous l'exécutez. Comme le contenu du répertoire /var/run est effacé au démarrage, il peut être utile d'ajouter cette commande dans le fichier crontab(5) de l'utilisateur root en utilisant l'option @reboot.

• Configurer syslogd(8) pour qu'il créé une ``socket'' supplémentaire log sur laquelle named dispose d'un accès en écriture. Pour cela, ajoutez -l /etc/namedb/dev/log à la variable syslogd_flags du fichier /etc/rc.conf.

• S'arranger à ce que named démarre et se ``chroot'' lui-même dans l'environnement ``sandbox'' en ajoutant ce qui suit au fichier /etc/rc.conf:

  named_enable="YES"
  named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf"
  

  Note : Notez que l'emplacement du fichier de configuration /etc/named.conf est référencé par rapport un chemin complet relatif au ``sandbox'', i.e. dans la ligne au-dessus, le fichier auquel on fait référence est en fait /etc/namedb/etc/named.conf.

L'étape suivante est d'éditer le fichier /etc/namedb/etc/named.conf pour que named puisse savoir quelles zones charger et où les trouver sur le disque. Un exemple commenté suit (tout ce qui n'est pas spécifiquement commenté ici n'est pas différent de la configuration d'un serveur DNS ne tournant pas dans un ``sandbox''):

options {
        directory "/";
        named-xfer "/bin/named-xfer";
        version "";     // Ne pas révéler la version de BIND
        query-source address * port 53;
};
// socket de contrôle ndc
controls {
        unix "/var/run/ndc" perm 0600 owner 0 group 0;
};
// Les zones:
zone "localhost" IN {
        type master;
        file "master/named.localhost";
        allow-transfer { localhost; };
        notify no;
};
zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "master/localhost.rev";
        allow-transfer { localhost; };
        notify no;
};
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" {
    type master;
    file "master/localhost-v6.rev";
    allow-transfer { localhost; };
    notify no;
};
zone "." IN {
        type hint;
        file "master/named.root";
};
zone "private.example.net" in {
        type master;
        file "master/private.example.net.db";
    allow-transfer { 192.168.10.0/24; };
};
zone "10.168.192.in-addr.arpa" in {
        type slave;
        masters { 192.168.10.2; };
        file "slave/192.168.10.db";
};

Après avoir complétées les étapes précédentes, redémarrez votre serveur ou relancez syslogd(8) et démarrez named(8), en s'assurant de bien utiliser les nouvelles options spécifiées dans les variables syslogd_flags et named_flags. Vous devriez disposez maintenant d'une version de named tournant dans un environnement ``sandbox''!

23.6.9. Sécurité

Bien que BIND soit l'implémentation la plus courante du DNS, le problème de la sécurité subsiste toujours. De possibles problèmes de sécurité exploitables sont parfois découvert.

C'est une bonne idée de lire les avis de sécurité du CERT et de s'inscrire à la liste de diffusion des avis de sécurité pour FreeBSD pour se maintenir au courant des problèmes de sécurité actuels de l'Internet et de FreeBSD.

23.6.10. Lectures supplémentaires

Les pages de manuel de BIND/named: ndc(8) named(8) named.conf(5).

• Page officielle ISC concernant BIND

• FAQ BIND

• DNS et BIND 4ème Edition de chez O'Reilly

• RFC1034 - Domain Names - Concepts and Facilities

• RFC1035 - Domain Names - Implementation and Specification