Installer et configurer BIND 9.4.x.

Laurent Archambault

<archi.laurent AT gmail.com>

Copyright © 2007 Laurent Archambault. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". http://www.gnu.org/licenses/fdl.html

Historique des versions

Version 1.0

20 sept 2007


Table des matières

Protection
1. BIND.
Un peu d'histoire.
Terminologie :
Les commentaires.
2. Installation
Installation depuis les sources
Les options de compilation.
Les fichiers importants et les programmes installés :
Groupe et utilisateur « named » :
3. Choix de votre DNS.
4. Choix techniques pour votre DNS.
5. Configuration :
Noms de machines :
La résolution interne :
Le fichier « /etc/host.conf »
Types de zones possibles.
6. Le fichier named.conf.
Le fichier « named.conf ».
Détails des options
Les zones minimales (IPv4) :
entêtes de zone. Explications sur les entêtes de zone.
Gestion des traces (log).
La syntaxe.
7. Les enregistrements dans une zone.
8. La gestion de zone (primaire + secondaire)
La gestion d'une zone en primaire et sur un secondaire.
Sur le serveur primaire :
Sur le serveur(S) secondaire(S) :
Le même style mais pour la REVERSE :
La délégation et gestion de plusieurs zones « REVERSES. »
9. Contrôle des transferts.
10. Lancer Bind.
Les logs au lancement.
11. Les « ACL » et les « VIEW ».
Les listes de contrôle d'accès (ACL) :
Les VIEW.
12. Les autres programmes
NSLOOCKUP
DIG
Piloter Bind (rndc).
L'authentification avec RNDC :
Les options et les commandes RNDC.
La commande host
13. TSIG et DNSsec.
TSIG
Le programme dnssec-keygen.
Création de la clé sur le primaire.
DNSsec.
Les clés et les signatures.
DNSSEC et Microsoft
14. Conclusion.
A1. Divers et autre programmes.
DNSTRACER
dnswalk
Divers programmes DNS et utilitaires...
Gbindadmin
WEBMIN
Bindgraph
DNS Bajaj
A2. Informations disponibles sur Internet.
A3. Les options pour le fichier named.conf
A4. Mon « named.conf »
A5. Mes fichiers « localhost » et « 127.0.0.1 ».
A6. Mes 2 fichiers de zones.
A7. Mon fichier pour les logs de Bind.
Glossaire

Liste des tableaux

1.1. Les options.
5.1. Les types de zones.
6.1. Les options.
6.2. Les options.
6.3. Les catégories.

Protection

Ce document peut être librement copié, distribué et/ou modifié selon les termes et conditions de la GNU Free Documentation Licence, version 1.1 ou ultérieure, la dernière version est disponible ici : http://www.gnu.org/licences/fdl.html

Important

Cette documentation ne prend en compte que l'installation et la configuration d'un serveur(s) de noms en particulier vis à vis d'internet. En se basant sur ce document (éventuellement), vous pourrez adapter les configurations pour faire de votre DNS ce que voulez.

Chapitre 1. BIND.

Table des matières

Un peu d'histoire.
Terminologie :
Les commentaires.

Un peu d'histoire.

Le programme BIND (Berkeley Internet Name Domain) date des années 1980, il ne fonctionnait que sur des Unix à l'époque. Depuis il a bien évolué, il peut s'installer de multitudes plate-formes possibles. La version 9 à été totalement réécrite afin d'apporter une meilleure sécurité du service DNS. Bind est de nos jours le serveur le plus utilisé sur internet pour la résolution de noms. Il est soutenu par l'ISC (Internet System Consortium), dans un but non lucratif. Cette équipe suit de très prêts d'autres projets comme NTP, DHCP, elle est très active, et répond rapidement à tout problème.

Terminologie :

Avant de commencer, il est important que les termes suivants soient connus, ils font tous parti du « langage » DNS.

Tableau 1.1. Les options.

Terme

Explication

Canonical

Représente le nom complet d'une machine ou d'un serveur. Pour le DNS, il représente en théorie une déclaration de type A (IPv4 et AAAA pour IPv6). Il n'est en aucun un alias, ce terme est très proche à mes yeux du FQDN avec une pointe de précision purement DNS.

FQDN

« Full Qualified Domain Name », ou nom complètement désigné... exemple pour le domaine « linux.org », le serveur de méls pour ce domaine pourrait être « mail.linux.org », celui-ci correspond à une adresse IP précise et ne doit pas correspondre à un alias (CNAME).

FORWARD

C'est la correspondance adresse IP vers un nom, c'est aussi la base du DNS. Exemple 127.0.0.1 doit donner localhost...etc.

REVERSE

C'est l'inverse d'une zone FORWARD, une zone REVERSE est donc capable de renvoyer des informations de l'adresse IP vers un nom exclusivement.

TTL

Employé dans beaucoup de domaine, il correspond pour le DNS à la durée de vie d'un enregistrement en mémoire. Le TTL est utilisé dans beaucoup de processus comme la mémoire cache, pour une zone, pour une donnée précise... Exemple : si la déclaration d'un type A est de 3600 secondes, cette donnée sera valide en mémoire dans un DNS pendant cette durée, puis elle sera effacée. Le DNS doit demander à nouveau cette valeur lors d'une requête... La valeur zéro est interdite.

Il est important de fiwer la meilleure valeur, un petit TTL demande plus de requêtes sur le réseau, et plus de travaille aux serveurs, mais vous théoriquement toujours la bonne valeur. C'est la réactivité qui est demandée à ce niveau.

Vous avez le domaine de la performance, qui utilise des TTL relativement longs, et utilise moins le réseau.

La bonne valeur d'un TTL regroupe la réactivité et la performance.

Délégation

En prenant un exemple simple, vous avez dans une société le domaine « masociete.com », et nous supposons que la maison mère est située à Paris. Mais l'entreprise doit s'etendre géographiquement parlant pour avoir une autre entité à Bordeaux (exemple). Il est plus logique désormais de faire un sous domaine en « bordeaux.masociete.com », ceci réduira les flux réseaux. Le DNS primaire de la zone « masociete.com » doit déléguer la zone « bordeaux.masociete.com », pour une meilleure gestion de cette zone. Une délégation de zone peut-être considérée comme un déport avec des droits d'administration sur une zone. La zone parente est « masociete.com » et la fille est « bordeaux.masociete.com », 2 termes qui font parties aussi du langage DNS.

CHAOS

Depuis très longtemps Bind utilise le nom de CHAOS (ou CH) pour désigner 4 zones particulières. Elles servent à renvoyer des informations sur Bind. De nos jours il est fortement conseillé de ne plus les activer, ou de limiter au stricte nécessaire leurs accès. Ces zones sont : authors - hostname - version - id. Ceci est repris ici également chaos none



Les commentaires.

Bind est très stricte sur les écritures... il faut donc être stricte également, la moindre « ; » oubliée, et c'est la catastrophe.

Pour les commentaires, vous avez le choix entre 3 modes différents qui peuvent être mélangés dans les fichiers, mais pas dans tous :

Chapitre 2. Installation

Table des matières

Installation depuis les sources
Les options de compilation.
Les fichiers importants et les programmes installés :
Groupe et utilisateur « named » :

Installation depuis les sources

Il est nécessaire de récupérer les sources depuis le site de « ISC.org ». A la date de création de ce document, voici le lien pour récupérer les sources de la version 9.4.2 dite stable : http://www.isc.org/index.pl?/sw/bind/view/?release=9.4.2#DOWNLOADS. Prenez la version « source », sa taille est d'environ 6,3 Méga-octets. Une fois les sources non compressées, placez vous dans ce même répertoire.

Il est possible de compiler tout programme par défaut, en lançant la commande « ./configure && make », mais nous allons travailler avec les options disponibles pour obtenir un produit adapté à nos besoins.

Note

La version 9.4.2 est sortie presque lors de la finalisation de ce document. En conséquence, vous trouverez beaucoup d'exemples avec la version 9.4.1 précédente. Elles restent compatibles entre elles, sans remise en cause de ce document.

Avertissement

Bind peut s'installer sur les plate-formes de chez Microsoft. Cette possibilité ne sera pas décrite dans ce document. Le système d'exploitation de référence pour ce document est basé sur Gnu/linux.

Les options de compilation.

Voici tout les paramètres utilisables :

./configure --help
`configure' configures this package to adapt to many kinds of systems.

Usage: ./configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE.  See below for descriptions of some of the useful variables.

Defaults for the options are specified in brackets.

Configuration:
  -h, --help              display this help and exit
      --help=short        display options specific to this package
      --help=recursive    display the short help of all the included packages
  -V, --version           display version information and exit
  -q, --quiet, --silent   do not print `checking...' messages
      --cache-file=FILE   cache test results in FILE [disabled]
  -C, --config-cache      alias for `--cache-file=config.cache'
  -n, --no-create         do not create output files
      --srcdir=DIR        find the sources in DIR [configure dir or `..']

Installation directories:
  --prefix=PREFIX         install architecture-independent files in PREFIX
                          [/usr/local]
  --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
                          [PREFIX]

By default, `make install' will install all the files in
`/usr/local/bin', `/usr/local/lib' etc.  You can specify
an installation prefix other than `/usr/local' using `--prefix',
for instance `--prefix=$HOME'.

For better control, use the options below.

Fine tuning of the installation directories:
  --bindir=DIR           user executables [EPREFIX/bin]
  --sbindir=DIR          system admin executables [EPREFIX/sbin]
  --libexecdir=DIR       program executables [EPREFIX/libexec]
  --datadir=DIR          read-only architecture-independent data [PREFIX/share]
  --sysconfdir=DIR       read-only single-machine data [PREFIX/etc]
  --sharedstatedir=DIR   modifiable architecture-independent data [PREFIX/com]
  --localstatedir=DIR    modifiable single-machine data [PREFIX/var]
  --libdir=DIR           object code libraries [EPREFIX/lib]
  --includedir=DIR       C header files [PREFIX/include]
  --oldincludedir=DIR    C header files for non-gcc [/usr/include]
  --infodir=DIR          info documentation [PREFIX/info]
  --mandir=DIR           man documentation [PREFIX/man]

System types:
  --build=BUILD     configure for building on BUILD [guessed]
  --host=HOST       cross-compile to build programs to run on HOST [BUILD]

Optional Features:
  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
  --enable-openssl-version-check
                          Check OpenSSL Version [default=yes]
  --enable-threads      enable multithreading
  --enable-largefile      64-bit file support
  --enable-shared[=PKGS]
                          build shared libraries [default=yes]
  --enable-static[=PKGS]
                          build static libraries [default=yes]
  --enable-fast-install[=PKGS]
                          optimize for fast installation [default=yes]
  --disable-libtool-lock  avoid locking (might break parallel builds)
  --enable-libbind              build libbind default=no
  --enable-ipv6         use IPv6 default=autodetect
  --enable-getifaddrs    Enable the use of getifaddrs() [yes|no|glibc].
             glibc: Use getifaddrs() in glibc if you know it supports IPv6.
  --disable-linux-caps  disable linux capabilities
  --enable-atomic       enable machine specific atomic operations
                        [default=autodetect]

Optional Packages:
  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
  --with-openssl=PATH   Build with OpenSSL yes|no|path.
                          (Required for DNSSEC)
  --with-randomdev=PATH Specify path for random device
  --with-ptl2           on NetBSD, use the ptl2 thread library (experimental)
  --with-purify=PATH    use Rational purify
  --with-libtool        use GNU libtool (following indented options supported)
  --with-gnu-ld           assume the C compiler uses GNU ld [default=no]
  --with-pic              try to use only PIC/non-PIC objects [default=use
                          both]
  --with-tags[=TAGS]
                          include additional configurations [automatic]
  --with-kame=PATH      use Kame IPv6 default path /usr/local/v6
  --with-idn=MPREFIX   enable IDN support using idnkit default PREFIX
  --with-libiconv=IPREFIX   GNU libiconv are in IPREFIX default PREFIX
  --with-iconv=LIBSPEC   specify iconv library default -liconv
  --with-idnlib=ARG    specify libidnkit
  --with-dlz-postgres=PATH   Build with Postgres DLZ driver yes|no|path.
                               (Required to use Postgres with DLZ)
  --with-dlz-mysql=PATH   Build with MySQL DLZ driver yes|no|path.
                               (Required to use MySQL with DLZ)
  --with-dlz-bdb=PATH   Build with Berkeley DB DLZ driver yes|no|path.
                               (Required to use Berkeley DB with DLZ)
  --with-dlz-filesystem=PATH   Build with filesystem DLZ driver yes|no.
                               (Required to use file system driver with DLZ)
  --with-dlz-ldap=PATH   Build with LDAP DLZ driver yes|no|path.
                               (Required to use LDAP with DLZ)
  --with-dlz-odbc=PATH   Build with ODBC DLZ driver yes|no|path.
                               (Required to use ODBC with DLZ)
  --with-dlz-stub=PATH   Build with stub DLZ driver yes|no.
                               (Required to use stub driver with DLZ)

Some influential environment variables:
  CC          C compiler command
  CFLAGS      C compiler flags
  LDFLAGS     linker flags, e.g. -L "lib dir" if you have libraries in a
              nonstandard directory "lib dir"
  CPPFLAGS    C/C++ preprocessor flags, e.g. -I "include dir"  if you have
              headers in a nonstandard directory  "include dir" 
  CPP         C preprocessor
  CXX         C++ compiler command
  CXXFLAGS    C++ compiler flags
  CXXCPP      C++ preprocessor
  F77         Fortran 77 compiler command
  FFLAGS      Fortran 77 compiler flags

Et voici les options retenues :

./configure --prefix=/usr --host=i686-pc-linux-gnu \
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share \
--sysconfdir=/etc --localstatedir=/var/lib --sysconfdir=/etc/bind \
--localstatedir=/var --with-libtool --disable-ipv6 \
--with-openssl --enable-linux-caps --enable-threads \
--with-randomdev=/dev/urandom --build=i686-pc-linux-gnu

Avertissement

J'ai rencontré sur une distribution un kernel/noyau qui ne supportait pas la « linux-caps (linux capabilities) ». C'est à dire pouvoir faire un tourner un serveur sous un autre nom différent du super utilisateur. Si vous rencontrez ce problème, vous n'avez pas beaucoup de choix, soit faire tourner Bind en tant que « root », avec ses risques possibles...ou de trouver/recompiler un noyau qui accepte ceci. Pour éviter ceci il suffit de retirer cette option : --disable-linux-caps. J'ai aussi rencontré un problème avec l'option with-randomdev=/dev/urandom. Evidemment je me suis trompé en plaçant la valeur « random », au lieu de « urandom ». Le résultat est très visible lors de fabrication et d'utilisation de clés de chiffrement...

Bind fonctionne très bien en environnement 64 bits, y compris compilé dans ce mode.

Voici les diverses explications sur les options de compilation :

Les options « --prefix=/usr --host=i686-pc-linux-gnu --enable-linux-caps --enable-threads --with-randomdev=/dev/urandom --build=i686-pc-linux-gnu --localstatedir=/var/lib », font toutes parties des options classiques, et nécessaires pour un système Gnu/Linux. Pour une machine mono processeur, l'option « --enable-threads » n'est pas utilisée. Les options « --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share » indiquent les répertoires pour les les fichiers MAN, info ...

Et voilà pour la compilation, il ne reste plus qu'à lancer les commandes make && make install

Ceci n'est pas important, mais voici les librairies utilisées par Bind, pour information :

        linux-gate.so.1 =>  (0xffffe000)
        liblwres.so.30 => /usr/lib/liblwres.so.30 (0xb7f06000)
        libdns.so.32 => /usr/lib/libdns.so.32 (0xb7dd5000)
        libbind9.so.30 => /usr/lib/libbind9.so.30 (0xb7dcb000)
        libisccfg.so.30 => /usr/lib/libisccfg.so.30 (0xb7db8000)
        libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0xb7c83000)
        libisccc.so.30 => /usr/lib/libisccc.so.30 (0xb7c7b000)
        libisc.so.32 => /usr/lib/libisc.so.32 (0xb7c35000)
        libnsl.so.1 => /lib/libnsl.so.1 (0xb7c1f000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7c09000)
        libc.so.6 => /lib/libc.so.6 (0xb7ae2000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7ade000)
        /lib/ld-linux.so.2 (0xb7f35000)

Les fichiers importants et les programmes installés :

Voici la liste des programmes compilés (ou pas) et les fichiers installé par Bind, chaque programme exécutable sera expliqué individuellement par la suite. :

/etc/bind/sec lien vers :  /var/bind/sec
/etc/bind/pri lien vers : /var/bind/pri
--- /etc/bind/named.conf
--- /etc/init.d/
/etc/init.d/named
/var/bind/sec/
--- /var/bind/pri/
--- /var/bind/pri/localhost.zone
--- /var/bind/pri/127.zone
--- /var/bind/named.ca
--- /var/bind/root.cache (lien vers named.ca)
--- /var/bind/named.ca
--- /var/lib/run/
--- /usr/sbin/lwresd
--- /usr/sbin/dnssec-keygen
--- /usr/sbin/named-compilezone
--- /usr/share/named-checkzone
--- /usr/sbin/rndc-confgen
--- /usr/sbin/rndc
--- /usr/sbin/named
--- /usr/sbin/named-checkzone
--- /usr/sbin/named-checkconf
--- /usr/sbin/dnssec-signzone
--- /usr/share/doc/bind-9.4.1_p1/
/usr/share/man/man3/
/usr/share/man/man5/
/usr/share/man/man1/
/usr/share/man/man8/
--- /usr/bin/isc-config.sh

A noter dans le répertoire « /etc/bind » les liens symboliques « pri » et « sec » dirigés vers le répertoire « /var/bind/ ». Le nommage de ces répertoires reste libre, ils désignent l'emplacement des zones primaires et secondaires.

Les 2 programmes named-checkzone et named-checkconf, ne seront pas utilisés, ni expliqué dans ce document. Si vous utilisez Bind dans un cadre classique, sans LDAP et sans une base de données, les moindres erreurs sont suffisamment bien expliquées dans les fichiers d'historiques, pour comprendre votre erreur rapidement.

Groupe et utilisateur « named » :

Bind utilise le fichier exécutable named comme serveur de noms. Par sécurité ce fichier est lancé sous les droits d'utilisateur et du groupe « named ». Pour créer cette utilisateur et ce groupe, il suffit de faire les commandes suivantes :

groupadd -g40 named

adduser -Gnamed -u40 -d /etc/bind named -s /bin/nologin

Le fichier pour le processus « named » sera installé dans le répertoire « /var/run/named » (à créer).

Il faut appliquer des droits d'écritures sur les répertoires suivants :

chown -R named:named /var/bind/ && chown -R named:named /var/run/named && chown -R named:named /var/log/named/.

Et c'est tout, le reste est sous contrôle du « root » comme les fichiers de configuration.

Avertissement

Attention au choix du chiffre (UID et GID) « 40 », il ne faut pas qu'il soit déjà « occupé »... La commande précédente est seulement un exemple applicable sur ma machine.

Chapitre 3. Choix de votre DNS.

Bind est très souple d'emploi et permet de multiples configurations. Selon votre réseau, vos besoins, vos contraintes, vous pouvez choisir selon les formules suivantes pour votre configuration. Les configurations les plus courantes seront expliquées en détail par la suite.

Chapitre 4. Choix techniques pour votre DNS.

A ce stade nous allons apprendre comment un DNS peut agir selon une requête, tout en sécurisant votre réseau.

Chapitre 5. Configuration :

Table des matières

Noms de machines :
La résolution interne :
Le fichier « /etc/host.conf »
Types de zones possibles.

A ce niveau l'administrateur doit connaître parfaitement l'architecture de son réseau. Il doit pouvoir répondre aux questions : qui vient interroger le DNS, qui à le droit de transférer une zone...etc

Noms de machines :

Toutes les machines de votre réseau ou de votre domaine, doivent porter un nom en liaison avec le domaine géré par votre DNS. Pour ce document, le DNS primaire et le DNS secondaire porteront les noms de serveur.archi.amt et second.archi.amt. L'extension « .amt » est volontaire, il existe sur internet déjà l'extension « org, net... ». Par la suite, vous comprendrez de vous même pourquoi ce choix ne pose aucun problème vis à vis du réseau DNS internet.

Pour la distribution Gentoo, il faut modifier les fichiers : /etc/conf.d/hostname (HOSTNAME=serveur) et /etc/conf.d/domainname (DNSDOMAIN=archi.amt).

Pour Mandriva, il suffit de modifier le fichier /etc/sysconfig/network (HOSTNAME=serveur.archi.amt)

Pour Ubuntu, il suffit de modifier les 2 fichiers suivants : /etc/hosts et /etc/hostname

La résolution interne :

Important

A ce niveau votre serveur DNS ne fonctionne pas encore, la modification qui va être apportée va stopper temporairement la résolution du service DNS. Le cas échéant il suffit de placer le caractère « # » devant la ligne concernant vos DNS (temporairement).

L'activation de la résolution de noms et d'adresses IP pour chaque machine est prise en compte par le fichier /etc/resolv.conf

Voici une solution possible :

 # /etc/resolv.conf
 #
 # search + le domaine pour mon réseau :
 # Conseille ... mais que j'utilise pas ...
 # impose par contre de taper tout completement 
 # 
 search archi.amt
 #
 # Mes DNS privés (local(serveur)) et second (.15):
 nameserver 127.0.0.1
 nameserver 192.168.1.15
 #
 #
 # A activer si probleme avec le DNS interne :
 # Attention a vos clients ...
 # Mes DNS de mon FAI/internet ou autre DNS :
 #nameserver 194.xxx.xxx.10
 #nameserver 194.xxx.xxx.15
 #

Le fichier « /etc/host.conf »

Ce fichier donne des instructions sur la manière dont va être traité les requêtes DNS. Les valeurs peuvent être multiples, comme hosts, bind, nis ... Nous concernant les valeurs hosts, bind sont conseillées. Avec l'activation des zones 127.0.0.1 et localhost, j'ai supprimé la valeur hosts, qui ne servait plus à rien, autant profiter du cache mémoire de Bind. C'est à vous de voir...à mon avis Bind va plus vite à répondre...

order hosts, bind

Avertissement

Ne pas confondre avec le fichier /etc/hosts qui permet des correspondances comme 127.0.0.1 avec localhost.

Pour la valeur search, j'ai personnellement retiré cette option, sans rencontré de problème. Par contre je me dois d'être stricte désormais, il me faut saisir mes résolutions sous forme FQDN. Comme je le fais pour les autres domaines, est-ce vraiment un problème... mais ceci me permet de ne pas trouver des domaines non résolus avec le domaine archi.amt (exemple) accolé à des requêtes...A vous de voir, une fois de plus.

Types de zones possibles.

Dans sa grande souplesse, Bind vous propose 4 types de gestion de zones.

Tableau 5.1. Les types de zones.

Type

Explication

HINT

Ce type de zone est obligatoire pour tout serveur de noms, elle représente qui gère le domaine (TLD), c'est le référencement des racines. Sur internet il s'agit d'un fichier téléchargeable appellé named.ca.

Le terme « TLD » est ausi utilisé pour les zones similaires à celle ci, comme la zone « .fr »,« .com »... D'ou la différence entre les mots « racines » et « TLD », beaucoup sont des « TLD », mais tout le monde (DNS) n'est pas une « racine ».

PRIMAIRE

Les termes maitre ou primaire sont équivalents. Il s'agit de la zone gérée par un serveur qui est désignée comme meilleure source d'informations pour une zone précise. C'est une vision importante pour le DNS, car rien ne prouve à l'exception des analyses de l'administrateur que les zones sont parfaitement à jour sur le ou les secondaires. Ce « rôle » de « primaire » est important, celui-ci doit faciliter les échanges de données envers ses secours|secondaires.

Le terme de DNS primaire concerne exclusivement une zone. De plus tous bon DNS peut-être primaire avec la prise en compte de la zone REVERSE 0.0.127.in-addr.arpa, et la zone « localhost ». , et vous serez dans cette position conforme à la RFC 1912...

SECONDAIRE

Une zone secondaire est la copie d'une zone située sur un serveur PRIMAIRE. Automatiquement les serveurs maintiennent les données mises à jour. Un serveur SECONDAIRE ne peut modifier des données d'une zone SECONDAIRE... Il est préférable de placer les fichiers de zones SECONDAIRES dans un répertoire spécifique.

STUB

C'est une technique très similaire à la délégation de zone. Par contre le serveur PRIMAIRE ne récupère (!) que les enregistrements de désignation des serveurs SECONDAIRES (champs NS). Lesquels peuvent gérer un sous domaine en tant que primaire sans problème. Cette technique n'est pas très utilisée. Elle mérite tout de même d'être signalée, elle permet au responsable d'une zone parente, de contrôler ou connaître les serveurs qui gèrent une délégation de zone, sans avoir à répondre sur les données internes de cette zone.

FORWARD

Après des essais sur ce type, j'en déduis : c'est une déclaration pour une zone non prise en compte au niveau du serveur (!), ou hors de votre domaine. Il est donc possible de désigner le ou les serveurs qui gèrent cette zone par cette déclaration.

Elle pourrait très bien intervenir sur un DNS filtrant pour accepter des requêtes vers un domaine particulier (mode ITERATIF), en interdisant beaucoup d'autres...



Chapitre 6. Le fichier named.conf.

Table des matières

Le fichier « named.conf ».
Détails des options
Les zones minimales (IPv4) :
entêtes de zone. Explications sur les entêtes de zone.
Gestion des traces (log).
La syntaxe.

Pour Bind, tout les fichiers sont importants, mais le fichier « named.conf » reste tout le même le coeur du système. Nous allons donc parler de celui-ci sans oublier les autres tout de même par la suite...

Voici en image l'architecture sur lequel je vais me baser, c'est important pour la suite :

Rien d'exceptionnel, 2 DNS coté internet, ils correspondent à ceux de mon FAI/PROVIDER. Ils sont déclarés en forward (rediriger vers...), et 2 DNS du coté du réseau privé composé de plusieurs clients (virtuels en parti).

Comme il est possible de le voir, mes 2 DNS sont autonomes en ce qui concerne les requêtes vers internet. Par contre ils sont liés vis à vis des zones gérées ensembles. En réalité les clients de mon réseau vont interroger sur mon réseau privé les deux DNS, plus ou moins à tour de rôle; ceci fait parti de la logique de Bind.

Le fichier « named.conf ».

Je me base sur mes paramètres de compilations, il doit se trouver dans /etc/bind/

/*
      /etc/named/named.conf
*/
//------------------------------------------------------
//////////////////////////////////
options {

        // SECURITE PAS DE TYPE CHAOS//
        version none;
        hostname none;
        server-id none;
        // DNSSEC //
        // dnssec-enable yes;
        // REPERTOIRE //
        directory "/etc/bind";
        dump-file "/var/run/named/named-dump.db";
        pid-file "/var/run/named/named.pid";
        // STATS via RNDC//
        statistics-file "/var/run/named/named.stats";
        zone-statistics yes;
        coresize 0M;
        // Limitation des clients (défaut=1000)
        // recursive-clients 1000;
        // query-source address * port 53; //surtout pour les FW
        // IP ecoute par ce serveur
        listen-on { 127.0.0.1; 192.168.1.11; };
        // Pas de zones vides automatiques...
        empty-zones-enable no;
        // si vousheberger au moins une zone :
        allow-transfer { none; };     // option globale
        // transfers-out 20;          // nb transfert max d'1 seul coup
        // transfers-per-ns 5;      // transfert par serveur
        auth-nxdomain no;           // conforme RFC 1035
        // pour internet = 0
        lame-ttl 0;                       //faux serveurs primaires
        // negatif cache en RAM
        max-ncache-ttl 7200;
        // positif cache en RAM
        // 127800 = 2 jours MAX et non une semaine (défaut)
        max-cache-ttl 172800;
        //Activation du forward ... pour internet ou autre réseau...
        forwarders { 194.117.200.10; 194.117.200.15; };
        // Accepte la recursion pour ces adresses (locales)
        recursion yes;
        // SECURITE -> DOS = Nbr de requêtes / clients
        clients-per-query 10;
        // SECURITE -> DOS = Nbr MAX clients pour une même requête (défaut 100)
        max-clients-per-query 50;
        // Active la recursion pour mon réseau INTERNE
        allow-recursion { INTERNE; }; 
        // Qui peut questionner le serveur ...ou avec une cle
        allow-query { INTERNE; key resolver-serveur; }; 
        // Qui peut questionner les caches du serveur ... ou avec une cle
        allow-query-cache { INTERNE; key resolver-serveur; };
        // limitation EDNS ...les paquets ne depassent pas 512 octets (max 4096)
        edns-udp-size 512 ;
        max-udp-size  512 ;
};
// Prise en compte des includes
include "/etc/bind/logging.inc";
//include "/etc/bind/view.inc";
//////////////////////////////////
// Gestion du point OBLIGATOIRE
//////////////////////////////////
zone "." {
        type hint;
        file "pri/named.ca";
};
//////////////////////////////////
// GESTION DU LOCALHOST -CONSELLE
//////////////////////////////////
zone "localhost" IN {
        type master;
        file "pri/localhost.zone";
        notify no;
};
//////////////////////////////////
// GESTION REVERSE 127.0.0.1 - CONSEILLE
//////////////////////////////////
zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "pri/127.zone";
        notify no;
};
//////////////////////////////////

Détails des options

Ce chapitre ne va traiter que des options du fichier named.conf, les déclarations de zone primaire et secondaire seront expliquées dans un autre chapitre.

Tableau 6.1. Les options.

Option

Explication

version none;

Permet de ne pas afficher la version de Bind. Fortement recommandé par sécurité. Cette option évite la fameuse zone CHAOS pour les versions antérieures à Bind 9.

hostname none;

Cette option cache le nom du serveur, fortement recommandé par sécurité. Utilisé pour résoudre les problèmes des serveurs anycast. Cette option évite la fameuse zone chaos pour les versions antérieures à Bind 9.

server-id none;

Identique à hostname none;. Cette option évite la fameuse zone chaos pour les versions antérieures à Bind 9.

dump-file "/var/run/named/named-dump.db";

Désigne le répertoire et le nom du fichier qui recevra les données de la commande : rndc dumpdb .... Par défaut la valeur est named_dump.db. dans le répertoire courant. Il est préférable que ce fichier soit clairement identifié pour le retrouver facilement, même si celui-ci est peut utilisé.

pid-file "/var/run/named/named.pid"

Désigne le répertoire et le nom du fichier pour identifier le fichier de processus. Par défaut la valeur est /var/run/named.pid.. Pour éviter de rechercher inutilement ou il est ... il est fortement conseillé d'inclure cette option.

statistics-file "/var/run/named/named.stats";

Désigne le répertoire et le nom du fichier qui recevra les données de la commande : rndc stats. Bien qu'il sera expliqué par la suite, ce fichier apporte un suivi de votre service DNS important, impossible à faire manuellement. Il est donc fortement recommandé d'activer cette option, et la suivante (zone-statistic).

zone-statistics yes;

Lié à l'option précédente statistics-file, cette option donne des informations complémentaires spécifiques sur les zones gérées. Fortement recommandé pour un meilleur suivi de votre service DNS.

coresize 0M;

Comme beaucoup de programme en cas de plantage, Bind génère une copie de sa mémoire en fichier. Toutefois la lecture de ce fichier, ne représente aucun intérêt, à l'exception des developpeurs. Par conséquent pour éviter de gros fichier inutiles sur un disque, la valeur 0M à été choisie.

listen-on { 127.0.0.1; 192.168.1.11; };

C'est ici qu'il faut déclarer les adresses IP avec lesquelles Bind doit travailler. La syntaxe est la suivante, il est possible d'indiquer le port d'écoute également listen-on { 5.6.7.8; };, ou listen-on port 1234 { !1.2.3.4; 1.2/16; };. En prenant ma configuration comme exemple, voici la valeur listen-on { 127.0.0.1; 192.168.1.11; };

recursion yes;

Le DNS est autorisé à faire de la résolution RECURSIVE. Attention à l'emploi de cette option avec la valeur no, qui est très spécifique. Cette option peut être limitée en portée par l'option expliquée ici : allow-recursion.

recursive-clients 1000;

Peut paraitre anodin, mais chaque requête récursive demande 20 Kb en mémoire, la valeur par défaut est 1000. Accepte les requêtes RECURSIVES vis à vis des clients.

query-source address * port *;

Il est possible surtout en présence d'un un pare-feux d'imposer à Bind comment répondre en TCP/UDP. Par défaut les 2 « * » sont activées mais il est possible de placer une adresse IP et un port précis. En plaçant une étoile au niveau du port Bind va répondre sur des ports aléatoires et supérieurs à 1023.

empty-zones-enable no;

Bind est prévu pour travailler sur internet principalement, il active tout seul plusieurs zones REVERSE corresponds à des adresses non routables sur internet, et pour protéger également les racines de requêtes inutiles.

Voici les zones sur mon serveur :

Nov 28 07:40:32 serveur named[10726]: automatic empty zone: 127.IN-ADDR.ARPA
Nov 28 07:40:32 serveur named[10726]: automatic empty zone: 254.169.IN-ADDR.ARPA
Nov 28 07:40:32 serveur named[10726]: automatic empty zone: 2.0.192.IN-ADDR.ARPA
Nov 28 07:40:32 serveur named[10726]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA
Nov 28 07:40:32 serveur named[10726]: automatic empty 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.0.IP6.ARPA
Nov 28 07:40:32 serveur named[10726]: automatic empty zone: 1.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.ARPA
Nov 28 07:40:32 serveur named[10726]: automatic empty zone: D.F.IP6.ARPA
Nov 28 07:40:32 serveur named[10726]: automatic empty zone: 8.E.F.IP6.ARPA
Nov 28 07:40:32 serveur named[10726]: automatic empty zone: 9.E.F.IP6.ARPA
Nov 28 07:40:32 serveur named[10726]: automatic empty zone: A.E.F.IP6.ARPA
Nov 28 07:40:32 serveur named[10726]: automatic empty zone: B.E.F.IP6.ARPA
                                  

Si votre serveur gère l'une de ces zones vous devez désactivée cette option. Par contre un serveur racine en particulier sur internet doit activer cette option.

Voici tout de même les zones soit disant complète provenant de la documentation de Bind. De là pourquoi mon serveur n'a pas tout créer...(172. ?) Le problème est réglé, car je n'active pas les zones automatiquements, mais je regarde aussi mes historiques pour éviter de polluer les autres...

    * 10.IN-ADDR.ARPA
    * 127.IN-ADDR.ARPA
    * 254.169.IN-ADDR.ARPA
    * 16.172.IN-ADDR.ARPA
    * 17.172.IN-ADDR.ARPA
    * 18.172.IN-ADDR.ARPA
    * 19.172.IN-ADDR.ARPA
    * 20.172.IN-ADDR.ARPA
    * 21.172.IN-ADDR.ARPA
    * 22.172.IN-ADDR.ARPA
    * 23.172.IN-ADDR.ARPA
    * 24.172.IN-ADDR.ARPA
    * 25.172.IN-ADDR.ARPA
    * 26.172.IN-ADDR.ARPA
    * 27.172.IN-ADDR.ARPA
    * 28.172.IN-ADDR.ARPA
    * 29.172.IN-ADDR.ARPA
    * 30.172.IN-ADDR.ARPA
    * 31.172.IN-ADDR.ARPA
    * 168.192.IN-ADDR.ARPA
    * 2.0.192.IN-ADDR.ARPA
    * 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.0.IP6.ARPA
    * 1.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.ARPA
    * D.F.IP6.ARPA
    * 8.E.F.IP6.ARPA
    * 9.E.F.IP6.ARPA
    * A.E.F.IP6.ARPA
    * B.E.F.IP6.ARPA
    

allow-transfer { none; };

Par défaut les transferts de zones ne sont pas autorisées, dans un contexte de globalité.

allow-update { none; };

Ce paramètre peut-être globale ou compris dans une zone. Il interdit ou autorise les mises à jour par le protocole DHCP.

transfers-out 20;

Pour un serveur PRIMAIRE (!) indique à Bind combien de transferts de zones il peut réaliser en parallèle. Plus le nombre est important, et plus votre réseau sera chargé... la valeur par défaut est 10.

Pour un serveur secondaire ou primaire/secondaire, il existe la comme inverse transfers-in 20;.

La valeur 20 est le réglage par défaut.

transfers-per-ns 2;

Cette instruction est importante sur des gros serveurs DNS qui gèrent des centaines de zones, ou plus. Il faut savoir qu'un serveur primaire est un peu à la merci de ses esclaves (secondaires). Il peut-être nécessaire de limiter le nombre de transferts par serveur afin de réduire la charge du serveur et du réseau. La confiance à apporter à un DNS esclave est toute relative.

auth-nxdomain no;

Cette option est conforme à la RFC 1035, les requêtes négatives en mémoire ne font autoritées.

lame-ttl 0;

Les lame-ttl représente les réponses des autres DNS qui se disent primaire d'une zone mais qui en réalisté ne le sont pas. Pour éviter à Bind de garder des erreurs en cache, elles sont éffacées par la valeur 0 qui représente le TTL. Cette option est obligatoire vis à vis d'internet, mais peut représenter une valeur interessante pour rechercher les mauvais DNS/administrateurs sur un réseau privé (sans accès internet).

max-ncache-ttl 1800;

Représente la valeur maximale en secondes pour le cache négatif, soit ici 30 minutes (1800 secondes).

En clair, toutes les résultats dues à des requêtes sont stockées dans l'une des 2 mémoires caches de Bind. La « positive » et la « négative » selon les réponses.

La valeur par défaut est de 10800 secondes ou 3 heures pour la négative, la valeur maximale ne peut dépasser 7 jours. Le choix de cette valeur va agir sur le comportement de Bind, une valeur trop petite demandera à Bind plus d'effort pour rechercher une information. Une valeur trop importante, réduit la charge de Bind mais celui-ci n'est donc pas forcément au « top » des mises à jour.

Pour le cache positif, il existe l'option similaire max-cache-ttl, la valeur maximale ne peut excéder également une semaine. C'est aussi sa valeur par défaut, à vous de voir si vous devez modifier et activer cette option.

forwarders { 194.117.200.10; 194.117.200.15; };

Cette option indique à Bind à qui il doit transmettre une requête qu'il ne sait résoudre. L'exemple précédent désigne les 2 DNS fournient par mon FAI Iinternet. Sans cette ordre, mes DNS auraient demandé à l'un des ROOT, et évidemment par sécurité ils sont protégés de la RECURSION, la réponse aurait été négative.

A utiliser vis à vis d'un LAN et d'internet, pour un DNS cache...

Il est possible d'utiliser en complément, l'option forward-only, l'ordre est plus stricte... Il existe aussi une options forward-first, peut utiliser. Ces 2 dernières options sont employées en particulier pour des zones.

J'ai aussi croisé plusieurs configurations qui utilisent cette configuration, exemple : forwarders { 194.117.200.10; 194.117.200.15; 194.117.200.10; 194.117.200.15; };. Donc les 2 DNS sont répétés volontairement, ceci à pour effet de poser les requêtes en double et d'avoir un système plus réactif. Avec les versions récentes de Bind, je trouve que le système réagit très bien, sans ajouter ceci, mais Bind le permet.

listen-on-v6 { none; };

Pour contraindre Bind à ne pas écouter en IPv6. Il est aussi possible lors du lancement de Bind (named) de placer l'option -4 qui force Bind à ne gérer que l'IPv4. Ces 2 options sont fortement recommandées dans un réseau en IPv4.

Et encore une nouvelle version de serveur DNS : le « dual-stack-server », qui est capable d'écouter, de gérer aussi bien en IPv4 comme en IPv6.

max-clients-per-query 10; max-clients-per-query 100;

Ces 2 options doivent être ensemble, elles permettent de réduire les « attaques  » vis à vis de votre DNS par saturation ou Déni de service (DOS). J'ai déjà rencontré un controleur de domaine faisant tout de même 1200 requêtes à la seconde. Il faut donc limiter ce genre d'attaque même involontaire, pour que votre DNS puisse respirer et travailler (au moins pour les autres).

La valeur max-clients-per-query 10; représente le nombre de requêtes RECURSIVES traitées simultanéement.

La valeur max-clients-per-query 100; représente le nombre maximum de requêtes pour une réponse précise attendue...si la réponse est négative, il va sauter les requêtes correspondantes pendant 20 minutes. Par contre si votre Bind trouve une réponse positive entre temps, le temps d'attente est automatiquement abaissé.

Une valeur de zéro représente une valeur sans limite.

allow-recursion { 127.0.0.1 ; 192.168.1.0; };

Qui est autorisé à faire des requêtes récursives.

allow-query { 127.0.0.1; 192.168.1.0/24; };

Qui vis à vis de Bind peut interroger le DNS... Cette option est utilisable ici, ou au niveau des zones (chapitre suivant).

allow-query -cache { 127.0.0.1; 192.168.1.0/24; };

Qui vis à vis de Bind peut interroger mon DNS via les caches... Cette option est inactive pour les DNS relié directement vers internet, vis à vis des clients potentiels de ce réseau.

include "/etc/bind/logging.inc";

Permet d'inclure un fichier dans le fichier de configuration, cette instruction evite de surcharger le fichier de configuration.

L'inscrustation de ce fichier pour les historiques fait l'objet d'un chapitre spécifique dans ce document.

edns-udp-size 512 ; max-udp-size 512 ;

Ces 2 paramètres vont ensembles, ils permettent de limiter la taille de paquets à 512 octets. Ce qui est suffisant dans un cadre normal (IPv4). Avec l'arrivée de DNSsec (Expliqué à la section intitulée « DNSsec. »), les choses ne sont plus pareils, celui-ci demande beaucoup plus. Ces 2 valeurs peuvent être modifiées pour votre réseau. J'ai volontairement limité ces valeurs à 512 pour répondre à certains DNS qui répondent avec des paquets supérieurs, et qui ne nécessite pas cette opération. C'est par contre un paramètre parfois obligatoire pour certains pare-feux, qui ne peuvent traiter que des paquets limité à 512 octets. Défini dans la RFC 2671



Voilà pour les options dites classiques, ou les options globales, communes à toutes les zones. Comme vous allez le voir plus loin, chaque déclaration de zone comporte son lots de paramètres et/ou d'options. A ce stade il est encore inutile de lancer Bind, car il manque les zones vitales comme localhost/127.0.0.1...etc.

Lors de l'écriture de ce document, j'ai bien évidemment rechercher de la documentation un peu partout. J'ai croisé beaucoup d'exemples, mais en général le chapitre « options » pour le fichier named.conf, est très court ou réduit. A la fin de ce document au niveau des annexes (options-named-debut), vous pouvez trouver toutes les options possibles. Personnellement je pense que les options précédemment expliquées, présentent un intérêt suffisant pour de nombreuses situations...

Note

Il est possible d'inclure une autre section appelé « server ». Cette section permet de régler votre serveur vis à vis d'un ou plusieurs autres serveurs particuliers. Si vous utilisez que des version récentes de Bind sur votre réseau, cette section est théoriquement inutile. Vous pouvez trouver tout les détails ici : options-server.

Vous pouvez retrouver ma configuration dans les annexes qui suivent ce lien : Annexe 4

Les zones minimales (IPv4) :

Avertissement

Je reste sur mes positions, je pense que les zones 127.0.0.1 et localhost doivent être gérées par Bind et non pas par le système.

Il s'agit de 2 zones à déclarer sur votre serveur, elles ne sont pas secourus bien évidemment. Voici la déclaration à faire au niveau du fichier named.conf, à la suite des précédentes options.

//////////////////////////////////
zone "." IN {
        type hint;
        file "named.ca";
};
//////////////////////////////////
// GESTION DU LOCALHOST - CONSEILLE
//////////////////////////////////
zone "localhost" IN {
        type master;
        file "pri/localhost.zone";
        notify no;
};
//////////////////////////////////
// GESTION REVERSE 127.0.0.1 - CONSEILLE
//////////////////////////////////
zone "127.in-addr.arpa" IN {
        type master;
        file "pri/127.zone";
        notify no;
};
//////////////////////////////////

Comme vous pouvez le voir, la zone "." correspond aux données des serveurs racines. Ce fichier est présent dans les sources de Bind, téléchargeable sur internet. Me concernant ce fichier provient d'internet, il s'appelle named.ca. Ce fichier est obligatoire.

Les 2 zones pour la gestion du localhost, concerne le nom localhost ou zone FORWARD, et la gestion des adresses IP, correspond à la zone REVERSE 127.0.0.1.

Pour déclarer une zone primaire et/ou secondaire il est nécessaire de commencer par : zone "son_nom" IN { des_options; }, représente réellement le nom de la zone, il est repris par Bind pour gérer cette zone. Le mot IN représente la valeur « INTERNET », même sur un réseau privé, c'est la bonne valeur. Il vous reste ensuite le choix possible avec CH, il correspondant aux zones CHAOS. Par sécurité ces zones sont inactives via les options version none; hostname none; server-id none;

Tableau 6.2. Les options.

Zone

Détail / Explication

zone "."

Bind contrôle dès son lancement la présence d'une zone de type « HINT », qui représente la déclaration des serveurs racines (internet pour moi). Sans ce fichier, Bind utilise des données internes dans son programme, il est fortement conseillé de créer cette zone, même en connaissant cela. Cette zone est gérée dans le répertoire pri sous le nom de fichier de named.ca. Ce fichier est contrôlable via la commande dig, cette commande est théoriquement présente dans toutes les distributions. Je ne peux que conseiller de garder le nom « named.ca » pour la gestion de cette zone.

zone "localhost"

Comme déjà expliqué vous avez 2 sortes d'administrateurs. Ceux qui font gérer cette zone et sa REVERSE (127.0.0.1) par Bind, et d'autres qui ne le font pas pas. Je reste sur mes positions, elles seront activées. Le plus compliqué est le début, elles ne bougent plus par la suite.

Cette zone est déclarée en PRIMAIRE via cette option : type master;.

Vous pouvez nommer le fichier pour cette zone comme vous bon il vous semble grace à cette option : file "pri/localhost.zone";.

Aucune notification ne sera faite : notify no;

zone "127.in-addr.arpa"

Cette zone reprend les mêmes caractéristiques que la zone précédente.

type master; file "pri/127.zone"; notify no;



Voici les détails des fichiers de zone pour « localhost » et l'adresse IP 127.0.0.1 :

Les paramètres serial,refresh... sont détaillés à la section intitulée « Explications sur les entêtes de zone. ».

$TTL 7D
@       IN      SOA     serveur.archi.amt. root.localhost.  (
                    2007102702 ; Serial
                    1D                 ; Refresh
                    1D                 ; Retry
                    1W                 ; Expire - 1 week
                    1D )               ; Minimum
$TTL 1D
@       IN NS   serveur.archi.amt.
$TTL 7D
@       IN A    127.0.0.1

Vous pouvez utiliser cette solution sans modification ou presque. Le caractère @ représente le nom du domaine, celui qui est défini par la valeur zone ... dans le fichier named.conf. Vous pouvez allonger/modifier le temps de vie des données par des valeurs supérieures ou inférieures, à ce niveau elles n'ont pas d'incidence. c'est le fameux TTL (exemples 1H (heure), 1D (jour), 1W (semaine) ou 1M (mois)...).

$TTL 1W
@      IN SOA       serveur.archi.amt. root.localhost. (
                    2007101601   ; serial
                    1D                   ; refresh
                    12H                 ; retry
                    1W                   ; expiry
                    1D )                 ; minimum
$TTL 2D
                IN NS   serveur.archi.amt.
*               IN PTR  localhost.

Récupère les mêmes remarques que la zone précédente, mais concerne une zone REVERSE. A noter la présence du caractère « * » qui représente n'importe quelle valeur. Donc 127.0.0.2 correspond aussi à localhost.

Et voilà, à ce stade vous avez un serveur DNS, certes il ne gère pas grand chose mais doit pourvoir vous répondre. C'est un « parfait » ou le début d'un DNS cache.

Explications sur les entêtes de zone.

Je prend comme exemple, les données de la zone précédente (localhost).

Il est possible de déclarer dans une zone des alias comme pour votre service de méls. Si votre serveur s'appelle asterix.archi.amt, il peut devenir pop.archi.amt grace à cette ligne pop IN CNAME serveur.archi.amt. Les CNAME ne doivent pas être utilisées pour les champs SOA/NS/MX, bien qu'il les supporte largement, c'est une question purement technique et de logique DNS . Bind 9 n'aime PLUS (!) les multiples CNAME pour une même entité, il les gère tout de même.

Note

En général les instructions comme le numéro de série, le refresh ... sont présentées sous la forme ligne par ligne. Il est possible de les présenter comme ceci ( 2002081603 86400 86400 604800 86400 )

Gestion des traces (log).

Votre DNS est pour l'instant configuré en version minimale, il doit pouvoir écrire ses historiques d'évènements dans au moins un fichier. Avec Bind vous avez la possibilité de gérer ces données selon 2 modes : par syslog et par lui-même.

Personnellement je n'aime pas chercher les « logs » d'un serveur parmi l'ensemble des traces de mon système. Plus le système est détaillé et présenté de façon clair, et plus je suis heureux. C'est dans cette direction que je vais vous présenter comment Bind peut vous aider à gérer ses propres historiques. A noter tout de même que la gestion des historiques via Bind nécessite de sa part une part de ressource supplémentaire. Mais j'ai confiance aux développeurs de Bind, cette technique existe depuis plusieurs versions, et ne rencontre aucun problème...

La syntaxe.

Une fois de plus Bind fait dans la souplesse et la puissance, les traces sont adaptables exactement comme vous le voulez.

Les traces de Bind sont basées sur 3 valeurs : les canaux (channel), les catégories (category), et les critères de gravité (severity). Une bonne configuration est le mélange de tout cela, il est donc possible de faire un fichier de traces par canaux.

Les catégories d'historiques possibles.

Tableau 6.3. Les catégories.

Zone

Détail / Explication

default

C'est le canal par défaut, qui regroupe d'autres canaux si ils ne sont pas déclarés explicitement.

general

Concerne le canal d'usage général, les données, ses caches.

database

Bind peut être couplé à une base de type LDAP... A activer si vous utiliselez les fonctions LWRES (base de données), ces actions ne sont pas prises en compte dans ce document.

security

Concerne tous les problèmes de sécurité, permet de découvrir que vous avez oublié un réseau dans votre configuration (exemple)...

config

Concerne tous les problèmes de configuration de votre serveur.

resolver

Valable pour des requêtes particulières souvent provenant de DNS cache.

xfer-in | xfer-out

Enregistre tout ce qui concerne les transferts de zone. xfer-in pour les transferts entrants (IN), donc valable pour un secondaire. Et à l'inverse xfer-out pour les traces sortants dans le sens primaire vers le ou les secondaires. C'est pour moi une nécessité de différencier ces 2 canaux pour faciliter le suivi des transferts.

notify

Valable pour tout type de DNS primaire/secondaire, ce paramètre enregistre toutes les notifications. Mérite à mon avis son fichier, pour vous faciliter le suivi des notifications.

client

Concerne l'enregistrement des requêtes des clients, reste très similaire à la catégorie « resolver ».

unmatched

Hors classement...Je ne pense pas qu'elle doit être désactivée, c'est une possibilité de découvrir un problème pour Bind, même rare, mais qui n'est pas pris en compte dans une autre catégorie.

network

Concerne tout les problèmes réseaux ...

update | update-security

Ces 2 canaux sont réservés exclusivement au protocole DHCP.

queries

Concerne toutes les interrogation DNS.

Les symboles A | AAAA concerne une requête en IPV4 ou en IPv6. Le symbole + | - est une requête récursive ou itérative. Le symbole E correspond à une requête EDNS. (UDP supérieur à 512 octets et lié à DNSsec (Expliqué à la section intitulée « DNSsec. »).

dispatch

Concerne les paquets qui ont fait l'objet d'un traitement. Option possible jamais rencontré...

dnssec

Concerne tout ce qui concerne le chiffrement de données avec DNSsec et TSIG (expliqué par la suite).

lame-servers

Concerne uniquement les erreurs des serveurs qui se disent primaires mais ne gère pas la zone. Sur un réseau privatif, permet de découvrir les zones mal administrées/gérées ...Comme vous ne pouvez agir sur un DNS sur internet, cette option est à exclure pour internet.

delegation-only

Concerne uniquement les logs liées aux délégations de zones, de ce style « zone "COM" { type delegation-only; }; »



Les critères.

Voici les critères de gravité (severity), ils ne méritent pas d'explications complémentaires. Il sont classés par ordre d'importance, à l'exception des 2 derniers :

Les critères debug et dynamic correspondent à des niveaux de debuggages. Le niveau debug possèdent 3 niveaux de 1(défaut) à 3. Ces niveaux sont fixés contrairement au mode similaire « dynamic », qui porte bien son nom. Le mode dynamic selon les commandes rndc trace lancées au fur et à mesure, active un niveau supplémentaire en plus ou en moins au niveau du « debuggage ». Il faut signaler que ceci ne nécessite pas de relancer Bind, contrairement à l'option debug pour changer de niveau.

Personnellement je ne comprends pas tous les messages enregistrés avec l'option severity debug, Bind est très bien documenté, les types de messages qui en découlent restent pour moi une spécialité pour les développeurs Bind.

Voici un exemple pour information en mode debug 3 d'une simple notification, suivi d'un transfert de zone :

01-Dec-2007 19:55:13.128 client: debug 3: client 192.168.1.11#32768: UDP request
01-Dec-2007 19:55:13.128 client: debug 3: client 192.168.1.11#32768: notify
01-Dec-2007 19:55:13.128 general: debug 1: queue_soa_query: zone archi.amt/IN: enter
01-Dec-2007 19:55:13.128 client: debug 3: client 192.168.1.11#32768: send
01-Dec-2007 19:55:13.129 client: debug 3: client 192.168.1.11#32768: sendto
01-Dec-2007 19:55:13.129 client: debug 3: client 192.168.1.11#32768: senddone
01-Dec-2007 19:55:13.129 client: debug 3: client 192.168.1.11#32768: next
01-Dec-2007 19:55:13.129 client: debug 3: client 192.168.1.11#32768: endrequest
01-Dec-2007 19:55:13.129 client: debug 3: client @0xb631e008: udprecv
01-Dec-2007 19:55:13.129 general: debug 1: soa_query: zone archi.amt/IN: enter
01-Dec-2007 19:55:13.129 general: debug 3: dns_request_createvia
01-Dec-2007 19:55:13.129 general: debug 3: request_render
01-Dec-2007 19:55:13.129 general: debug 3: requestmgr_attach: 0xb7bf2e08: eref 1 iref 1
01-Dec-2007 19:55:13.129 general: debug 3: mgr_gethash
01-Dec-2007 19:55:13.129 general: debug 3: req_send: request 0xb7c163c8
01-Dec-2007 19:55:13.129 general: debug 3: dns_request_createvia: request 0xb7c163c8
01-Dec-2007 19:55:13.129 general: debug 3: req_senddone: request 0xb7c163c8
01-Dec-2007 19:55:13.130 general: debug 3: req_response: request 0xb7c163c8: success
01-Dec-2007 19:55:13.130 general: debug 3: req_cancel: request 0xb7c163c8
01-Dec-2007 19:55:13.130 general: debug 3: req_sendevent: request 0xb7c163c8
01-Dec-2007 19:55:13.130 general: debug 1: refresh_callback: zone archi.amt/IN: enter
01-Dec-2007 19:55:13.130 general: debug 3: dns_request_gêtresponse: request 0xb7c163c8
01-Dec-2007 19:55:13.130 general: debug 1: refresh_callback: zone archi.amt/IN: serial: new 2007112601, old 2007112401
01-Dec-2007 19:55:13.130 general: debug 3: dns_request_destroy: request 0xb7c163c8
01-Dec-2007 19:55:13.130 general: debug 3: req_destroy: request 0xb7c163c8
01-Dec-2007 19:55:13.130 general: debug 3: requestmgr_detach: 0xb7bf2e08: eref 1 iref 0
01-Dec-2007 19:55:13.130 general: debug 1: queue_xfrin: zone archi.amt/IN: enter
01-Dec-2007 19:55:13.130 general: info: zone archi.amt/IN: Transfer started.
01-Dec-2007 19:55:13.130 general: debug 1: zone archi.amt/IN: requesting IXFR from 192.168.1.11#53
01-Dec-2007 19:55:13.133 general: debug 3: dumping new zone version
01-Dec-2007 19:55:13.142 general: debug 3: removing journal file
01-Dec-2007 19:55:13.142 general: debug 3: replacing zone database
01-Dec-2007 19:55:13.142 database: debug 1: calling free_rbtdb(archi.amt)
01-Dec-2007 19:55:13.142 database: debug 1: done free_rbtdb(archi.amt)
01-Dec-2007 19:55:13.142 general: debug 1: zone archi.amt/IN: zone transfer finished: success
01-Dec-2007 19:55:13.142 general: info: zone archi.amt/IN: transferred serial 2007112601: TSIG 'serveur-second'
01-Dec-2007 19:55:13.142 general: debug 1: zone_timer: zone archi.amt/IN: enter
01-Dec-2007 19:55:13.142 general: debug 1: zone_maintenance: zone archi.amt/IN: enter

Voici la procédure :

Vous devez choisir la catégorie qui vous intéresse, ensuite je ne peux que conseiller de séparer un par un vos logs différents dans un fichier différent. Ensuite vous devez choisir le type d'affichage debug, critical,warning...info, puis vous devez déclarer le répertoire et les noms des fichiers désirés.

Dans l'exemple qui suit, il est à noter la non prise en compte de certaines catégories volontairement, car je n'utilise aucune délégation, de mises à jour(DHCP). La gestion de la catégorie « délégation » , comme toutes les autres peuvent être rendues inactives par l'option null, à placer dans la déclaration de catégorie.

Après des essais, le système de gestion des historiques globales comme logrotate™ est très pratique. celui-ci dans la nuit (en général), procède à la rotation automatique des fichiers d'historiques. Ce système fonctionne bien, mais par contre nécessite de relancer Bind. Cette conséquence est fâcheuse, car les caches sont vidées systématiquement, une série de notifications est lancées... les TTL supérieurs à 24 heures sont inutiles, sauf pour les autres DNS éventuellement. La solution réside par la gestion des logs par Bind lui-même, la procédure est simple et très souple, il suffit de rajouter deux options :

Pour en finir avec les versions et les tailles de vos fichiers, pensez bien à multiplier la valeur « version » et la valeur « size », ceci pour prévoir la place disponible sur votre disque. Pensez à adapter les valeurs selon votre réseau, une valeur pour mon DNS de 4G, devrait faire que Bind procédera à sa rotation en 2012...

Ce fichier est à enregistrer là ou le fichier named.conf est présent. Pour activer ce fichier, il suffit d'inclure la directive include "/etc/bind/logging.inc"; et c'est tout (relancé Bind tout de même). Cette ligne ne doit pas être incluse dans une section, personnellement elle est présente juste après les options globales. Vous pouvez bien évidemment prendre un autre nom pour ce fichier...

Voici un exemple de configuration pour les historiques, avec des valeurs assez petites.

////////////////////////////////////////////////
// Systeme de gestion des historiques pour BIND.
// fichier : /etc/named/logging.inc
// Declaration des channels
///////////////////////////

logging {
        // Concerne les problemes de securite
        channel security_channel {
                file "/var/log/named/security.log" versions 2 size 500K ;
                severity info;
                print-time yes;
                };

        // Concerne les log divers 
        channel default_channel {
                file "/var/log/named/default.log" versions 2 size 1M ;
                severity dynamic;
                print-category yes;
                print-severity yes;
                print-time yes;
                };
        
        // Concerne les tranferts entrants (zones slave|stub)
        channel xfer-in_channel {
                file "/var/log/named/xfer-in.log" versions 1 size 500K ;
                severity info;
                print-time yes;
                };

        // Concerne les tranferts sortants (zones master)
        channel xfer-out_channel {
                file "/var/log/named/xfer-out.log" versions 1 size 500K ;
                severity info;
                print-time yes;
                };

        // log les notifcations uniquement
        channel notify_channel {
                file "/var/log/named/notify.log" versions 1 size 100K ;
                severity info;
                print-time yes;
                };
                
        // historique des requêtes sur votre serveur
        channel querylog {
                file "/var/log/named/query.log" versions 10 size 400K ;
                severity info;
                print-time yes;
                };
                
        // historique des LAME-SERVER
        channel lame_channel {
                file "/var/log/named/lame.log" versions 1 size 100K ;
                severity info;
                print-time yes;
                };
        
// Activation des CANAUX ///////////////        
        
        /* activer si delegation de zone
        category delegation-only { default_channel; };
        */
        // si pas internet ...ou pour info
        category lame-servers { lame_channel; };
        category update { null; };
        category notify { notify_channel; };
        category xfer-out { xfer-out_channel;};
        category xfer-in { xfer-in_channel; };
        category default { default_channel; };
        category queries { querylog; };
        category client { querylog; };
        category resolver { querylog; };
        
        category unmatched { default_channel; };
        category security { security_channel; };
        
        // si DNSsec     
        category dnssec { security_channel; };

};
////////   FIN   /////////

Avertissement

Si vous adoptez la technologie : une catégorie = un fichier, le paramètre print severity yes;, ne sert à rien, sauf à remplir un champ qui est déjà inclus dans le nom du fichier.

Dans mes exemples, tous les canaux affichent des données pour information au minimum, à l'exception du canal « défaut ». Celui-ci affiche des détails sur la catégorie via l'option print-category;. Cette option est nécessaire par la multitude des logs à ce niveau, parfaitement inutile ailleurs.

Voici les fichiers crées conformément au précédent fichier de configuration.

-rw-rw---- 1 named named  23665 Nov  8 19:35 default.log
-rw-rw---- 1 named named    117 Nov  6 22:29 lame.log
-rw-rw---- 1 named named  24741 Nov  8 19:27 notify.log
-rw-rw---- 1 named named    820 Nov  8 19:39 query.log
-rw-rw---- 1 named named   4518 Nov  8 19:37 query.log.0
-rw-rw---- 1 named named 385623 Nov  8 18:54 query.log.1
-rw-rw---- 1 named named     93 Nov  4 08:25 security.log
-rw-rw---- 1 named named      0 Oct 29 07:20 xfer-in.log
-rw-rw---- 1 named named   2404 Nov  4 08:55 xfer-out.log

Note

Il ne faut pas oublier et surtout lors des problèmes éventuels lors du lancement de Bind, que celui-ci écrit également dans le fichier /var/log/messages.Voici un exemple :

Nov 25 09:21:55 serveur named[8763]: starting BIND 9.4.2rc2 -u named -n 2 -4
Nov 25 09:21:55 serveur named[8763]: found 2 CPUs, using 2 worker threads
Nov 25 09:21:55 serveur named[8763]: loading configuration from '/etc/bind/named.conf'
Nov 25 09:21:55 serveur named[8763]: listening on IPv4 interface eth1, 192.168.1.11#53
Nov 25 09:21:55 serveur named[8763]: listening on IPv4 interface lo, 127.0.0.1#53
Nov 25 09:21:55 serveur named[8763]: command channel listening on 127.0.0.1#953

Ensuite Bind écrit dans ses propres fichiers les historiques...

Attention

Si votre serveur possède au moins une zone en secondaire|primaire, gardez l'enregistrement des historiques des commandes AXFR|IXFR. En éffet ces commandes seront inscrites dans le fichier xfer-out. Ceci vous permet de connaîre qui vient ou à essayer de récupérer une zone, même si toutes les options interdisent cette transaction.

Exemples d'historiques :

Pour le fichier

15-Dec-2007 12:17:13.374 general: notice: running
15-Dec-2007 12:17:13.374 general: warning: zone sous.archi.amt/IN: expired
15-Dec-2007 12:17:13.385 general: warning: zone stub.archi.amt/IN: expired
15-Dec-2007 12:18:43.374 general: info: zone sous.archi.amt/IN: refresh: retry limit for master 192.168.1.15#53 exceeded (source 0.0.0.0#0)
15-Dec-2007 12:18:43.374 general: info: zone sous.archi.amt/IN: Transfer started.
15-Dec-2007 12:32:34.896 general: info: zone stub.archi.amt/IN: refresh: retry limit for master 192.168.1.15#53 exceeded (source 0.0.0.0#0)
15-Dec-2007 16:06:19.391 general: info: zone sous.archi.amt/IN: Transfer started.
15-Dec-2007 16:06:34.896 general: info: zone stub.archi.amt/IN: refresh: retry limit for master 192.168.1.15#53 exceeded (source 0.0.0.0#0)
15-Dec-2007 19:00:53.105 general: info: received control channel command 'reload archi.amt'
15-Dec-2007 19:00:56.467 general: info: received control channel command 'reload'
15-Dec-2007 19:00:56.467 general: info: loading configuration from '/etc/bind/named.conf'
15-Dec-2007 19:00:56.536 general: info: reloading configuration succeeded
15-Dec-2007 19:00:56.547 general: info: zone sous.archi.amt/IN: loaded serial 2007112501
15-Dec-2007 19:00:56.575 general: info: zone stub.archi.amt/IN: loaded serial 2007112302
15-Dec-2007 19:00:56.576 general: info: reloading zones succeeded
15-Dec-2007 19:00:56.577 general: warning: zone sous.archi.amt/IN: expired
15-Dec-2007 19:00:56.577 general: warning: zone stub.archi.amt/IN: expired
15-Dec-2007 19:01:00.843 general: info: received control channel command 'flush'
15-Dec-2007 19:01:00.848 general: info: flushing caches in all views succeeded
15-Dec-2007 19:01:05.641 general: info: received control channel command 'notify'
15-Dec-2007 19:01:09.425 general: info: received control channel command 'notify archi.amt'

Rien de bien spécial dans ces log, à l'exception de la zone « sous.archi.amt » qui faute d'un transfert à expirer. En conséquence, Bind tente régulièrement de joindre mon autre PC (primaire de cette zone).

Pour le fichier query.log

15-Dec-2007 19:06:47.079 client 127.0.0.1#32844: query: serveur.archi.amt IN A +
15-Dec-2007 19:06:47.079 client 192.168.1.11#32844: query: localhost IN SOA -
15-Dec-2007 19:06:54.749 client 127.0.0.1#32844: query: 1.0.0.127.in-addr.arpa IN PTR +
15-Dec-2007 19:06:54.750 client 127.0.0.1#32844: query: serveur.archi.amt IN A +
15-Dec-2007 19:06:54.750 client 192.168.1.11#32844: query: 1.0.0.127.in-addr.arpa IN SOA -
15-Dec-2007 19:07:01.965 client 127.0.0.1#32844: query: 1.0.0.127.in-addr.arpa IN PTR -
15-Dec-2007 19:07:30.259 client 127.0.0.1#60624: query: archi.amt IN AXFR -ED
15-Dec-2007 19:07:40.160 client 127.0.0.1#48452: query: archi.amt IN SOA +ED
15-Dec-2007 19:07:52.868 client 127.0.0.1#32844: query: archi.amt IN NS +ED
15-Dec-2007 19:08:53.975 client 127.0.0.1#32846: query: . IN NS -
15-Dec-2007 19:08:53.977 client 127.0.0.1#32846: query: C.ROOT-SERVERS.NET IN A +
15-Dec-2007 19:08:54.149 client 127.0.0.1#32847: query: F.GTLD-SERVERS.NET IN A +
15-Dec-2007 19:08:54.476 client 127.0.0.1#32848: query: ns2.google.com IN A +
15-Dec-2007 19:26:33.966 client 192.168.1.15#1024: query: archi.amt IN SOA -SE
15-Dec-2007 19:26:34.042 client 192.168.1.15#3349: query: archi.amt IN AXFR -S
15-Dec-2007 19:26:34.466 client 192.168.1.15#1024: query: 1.168.192.in-addr.arpa IN SOA -SE
15-Dec-2007 19:26:34.468 client 192.168.1.15#4022: query: 1.168.192.in-addr.arpa IN AXFR -S

Vous avez dans ce fichier un peu de tout, comme du récursif, du reverse, du TSIG et même du DNSsec...

Pour le fichier notify.log

05-Dec-2007 20:08:22.385 zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 2007112101)
05-Dec-2007 20:34:08.176 zone archi.amt/IN: sending notifies (serial 2007120202)

Pour le fichier security.log

15-Dec-2007 19:22:28.525 client 192.168.1.15#1025: request has invalid signature: TSIG serveur-second: tsig verify failure (BADTIME)
    15-Dec-2007 19:22:29.029 client 192.168.1.15#1025: request has invalid signature: TSIG serveur-second: tsig verify failure (BADTIME)

Ceci sera vu plus tard dans le document, mais une erreur importante concernat la sécurité est indiquée. Pour cette exemple, une différence entre les horaires de mes 2 machines était la cause (-1 heure).

Pour syslog :

Avertissement

N'étant pas favorable à un rassemblement des fichiers ou des données d'historiques dans un fichier unique, je détaille cette possibilité que succinctement.

Voici un exemple possible utilisable avec syslog :

  logging {
    channel vers-syslog {
           syslog daemon;
           severity info;
    }
                    
  category  default { vers-syslog; }
  category  queries { vers-syslog; }
  category  xfer-out { null; }
 }
                     

La syntaxe « logging ».

logging {
   [ channel channel_name {
     ( file path name
         [ versions ( number | unlimited ) ]
         [ size size spec ]
       | syslog syslog_facility
       | stderr
       | null );
     [ severity (critical | error | warning | notice |
                 info | debug [ level ] | dynamic ); ]
     [ print-category yes or no; ]
     [ print-severity yes or no; ]
     [ print-time yes or no; ]
   }; ]
   [ category category_name {
     channel_name ; [ channel_name ; ... ]
   }; ]
   ...
   };

Chapitre 7. Les enregistrements dans une zone.

Avant de concevoir et gérer une zone, il est nécessaire de connaître ce qui peut être gérer ou pas... Voici un échantillon des types les plus utilisés, il en existe beaucoup y compris pour la géolocalisation, DNSsec....

Chapitre 8. La gestion de zone (primaire + secondaire)

Table des matières

La gestion d'une zone en primaire et sur un secondaire.
Sur le serveur primaire :
Sur le serveur(S) secondaire(S) :
Le même style mais pour la REVERSE :
La délégation et gestion de plusieurs zones « REVERSES. »

La gestion d'une zone en primaire et sur un secondaire.

Nous allons travailler sur une zone totalement fictive, et bien sure non présente sur internet. Le nom choisi est « archi.amt » qui du point de vue internet ne représente rien, et c'est volontaire. Mais ceci me permet de posséder mon DNS primaire et secondaire sans rien demander... et aussi c'est important sans perturber personne. C'est totalement transparent, il me suffit de compléter ceci par un chnagement de domaine au niveau de mon serveur de méls et le tour est joué.

Sur le serveur primaire :

Maintenant que notre serveur primaire fonctionne, il suffit de transférer ou recopier les fichiers de configurations du primaire vers votre secondaire. Il est nécessaire de les adapter, mais ceci doit représenter un travail rapide et facile. Ensuite vous pouvez le lancer.

Le nom de domaine « archi.amt » possède la plage IP : 192.168.1.0/24.

zone "archi.amt" IN {
        type master;
        file "pri/archi.amt";
        allow-transfer { 192.168.1.15; };
        notify yes;
};
//////////////////////////////////
zone "1.168.192.in-addr.arpa" IN {
        type master;
        file "pri/1.168.192.in-addr.arpa";
        allow-transfer { 192.168.1.15; };
        notify yes;
};

La déclaration d'une zone commence toujours par « zone nom { options et paramètres divers; } ». Elle gère le domaine archi.amt, elle est déclarée comme primaire par la valeur type master;. Le paramètre facultatif allow-update {none;} ne permet pas la mise à jour dynamique (DHCP). Il est facultatif ou même inutile, car déjà traiter dans les options globales. Par contre allow-transfer { 192.168.1.15: }, désigne le ou les adresses IP des serveurs secondaires qui peuvent transférer la zone. C'est un paramètre primordial. Je peux transférer cette zone comme d'autres en local (127.0.0.1), car ceci est déclaré dans les options globales. La notification est demandée par le paramètre notify yes;. Ce paramètre permet dès une modification sur cette zone de prévenir le ou les secondaires. C'est une sorte d'annonce "ma zone a bougé...", elle déclenche sur les secondaires les transferts.

Vous avez dans cette zone des déclarations de type ressource (RP) et texte (TXT). Elles restent totalement facultatives, mais peuvent apporter un petit plus.

Vous avez également des déclarations d'alias sous la forme CNAME, ceci permet de transformer certaines valeurs, exemple : pop.archi.amt et/ou smtp.archi.amt peuvent pointer vers serveur.archi.amt. C'est très souvent utilisé dans les zones (www, smtp,ftp;ldap...), par contre ces déclarations ne doivent pas être déclarées dans une champ SOA|NS|MX... il sont à considérer comme des additifs et non des éléments essentiels.

Autre champ ou type important, ou très utilisé, le MX ( Mail eXchanger), il correspond à la désignation du serveur de méls. Ce champ doit posséder un chiffre après les lettres MX. Ceci permet de faire un classement et de les contacter l'un après l'autre en cas de non réponse. Avec ma valeur de 10 sur mon seul serveur, le chiffre 1 ou 100 sont à égalité. La numérotation est totalement libre à condition d'être incrémentée.

Vous pouvez trouver toutes les options pour la section zone ici : options-zone

La zone primaire :

$TTL 24H
@       IN      SOA     serveur.archi.amt.  laurent.serveur.archi.amt. (
                        2007110101 ; serial
                        1D         ; refresh
                        1H         ; retry
                        1W         ; expiry
                        1D )       ; minimum
@       IN NS   serveur.archi.amt.
        IN NS   second.archi.amt.
;
$TTL 12H
serveur         IN A    192.168.1.11
@           3600   IN TXT "Serveur DNS de Archi"
@           3600   IN TXT "01.02.03.0512 De 10h00 a 10h05"
@           3600   IN RP  Jean.Paul.domain.com Admin.pour.Bind
@           3600   IN RP  Maurice.domain.com  Mise.a.jour.des.donnees

$TTL 6H
                IN MX 10 serveur.archi.amt.
pop             IN CNAME serveur.archi.amt.
smtp            IN CNAME serveur.archi.amt.
;               IN MX 20 second.archi.amt.   ;; pour un 2eme ...
;
$TTL 1D
second          IN A    192.168.1.15
$TTL 2D
dm              IN A    192.168.1.100
fh              IN A    192.168.1.20
test            IN A    192.168.1.22

Petites explications sur certains paramètres :

La déclaration d'une machine dans une zone se déclare par son-nom IN A son-ip, sans le caractère « . » en fin de ligne. Cette solution est pratique, il est nécessaire de ne placer aucun « . » après le nom de machine. En effet Bind interprète le « . » comme la fin d'une déclaration complète, domaine compris (!). Et cette erreur est fatale...mais décelable facilement. Ceci reste valable aussi pour les zones REVERSES. La déclaration des serveurs secondaires se déclarent par les paramètres NS, le @ représente pour Bind le domaine complet, vous évitant de l'écrire. Cette valeur est récupérée depuis les informations de déclarations du fichier named.conf. Le paramètre * peut représenter toutes les valeurs, au niveau des zones REVERSES. Comme vous pouvez le voir le changement de durée de vie d'un enregistrement se fait au cas par cas. Le premier TTL souvent d'une journée, concerne la zone complète, et aussi une valeur par défaut.

Avertissement

Une zone secondaire est en quelque sorte une copie de sauvegarde pour le primaire, et une source(s) de données pour le réseau. En aucun cas, un administrateur ne doit modifier les données d'une zone secondaire, c'est le rôle exclusif du primaire.

Sur le serveur(S) secondaire(S) :

Voici le named.conf pour le secondaire, puis la « copie » de la zone archi.amt.

//////////////////////////////////
// EXEMPLE FORWARD SLAVE
//////////////////////////////////
zone "archi.amt" IN {
        type slave;
        file "sec/archi.amt";
        masters { 192.168.1.11; };
        forwarders {};                  // inutile d'aller voir ailleurs - Facultatif
        allow-transfer { none;};    // pas de transfert possible
};
//////////////////////////////////
// EXEMPLE REVERSE SLAVE
//////////////////////////////////
zone "1.168.192.in-addr.arpa" IN {
        type slave;
        file "sec/1.168.192.in-addr.arpa";
        masters { 192.168.1.11; };
        forwarders {};                    // inutile d'aller voir ailleurs - Facultatif
        allow-transfer { none;};      // pas de transfert possible
};
//////////////////////////////////

C'est réellement la copie du « master » mais avec les adaptations nécessaires pour un secondaire. Donc désormais le paramètre type est type slave;. L'emplacement du fichier est différent et non ambigu « sec » pour secondaire au lieu de « pri ». Vous êtes libre de faire ce que vous voulez pour le nommage et le choix de l'emplacement du ou des fichiers secondaires, le cloisonnement reste tout de même la meilleur solution. Le paramètre master { 192.168.1.11; }; identifie le serveur primaire par son IP. Ce paramètre est capitale, c'est cette option qui permet les dialogues de mises à jour des zones. Ensuite on retrouve le paramètre forwarder {};, théoriquement les zones sont identiques entre le primaire et le secondaire. Il est donc inutile d'aller voir ailleurs si ce serveur ne connaît pas l'information. C'est ce que représente cette option. Elle reste facultative, elle pourrait par contre être mieux utilisée dans un DNS en frontal sur internet, avec une zone réduite, comportant que des champs importants comme le MX, la déclaration de serveurs divers (WWW...). Cette valeur est donnée ici à titre d'exemple. Et le transfert de zone est interdit, c'est la mission du serveur primaire vis à vis de ces secondaires. C'est à lui de gérer, bien qu'un secondaire puisse transférer une zone vers un autre secondaire, vers un client qui le demande...

Voici la copie de la zone après un transfert, toutes les données sont là, dans l'ordre de Bind.

ORIGIN .
$TTL 86400      ; 1 day
archi.amt               IN SOA  serveur.archi.amt. laurent.serveur.archi.amt. (
                                2007112601 ; serial
                                86400      ; refresh (1 day)
                                7200       ; retry (2 hours)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
                        NS      serveur.archi.amt.
                        NS      second.archi.amt.
$TTL 21600      ; 6 hours
                        MX      10 serveur.archi.amt.
$TTL 3600  ; 1 hour
                        TXT     "Serveur DNS de Archi"
                        TXT     "01.02.03.0512 De 10h00 a 10h05"
                        RP      Jean.Paul.domain.com.archi.amt. Admin.pour.Bind.archi.amt.
                        RP      Maurice.domain.com.archi.amt. Mise.a.jour.des.donnees.archi.amt.
$ORIGIN archi.amt.
$TTL 172800     ; 2 days
dm                      A       192.168.1.100
$TTL 172800     ; 2 days
fh                      A       192.168.1.20
$TTL 21600      ; 6 hours
pop                     CNAME   serveur
$TTL 86400      ; 1 day
second                  A       192.168.1.15
$TTL 43200      ; 12 hours
serveur                 A       192.168.1.11
$TTL 86400      ; 1 day
$TTL 21600      ; 6 hours
smtp                    CNAME   serveur
$TTL 86400      ; 1 day
$TTL 172800     ; 2 days
test                    A       192.168.1.22
$TTL 86400      ; 1 day

Le même style mais pour la REVERSE :

La gestion d'une zone REVERSE est similaire, bien que très spécifique, en particulier lors d'une délégation de zone.

Voici ma REVERSE en liaison avec ma plage IP privative, et des machines totalement virtuelles...

$TTL 24H
@       1H      IN      SOA     serveur.archi.amt. laurent.serveur.archi.amt. (
                        2007102701  ; serial
                        12H        ;
                        1H          ;
                        1W          ;
                        1H )        ;
$TTL 12H
            IN NS   serveur.archi.amt.
            IN NS   second.archi.amt.
$TTL 1M
1           IN PTR  routeur.archi.amt.
$TTL 3H
10          IN PTR  serveur.archi.amt.
$TTL 2H
15          IN PTR  second.archi.amt.
$TTL 1D
100         IN PTR  dm.archi.amt.
11           IN PTR  serveur2.archi.amt.
100         IN PTR  dm.archi.amt.
22           IN PTR  test.archi.amt.
20           IN PTR  fh.archi.amt.

Notez bien que toutes les machines sont déclarées intégralement (FQDN), et se terminent toutes par un « . ». L'erreur à ce niveau, est fatale...

Pour activer cete zone au niveau du secondaire, il suffit de procéder comme pour la zone FORWARD.

La délégation d'une zone FORWARD.

C'est très simple, c'est une inversion des roles entre un primaire et un secondaire. Ceci est du à la présence en particulier de la zone parente, celle ci doit connaître qu'il existe un sous domaine. Pour information, un sous domaine n'est pas obligé d'être délégué. Pour cette situation il suffit de remplir la zone parente avec les données de la sous zone (sous-domaine). Si les données sont nombreuses, il existe l'option $INCLUDE pour cela.

Note

Pour des besoins spécifiques, il existe la zone type FORWARD. Elle est implémentée pour diriger les requêtes vers un domaine non géré sur une machine ou un réseau. C'est évidemment peu utilisé, et ne rentre pas forcément dans ce cadre de la délégation...

Le terme de zone « fille » va être employé, il désigne une zone, ou plus exactement un sous domaine géré par un autre serveur(s). Si vous recherchez réellement une grande dépendance entre la zone parente et sa zone « fille », prenez le choix de la délégation classique. Pour l'effet inverse, dans le style « chacun dans son coin, si la sous zone est mal gérée c'est pas mon problème » , la déclaration en tant que zone stub est idoine.

Avertissement

La zone parente doit toujours avoir une trace de sa ou ces sous zones, c'est un impératif.

Voici comment activer un sous domaine dans une zone parente. Il suffit de rajouter cette instruction $ORIGIN sous.archi.amt. et de continuer avec les données de ce sous domaine.

$TTL 24H
@       IN      SOA     serveur.archi.amt.  laurent.serveur.archi.amt. (
                        2007112601 ; serial
                        1D         ; refresh
                        2H         ; retry
                        1W         ; expiry
                        1D )       ; minimum
@       IN NS   serveur.archi.amt.
         IN NS   second.archi.amt.
$TTL 1D
serveur         IN A    192.168.1.11
second          IN A    192.168.1.15
$TTL 2D
dm              IN A    192.168.1.100
;
;   Activation de mon sous somaine sous.archi.amt
;
$ORIGIN sous.archi.amt.
$TTL 1D
sd1              IN A      192.168.1.250
sd2              IN A      192.168.1.251

La délégation et gestion de plusieurs zones « REVERSES. »

La gestion d'une zone REVERSE n'est pas plus difficile qu'une autre. Ce qui est particulier, c'est qu'une plage d'adresses IP peut être répartie sur plusieurs sites, le problème est là. Il est nécessaire de gérer tout ceci le mieux possible, sans que le travail soit fait sur un seul serveur ou administrateur. Les exemples vont se baser sur la plage 192.168.1.0/24 que je vais scinder en deux.

Voici les plages de 192.168.1.0 à 192.168.1.150/24, et de 192.168.1.151 à 192.168.1.254/24 (le reste). La 1ere plage est hébergée sur le serveur « serveur » et la seconde plage sur le serveur DNS « second » (le nommage des machines est parfois important...). Voici comment pourrait être délégué les adresses IP :

        1.1.168.192.in-addr.arpa.    86400    IN NS serveur.archi.amt.
        1.1.168.192.in-addr.arpa.    86400    IN NS second.archi.amt.
        2.1.168.192.in-addr.arpa.    86400    IN NS serveur.archi.amt.
        2.1.168.192.in-addr.arpa.    86400    IN NS second.archi.amt.
        ... etc ...
        151.1.168.192.in-addr.arpa.    86400    IN NS second.archi.amt.
        151.1.168.192.in-addr.arpa.    86400    IN NS serveur.archi.amt.
        ... etc ...
        254.1.168.192.in-addr.arpa.    86400    IN NS second.archi.amt.
        254.1.168.192.in-addr.arpa.    86400    IN NS serveur.archi.amt.

C'est fiable mais long, mais mérite d'être claire. Pour palier ceci il est possible de traiter les adresses IP (REVERSES !) différemment, pour cela Bind met à votre disposition l'instruction : $GENERATE. Voici comment générer toutes les lignes de la même façon pour un même résultat :

            $GENERATE 0-150       $.1.168.192.in-addr.arpa.    86400    IN NS serveur.archi.amt.
            $GENERATE 0-150       $.1.168.192.in-addr.arpa.    86400    IN NS second.archi.amt.
            ; Bascule de NS 
            $GENERATE 151-254      $.1.168.192.in-addr.arpa.    86400    IN NS second.archi.amt.
            $GENERATE 151-254      $.1.168.192.in-addr.arpa.    86400    IN NS serveur.archi.amt.
        

Avec une seule plage d'adresses, cette solution est un peu lourde. La solution de prendre une autre plage réseau pour un sous réseau est de loin préférable (192.168.1.0 et 192.168.2.0 par exemple). Pour information, Bind comme d'autres serveurs ne gère pas les masques.

Autant il est facile de gérer des zones FORWARD, par contre une plage IP distribuée sur plusieurs DNS pose réellement un problème. Soit vous pouvez découper votre plage à un octets précis (192.168.1 et 192.168.2...), puis faire gérer les derniers octets par plusieurs serveurs. Ou alors la situation n'est pas simple, et ne trouve pas de solution du coté de Bind. La solution ultime consiste à partager cette zone critique entres chaque administrateurs. Il existe des outils pour cela comme « webmin », un accès SSH... (Autre programmes et utilitaires DNS)

Chapitre 9. Contrôle des transferts.

Vous pouvez contrôler par téléphone, en vous déplaçant, mais Bind apporte toutes les solutions sans bouger.

Si vous avez suivi ma configuration, il suffit de regarder dans les fichiers : /var/log/named/notify.log, puis dans /var/log/named/xfer-out.log. Vous devriez apercevoir des lignes comparables à celles ci. Il est à noter que les notifications peuvent être émises plusieurs fois. Bind ne transfère pas la zone systématiquement, il est impératif que le serial, soit différent entre le primaire et le secondaire(s).

Voici les historiques sur les différentes machines/serveurs :

Sur le primaire :

27-Oct-2007 13:33:20.954 zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 2007102701)
27-Oct-2007 18:15:23.200 zone archi.amt/IN: sending notifies (serial 2007102706)
    

. Et depuis le secondaire, vous pouvez constater que le transfert est éffectué.

Voici le résultat depuis le fichier de transfert sur le primaire (ne pas prendre en compte les horaires ...), les historiques sur le secondaire sont similaires...

27-Oct-2007 09:40:01.618 client 192.168.1.15#4941: transfer of 'archi.amt/IN': AXFR-style IXFR started
27-Oct-2007 09:40:01.618 client 192.168.1.15#4941: transfer of 'archi.amt/IN': AXFR-style IXFR ended
27-Oct-2007 18:56:10.676 client 192.168.1.15#1867: transfer of '1.168.192.in-addr.arpa/IN': AXFR-style IXFR started
27-Oct-2007 18:56:10.682 client 192.168.1.15#1867: transfer of '1.168.192.in-addr.arpa/IN': AXFR-style IXFR ended

Au niveau d"un secondaire, les traces sont identiques (mais inversées).

27-Oct-2007 18:56:11.218 xfer-in: info: transfer of '1.168.192.in-addr.arpa/IN' from 192.168.1.11#53: connected using 192.168.1.15#1867
27-Oct-2007 18:56:11.226 xfer-in: info: transfer of '1.168.192.in-addr.arpa/IN' from 192.168.1.11#53: end of transfer

Et comme nous sommes en plein dans les transferts, Bind fait aussi bien des transferts en AXFR (zone complète), comme uniquement les mises à jour via le mode IXFR. Le premier transfert de zone est obligatoirement en AXFR.

Avertissement

Ceci sera expliqué dans la la section intitulée « Piloter Bind (rndc). », voici les commandes à faire après une modification sur une zone primaire : rndc reload archi.amt ; rndc notify archi.amt. Le résultat est immédiat, le secondaire(s) à demandé un transfert de zone :

02-Dec-2007 08:06:56.820 general: info: zone archi.amt/IN: Transfer started.
02-Dec-2007 08:06:56.875 general: info: zone archi.amt/IN: transferred serial 2007120201
02-Dec-2007 08:07:04.146 general: info: zone archi.amt/IN: notify from 192.168.1.11#32768: zone is up to date

Chapitre 10. Lancer Bind.

Table des matières

Les logs au lancement.

Il va être temps de lancer notre serveur, j'ai dans le chapitre précédent présenté déjà des historiques...

La commande est simple, elle doit être reprise dans chaque distribution par le fichier /etc/init.d/named, bind9 chez Ubuntu.

Avertissement

Suite à des problèmes, il faut retirer le cas échéant de votre distribution le programme avahi. Celui ci perturbe Bind par ses propres écritures dans divers fichiers. Voici la commande radicale pour Ubuntu sudo update-rc.d -f avahi-daemon remove.

Ce fichier ne fait que lancer la commande suivante : /usr/sbin/named. Il est obligatoire d'ajouter des options, voici les paramètres utilisables :

usage: named [-4|-6] [-c conffile] [-d debuglevel] [-f|-g] [-n number_of_cpus]
             [-p port] [-s] [-t chrootdir] [-u username]
             [-m {usage|trace|record|size|mctx}]

Note

Le mode -m affiche des données difficilement compréhensibles ...

Les logs au lancement.

Il suffit de regarder dans le fichier /var/log/messages, pour moi c'est une obligation de regarder dans ce fichier...au moins au tout début.

Nov  1 16:57:28 serveur named[14435]: starting BIND 9.4.1-P1 -u named -n 2 -4
Nov  1 16:57:28 serveur named[14435]: found 2 CPUs, using 2 worker threads
Nov  1 16:57:28 serveur named[14435]: loading configuration from '/etc/bind/named.conf'
Nov  1 16:57:28 serveur named[14435]: listening on IPv4 interface eth1, 192.168.1.11#53
Nov  1 16:57:28 serveur named[14435]: listening on IPv4 interface lo, 127.0.0.1#53
Nov  1 16:57:28 serveur named[14435]: command channel listening on 127.0.0.1#953

Donc rien d'exceptionnel, tout se déroule comme il faut.

Il faut obligatoirement regarder le déroulement du lancement de Bind dans ce fichier également :/var/log/named/defaul.log. C'est ici que toutes les erreurs non fatales pour le service DNS sont référencées ... Voici un exemple de déroulement classique, toutes les zones sont chargées :

01-Nov-2007 16:57:28.145 general: info: zone archi.amt/IN: loaded serial 2007102802
01-Nov-2007 16:57:28.145 general: info: zone stub.archi.amt/IN: loaded serial 2007102802
01-Nov-2007 16:57:28.146 general: info: zone 0.0.127.in-addr.arpa/IN: loaded serial 2002081603
01-Nov-2007 16:57:28.146 general: info: zone 1.168.192.in-addr.arpa/IN: loaded serial 2007103101
01-Nov-2007 16:57:28.146 general: info: zone localhost/IN: loaded serial 2008102702
01-Nov-2007 16:57:28.146 general: notice: running
    

Si le serveur est primaire pour au moins une zone, lors de son lancement il notifie obligatoirement les secondaires pour cette zone. Il faut donc ne pas hésiter à regarder le fichier de notifications et des transferts, si nécessaire.

Chapitre 11. Les « ACL » et les « VIEW ».

Table des matières

Les listes de contrôle d'accès (ACL) :
Les VIEW.

Avertissement

LES ACL et les VIEW sont particulièrement utilisées pour les administrateurs de DNS, en effet elles simplifient la lecture du fichier de configuration(s). C'est pas le but recherché des ACL (bien que) et des VIEW...

Les listes de contrôle d'accès (ACL) :

Il est préférable de séparer le fichier de configuration classique named.conf avec les données pour les ACL. Il suffit de créer (exemple) le fichier : acl.inc. Sa prise en compte dans le fichier de configuration se fait par le paramètre include /etc/bind/acl.inc., et comme nous avons toucher la configuration principale, il faut relancer Bind. Les instructions d'importations de ces fichiers ne se font pas dans la section « options », ... dès le début est je pense une bonne place. Cette position vous permet de les utiliser dans les options justement. La procédure reste identique pour le fichier des VIEW.

Je vais donc créer 4 ACL (plus que mes machines) à titre d'exemple. Les noms des ACL importent peu, ils peuvent être en minuscules ou en majuscules sans problème. Vous ne pouvez utiliser pour un nommage les valeur suivantes, par contre elles peuvent servir à l'intérieure d'une déclaration : any (tout le monde) none (personne) localhost (la machine en local) localnets (votre réseau d'appartenance (!))

Voici la syntaxe pour créer des ACL :

acl "acl-nom" {
       adressesIP|acl-nom|une_plage;
       };

Voici le résultat dans le fichier appelé « acl.inc ». Il est à noter qu'il est possible d'utiliser une liste (ACL) après déclarations (!) dans une autre. Donc j'aurais pu créer cette liste : « ALL » incluant INTERNE+ESCLAVE+ADMIN (ou any ...). Il suffit de placer les valeurs suivantes pour le faire à titre d'exemple :

/////////////////////////////////////
// Fichier reserve aux ACL
// /etc/bind/acl.inc
/////////////////////////////////////
//-----------------------------------
// Emploi de (!) = qui ne correspond pas compris a ...
// Reserve pour internet
        acl "EXTERNE" {
                !localhosts;
                !localnets;
        };
//-----------------------------------
// Reserve pour internet
        acl "INTERNE" {
                localhost;
                localnets;
                192.168.1/24;
        };
//-----------------------------------
// Reserve pour le/les secondaire(s)...
// un acl par slave est largement faisable ...
        acl "SECOND" {
                192.168.1.15;
        };
//-----------------------------------
// Reserve pour les admins ...
        acl "ADMINS" {
                192.168.1.11;
                192.168.1.15;
                192.168.1.100;
        };
//----------------------------------
////////// FIN ///////////

Vous pouvez donc utiliser les ACL désormais, voici un extrait de mon fichier de configuration modifié/adapté :

   allow-recursion { INTERNE; };
  // Qui peut questionner le serveur ...
  allow-query { INTERNE; };
  // Qui peut questionner les caches du serveur ...
  allow-query-cache { INTERNE; };
};
//////////////////////////////////
zone "archi.amt" IN {
        type master;
        file "pri/archi.amt";
        allow-transfer { SECOND; };
        }

Avertissement

Bien évidemment j'ai essayé et ceci se traduit par un échec assez inexplicable : il ne faut pas utiliser les ACL avec les options forwarders.

Il est claire que les ACL apportent une compréhension du fichier de configuration plus aisée.

Les VIEW.

Les vues (VIEW) permettent plus de réaliser plus d'actions précises que les ACL. Elles n'agissent pas uniquement sur le réseau, mais sur le comportement de Bind, selon des directives adaptées à une situation/action. Particulièrement utilisé pour les DNS exposés à internet, les passerelles...ils apportent la simplicité pour l'administrateur, et toute la souplesse et la puissance de Bind. Les VEWS sont à déclarés dans le fichier de configuration (named.conf) après les options globales.

Si vous activez les vues, il faut les appliquer à toutes les zones, ou à chaque zone. Ceci peut rendre votre fichier de configuration difficilement lisible. Pour plus de clarté, utilisez une directive include

Je n'ai pas activé cette possibilité, mon DNS à comme ordre de ne pas répondre vis à vis d'internet. Pour éviter une view, il est possible d'activer un serveur pour répondre à une mission précise, avec des données minimales, c'est une autre possibilité.

Voici un exemple de vues possibles, et très souvent utilisé entre deux mondes différents (réseau privé et internet...). ( extrait du site : http://www.isc.org/sw/bind/):

view "internal" {
      // Pour le réseau interne en 10.0.0.0.
      match-clients { 10.0.0.0/8; };
      // La récursion est possible pour eux
      recursion yes;
      // la zone complète/intégrale
      zone "exemple.com" {
            type master;
            file "exemple-internal.db";
      };
};
view "external" {
      // Tous les clients qui ne sont pas du réseau "interne"
      match-clients { any; };
      // Ils n'ont pas accès à la récursion...
      recursion no;
      // La zone ne contient que des données nécessaires...
      zone "exemple.com" {
           type master;
           file "exemple-external.db";
      };
      };

Voici l'une des possibilités les plus utilisées, en fin de document (options-VIEW ), vous pouvez trouver toutes les différentes options possibles. Vous comprendrez pourquoi, je ne peux expliquer tout en détail. Une vue n'est pas forcément utilisée que pour internet vis à vis de votre réseau.

Il est possible d'utiliser dans les vues les options suivantes, cece ne représente qu'un mince echantillon :

Chapitre 12. Les autres programmes

Table des matières

NSLOOCKUP
DIG
Piloter Bind (rndc).
L'authentification avec RNDC :
Les options et les commandes RNDC.
La commande host

Et hélas pour moi, ils sont nombreux avec pleins d'options ... Je ne présente que les programmes présents avec les sources de Bind.

NSLOOCKUP

Beaucoup de puristes du DNS, disent qu'il ne faut plus l'utiliser, cette commande est remplacée désormais par dig. Néanmoins je trouve nsloockuppratique, en particulier pour résoudre les adresse en REVERSE. Ce programme existe sur de très nombreux système d'exploitation, il peut être lancé par un utilisateur classique. Avec nsloockup pour changer de serveur DNS, il suffit de placer la commande suivante server 194.117.200.15, après avoir lancé le programme. Voici quelques exemples simples :

Avertissement

Beaucoup d'exemples utilisent cette commande pour lister une zone comme, ls -d archi.amt. Cette commande semble désormais non prise en compte, probablement par sécurité.

DIG

Dig est pour moi la version récente ou actualisée du nsloockup vieillissant. C'est un outil simple, qui reste très puissant de par ses multiples options. Dig est accessible en mode console par tout utilisateur.

Voici un extrait des options qui peuvent être utilisées :

serveur named # dig -h
Usage:  dig [@un_serveurDNS] [domaine] [q-type] [q-class] {q-opt}  {global-d-opt} host [@local-server] {local-d-opt}
            [ host [@local-server] {local-d-opt} [...]]
            
        q-class  est : IN ou CH [défaut: in]
        q-type   choisir entre (a,any,mx,ns,soa,hinfo,axfr,txt,...) [défaut:a]
                 (si ixfr=numero_version pour type de ixfr)
        q-opt    est l'un de :
                 -x dot-notation     (recherche en REVERSE, donc adresse IP à donner)
                 -f filename         (fichier de commandes)
                 -b address[#port]   (cherche avec les address/port)
                 -p port             (numéro de port)
                 -t type             (type= A, AAAA, NS...)
                 -4                  (utilise l'IPv4)

                 +time=###           (Valeur du timeout) [5]
                 +[no]showsearch     (Recherche avec des resultats intermédiaires)
                 +[no]recurse        (Mode Recursif)
                 +[no]cmd            (Controle sur la partie COMMAND)
                 +[no]comments       (Controle sur la partie COMMENTS)
                 +[no]question       (Controle sur la partie QUESTION)
                 +[no]answer         (Controle sur la partie ANSWAR)
                 +[no]authority      (Controle sur la partie AUTHORITY)
                 +[no]additional     (Controle sur la partie ADDITIONAL)
                 +[no]stats          (Controle sur la partie STATISTICS)
                 +[no]short          (Ne donne que la réponse)
                 +[no]all            (Affiche les drapeaux)
                 +[no]nssearch       (Recherche avec tous les serveurs qui font autorité)
                 +[no]trace          (Affiche toutes les demandes (mode RECURSIF) du ROOT jusqu'à ...)

        -h                           (affiche l'aidet)
        -v                           (affiche la version)

Comme vous pouvez le constater, dig n'est pas à première vue un outil simple. C'est pourtant pas le cas, il peut très bien servir dans un script...Il peut-être nécessaire de pouvoir avoir les données comme nous le souhaitons. Je vais donc vous donner des exemples de commandes diverses, sans attaquer les commandes pour TSIG et DNSSEC, réservées pour plustard.

Avertissement

La plupart des exemples sont en mode d'affichage classique, donc relativement long. Il faut bien noter les différentes sections présentes dans les réponses à l'affichage, comme HEADER/QUESTION ...

Pour interroger un serveur DNS précis, il est nécessaire de le passer en paramètre sous cette forme dig @serveur-DNS, suivi de la commande(s) désirée. Sinon dig choisira un DNS qui est désigné dans le fichier « /etc/resolv.conf ».

Avertissement

Pour connaître si votre serveur utilise correctement le cache, il suffit de faire une requête non déjà effectuée, et de relever le temps de résolutions. Puis de refaire cette même commande et de comparer les temps. Voici un exemple, et c'est sure je ne gère pas cette zone en local, la réponse est donnée en 0 ms.

;  DiG 9.4.1-P1 - google.fr soa +stats +noauthority +noanswer +noadditional
;; global options:  printcmd
;; Got answer:
;; HEADER- opcode: QUERY, status: NOERROR, id: 8905
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 5

;; QUESTION SECTION:
;google.fr.                     IN      SOA

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Nov  4 20:11:39 2007
;; MSG SIZE  rcvd: 378

Piloter Bind (rndc).

rndc fait parti de Bind, il est inclus dans ses sources. Ce programme permet de faire beaucoup avec Bind, à l'exception d'intervenir sur les données d'une zone. Selon les paramètres de compilation, ce fichier doit être installé dans le répertoire /usr/sbin/, donc seul l'administrateur (root) peut le lancer. rndc peut fonctionner sous 2 façons bien différentes : en local ou à distance. Pour travailler à distance, il est nécessaire d'authentifier l'utilisateur, ou la station. Pour une utilisation en local sans authentification et rapide, il suffit d'effacer le fichier d'origine rndc.conf. Ceci reste tout de même une situation non sécurisée...et donc à éviter. La meilleure solution est expliquée dans le chapitre suivant.

rndc utilise par défaut l'adresse 127.0.0.1 et le port 953 en TCP exclusivement. Dans le fichier /var/log/messages, c'est lui le responsable de cette ligne :

Nov 30 21:07:03 serveur named[5639]: command channel listening on 127.0.0.1#953

L'authentification avec RNDC :

Compte tenu des possibilités offertes par la commande rndc, l'authentification est pour moi une obligation. Cette action va nécessité la création d'un nouveau fichier, et de placer des paramètres supplémentaires dans le fichier named.conf.

Pour générer des clés, il existe un programme bien pratique pour faire ce travail. Il s'appelle rndc-confgen. Ce programme réalise tout ou presque, et simplement. Toutes les options vont être expliquées, néanmoins il est utilisable directement sans aucun paramètre. Dans cette situation, vous devez travailler et scinder le résultat qui apparaît sur l'écran, ou depuis le fichier pour l'adapter à votre configuration. Vous pouvez diriger l'affichage de l'écran vers votre nouveau fichier comme ceci rndc-confgen > /etc/bind/rndc.conf.

rndc utilise sont propre fichier de configuration qui s'appelle rndc.conf, celui-ci est obligatoire pour un usage classique avec authentification. Personnellement je préfère scinder chaque spécifications dans des fichiers différents, donc au total avec ma solution, vous devez avoir deux fichiers nouveaux.

Voici le résultat sans aucune option pour la commande rndc-confgen, affichage uniquement sur l'écran.

serveur sbin # rndc-confgen
# Start of rndc.conf
key "rndc-key" {
        algorithm hmac-md5;
        secret "nqUx8EW2U74M+6P+BI+ovw==";
};

options {
        default-key "rndc-key";
        default-server 127.0.0.1;
        default-port 953;
};
# End of rndc.conf
# 
# Use with the following in named.conf, adjusting the allow list as needed:
# key "rndc-key" {
#       algorithm hmac-md5;
#       secret "nqUx8EW2U74M+6P+BI+ovw==";
# };
#
# controls {
#       inet 127.0.0.1 port 953
#       allow { 127.0.0.1; } keys { "rndc-key"; };
# };
# End of named.conf

Comme vous pouvez le lire, les données pour les divers fichiers nécessaires sont présents (rndc.conf et named.conf). Dans un souci de ne pas surcharger mon fichier de configuration principal, les données spécifiques pour ce fichier ont été incluse dans un fichier supplémentaire rndc.key. Ce fichier fait l'objet d'une directive include appropriée.

Voici comment générer une clé locale (-a) en 256 bits avec le nom de « serveur » pour le port 953 et avec comme « user »named. De nos jours avec les processeurs de plus en plus puissant, 256 bits est un minimum...

rndc-confgen -a -b 256 -k serveur -p 953 -u named
           wrote key file "/etc/bind/rndc.key"

Le détail du fichier rndc.key

serveur bind # cat rndc.key
//////////////////////////////////////
// rndc.key est suivi de rndc.conf +
// instructions dans named.conf (controls)
/////////////////////////////////////
//
// Paramêtre pour rndc en local
//
key serveur {
        algorithm hmac-md5;
        secret "/eS0cl8t1pMH6heclJoI+I9ekFw6/7imiiMhahQnGk0=";
};
////////////////////////////////////

Le détail du fichier rndc.conf

//////////////////////////////////////
// rndc.conf
/////////////////////////////////////
//
// Paramêtre pour rndc en local
//
key serveur {
        algorithm hmac-md5;
        secret "/eS0cl8t1pMH6heclJoI+I9ekFw6/7imiiMhahQnGk0=";
};
////////////////////////////////////
// le mot "serveur" est declare juste au dessus ...
options {
        default-key serveur;
        default-server 127.0.0.1;
        default-port 953;
};
////////////////////////////////////

Comme vous pouvez le remarquer les clés entre les deux fichiers sont identiques. Ce fichier n'est pas utilisé par Bind, mais exclusivement par rndc. C'est pourquoi vous retrouver des paramètres identiques.

Et les modifications à apporter au fichier named.conf,

include "/etc/bind/rndc.key";

à placer avant les options ou après, puis une nouvelle section controls :

// -- pour RNDC
        controls {
                inet 127.0.0.1 port 953
                allow { 127.0.0.1; } keys { "serveur"; };
        };
     

Ces options doivent être placé avant ou après la section « options ».

Et c'est tout ! De là vous communiquez avec une clé pour lancer rndc.

Le renouvellement de la clé s'opère uniquement par le changement des clés.

Voici les explications sur les diverses options possibles :

// fichier rndc.conf (partie cle)
 key "nom-de-la-clé" {
       algorithm hmac-md5;
       secret "la-clé-secrete:nqUx8EW2U74M+6P+BI+ovw==";
 };

C'est très simple vous devez avoir trois paramètres, dont un nom pour votre clé. celui-ci servira par la suite, il doit être précis et à mon avis pas trop long. L'encodage est par défaut du « hmac-md5 », je ne le change pas. Et dernier paramètre, il représente la clé proprement dite.

Par défaut, Bind utilise l'encodage HMAC-MD5 pour les clés. Il peut utiliser d'autres codages,toujours dans le système BASE-64 comme « mimencode », par l'intermédiaire du programme mmencode.

// fichier rndc.con (suite)
 options {
       default-key "nom-de-la-clé";
       default-server 127.0.0.1;
       default-port 953;
 };

L'option options est nécessaire; elle permet de régler rndc vis à vis de votre serveur. Ceci concerne les ports, l'adresse IP à écouter et la clé.

Le 1ere ligne identifie (default-key) le nom de la clé prédéfinie auparavant, elle est suivie de l'options default-server. Cette option règle l'adresse IP d'écoute de rndc (127.0.0.1). Et l'option default-port règle le port 953, c'est la valeur par défaut.

Avertissement

Pour commander votre Bind à distance, il suffit de procéder de la même manière, en prenant en compte l'adresse IP de l'autre machine.

Les différents exemples sont utilisables pour un emploi de rndc en local (!).

Note

J'ai personnellement recherché comment contrôler la durée de validité de cette clé pour rndc, et j'ai rien trouvé. Une chose est fiable, rndc ne fonctionne plus dès qu'un paramètre est mauvais ou manquant.

Avertissement

Les paramètres pour la gestion des clés peuvent être inclus dans le fichier named.conf, mais ceci peut engender des problèmes de sécurité, par la mtéthode de lecture de ce fichier. Il est préférable de séparer ces données par une inclusion dans named.conf. Les droits d'accès doivent être réservées uniquement à l'utilisateur « named » et son groupe.

Les options et les commandes RNDC.

Nous avons précédemment vu comment sécuriser rndc, mais sans trop savoir ce qu'il pouvait faire à distance ou en local. Voici la liste des options disponibles :

Avertissement

Certaines actions nécessitent que le fichier de configurations possède des options activées, en particulier :

        dump-file "/var/run/named/named-dump.db";
        // STATS //
        statistics-file "/var/run/named/named.stats";
        zone-statistics yes;

Les options

Les commandes :

Voici un exemple de la commande rndc dumpdb -all, tout ce que Bind connait est là !

;
        ; Start view _default
        ; Cache dump of view '_default'
        ;
        $DATE 20071114203211
        ; answer
        .                       169722  IN NS   F.ROOT-SERVERS.NET.
        169722  IN NS   D.ROOT-SERVERS.NET.
        169722  IN NS   H.ROOT-SERVERS.NET.
        169722  IN NS   B.ROOT-SERVERS.NET.
        169722  IN NS   M.ROOT-SERVERS.NET.
        ; answer
        102.gmodules.com.       171193  CNAME   www.google.com.
        ; answer
        103.gmodules.com.       171257  CNAME   www.google.com.
        ; answer
        27.gmodules.com.        171190  CNAME   www.google.com.
        ; answer
        73.gmodules.com.        171193  CNAME   www.google.com.
        ; answer
        84.gmodules.com.        171257  CNAME   www.google.com.
        ; answer
        93.gmodules.com.        171257  CNAME   www.google.com.
        ; answer
        img0.gmodules.com.      171190  CNAME   www.google.com.
        ; answer
        img1.gmodules.com.      171190  CNAME   www.google.com.
        ; answer
        img2.gmodules.com.      171193  CNAME   www.google.com.
        ; answer
        sb.l.google.com.        5       A       72.14.217.91
        ; answer
        mail.google.com.        171316  CNAME   googlemail.l.google.com.
        ; answer
        chatenabled.mail.google.com. 171321 CNAME b.googlemail.l.google.com.
        ; answer
        sb.google.com.          171453  CNAME   sb.l.google.com.
        ; answer
        www.google.com.         171386  CNAME   www.l.google.com.
        ; answer
        www.google-analytics.com. 684   CNAME   www-google-analytics.l.google.com.
        ; answer
        pagead2.googlesyndication.com. 78663 CNAME pagead.l.google.com.
        ; answer
        www.oxygenxml.com.      11714   A       64.41.124.7
        ; answer
        spell.wordreference.com. 1182   A       75.126.138.100
        ; answer
        www.google.fr.          171167  CNAME   www.google.com.
        ; answer
        luc-ghgk.fr.            84875   A       213.186.33.18
        www.pages.fr        .   1993    A       193.252.242.142
        1993    A       193.252.242.225
        ; answer
        paris-live.net.         64992   A       213.186.33.16
        ; answer
        www.paris-live.net.     62670   CNAME   paris-live.net.
        ; answerhel.fr. answer
        efattal.org.       77424        A       213.251.131.44
        ;
        ; Address database dump
        ;
        ; A.ROOT-SERVERS.NET [v4 TTL 83714] [v4 success] [v6 unexpected]
        ;       198.41.0.4 [srtt 0] [flags 00000000] [ttl 1706]
         ;      128.63.2.53 [srtt 0] [flags 00000000] [ttl 1706]
        ; K.ROOT-SERVERS.NET [v4 TTL 83714] [v4 success] [v6 unexpected]
        ;       193.0.14.129 [srtt 0] [flags 00000000] [ttl 1706]
        ;
        ; Unassociated entries
        ;
        ;       194.117.200.10 [srtt 48260] [flags 00000000] [ttl 1706]
        ;       194.117.200.15 [srtt 41642] [flags 00000000] [ttl 1706]
        ;
        ; Zone dump of 'archi.amt/IN'
        ;
        archi.amt.                                    86400 IN SOA      serveur.archi.amt. laurent.serveur.archi.amt. 2007110401 86400 7200 604800 86400
        archi.amt.                                    86400 IN NS       serveur.archi.amt.
        archi.amt.                                    86400 IN NS       second.archi.amt.
        archi.amt.                                    21600 IN MX       10 serveur.archi.amt.
        archi.amt.                                    3600 IN TXT               "Serveur DNS de Archi"
        dm.archi.amt.                                 172800 IN A       192.168.1.100
        fh.archi.amt.                                 172800 IN A       192.168.1.20
        pop.archi.amt.                                21600 IN CNAME    serveur.archi.amt.
        second.archi.amt.                             86400 IN A        192.168.1.15
        serveur.archi.amt.                            43200 IN A        192.168.1.11
        smtp.archi.amt.                               21600 IN CNAME    serveur.archi.amt.
        test.archi.amt.                               172800 IN A       192.168.1.22
        ;
        ; Zone dump of 'stub.archi.amt/IN'
        ;
        ; zone not loaded
        ;
        ; Zone dump of '0.0.127.in-addr.arpa/IN'
        ;
        0.0.127.in-addr.arpa.                         604800 IN SOA     serveur.archi.amt. root.localhost. 2002081603 86400 86400 604800 86400
        0.0.127.in-addr.arpa.                         86400 IN NS       serveur.archi.amt.
        *.0.0.127.in-addr.arpa.                       604800 IN PTR     localhost.
        ;
        ; Zone dump of '1.168.192.in-addr.arpa/IN'
        ;
        1.168.192.in-addr.arpa.                       3600 IN SOA       serveur.archi.amt. laurent.serveur.archi.amt. 2007103101 86400 7200 604800 86400
        1.168.192.in-addr.arpa.                       43200 IN NS       serveur.archi.amt.
        1.168.192.in-addr.arpa.                       43200 IN NS       second.archi.amt.
        1.1.168.192.in-addr.arpa.                     60 IN PTR         routeur.archi.amt.
        10.1.168.192.in-addr.arpa.                    10800 IN PTR      serveur2.archi.amt.
        100.1.168.192.in-addr.arpa.                   86400 IN PTR      dm.archi.amt.
        11.1.168.192.in-addr.arpa.                    86400 IN PTR      serveur.archi.amt.
        15.1.168.192.in-addr.arpa.                    7200 IN PTR       second.archi.amt.
        20.1.168.192.in-addr.arpa.                    86400 IN PTR      fh.archi.amt.
        22.1.168.192.in-addr.arpa.                    86400 IN PTR      test.archi.amt.
        ;
        ; Zone dump of 'localhost/IN'
        ;
        localhost.                                    604800 IN SOA     serveur.archi.amt. root.localhost. 2008102702 86400 86400 604800 86400
        localhost.                                    86400 IN NS       serveur.archi.amt.
        localhost.                                    604800 IN A       127.0.0.1
        localhost.                                    86400 IN RP       archi\.laurent.gmail.com.localhost. admin.serveur.archi.amt.
        localhost.                                    86400 IN RP       archi\.laurent.gmailp.com.localhost. clients.serveur.archi.amt.
        admin.localhost.                              86400 IN TXT      "Tel 01-22-33-44-44 de 09 a 10h"
        clients.localhost.                            86400 IN TXT      "Tel 01-33-44-55-55 de 10 a 11h"
        ;
        ; Start view _bind
        ; Cache dump of view '_bind'
        ;
        $DATE 20071114203211
        ;
        ; Address database dump
        ; Unassociated entries
        ;
        ; Zone dump of 'authors.bind/CH'
        ; not implemented
        ;
        ; Zone dump of 'hostname.bind/CH'
        ; not implemented
        ;
        ; Zone dump of 'version.bind/CH'
        ; not implemented
        ;
        ; Zone dump of 'id.server/CH'
        ; not implemented
        ; Dump complete
    

rndc stats

C'est une des commandes disponibles avec rndc, elle permet de sortir sous forme d'un fichier prédéfini des statistiques sur les requêtes et les zones. Il est nécessaire dans le fichier named.conf, que les les options : statistics-file "/var/run/named/named.stats"; zone-statistics yes; soient activées. Ensuite pour générer ces statistiques, il suffit de lancer cette commande : rndc stats, vous avez accès à diverses statistiques sur votre serveur et vos zones. Ce programme ou plutôt ces statistiques travaillent par zone, selon votre configuration le fichier sera plus ou moins long... Voici en exemple et un extrait également du résultat de cette commande :

+++ Statistics Dump +++ (1196882149)
success 81
referral 0
nxrrset 6
nxdomain 0
recursion 70
failure 0
duplicate 0
dropped 0
success 22 archi.amt
referral 0 archi.amt
nxrrset 6 archi.amt
nxdomain 0 archi.amt
recursion 0 archi.amt
failure 0 archi.amt
duplicate 0 archi.amt
dropped 0 archi.amt
success 7 1.168.192.in-addr.arpa
referral 0 1.168.192.in-addr.arpa
nxrrset 0 1.168.192.in-addr.arpa
nxdomain 0 1.168.192.in-addr.arpa
recursion 0 1.168.192.in-addr.arpa
failure 0 1.168.192.in-addr.arpa
duplicate 0 1.168.192.in-addr.arpa
dropped 0 1.168.192.in-addr.arpa
--- Statistics Dump --- (1196882149)

Les mises à jour de zones avec RNDC

Il n'est pas nécessaire de relancer un ou plusieurs serveurs Bind pour procéder aux mises à jour des zones... Bind est un outil professionnel, il existe tout ce qu'il faut pour faire transférer une zone, c'est le processus de la notification. Lequel doit être suivi d'une demande de transfert, et du transfert de la zone. Ceci mérite une certaine rigueur de l'administrateur de la zone parente. Il doit impérativement changer le « serial » lors d'une modification dans une zone. Ensuite il doit recharger cette zone en mémoire avec les nouvelles données. Pour finir il faut qu'il provoque la notification forcée de cette zone. Sans cette notification, le ou les secondaires doivent attendre la fin du TTL refresh pour comparer la zone...

Avertissement

Voici les commandes à faire pour réaliser ceci automatiquement, évidemment l'administrateur doit contrôler que le transfert est effectué. Cette opération est simplifiée par la présence du fichier /var/log/named/xfer-out.log, il lui suffit de vérifier le bon déroulement. Voici les commandes pour la zone « archi.amt » :

serveur pri # rndc reload archi.amt ; rndc notify archi.amt
zone reload up-to-date
zone notify queued

rndc status

Cette commande permet de savoir comment votre DNS travaille, et si il travaille pour un client(s). Cette commande ne mérite pas d'explication particulière, les termes utilisés sont simples à comprendre.

Voici un exemple :

serveur ~ # rndc status
version: 9.5.0a7 (version.bind/txt/ch disabled)
number of zones: 6
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is ON
recursive clients: 5/0/1000
tcp clients: 0/100
server is up and running

La commande host

Cette commande ne fait pas parti de Bind, mais comme elle intervient sur le DNS, je me dois d'en parler et de la décrire. Cette commande est accessible à tous sur une ordinateur...

Voici ses différentes options :

Usage: host [-aCdlriTwv] [-c class] [-N ndots] [-t type] [-W time]
            [-R number] [-m flag] hostname [server]
       -a is equivalent to -v -t ANY
       -c specifies query class for non-IN data
       -C compares SOA records on authoritative nameservers
       -d is equivalent to -v
       -l lists all hosts in a domain, using AXFR
       -i IP6.INT reverse lookups
       -N changes the number of dots allowed before root lookup is done
       -r disables recursive processing
       -R specifies number of retries for UDP packets
       -s a SERVFAIL response should stop query
       -t specifies the query type
       -T enables TCP/IP mode
       -v enables verbose output
       -w specifies to wait forever for a reply
       -W specifies how long to wait for a reply
       -4 use IPv4 query transport only
       -6 use IPv6 query transport only
       -m set memory debugging flag (trace|record|usage)

J'ai retenu en particulier ces commandes intéressantes :

Chapitre 13. TSIG et DNSsec.

Table des matières

TSIG
Le programme dnssec-keygen.
Création de la clé sur le primaire.
DNSsec.
Les clés et les signatures.
DNSSEC et Microsoft

Pour l'instant à l'exception de RNDC, notre configuration est seulement sécurisée par des limitations sur les adresses IP, aux travers des ACL, des VIEW et des options. C'est fiable mais ne représente aucune garantie d'intégrité lors des transferts de zones, et d'authentification diverses. TSIG et DNSSEC permettent de sécuriser Bind ou un réseau DNS.

Avertissement

A ce stade il est obligatoire que les serveurs qui activent TSIG/DNSSEC soient tous basés sur une horloge horaire très précise NTP. Il est nécessaire que soit activé le protocole NTP sur vos serveurs, au risque de voir toutes vos requêtes rejetées, alors que tout est correcte. Ce type d'erreur est mentionné dans les fichiers d'historiques de Bind.

TSIG

TSIG veut dire « Transaction SIGnature », et donc sa mission principale consiste à renforcer les transactions (transferts de zone et mises à jour dynamique).

Le programme dnssec-keygen.

Malgré son nom comportant « dnssec... », il reste également l'outil pour générer les clés pour TSIG. Nous allons voir ces différentes options :

serveur bind # dnssec-keygen
Usage:
    dnssec-keygen -a alg -b bits -n type [options] name

Version: 9.4.2rc2
Required options:
    -a algorithm: RSA | RSAMD5 | DH | DSA | RSASHA1 | HMAC-MD5 | HMAC-SHA1 | HMAC-SHA224 | HMAC-SHA256 |  HMAC-SHA384 | HMAC-SHA512
    -b key size, in bits:
        RSAMD5:         [512..4096]
        RSASHA1:                [512..4096]
        DH:             [128..4096]
        DSA:            [512..1024] and divisible by 64
        HMAC-MD5:       [1..512]
        HMAC-SHA1:      [1..160]
        HMAC-SHA224:    [1..224]
        HMAC-SHA256:    [1..256]
        HMAC-SHA384:    [1..384]
        HMAC-SHA512:    [1..512]
    -n nametype: ZONE | HOST | ENTITY | USER | OTHER
    name: owner of the key
Other options:
    -c  class (default: IN)
    -d  digest bits  (0 = max, default)
    -e  use large exponent (RSAMD5/RSASHA1 only)
    -f   keyflag: KSK
    -g  generator; use specified generator (DH only)
    -t   type: AUTHCONF | NOAUTHCONF | NOAUTH | NOCONF (default: AUTHCONF)
    -p  protocol : default: 3 [dnssec]
    -s  strength> strength value this key signs DNS records with (default: 0)
    -r  randomdev : a file containing random data
    -v  verbose level>
    -k : generate a TYPE=KEY key
Output:
K name +alg + id.key, K name + alg + id .private

L'option -p 3 est obligatoire (par défaut), ceci reste à confirmer mais le cryptage par DNSSEC ne peut servir qu'à cette fin.

Création de la clé sur le primaire.

dnssec-keygen -a HMAC-MD5 -b256 -n HOST serveur-second.archi.amt En se basant sur les options de dnssec-keygen, les options pour TSIG sont simples.

Voici les résulats de cette commande, c'est 2 fichiers ou 2 clés :

  -rw------- 1 named named   78 Nov 17 18:27 Kserveur-second.+157+17511.key
  -rw------- 1 named named  112 Nov 17 18:27 Kserveur-second.+157+17511.private

Vous pouvez vérifier qu'il s'agit réellement de clé par les commandes suivantes, et pour un but purement lucratif :

 serveur bind # more Kserveur-second.+157+17511.key
 serveur-second. IN KEY 512 3 157 3BEGM8Dk3qFSpktTDkGtE4VmHTG3AX6XUUe5Zf76gdc=
 serveur bind # more Kserveur-second.+157+17511.private
 Private-key-format: v1.2
 Algorithm: 157 (HMAC_MD5)
 Key: 3BEGM8Dk3qFSpktTDkGtE4VmHTG3AX6XUUe5Zf76gdc=
 Bits: AAA=

Activation des clés pour les machines concernés.

Il est nécessaire de transmettre la clé aux machines qui doivent utiliser TSIG entres elles. Ce choix peut concerner un serveur et tous ses secondaires, mais peut concerner qu'une zone précise en réalité. Ceci nécessite selon votre serveur une ou plusieurs clés, mais le principe reste le même. Pour mémoire il existe cette solution :

scp root@serveur.archi.amt:/etc/bind/tsig-serveur-second.key root@second.archi.amt:tsig-serveur-second.key

La procédure reste la même pour la ou les autres machines, il faut modification le fichier named.conf :

include "/etc/bind/tsig-second-serveur.key";

Ce fichier contient les données suivantes :

// Recopie de la cle via (exemple) Kserveur-second.key
//
key serveur-second {
        algorithm hmac-md5;
        secret "3BEGM8Dk3qFSpktTDkGtE4VmHTG3AX6XUUe5Zf76gdc=";
};

Activation de TSIG pour les transactions par une instruction server :

// ---- TSSIG
server 192.168.1.15 {
keys { serveur-second.; };
};

L'instruction server est à placer avant ou après les autres options comme « options, control... ». Cette instruction pour TSIG veut dire : pour l'adresse IP 192.168.1.15 utiliser la clé « serveur-second ».

Et vous pouvez relancer Bind

Pour le secondaire(s), même principe mais avec la modification suivante, concerne l'adresse IP du primaire :

// ---- TSSIG
server 192.168.1.11 {
keys { serveur-second.; };
};

Il faut également relancer Bind pour cette prise en compte, concerne toutes les machines utilisant la même clé. Et comment vérifier que tout fonctionne bien, Il suffit de regarder dans le fichier sur chaque machine pour constater que les clés servent. Les dates présentent dans les exemples ne sont pas correctes ...>

Pour le fichier de notification :

18-Nov-2007 07:47:17.937 client 192.168.1.11#32781: received notify for zone 'archi.amt': TSIG 'serveur-second'
18-Nov-2007 07:48:33.288 client 192.168.1.11#32781: received notify for zone 'archi.amt': TSIG 'serveur-second'

Et voici pour les transferts de zones, voivi un exemple de transferts sans ete avec TSIG.

17-Nov-2007 18:48:07.970 client 192.168.1.15#3896: transfer of '1.168.192.in-addr.arpa/IN': AXFR started
17-Nov-2007 18:48:07.970 client 192.168.1.15#3896: transfer of '1.168.192.in-addr.arpa/IN': AXFR ended
18-Nov-2007 07:47:17.937 client 192.168.1.11#32781: received notify for zone 'archi.amt': TSIG 'serveur-second'
18-Nov-2007 07:48:33.288 client 192.168.1.11#32781: received notify for zone 'archi.amt': TSIG 'serveur-second'

Encore un peu plus loin avec TSIG.

Les notifications et les transferts de zones se font désormais par authentification. Mais il est possible d'aller un peu plus loin encore avec l'activation des options suivantes : allow-{ query | transfer | update }.

A la place des traditionnels ACL ou en complément, vous pouvez ajouter le paramètre suivant pour obliger une requête à utiliser une clé précise :

key serveur-second.;.

Voilà qui limite les transferts, les mises à jour et peut même s'appliquer aux requêtes en elles-même. Cette dernière option est à activer pour des situations particulières...

Avertissement

Attention aux droits sur les fichiers de clés, ils doivent être accessibles uniquement à l'utilisateur « named ».

DNSsec.

DNSsec est très différent comparé à TSIG, il est même peut comparable à mes yeux.

DNSsec signifie « DNS sécurité extensions ». Avec TSIG nous avions une clé partagé, avec DNSsec nous allons avoir un lot de clés. L'une va servir à déchiffrer une message chiffré par une autre clé, c'est le système des clés publiques et privées. C'est une technique plus moderne qui doit pourvoir s'appuyer un service de clés (PKI) (non testé).

Nous allons avoir une clé privé, à garder soigneusement et à protéger, et une clé publique que tout le monde peut voir. Le principe de DNSsec est basé sur un nouveau type les enregistrements RRset Un enregistremnt RRset correspond à une ligne complète renvoyé par un DNS.Voici un exemple complet de RRSET pour le champ MX de « undomain  » : undomain.fr. 900 IN MX 10 smtpb1.undomain.fr.

Avertissement

Après une création de clés qui a pris tout de même 4 heures, pour accélérer ce processus il suffit de rajouter -r /dev/urandom ou /dev/random, selon votre système d'exploitation. Et tout de suite la rapidité est là...

Les clés et les signatures.

Clés DNSsec pour une zone.

La commande est simple , l'utilisation de l'algorithme RSA-SHA1 est obligatoire. Ce même algorithme permet un encodage de 512 à 4096 bits, il est conseillé de choisir au moins 1024 bits à ce jour. Il est fortement conseillé de placer toutes les clés dans le répertoire de travail de Bind. Mes clés seront stockés dans le répertoire de travail des zones.

Création des clés KSK (clés de signature de clés) puis des clés de signature de zone ZSK

Cette technique de deux signatures par zone est un peu lourde, mais c'est la version conseillée et la plus sécurisée par tous sur internet. Il est donc possible de travailler sans une KSK...

La seule différence dans les commandes vient de l'option -f KSK à placer ou non, les 2 commandes ne sont pas liées entres elles.

serveur pri # serveur pri # dnssec-keygen -f KSK -a RSASHA1 -b 2048 -r /dev/urandom -n ZONE archi.amt.
Karchi.amt.+005+13651
serveur pri # dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -n ZONE archi.amt.
Karchi.amt.+005+10926
             

Les résultats correspondent aux 4 fichiers suivants, dont il est facile de récupérer les clés publiques, tous les fichiers sont positionnés en lecture pour tous. Il est important pour la suite de bien noter à quoi correspond chaque fichier, car entre le fichier Karchi.amt.+005+13651 et Karchi.amt.+005+10926, il est difficile de reconnaitre la KSK et le ZSK au niveau des clés.

-rw-r--r-- 1 root  root   384 Nov 20 22:04 Karchi.amt.+005+10926.key
-rw------- 1 root  root  1701 Nov 20 22:04 Karchi.amt.+005+10926.private
-rw-r--r-- 1 root  root   384 Nov 20 22:04 Karchi.amt.+005+13651.key
-rw------- 1 root  root  1701 Nov 20 22:04 Karchi.amt.+005+13651.private

Les fichiers se terminant par « .key » correspondent aux clés publiques (KSK et ZSK) Maintenant les deux clés publiques doivent être incluses dans la zone correspondante. Cette procédure est simple, il suffit d'inclure chaque clé par l'instruction suivante, ou de l'inclure directement dans la zone,en fin de zone. C'est à vous de voir... La solution d'inclure les est à mon avis la meilleure solution...

   $INCLUDE "/etc/bind/pri/Karchi.amt.+005+10926.key";
   $INCLUDE "/etc/bind/pri/Karchi.amt.+005+13651.key";
                 

Me concernant, j'ai inscrusté ces lignes justes après les lignes de déclaration de mon secondaire (NS). Cette mesure permet de séparer les données d'entêtes qui ne bougent pas souvent ou rarement, avec les données purement de zone qui bougent plus souvent. Il ne reste plus qu'a recharger la zone pour voir apparaître la clé dans la zone.

La signature de zone.

Cette signature va intervenir directement sur le fichier zone cible, elle nécessite une nouvelle commande qui s'appelle : dnssec-signzone.

Voici comment faire en sorte que vos clés précédentes soient utilisées, elles vont servir à générer une signature pour chaque enregistrement ou RRset. La commande suivante va générer un fichier avec l'extension .signed, c'est ce même fichier qui doit être pris en compte dans le fichier named.conf, mais je vais y revenir pour une autre raison.

dnssec-signzone -e 20080122120000 -o 1.168.192.in-addr.arpa. 1.168.192.in-addr.arpa

Cette commande va signer la zone REVERSE avec en plus une option non conseillée. Elle concerne l'échéance de la clé, qui par défaut est de 30 jours, à titre personnel et pour tester j'ai volontairement augmenter cette valeur. Donc cette clé est valable jusqu'au 22 janvier 2008 à 12 heures 00 secondes. Il est possible de faire également cette possibilité : -e +100000000 (1an)

Cette même commande à générer également le fichier keyset-archi.amt. Ce fichier ne sera pas utilisé, car il permet de remonter d'un niveau dans la hiérarchie DNS pour faire approuvé ma signature. Je vais le faire par contre vis de mon secondaire vers le primaire.

Voici un premier exemple de zone signée avec quelques enregistrements nouveaux, je vais détailler chaque RRset individuellement. En prenant une clé basé sur 1024 bits, le fichier original à grossi de 13 fois...ce chiffre 13 va donc se retrouver partout après, au niveau du CPU, sur le réseau, stockage...

dig archi.amt +dnssec

; DiG 9.4.2rc2 - archi.amt +dnssec
;; global options:  printcmd
;; Got answer:
;; ->>HEADER - opcode: QUERY, status: NOERROR, id: 27449
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;archi.amt.                     IN      A

;; AUTHORITY SECTION:
archi.amt.              86400   IN      SOA     serveur.archi.amt. laurent.serveur.archi.amt. 2007112101 86400 7200 604800 86400
archi.amt.              86400   IN      RRSIG   SOA 5 2 86400 20080122120000 20071121055311 10926 archi.amt. WaE+IcN0LMIetSZEBScICqKwy7K9IWd4IAgj/P5efrVkgdXIFfspZeDu oFiHAxS9vcXcWO2uaLFxIDrin81gVj4hv1C6xk7GqZDfG1hydhBWZroE twJ4shyoORq0O8vgFZl/vnn7jn/L8+SNbKbcePdxwmeCeO3PcKp5HzGV YWfv0Yg9Nba+s03pFUzD7668aTkmnpu4T3sYVedsTYYvtk+xUhb7TAhH Vs3l75ZNHTYqF7LCA8bS8ZbOwNDpRncmNQ0HJF82IQyyLRYomThObyL1 m4V50C0lg/kUmndLR6fe+zjDJIEG/3DYjh69aJlvA7E7jO0tl97rqJDc 55gSwQ==
archi.amt.              86400   IN      NSEC    dm.archi.amt. NS SOA MX TXT RRSIG NSEC DNSKEY
archi.amt.              86400   IN      RRSIG   NSEC 5 2 86400 20080122120000 20071121055311 10926 archi.amt. VvQV1yfmiQ4GNalg6BehKJit4w+EbxAT6UcgOCavlLL2cfISIKdqW2ZN YqVI/WXdUF/+OysIOcTPweZ9srb9aRZMJbDuGVolTWzSQpITVs4cOZPF xjrK0H8B/cYIYclhw0ncNvIDEFYPNd9mGitKZcbxiInfOGO90UVmvHVn F9pqVEcj3Sdvicmyu0oVEsJNoYNZGAaAmztez868rx+ntCUOomLFwiEh ObKbJ8FfUk+CkZcrI3y3eUpq+opu3F+mS4BiuatUadFbcIzM8k/oCo8P /m71cziAUmjT6BUrCRBBKwqQih/Z3F7xUEda2i6P39dNiI7kZN4Hu/Iz 9woscA==

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Nov 21 20:00:41 2007
;; MSG SIZE  rcvd: 719
                 

Vous pouvez apercevoir une nouvelle section qui s'appelle « OPT PSEUDOSECTION », suivie du mot EDNS. Ceci correspond à l'activation du "protocole" DNSsec ou EDNS0 (EDNS version 0) qui à besoin pour transmettre ses clés de plus de 512 octets. Le paramètre/drapeau flag doit être positionné à do, qui correspond à « DNSsec OK », il est suivi de la taille maximale des paquets en UDP (4096).

Et ensuite çà se complique, comme déjà mentionné les RRset interviennent. La 1ere ligne RRSIG correspond à la clé publique pour la zone complète. Le chiffre 5 correspond à l'algorithme RSA/SHA1, 2 pour DSA.. Le TTL est identique à la donnée RRset orginale (86400). Il est facile de comprendre la durée de validité de ma clé, car les données : 20080122120000 et 20071121055311 correspondent bien à des données années-mois-jour-secondes, et à la date de création et d'expiration aussi. Par contre il n'était pas 05h53 lors de la création des clés, je rassure tout le monde mais 07h53, comme quoi le système permet un transport ou une compatibilité internationale. Pour le mot RRSIG il correspond à la signature du RRset juste avant lui.

Comme tout le monde à aimer les RRset je continue avec encore plus de données, voici des échantillons d'une zone après la commande rndc dumpdb -all:

 Zone dump of 'archi.amt/IN'
;
archi.amt.                                    86400 IN SOA      serveur.archi.amt. laurent.serveur.archi.amt. 2007112101 86400 7200 604800 86400
archi.amt.                                    86400 IN RRSIG    SOA 5 2 86400 20080122120000 20071121055311 10926 archi.amt. WaE+IcN0LMIetSZEBScICq
Kwy7K9IWd4IAgj/P5efrVkgdXIFfspZeDu oFiHAxS9vcXcWO2uaLFxIDrin81gVj4hv1C6xk7GqZDfG1hydhBWZroE twJ4shyoORq0O8vgFZl/vnn7jn/L8+SNbKbcePdxwmeCeO3PcKp5HzG
V YWfv0Yg9Nba+s03pFUzD7668aTkmnpu4T3sYVedsTYYvtk+xUhb7TAhH Vs3l75ZNHTYqF7LCA8bS8ZbOwNDpRncmNQ0HJF82IQyyLRYomThObyL1 m4V50C0lg/kUmndLR6fe+zjDJIEG/3D
Yjh69aJlvA7E7jO0tl97rqJDc 55gSwQ==
archi.amt.                                    86400 IN NS       serveur.archi.amt.
archi.amt.                                    86400 IN NS       second.archi.amt.
archi.amt.                                    86400 IN RRSIG    NS 5 2 86400 20080122120000 20071121055311 10926 archi.amt. d6Z1qDDYOCwF5QCyOEIqChH
vqHbkgQl5Bkr7GyP8k8+s2yG9XYOr6cwH CM6bQenniZM26XHyN7TivH7gHWdK2WQ5AXbhrzVM1Jm4fvCHpE5ANT6G XYwePSLENptNTXPrUP08ZEA6B1fOMgpvg3PT0nqtYpERo1W1D9FBGssm
 IfG/e9Ja/xETt74/mJE+vE2V0TRZvrDRzD2g2LsNyLPTGYb4bpxJBfeQ 6vkbLaZ0GyuIKa5my8ZU8xJpkd0/fwkC4bgB58rQs/biU6YYq4NlsNZL 3gTMbCjfdnNazqvwgXkkwsHTOMXnZIyQ
Dhh4jV/oOSZrZDHs6VitJJhQ QLAdlw==
archi.amt.                                    21600 IN MX       10 serveur.archi.amt.
archi.amt.                                    21600 IN RRSIG    MX 5 2 21600 20080122120000 20071121055311 10926 archi.amt. t98zUTnMoASM611km77QIJQ
81KuIGFB6+wS1KP4U4DJ4KS89zpWfsHvP 2aJnAv6QIDuWNoiXp912A+Ff3tkXg+Bl0MerlseQHOcp55WX51bZyANb JrFFzDragN+3wRp9ANOUGv1ichVa4s90Uvz2F/sKhdMDshV0EMxAMtIp
 lB+2F4sEU1g6gSuVQtxkKize6lPFG2oeS0fH8x/l0Z/dCvZEEjSrcEj6 +b9s7InLj72o4PmLj4ukgWYT6hkL3BvJ7cERNlh3NgbN95Js0E/O9IsB JnF5Xb29Jp8DeJFiO9WNee0TwUGTL1xR
BcaFPdJMNnA/APbXo4wRId20 gGh/Pw==
archi.amt.                                    86400 IN TXT          "Serveur DNS de Archi"
archi.amt.                                    86400 IN RRSIG        TXT 5 2 0 20080122120000 20071121055311 10926 archi.amt. mSV60zF0bVGUqYFG/9BMUSlFQl
YUhafXymf33Sy3br7oCAWUoNz3jZAD oqKRXHdjQ1wo5QU3gIkIuF1n3Cg3yrMiOpwTrxj/Whf0Xr6gOOa/ofUD ax3YnY4CSjJo8liXzUwWV5ViKe/RmeYFMIWhzUMOg1kOWxKhzwl5HS/F nw
cf93ZgaeFMTL5qdbIqrD4vea7jU8CFbImJ2sX3nSJkwk93FQrEjN6u cSHdOQq1AZ8L0zrjxyNR8m4yxY6f9Crgn9exAgah0TB8pgZ94gHLBOPR QVdx/anqdaep+HS/XJS57JroUoTRKrYC/3G
n80WGDnnRMf8odRzcuruI JL/3wA==
archi.amt.                                    86400 IN NSEC     dm.archi.amt. NS SOA MX TXT RRSIG NSEC DNSKEY
archi.amt.                                    86400 IN RRSIG    NSEC 5 2 86400 20080122120000 20071121055311 10926 archi.amt. VvQV1yfmiQ4GNalg6BehK
Jit4w+EbxAT6UcgOCavlLL2cfISIKdqW2ZN YqVI/WXdUF/+OysIOcTPweZ9srb9aRZMJbDuGVolTWzSQpITVs4cOZPF xjrK0H8B/cYIYclhw0ncNvIDEFYPNd9mGitKZcbxiInfOGO90UVmvH
Vn F9pqVEcj3Sdvicmyu0oVEsJNoYNZGAaAmztez868rx+ntCUOomLFwiEh ObKbJ8FfUk+CkZcrI3y3eUpq+opu3F+mS4BiuatUadFbcIzM8k/oCo8P /m71cziAUmjT6BUrCRBBKwqQih/Z3F
7xUEda2i6P39dNiI7kZN4Hu/Iz 9woscA==
archi.amt.                                    86400 IN DNSKEY   256 3 5 AwEAAdTcUnwRJQzQMwFm/qjyR94lIYaypk3erZdmVG9ORPnWksCLOMnm CYSCIB65Nk7/Jy4T5o
DfFSGkjQGpGACiqBOW2qGf0HQDaFdc8R2oRtRR IUMefd7vMlD/stmxp9S8pA0wA1WrEetQUZy3XLEdt2DmY97NiTsuwE+S rkI6bwfLdUo7vU9XJ0fbQBofEggZRQACeSKJpsJHi3Ubr/QCkd9
mAIJz J3ibhminzrz2r8Bsm7xAVvvwFXY31V6JzsOehZVocq4NIhKyUYh/eYOn yul+WDscFGB3gFs0zqT/5Fde1zikiSQgjWwaz3TOHr3heBsdNLaFDFj0 wQblRjfbYH8=  ; key id = 10
926
archi.amt.                                    86400 IN DNSKEY   257 3 5 AwEAAdW61etMG09fMwhWw0PTflUU/5iUQlI+iSwrAYnfJYoa2/wr11EU N82XAzM720I+/HsYgk
aaOPVtHm43FHgrNsiDmvBSMNuHdrB6A7JiVU4O ZzYcuvXxrocjV9S35p16CQLhJexf+3aW44RkjuLz7leBHpQEANtYhONd jjvgN71hJqZRq6Wupwf0bTPfIS2DQrQfOoLIPuP6DQnsAovf8sp
cVrNi o14hoIiSOPHojv6TAa9pZfCU6VTp2lXtVMrB7M1LjwbN+rvt++aXI8+p GrztnaBgqc7Cn1sQChrT+0N1sgP2Q8bBoSXX6M7c+FCaw1KNIH0we2dY /X90W/3BylM=  ; key id = 13
651
archi.amt.                                    86400 IN RRSIG    DNSKEY 5 2 86400 20080122120000 20071121055311 10926 archi.amt. eBQ+mwkALFQ6uauVJrq
7J5xD+DXcj68bbbuUg7ZMeVdHkz6ftDswhIEg zgZ6Cc4jUnHh0WOKaflAOdLL1Jluc0xaaWAwqOw0sfQDCTXeDF99GtvF f4zJPOGvnMslBT7oSMXtMlTG+Cmpn2d3fCLoYUBd1FOAGxVjfk5T
iaEw A0kB/hpibj/xNzV9oKTiNSa2LSgu929t/DV4XmCXc2MR2FikwZYiJi2z WHcTXrBFLk5I/zON3u++E5wzJ0sIu0jv7waX1MVwcvaA/X9X2Y6C75ud hPddyJ/Pr9Y36DLXoDbpV3gGlESn
CkUOuJTshMVhFUyc8awQzVoj3S+c 2QhkLA==

Ce qu'il faut retenir de tout cela... chaque RRset possède sa signature, les valeurs NSEC possèdent les types certifiés pour un cette zone. Voici un exemple : archi.amt. 86400 IN NSEC dm.archi.amt. NS SOA MX TXT RRSIG NSEC DNSKEY. Ceci veut dire dans le domaine « archi.amt » pour la machine « dm.archi.amt » les type NS, SOA MX TXT RRSIG NSEC DNSKEY sont garantis et certifiés. Ce qui veut aussi qu'il va être inutile de demander autre chose.

Activation des zones et de DNSsec.

Cette opération concerne exclusivement le fichier named.conf. Ce fichier doit gérer les zones signées, il suffit de rajouter .signed (ou autre mot clé) vis à vis des zones concernées.

zone "archi.amt" IN {
        type master;
        file "pri/archi.amt.signed";
        allow-transfer { SECOND; ADMINS; key serveur-second.; };
        notify yes;
};
                     

Il faut rajouter avant les options globales, les fameuses trusted keys, attention de bien prendre les bonnes clés. Le bon repère est le chiffre 257, une fois les clés trouvées, il suffit de les insérer pour toutes les zones signées via cette instruction :

trusted-keys {
archi.amt.   257 3 5 "AwEAAdW61etMG09fMwhWw0PTflUU/5iUQlI+iSwrAYnfJYoa2/wr11EU N82XAzM720I+/HsYgkaaOPVtHm43FHgrNsiDmvBSMNuHdrB6A7JiVU4O ZzYcuvXxrocjV9S35p16CQLhJexf+3aW44RkjuLz7leBHpQEANtYhONd jjvgN71hJqZRq6Wupwf0bTPfIS2DQrQfOoLIPuP6DQnsAovf8spcVrNi o14hoIiSOPHojv6TAa9pZfCU6VTp2lXtVMrB7M1LjwbN+rvt++aXI8+p GrztnaBgqc7Cn1sQChrT+0N1sgP2Q8bBoSXX6M7c+FCaw1KNIH0we2dY /X90W/3BylM=";
};
trusted-keys {
1.168.192.in-addr.arpa. 257 3 5 "AwEAAca648pd/6b3MtZaQxOqkUvCr9k58/YUU0a+Y5tnAaDxTxfZ+V+C lolzZAp9jSGLEhx3tSnS9K0LBMmWuC7EnZghbKt/WQ7Hp+O1La6mwjK6 lONpBSDRdHlTCDi4MtebOW0MqYNLclqfBqmVXlx6ul5JuW6zd16SZaqY 6j4qMWEK/WSxcb9seHp16fRwvYyYkyywQUUt+xRI8r6o7pxg/G189awz CONZ4a3qIYHVqpoMCVWyXn4UCaaAe3d2uP+LWvj9hHi+vrvmm98rOtq3 lHMPTnAUUCEnxoRVGQxg6Mt/FRStYr/VhatRld7W1YrBz2d0z3u3Dfhv 5MLeA/cgSxU=";
};

. Il faut également ajouter dans les options dnssec-enable yes;.

Vous pouvez relancer Bind pour la prise en compte.

Pour confirmer que vos zones soient bien conformes, il suffit de regarder dans le fichier d'historique par défaut, chaque zone est marquée comme signée (signed).

22-Nov-2007 07:32:27.299 general: info: zone archi.amt/IN: loaded serial 2007112101 (signed)
22-Nov-2007 07:32:27.307 general: info: zone stub.archi.amt/IN: loaded serial 2007111801
22-Nov-2007 07:32:27.311 general: info: zone 0.0.127.in-addr.arpa/IN: loaded serial 2002081603
22-Nov-2007 07:32:27.315 general: info: zone 1.168.192.in-addr.arpa/IN: loaded serial 2007112101 (signed)
22-Nov-2007 07:32:27.316 general: info: zone localhost/IN: loaded serial 2008102702

Voici les options possibles pour la commande dnssec-signzone :

Usage:
                     dnssec-signzone [options] zonefile [keys]
                     
                     Version: 9.4.2rc2
                     Options: (default value in parenthesis)
                     -c class (IN)
                     -d directory
                     directory to find keyset files (.)
                     -g:     generate DS records from keyset files
                     -s [YYYYMMDDHHMMSS|+offset]:
                     RRSIG start time - absolute|offset (now - 1 hour)
                     -e [YYYYMMDDHHMMSS|+offset|"now"+offset]:
                     RRSIG end time  - absolute|from start|from now (now + 30 days)
                     -i interval:
                     cycle interval - resign if  -- interval from end ( (end-start)/4 )
                     -j jitter:
                     randomize signature end time up to jitter seconds
                     -v debuglevel (0)
                     -o origin:
                     zone origin (name of zonefile)
                     -f outfile:
                     file the signed zone is written in (zonefile + .signed)
                     -I format:
                     file format of input zonefile (text)
                     -O format:
                     file format of signed zone file (text)
                     -N format:
                     soa serial format of signed zone file (keep)
                     -r randomdev:
                     a file containing random data
                     -a:     verify generated signatures
                     -p:     use pseudorandom data (faster but less secure)
                     -t:     print statistics
                     -n ncpus (number of cpus present)
                     -k key_signing_key
                     -l lookasidezone
                     -z:     ignore KSK flag in DNSKEYs
                     Signing Keys: (default: all zone keys that have private keys)
                     keyfile (Kname+alg+tag)

Pour modifier un enregistrement dans une zone, il faut en plus du changement du « serial », faire la ou les commandes suivantes. Ces commandes prennent en compte la mise à jour de zones.

serveur pri # dnssec-signzone -e 20080122120000 -o 1.168.192.in-addr.arpa. 1.168.192.in-addr.arpa
1.168.192.in-addr.arpa.signed
serveur pri # dnssec-signzone -e 20080122120000 -o archi.amt. archi.amt
archi.amt.signed
serveur pri # rndc reload
server reload successful
DNSsec et le/les secondaires, les délégations de zone.

Comme vu précédemment la zone parente doit pourvoir certifier que les zones des secondaires ou déléguer sont correctes. La procédure est simple, après signature de chaque zone, un fichier keyset-archi.amt. (exemple) est généré automatiquement. Ce fichier est dédié à la certification vis à vis du parent. Il suffit de l'envoyer à ce parent, lequel doit procéder à la commande suivante pour la signer :

dnssec-signzone -o sousz.archi.amt -f sousz.archi.amt.signed -d keyset-sousz.archi.amt Karchi.amt.+005+10926.key Karchi.amt.+005+13651.key

Et c'est tout.

Conclusion sur DNSsec.

DNSsec mérité bien une partie conclusion, c'est tout de même une spécificité particulière pour Bind.

Après cette mise en oeuvre réduite pour moi, mais qui occupe...le déploiement de DNSsec à mes yeux, n'est pas forcément une chose simple. Heureusement DNSsec reste compatible avec le DNS standard, et envers les clients non pourvus de cette fonctionnalité. Il est possible de créer un réseau possédant un mixage avec et sans DNSsec. Autre point important non évoqué dans cette article, c'est la maitrise des TTL, et les valeurs dans les caches.

Ensuite j'ai voulu testé divers serveurs soit disant DNSsec sur le réseau internet...et je cherche encore. J'ai pas dit que c'est introuvable, mais cette technologie est loin d'être déployée partout ou beaucoup.

Depuis j'ai découvert que les 13 racines doivent pour se conformer aux RFC, activer DNSsec entre eux.

DNSSEC et Microsoft

A la lecture du lien ci-dessous, Microsoft viendrait à inclure DNSsec dans son architecture...à suivre.

http://www.dnssec-deployment.org/news/200611-Microsoft.html

Chapitre 14. Conclusion.

Au début, je pensais écrire ce document en peu de temps, mais c'était mal connaître Bind. Cette outil est très puissant, souple mais hélas pas facile à administrer. C'est aussi à mon avis son seul défaut. Hélas, il n'est pas le seul dans le monde du libre dans cette situation. Il n'est pas possible d'adminsitrer un serveur Bind en trois clics de souris. Et même si des logiciels comme WEBMIN (Autre programmes et utilitaires DNS) s'efforce de résoudre ce problème. Il ne prend pas en compte les situations particulières, ne prend pas en compte également toutes les options possibles. Il faut réellement mettre la main à la patte pour parvenir à le maitriser, ou penser le maitriser.

Désormais je pense de plus en plus qu'il existe un métier ou une spécificité pour les administrateurs de serveur DNS. En particulier pour des gros systèmes, et les gros réseaux; le tout est amplifié par la sécurité avec TSIG et/ou DNSEC... En clair, le service DNS est loin d'être une rigolade et surtout pour un débutant.

Je tiens à signaler que la liste bind-users@isc.org est très active. Comme d'habitude il est fortement recommandé de regarder les archives, avant de poser une question déjà résolue. De là vous pouvez poser vos questions, la communanuté doit vous répondre...

Après beaucoup de lectures sur les divers documents concernant Bind, j'en conclut qu'il est possible de trouver pour un même travail ou fonction, de multiples configurations et toutes différentes. En prenant comme exemple les diverses distributions Gnu/linux, pas une seule ne présentent la même chose, et pourtant elles sont toutes efficaces et performantes à ce niveau. Il est donc impossible d'imposer une configuration stricte, mais seulement une base, ensuite l'administrateur devra adapter cette configuration vis à vis de son environnement, de son réseau, de ses clients, de ses secondaires...

Dans cette documentation, j'ai parlé de IPv6 uniquement quand il le fallait. Bind et l'IPv6 c'est clairement pas une mince affaire, ceci fera peut-être l'objet d'une mise à jour de ce même document. Mais pour l'instant, cette situation est difficile à exploiter. Et j'imagine déjà IPv6 et DNSsec dans une zone, il va pas être simple de reconnaître les données, toutes plus longues ques les autres... Et poutant c'est l'avenir au moins pour IPv6.

Il manque encore beaucoup d'explications sur les possibilités que peut procurer Bind comme : la prise en charge de la répartition de charge pour un serveur WEB, « chrooter Bind », la gestion des zones dynamiques (DHCP), l'intégration avec Active Directory, Bind et les bases de données (DLZ)... un jour peut-être cette documentation s'embellira de ces informations.

Annexe A1. Divers et autre programmes.

Table des matières

DNSTRACER
dnswalk
Divers programmes DNS et utilitaires...
Gbindadmin
WEBMIN
Bindgraph
DNS Bajaj

DNSTRACER

C'est une programme bien pratique pour visualiser qui fait quoi. Il est comparable à la bien connue commande traceroute, mais uniquement pour le DNS. Rien de tel qu'un exemple pour comprendre (?) :

serveur ~ #  dnstracer -4 -v www.free.fr
Tracing to www.free.fr[a] via 127.0.0.1, maximum of 3 retries
127.0.0.1 (127.0.0.1) IP HEADER
- Destination address:  127.0.0.1
DNS HEADER (send)
- Identifier:           0x701F
- Flags:                0x00 (Q )
- Opcode:               0 (Standard query)
- Return code:          0 (No error)
- Number questions:     1
- Number answer RR:     0
- Number authority RR:  0
- Number additional RR: 0
QUESTIONS (send)
- Queryname:            (3)www(4)free(2)fr
- Type:                 1 (A)
- Class:                1 (Internet)
DNS HEADER (recv)
- Identifier:           0x701F
- Flags:                0x8080 (R RA )
- Opcode:               0 (Standard query)
- Return code:          0 (No error)
- Number questions:     1
- Number answer RR:     0
- Number authority RR:  13
- Number additional RR: 0
QUESTIONS (recv)
- Queryname:            (3)www(4)free(2)fr
- Type:                 1 (A)
- Class:                1 (Internet)
AUTHORITY RR
- Domainname:           (1).
- Type:                 2 (NS)
- Class:                1 (Internet)
- TTL:                  170426 (1d23h20m26s)
- Resource length:      4
- Resource data:        (1)L(12)ROOT-SERVERS(3)NET
AUTHORITY RR
- Domainname:           (1).
- Type:                 2 (NS)
- Class:                1 (Internet)
- TTL:                  170426 (1d23h20m26s)
- Resource length:      4
- Resource data:        (1)D(12)ROOT-SERVERS(3)NET
AUTHORITY RR
- Domainname:           (1).
- Type:                 2 (NS)
- Class:                1 (Internet)
- TTL:                  170426 (1d23h20m26s)
- Resource length:      20
- Resource data:        (1)J(12)ROOT-SERVERS(3)NET
Refers backwards

dnswalk possède de nombreuses options dont celle ci qui permet de voir les trames UDP. Voivi un exemple bien intéressant (?), qui à subit une césure volontaire :

serveur ~ # dnstracer -c -v www.free.fr
Tracing to www.free.fr[a] via 127.0.0.1, maximum of 3 retries
127.0.0.1 (127.0.0.1) IP HEADER
- Destination address:  127.0.0.1
DNS HEADER (send)
- Identifier:           0x6E1C
- Flags:                0x00 (Q )
- Opcode:               0 (Standard query)
- Return code:          0 (No error)
- Number questions:     1
- Number answer RR:     0
- Number authority RR:  0
- Number additional RR: 0
QUESTIONS (send)
- Queryname:            (3)www(4)free(2)fr
- Type:                 1 (A)
- Class:                1 (Internet)
DNS HEADER (recv)
- Identifier:           0x6E1C
- Flags:                0x8080 (R RA )
- Opcode:               0 (Standard query)
- Return code:          0 (No error)
- Number questions:     1
- Number answer RR:     0
- Number authority RR:  13
- Number additional RR: 0
QUESTIONS (recv)
- Queryname:            (3)www(4)free(2)fr
- Type:                 1 (A)
- Class:                1 (Internet)
AUTHORITY RR
- Domainname:           (1).
- Type:                 2 (NS)
- Class:                1 (Internet)
- TTL:                  143225 (1d15h47m5s)
- Resource length:      4
- Resource data:        (1)K(12)ROOT-SERVERS(3)NET
AUTHORITY RR
- Domainname:           (1).
- Type:                 2 (NS)
- Class:                1 (Internet)
- TTL:                  143225 (1d15h47m5s)
- Resource length:      20
- Resource data:        (1)C(12)ROOT-SERVERS(3)NET
Refers backwards

Dnstracer est disponible ici : DNSTRACER

dnswalk

Il est nécessaire pour une bonne analyse que la commande AXFR soit acceptée par le DNS cible, ce qui est loin d'être gagné... Sinon autant dire que cette outil ne sert à pas grand chose. Sinon, il permet beaucoup un contrôle d'une zone locale. Une fois ceci réalisée, vous pouvez connaître si votre zone est conforme ou pas, le cas échéant les erreurs sont clairements expliquées ...

Ce programme est disponible ici : DNSWALK (http://sourceforge.net/project/showfiles.php?group_id=1103)

serveur ~ # dnswalk archi.amt.
            Checking archi.amt.
            Getting zone transfer of archi.amt. from serveur.archi.amt...done.
            SOA=serveur.archi.amt   contact=laurent.serveur.archi.amt
            0 failures, 0 warnings, 0 errors.

Divers programmes DNS et utilitaires...

Avec ce lien, vous pouvez trouver beaucoup de programmes lié aux DNS.http://www.bind9.net/dns-tools

Gbindadmin

Voici un superbe produit, mais que je le trouve trop stricte envers la configuration pour Bind. J'aurais volontier aimé qu'il puisse travailler avec mes répertoires courants ou spécifiques, et non pas imposer une architecture. http://85.214.17.244/gadmintools/index.php

WEBMIN

Webmin est outil d'administration WEB capable d'administrer beaucoup de services pour Gnu/Linux. Bind n'y échappe pas, il existe un module pour celui-ci. Après approximativement 5 minutes pour le configurer, tout les paramètres sont pris en compte. Certes il nécessite une prise en main obligatoire, mais après, pour ceux qui préfère cliquer (à l'inverse de moi) c'est je pense l'outil idoine. Son seul défaut est qu'il nécessite un serveur WEB, apportant de surcroit un soucis même mineur au niveau de la sécurité. Webmin est disponible ici http://www.webmin.com/ Et malgré le « .com », il est totalement gratuit.

Et pour ceux qui cherche un guide, j'ai trouvé ceci : http://swelltech.com/support/webminguide/ch08.html

Bindgraph

Bindgraph permet de visualiser sous forme de graphiques les types et le nombre de requêtes traitées par votre DNS. C'est beau, simple à mettre en oeuvre et performant, nécessite une serveur WEB tout de même. Ce logiciel est disponible au moins pour Mandriva et Debian, Ubuntu(S) : http://packages.debian.org/unstable/admin/bindgraph

DNS Bajaj

C'est un tout petit programme libre (GPL), capable de créer une image des relations DNS qui existe entre eux, en partant d'une racine vers un domaine déterminé. Vous pouvez tester avec le domaine europa.eu qui correspond à l'UE, et essayez de comprendre qui fait quoi ... http://www.zonecut.net/dns/

Annexe A2. Informations disponibles sur Internet.

Annexe A3. Les options pour le fichier named.conf

C'est assez énorme ... il est difficile de parler de tout ...

Note

Toutes les balises < > ont été remplacé par des ( ), car incompatibles avec la rédaction de ce document (docbook).

 options {
        avoid-v4-udp-ports { (port); ... };
        avoid-v6-udp-ports { (port); ... };
        blackhole { (address_match_element); ... };
        coresize (size);
        datasize (size);
        deallocate-on-exit (boolean); // obsolete
        directory (quoted_string);
        dump-file (quoted_string);
        fake-iquery (boolean); // obsolete
        files (size);
        has-old-clients (boolean); // obsolete
        heartbeat-interval (integer);
        host-statistics (boolean); // not implemented
        host-statistics-max (integer); // not implemented
        hostname ( (quoted_string) | none );
        interface-interval (integer);
        listen-on [ port (integer) ] { (address_match_element); ... };
        listen-on-v6 [ port (integer) ] { (address_match_element); ... };
        match-mapped-addresses (boolean);
        memstatistics-file (quoted_string);
        multiple-cnames (boolean); // obsolete
        named-xfer (quoted_string); // obsolete
        pid-file ( (quoted_string) | none );
        port (integer);
        querylog (boolean);
        recursing-file (quoted_string);
        random-device (quoted_string);
        recursive-clients (integer);
        serial-queries (integer); // obsolete
        serial-query-rate (integer);
        server-id ( (quoted_string) | none |;
        stacksize (size);
        statistics-file (quoted_string);
        statistics-interval (integer); // not yet implemented
        tcp-clients (integer);
        tcp-listen-queue (integer);
        tkey-dhkey (quoted_string) (integer);
        tkey-gssapi-credential (quoted_string);
        tkey-domain (quoted_string);
        transfers-per-ns (integer);
        transfers-in (integer);
        transfers-out (integer);
        treat-cr-as-space (boolean); // obsolete
        use-id-pool (boolean); // obsolete
        use-ixfr (boolean);
        version ( (quoted_string) | none );
        flush-zones-on-shutdown (boolean);
        allow-query-cache { (address_match_element); ... };
        allow-recursion { (address_match_element); ... };
        allow-v6-synthesis { (address_match_element); ... }; // obsolete
        sortlist { (address_match_element); ... };
        topology { (address_match_element); ... }; // not implemented
        auth-nxdomain (boolean); // default changed
        minimal-responses (boolean);
        recursion (boolean);
        rrset-order { [ class (string) ] [ type (string) ] [ name
            (quoted_string) ] (string) (string); ... };
        provide-ixfr (boolean);
        request-ixfr (boolean);
        fetch-glue (boolean); // obsolete
        rfc2308-type1 (boolean); // not yet implemented
        additional-from-auth (boolean);
        additional-from-cache (boolean);
        query-source (querysource4);
        query-source-v6 (querysource6);
        cleaning-interval (integer);
        min-roots (integer); // not implemented
        lame-ttl (integer);
        max-ncache-ttl (integer);
        max-cache-ttl (integer);
        transfer-format ( many-answers | one-answer );
        max-cache-size (size_no_default);
        check-names ( master | slave | response ) ( fail | warn | ignore );
        cache-file (quoted_string);
        suppress-initial-notify (boolean); // not yet implemented
        preferred-glue (string);
        dual-stack-servers [ port (integer) ] { ( (quoted_string) [port
            (integer)] | (ipv4_address) [port (integer)] | (ipv6_address) [port (integer)] ); ... };
        edns-udp-size (integer);
        max-udp-size (integer);
        root-delegation-only [ exclude { (quoted_string); ... } ];
        disable-algorithms (string) { (string); ... };
        dnssec-enable (boolean);
        dnssec-validation (boolean);
        dnssec-lookaside (string) trust-anchor (string);
        dnssec-must-be-secure (string) (boolean);
        dnssec-accept-expired (boolean);
        ixfr-from-differences (ixfrdiff);
        acache-enable (boolean);
        acache-cleaning-interval (integer);
        max-acache-size (size_no_default>;
        clients-per-query (integer);
        max-clients-per-query (integer);
        empty-server (string);
        empty-contact (string);
        empty-zones-enable (boolean);
        disable-empty-zone (string);
        zero-no-soa-ttl-cache (boolean);
        allow-query { (address_match_element); ... };
        allow-transfer { (address_match_element); ... };
        allow-update { (address_match_element); ... };
        allow-update-forwarding { (address_match_element); ... };
        allow-notify { (address_match_element); ... };
        masterfile-format ( text | raw );
        notify (notifytype);
        notify-source ( (ipv4_address) | * ) [ port ( (integer) | * ) ];
        notify-source-v6 ( (ipv6_address) | * ) [ port ( (integer) | * ) ];
        also-notify [ port (integer) ] { ( (ipv4_address) | (ipv6_address)
            ) [ port (integer) ]; ... };
        notify-delay (integer);
        dialup (dialuptype);
        forward ( first | only );
        forwarders [ port (integer) ] { ( (ipv4_address) | (ipv6_address) )
            [ port (integer) ]; ... };
        maintain-ixfr-base (boolean); // obsolete
        max-ixfr-log-size (size); // obsolete
        max-journal-size (size_no_default);
        max-transfer-time-in (integer);
        max-transfer-time-out (integer);
        max-transfer-idle-in (integer);
        max-transfer-idle-out (integer);
        max-retry-time (integer);
        min-retry-time (integer);
        max-refresh-time (integer);
        min-refresh-time (integer);
        multi-master (boolean);
        sig-validity-interval (integer);
        transfer-source ( (ipv4_address) | * ) [ port ( (integer) | * ) ];
        transfer-source-v6 ( (ipv6_address) | * ) [ port ( (integer) | * ) ];
        alt-transfer-source ( (ipv4_address) | * ) [ port ( (integer) | * )
            ];
        alt-transfer-source-v6 ( (ipv6_address) | * ) [ port ( (integer) |
            * ) ];
        use-alt-transfer-source (boolean);
        zone-statistics (boolean);
        key-directory (quoted_string);
        check-wildcard (boolean);
        check-integrity (boolean);
        check-mx ( fail | warn | ignore );
        check-mx-cname ( fail | warn | ignore );
        check-srv-cname ( fail | warn | ignore );
        check-sibling (boolean);
        zero-no-soa-ttl (boolean);
        update-check-ksk (boolean);
};
controls {
        inet ( (ipv4_address) | (ipv6_address) | * ) [ port ( (integer) | *
            ) ] allow { (address_match_element); ... } [ keys { (string); ... } ];
        unix (quoted_string) perm (integer) owner (integer) group (integer)
            [ keys { (string); ... } ];
};
acl (string) { (address_match_element); ... };
masters (string) [ port (integer) ] { ( (masters) | (ipv4_address) [port
    (integer)] | (ipv6_address) [port (integer)] ) [ key (string) ]; ... };
       
logging {
        channel (string) {
                file (log_file);
                syslog (optional_facility);
                null;
                stderr;
                severity (log_severity);
                print-time (boolean);
                print-severity (boolean);
                print-category (boolean);
        };
        category (string) { (string); ... };
};
view (string) (optional_class) {
        match-clients { (address_match_element); ... };
        match-destinations { (address_match_element); ... };
        match-recursive-only (boolean);
        key (string) {
                algorithm (string);
                secret (string);
        };
        zone (string) (optional_class) {
                type ( master | slave | stub | hint | forward |
                    delegation-only );
                file (quoted_string);
                journal (quoted_string);
                ixfr-base (quoted_string); // obsolete
                ixfr-tmp-file (quoted_string); // obsolete
                masters [ port (integer) ] { ( (masters) | (ipv4_address)
                    [port (integer)] | (ipv6_address) [port (integer)] ) [ key (string) ]; ... };
                pubkey (integer) (integer) (integer) (quoted_string); //
                    obsolete
                update-policy { ( grant | deny ) (string) ( name |
                    subdomain | wildcard | self | selfsub | selfwild ) (string) (rrtypelist); ... };
                database (string);
                delegation-only (boolean);
                check-names ( fail | warn | ignore );
                ixfr-from-differences (boolean);
                allow-query { (address_match_element); ... };
                allow-transfer { (address_match_element); ... };
                allow-update { (address_match_element); ... };
                allow-update-forwarding { (address_match_element); ... };
                allow-notify { (address_match_element); ... };
                masterfile-format ( text | raw );
                notify (notifytype);
                notify-source ( (ipv4_address) | * ) [ port ( (integer) | *
                    ) ];
                notify-source-v6 ( (ipv6_address) | * ) [ port ( (integer)
                    | * ) ];
                also-notify [ port (integer) ] { ( (ipv4_address) |
                    (ipv6_address) ) [ port (integer) ]; ... };
                notify-delay (integer);
                dialup (dialuptype);
                forward ( first | only );
                forwarders [ port (integer) ] { ( (ipv4_address) |
                    (ipv6_address) ) [ port (integer) ]; ... };
                maintain-ixfr-base (boolean); // obsolete
                max-ixfr-log-size (size); // obsolete
                max-journal-size (size_no_default);
                max-transfer-time-in (integer);
                max-transfer-time-out (integer);
                max-transfer-idle-in (integer);
                max-transfer-idle-out (integer);
                max-retry-time (integer);
                min-retry-time (integer);
                max-refresh-time (integer);
                min-refresh-time (integer);
                multi-master (boolean);
                sig-validity-interval (integer);
                transfer-source ( (ipv4_address) | * ) [ port ( (integer) |
                    * ) ];
                transfer-source-v6 ( (ipv6_address) | * ) [ port (
                    (integer) | * ) ];
                alt-transfer-source ( (ipv4_address) | * ) [ port (
                    (integer) | * ) ];
                alt-transfer-source-v6 ( (ipv6_address) | * ) [ port (
                    (integer) | * ) ];
                use-alt-transfer-source (boolean);
                zone-statistics (boolean);
                key-directory (quoted_string);
                check-wildcard (boolean);
                check-integrity (boolean);
                check-mx ( fail | warn | ignore );
                check-mx-cname ( fail | warn | ignore );
                check-srv-cname ( fail | warn | ignore );
                check-sibling (boolean);
                zero-no-soa-ttl (boolean);
                update-check-ksk (boolean);
        };
        dlz (string) {
                database (string);
        };
        server (netprefix) {
                bogus (boolean);
                provide-ixfr (boolean);
                request-ixfr (boolean);
                support-ixfr (boolean); // obsolete
                transfers (integer);
                transfer-format ( many-answers | one-answer );
                keys (server_key);
                edns (boolean);
                edns-udp-size (integer);
                max-udp-size (integer);
                notify-source ( (ipv4_address) | * ) [ port ( (integer) | *
                    ) ];
                notify-source-v6 ( (ipv6_address) | * ) [ port ( (integer)
                    | * ) ];
                query-source (querysource4);
                query-source-v6 (querysource6);
                transfer-source ( (ipv4_address) | * ) [ port ( (integer) |
                    * ) ];
                transfer-source-v6 ( (ipv6_address) | * ) [ port (
                    (integer) | * ) ];
        };
        trusted-keys { (string) (integer) (integer) (integer)
            (quoted_string); ... };
        allow-query-cache { (address_match_element); ... };
        allow-recursion { (address_match_element); ... };
        allow-v6-synthesis { (address_match_element); ... }; // obsolete
        sortlist { (address_match_element); ... };
        topology { (address_match_element); ... }; // not implemented
        auth-nxdomain (boolean); // default changed
        minimal-responses (boolean);
        recursion (boolean);
        rrset-order { [ class (string) ] [ type (string) ] [ name
            (quoted_string) ] (string) (string); ... };
        provide-ixfr (boolean);
        request-ixfr (boolean);
        fetch-glue (boolean); // obsolete
        rfc2308-type1 (boolean); // not yet implemented
        additional-from-auth (boolean);
        additional-from-cache (boolean);
        query-source (querysource4);
        query-source-v6 (querysource6);
        cleaning-interval (integer);
        min-roots (integer); // not implemented
        lame-ttl (integer);
        max-ncache-ttl (integer);
        max-cache-ttl (integer);
        transfer-format ( many-answers | one-answer );
        max-cache-size (size_no_default);
        check-names ( master | slave | response ) ( fail | warn | ignore );
        cache-file (quoted_string);
        suppress-initial-notify (boolean); // not yet implemented
        preferred-glue (string);
        dual-stack-servers [ port (integer) ] { ( (quoted_string) [port
            (integer)] | (ipv4_address) [port (integer)] | (ipv6_address) [port (integer)] ); ... };
        edns-udp-size (integer);
        max-udp-size (integer);
        root-delegation-only [ exclude { (quoted_string); ... } ];
        disable-algorithms (string) { (string); ... };
        dnssec-enable (boolean);
        dnssec-validation (boolean);
        dnssec-lookaside (string) trust-anchor (string);
        dnssec-must-be-secure (string) (boolean);
        dnssec-accept-expired (boolean);
        ixfr-from-differences (ixfrdiff);
        acache-enable (boolean);
        acache-cleaning-interval (integer);
        max-acache-size (size_no_default);
        clients-per-query (integer);
        max-clients-per-query (integer);
        empty-server (string);
        empty-contact (string);
        empty-zones-enable (boolean);
        disable-empty-zone (string);
        zero-no-soa-ttl-cache (boolean);
        allow-query { (address_match_element); ... };
        allow-transfer { (address_match_element); ... };
        allow-update { (address_match_element); ... };
        allow-update-forwarding { (address_match_element); ... };
        allow-notify { (address_match_element); ... };
        masterfile-format ( text | raw );
        notify (notifytype);
        notify-source ( (ipv4_address) | * ) [ port ( (integer) | * ) ];
        notify-source-v6 ( (ipv6_address) | * ) [ port ( (integer) | * ) ];
        also-notify [ port (integer) ] { ( (ipv4_address) | (ipv6_address)
            ) [ port (integer) ]; ... };
        notify-delay (integer);
        dialup (dialuptype);
        forward ( first | only );
        forwarders [ port (integer) ] { ( (ipv4_address) | (ipv6_address) )
            [ port (integer) ]; ... };
        maintain-ixfr-base (boolean); // obsolete
        max-ixfr-log-size (size); // obsolete
        max-journal-size (size_no_default);
        max-transfer-time-in (integer);
        max-transfer-time-out (integer);
        max-transfer-idle-in (integer);
        max-transfer-idle-out (integer);
        max-retry-time (integer);
        min-retry-time (integer);
        max-refresh-time (integer);
        min-refresh-time (integer);
        multi-master (boolean);
        sig-validity-interval (integer);
        transfer-source ( (ipv4_address) | * ) [ port ( (integer) | * ) ];
        transfer-source-v6 ( (ipv6_address) | * ) [ port ( (integer) | * ) ];
        alt-transfer-source ( (ipv4_address) | * ) [ port ( (integer) | * )
            ];
        alt-transfer-source-v6 ( (ipv6_address) | * ) [ port ( (integer) |
            * ) ];
        use-alt-transfer-source (boolean);
        zone-statistics (boolean);
        key-directory (quoted_string);
        check-wildcard (boolean);
        check-integrity (boolean);
        check-mx ( fail | warn | ignore );
        check-mx-cname ( fail | warn | ignore );
        check-srv-cname ( fail | warn | ignore );
        check-sibling (boolean);
        zero-no-soa-ttl (boolean);
        update-check-ksk (boolean);
        database (string);
};
lwres {
        listen-on [ port (integer) ] { ( (ipv4_address) | (ipv6_address) )
            [ port (integer) ]; ... };
        view (string) (optional_class);
        search { (string); ... };
        ndots (integer);
};

key (string) {
        algorithm (string);
        secret (string);
};
zone (string) (optional_class) {
        type ( master | slave | stub | hint | forward | delegation-only );
        file (quoted_string);
        journal (quoted_string);
        ixfr-base (quoted_string); // obsolete
        ixfr-tmp-file (quoted_string); // obsolete
        masters [ port (integer) ] { ( (masters) | (ipv4_address) [port
            (integer)] | (ipv6_address) [port (integer)] ) [ key (string) ]; ... };
        pubkey (integer) (integer) (integer) (quoted_string); // obsolete
        update-policy { ( grant | deny ) (string) ( name | subdomain |
            wildcard | self | selfsub | selfwild ) (string) (rrtypelist); ... };
        database (string);
        delegation-only (boolean);
        check-names ( fail | warn | ignore );
        ixfr-from-differences (boolean);
        allow-query { (address_match_element); ... };
        allow-transfer { (address_match_element); ... };
        allow-update { (address_match_element); ... };
        allow-update-forwarding { (address_match_element); ... };
        allow-notify { (address_match_element); ... };
        masterfile-format ( text | raw );
        notify (notifytype);
        notify-source ( (ipv4_address) | * ) [ port ( (integer) | * ) ];
        notify-source-v6 ( (ipv6_address) | * ) [ port ( (integer) | * ) ];
        also-notify [ port (integer) ] { ( (ipv4_address) | (ipv6_address)
            ) [ port (integer) ]; ... };
        notify-delay (integer);
        dialup (dialuptype);
        forward ( first | only );
        forwarders [ port (integer) ] { ( (ipv4_address) | (ipv6_address) )
            [ port (integer) ]; ... };
        maintain-ixfr-base (boolean); // obsolete
        max-ixfr-log-size (size); // obsolete
        max-journal-size (size_no_default);
        max-transfer-time-in (integer);
        max-transfer-time-out (integer);
        max-transfer-idle-in (integer);
        max-transfer-idle-out (integer);
        max-retry-time (integer);
        min-retry-time (integer);
        max-refresh-time (integer);
        min-refresh-time (integer);
        multi-master (boolean);
        sig-validity-interval (integer);
        transfer-source ( (ipv4_address) | * ) [ port ( (integer) | * ) ];
        transfer-source-v6 ( (ipv6_address) | * ) [ port ( (integer) | * ) ];
        alt-transfer-source ( (ipv4_address) | * ) [ port ( (integer) | * )
            ];
        alt-transfer-source-v6 ( (ipv6_address) | * ) [ port ( (integer) |
            * ) ];
        use-alt-transfer-source (boolean);
        zone-statistics (boolean);
        key-directory (quoted_string);
        check-wildcard (boolean);
        check-integrity (boolean);
        check-mx ( fail | warn | ignore );
        check-mx-cname ( fail | warn | ignore );
        check-srv-cname ( fail | warn | ignore );
        check-sibling (boolean);
        zero-no-soa-ttl (boolean);
        update-check-ksk (boolean);
};

dlz (string) {
        database (string);
};
server (netprefix) {
        bogus (boolean);
        provide-ixfr (boolean);
        request-ixfr (boolean);
        support-ixfr (boolean); // obsolete
        transfers (integer);
        transfer-format ( many-answers | one-answer );
        keys (server_key);
        edns (boolean);
        edns-udp-size (integer);
        max-udp-size (integer);
        notify-source ( (ipv4_address) | * ) [ port ( (integer) | * ) ];
        notify-source-v6 ( (ipv6_address) | * ) [ port ( (integer) | * ) ];
        query-source (querysource4);
        query-source-v6 (querysource6);
        transfer-source ( (ipv4_address) | * ) [ port ( (integer) | * ) ];
        transfer-source-v6 ( (ipv6_address) | * ) [ port ( (integer) | * ) ];
};
trusted-keys { (string) (integer) (integer) (integer) (quoted_string); ... };

Annexe A4. Mon « named.conf »

Le fichier named.conf.

/*
      /etc/named/named.conf
*/
//------------------------------------------------------

// inclusions de fichiers :
include "/etc/bind/acl.inc";
include "/etc/bind/rndc.key"; 
include "/etc/bind/tsig-key";
//------------------------------------------------------
trusted-keys {
archi.amt.   257 3 5 "AwEAAdW61etMG09fMwhWw0PTflUU/5iUQlI+iSwrAYnfJYoa2/wr11EU N82XAzM720I+/HsYgkaaOPVtHm43FHgrNsiDmvBSMNuHdrB6A7JiVU4O ZzYcuvXxrocjV9S35p16CQLhJexf+3aW44RkjuLz7leBHpQEANtYhONd jjvgN71hJqZRq6Wupwf0bTPfIS2DQrQfOoLIPuP6DQnsAovf8spcVrNi o14hoIiSOPHojv6TAa9pZfCU6VTp2lXtVMrB7M1LjwbN+rvt++aXI8+p GrztnaBgqc7Cn1sQChrT+0N1sgP2Q8bBoSXX6M7c+FCaw1KNIH0we2dY /X90W/3BylM=";
};
trusted-keys {
1.168.192.in-addr.arpa. 257 3 5 "AwEAAca648pd/6b3MtZaQxOqkUvCr9k58/YUU0a+Y5tnAaDxTxfZ+V+C lolzZAp9jSGLEhx3tSnS9K0LBMmWuC7EnZghbKt/WQ7Hp+O1La6mwjK6 lONpBSDRdHlTCDi4MtebOW0MqYNLclqfBqmVXlx6ul5JuW6zd16SZaqY 6j4qMWEK/WSxcb9seHp16fRwvYyYkyywQUUt+xRI8r6o7pxg/G189awz CONZ4a3qIYHVqpoMCVWyXn4UCaaAe3d2uP+LWvj9hHi+vrvmm98rOtq3 lHMPTnAUUCEnxoRVGQxg6Mt/FRStYr/VhatRld7W1YrBz2d0z3u3Dfhv 5MLeA/cgSxU=";
};
//------------------------------------------------------
//////////////////////////////////
options {
        
        // SECURITE PAS DE TYPE CHAOS//
        version none;
        hostname none;
        server-id none;
        // DNSSEC //
        dnssec-enable yes;
        // REPERTOIRE //
        directory "/etc/bind";
        dump-file "/var/run/named/named-dump.db";
        pid-file "/var/run/named/named.pid";
        # manque un truc pour : memstatistics-file "/var/run/named/named-memory"
        // STATS //
        // pour 9.5 :
        stats-server address 127.0.0.1 port 8080;
        // ----------
        statistics-file "/var/run/named/named.stats";
        zone-statistics yes;
        // en test ...
        memstatistics-file "/var/run/named/memory.stats";
        // fichier ultra reduit
        coresize 0M;
        // Limitation des clients (defaut=1000)
        // recursive-clients 1000;
        // query-source address * port 53; //surtout pour les FW
        // IP ecoute par ce serveur
        listen-on { 127.0.0.1; 192.168.1.11; };
        // Pas de zones vides automatiques...
        empty-zones-enable no;
        // pour un primaire (secondaire = transfers-in)
        allow-transfer { 127.0.0.1 ; none; }; // option globale
        allow-update { none; };         // pas de mise a jour DHCP
        // transfers-out 20;            // nb transfert max d'1 seul coup
        // transfers-per-ns 2;          // transfert par serveur      
        auth-nxdomain no;               // conforme RFC 1035
        // pour internet = 0 
        lame-ttl 0;               //faux serveurs primaires
        // negatif cache en RAM
        max-ncache-ttl 1800;
        // positif cache en RAM
        // 127800 = 2 jours MAX et non une semaine (defaut)
        max-cache-ttl 172800;
        //Activation du forward ... pour internet
        forwarders { 194.117.200.10; 194.117.200.15; };
        // Peut faire de la récursion - option globale voir allow-recursion...
        recursion yes;
        // Traitement DOS DNS ...
        // par defaut 10 clients
        clients-per-query 10; 
        // Par defaut 100 ...
        max-clients-per-query 100; 
        allow-recursion { INTERNE; };  // mais que pour eux
        // Qui peut questionner le serveur ...
        allow-query { INTERNE; key resolver-serveur; };
        // Qui peut questionner les caches du serveur ...
        allow-query-cache { INTERNE; key resolver-serveur; };
        // limitation EDNS ...(max 4096)
        edns-udp-size 512 ;
        max-udp-size  512 ;

};

//------------------------------------------------------
// ---- TSIG
// Vers .... utilise cette cle ...
server 192.168.1.15 { keys { serveur-second.; }; };
//------------------------------------------------------
// -- pour RNDC --
controls { 
        inet 127.0.0.1 port 953 
        allow { 127.0.0.1; } keys { serveur; };
};
// Prise en compte des includes
include "/etc/bind/logging.inc";
//include "/etc/bind/view.inc";

//////////////////////////////////
// Gestion du point OBLIGATOIRE
//////////////////////////////////
zone "." {
        type hint;
        file "pri/named.ca";
};
//////////////////////////////////
// GESTION DU LOCALHOST - CONSEILLE
//////////////////////////////////
zone "localhost" IN {
        type master;
        file "pri/localhost.zone";
        notify no;
};
//////////////////////////////////
// GESTION REVERSE 127.0.0.1 - CONSEILLE
//////////////////////////////////
zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "pri/127.zone";
        notify no;
};
//------------------------------------------------------
//////////////////////////////////
// EXEMPLE MASTER
//////////////////////////////////
zone "archi.amt" IN {
        type master;
        file "pri/archi.amt.signed";
        allow-transfer { ADMINS; key serveur-second; };
        notify yes;
};
//////////////////////////////////
// EXEMPLE REVERSE MASTER
//////////////////////////////////
zone "1.168.192.in-addr.arpa" IN {
        type master;
        file "pri/1.168.192.in-addr.arpa.signed";
        allow-transfer { ADMINS; key serveur-second; };
        notify yes;
};
/////////////////////////////////
// EXEMPLE SOUS DOMAINE
/////////////////////////////////
zone "sous.archi.amt" IN {
        type slave;
        file "sec/sous.archi.amt";
        masters { 192.168.1.15; };
        notify no;
        forwarders { 192.168.1.15; }; // facultatif ...
        };
/////////////////////////////////
// EXEMPLE STUB
/////////////////////////////////
zone "stub.archi.amt" IN {
        type stub;
        file "stub/stub.archi.amt";
        masters { 192.168.1.15; };
        // Pas de allow-transfer pour une zone STUB
        };
/////////////////////////////////
/////////////FIN/////////////////

Annexe A5. Mes fichiers « localhost » et « 127.0.0.1 ».

Le fichier localhost.zone :

$TTL 1W
@       IN      SOA     serveur.archi.amt. root.localhost.  (
                    2008102702      ; Serial
                    1W                     ; Refresh
                    1D                     ; Retry
                    1M                     ; Expire - 1 week
                    1D )                   ; Minimum
$TTL 1D
@       IN NS   serveur.archi.amt.
$TTL 1W
@       IN A    127.0.0.1

Le fichier 127.zone :

$TTL 1W
@       IN SOA serveur.archi.amt. root.localhost. (
                2002081603      ; serial
                1D              ; refresh
                1H              ; retry
                1W              ; expiry
                1D )            ; minimum
$TTL 1D
@       IN NS   serveur.archi.amt.
$TTL 1W
*       IN PTR  localhost.

Annexe A6. Mes 2 fichiers de zones.

Le fichier archi.amt.

$TTL 1D
@       IN      SOA     serveur.archi.amt.  laurent.serveur.archi.amt. (
                        2007120202 ; serial
                        1D         ; refresh
                        1H         ; retry
                        1W         ; expiry
                        1D )       ; minimum
@       IN NS   serveur.archi.amt.
         IN NS   second.archi.amt.
; DNSsec :
$INCLUDE "/etc/bind/pri/Karchi.amt.+005+10926.key";
;
$TTL 1W
serveur         IN A    192.168.1.11
$TTL 2D
@               IN TXT "Serveur DNS de Archi"
@               IN TXT "01.02.03.0512 De 10h00 a 10h05"
@               IN RP  Jean.Paul.domain.com Admin.pour\.Bind
@               IN RP  Maurice.domain.com  Mise.a.jour.des.donnees
;
$TTL 1D
                IN MX 10 serveur.archi.amt.
pop             IN CNAME serveur.archi.amt.             
smtp            IN CNAME serveur.archi.amt.             
;               IN MX 20 second.archi.amt.   ;; pour un 2eme ...
;
$TTL 2D
second          IN A    192.168.1.15
dm                IN A    192.168.1.100
fh                 IN A    192.168.1.20
test               IN A    192.168.1.22
Le fichier 1.168.192.in-addr.arpa.        
        $TTL 1D
@       1D      IN      SOA     serveur.archi.amt. laurent.serveur.archi.amt. (
                        2007112101  ; serial
                        1D          ; refresh
                        1H          ; retry
                        1W          ; expire
                        1D )        ; minimum
$TTL 12H
        IN NS   serveur.archi.amt.
        IN NS   second.archi.amt.
; DNSsec
$INCLUDE "/etc/bind/pri/K1.168.192.in-addr.arpa.+005+18028.key";
$INCLUDE "/etc/bind/pri/K1.168.192.in-addr.arpa.+005+52131.key";
;
$TTL 1M
1       IN PTR  routeur.archi.amt.
$TTL 1W
10      IN PTR  serveur2.archi.amt.
$TTL 12H
15      IN PTR  second.archi.amt.
$TTL 1W
100     IN PTR  dm.archi.amt.
11      IN PTR  serveur.archi.amt.
100     IN PTR  dm.archi.amt.
22      IN PTR  test.archi.amt.
20      IN PTR  fh.archi.amt.

Annexe A7. Mon fichier pour les logs de Bind.

Le fichier logginc.inc

////////////////////////////////////////////////
// Systeme de gestion des historiques pour BIND.
// fichier : /etc/named/logging.inc
// Declaration des channels
///////////////////////////////////////////////

logging {
        // Concerne les problemes de securite
        channel security_channel {
                file "/var/log/named/security.log" versions 2 size 400K ;
                severity info;
                print-time yes;
                };

        // Concerne les log divers 
        channel default_channel {
                file "/var/log/named/default.log" versions 2 size 400K ;
                severity dynamic;
                print-category yes;
                print-severity yes;
                print-time yes;
                };
        
        // Concerne les tranferts entrants (zones slave|stub)
        channel xfer-in_channel {
                file "/var/log/named/xfer-in.log" versions 1 size 100K ;
                severity info;
                print-time yes;
                };

        // Concerne les tranferts sortants (zones master)
        channel xfer-out_channel {
                file "/var/log/named/xfer-out.log" versions 1 size 100K ;
                severity info;
                print-time yes;
                };

        // log les notifcations uniquement
        channel notify_channel {
                file "/var/log/named/notify.log" versions 1 size 100K ;
                severity info;
                print-time yes;
                };
                
        // historique des requetes sur votre serveur
        channel querylog {
                file "/var/log/named/query.log" versions 2 size 400K ;
                severity info;
                print-time yes;
                };
                
        // historique des LAME-SERVER
        channel lame_channel {
                file "/var/log/named/lame.log" versions 2 size 50K ;
                severity info;
                print-time yes;
                };
        "
// Activation des CANAUX ///////////////        
        
        category lame-servers { lame_channel; };
        category update { null; };
        category notify { notify_channel; };

        // A GARDER pour le suivi des AXFR
        category xfer-out { xfer-out_channel; };

           category xfer-in { xfer-in_channel; };
        category default { default_channel; };
        category security { security_channel; };
        category queries { querylog; };
        category client { querylog; };
        category resolver { querylog; };
        category unmatched { default_channel; };
        //category dnssec { security_channel;  };
};
////////   FIN   /////////

Glossaire

EDNS
Extension Mechanism for DNS. C'est une extension de taille des paquets UDP qui peuvent passer de 512 octes à 4096. Peut poser des problèmes vis à vis des pare-feux, il est possible de limiter ceci par edns-udp-size 512;, à placer au niveau des options dans le fichier de configuration de Bind (EDNS-512). Très utilisé avec DNSsec en particulier, ceci se comprend facilement.
Beaucoup de serveurs (Active directory en particulier) répondent en EDNS, c'est le réflexe d'une réponse à un paquet mal compris par eux. Les réponses EDNS peuvent également arriver suite à une communication sans réponse (time out). En clair, si vous n'avez pas activé DNSsec, aucune raison d'activer ou d'utiliser EDNS.
RRset
C'est un ensemble d'enregistrement dans une zone. Exemple le champ MX dans une zone correspond à un RRset car il contient l'adresse IP, un TTL, une classe ...
RRSIG
Lié à DNSsec, il représente la signature (DNSsec) pour une donnée de ressource, plusieurs types MX (exemple) donne seulement une seule clé.
DHCP
Le « Dynamic Host Configuration Protocol » est un protocole réseau qui assure la configuration automatique des clients. Ce protocole nécessite d'enregistrer des données dynamiques dans les zone gérées par Bind. L'appellation de DDNS peut être utilisé pour désigner un « Dynamique DNS ».
NTP
C'est le protocole qui sert à maintenir au niveau horaire des machines/serveurs à l'heure atomique (Network Time Protocol). Ce le logiciel est également soutenu par ISC.org comme Bind.
TLD
Le « Top Level Domain  » représente les serveurs au plus haut niveau dans la hiérarchie DNS. Donc c'est les 13 ROOT déclarés, qui sont plus nombreux que cela par la présence de grappes. Le terme de TLDN est aussi un équivalent, la lettre « N », veut dire « name ». Et en dessous des TLD, il existe une multitude de sous classes comme :
« ccTLD (country code top-level domain) » qui représente 2 lettres pour identifier les divers pays, dont le ".fr".
« gTLD (generic top-level domain) » qui gère les particules ".net", ".org"...etc
Et encore bien d'autres encore, la liste pourrait être longue...