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
named.conf
.host
dnssec-keygen
.named.conf
Liste des tableaux
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
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.
Table des matières
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.
Avant de commencer, il est important que les termes suivants soient connus, ils font tous parti du « langage » DNS.
Terme |
Explication |
---|---|
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. |
|
« 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). |
|
C'est la correspondance adresse IP vers un nom, c'est aussi la
base du DNS. Exemple |
|
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. |
|
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. |
Depuis très longtemps Bind utilise le nom de |
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 :
// ...
Vos commentaires sur 1 ligne. A utiliser dans les fichiers de configurations.
/* ... */
Vos commentaires possibles sur plusieurs lignes. A utiliser dans les fichiers de configurations.
; ...
UNIQUEMENT dans les zones, aucun des autres caractères précités pour un fichier de zone (!).
# ...
A utiliser dans les fichiers de configurations.
Table des matières
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.
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.
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.
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
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 ...
« --sysconfdir=/etc/bind » indique le répertoire ou va se trouver les fichiers de configuration pour Bind.
« --localstatedir=/var » indique le répertoire ou seront stockées les zones « /var/bind/ »
« --disable-ipv6 » ne supporte pas IPv6, et donc ne va pas créer de zone au format IPv6 (option bien pratique).
« --with-openssl » pour utiliser le cryptage (TSIG et/ou DNSsec) (OpenSSL doit être installé avant et séparément).
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)
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.
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.
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.
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.
DNS Primaire ou secondaire :
Ces serveurs gèrent une ou plusieurs zones en primaires ou en secondaires.
DNS Primaire et secondaire :
Ces serveurs gèrent une ou plusieurs zones en primaires et en secondaires.
DNS Cache
Ces serveurs ne gèrent aucune zone, la présence de caches à leurs niveaux participent à optimiser le réseau. J'ai même croisé le terme de CNS (cache name service).
DNS forward :
Ces serveurs installés derrière un réseau, gèrent au moins une zone en interne. Cette configuration est souvent utilisée pour internet. L'option « forward » indique à Bind comment résoudre une requête qu'il ne peut traiter en se basant sur ses données internes.
DNS proxy (transparent) :
Ces serveurs servent de passerelles entre plusieurs réseaux, ils ne gèrent aucune zone.
DNS ROOT :
Ces DNS sont capitaux, et sont nommés les TLD (Top Level Domain) ( également expliqué ici : Glossaire), car uniquement eux gèrent le niveau le plus haut, qui est le point « . » pour l'ensemble des domaines. Internet comporte actuellement 13 ROOT (visibles), mais en comporte réellement plus.
Sans ces racines le réseau DNS n'est plus rien, ils sont très bien protégés...heureusement.
A ce stade nous allons apprendre comment un DNS peut agir selon une requête, tout en sécurisant votre réseau.
Résolution ITERATIVE :
Ce n'est pas le mode de requête le plus rencontré car il est très spécifique. A ce sujet, il est important de savoir, qu'un résolver (niveau client ou application) ne peut agir autrement que en posant une question, dans le style « je veux joindre le www.europa.eu ». Lequel attend uniquement une adresse IP en réponse. Il ne peut travailler si par exemple un DNS lui renvoi l'information suivante : « va voir les DNS de xxxx.domain.com, pour la réponse. ». Par contre, un serveur DNS sait résoudre ce genre de requête ou réponse. Avec le mode ITERATIF, soit le DNS connaît l'information parce qu'il gère ces données, soit la réponse est négative, non résolue intégralement. Il ne fera rien de plus pour aller chercher l'information ailleurs. Ce type de requête est surtout utilisé vis à vis d'internet vers un DNS « privé », ou il existe une ou plusieurs zones précises. Cette solution évite que les clients internets se servent de votre DNS en relais, au même titre que celui d'un FAI... Cette solution n'empêche tout de même pas à un client internet de demander à votre DNS votre champ MX (...), votre DNS doit répondre positivement, mais il ne fera rien de plus.
Attention à ne pas activer cette option par erreur, son action peut-être catastrophique. Les serveurs racines (13 au total) ou ROOT sont configurés avec l'option ITERATIVE, ce qui se comprend facilement.
Résolution RECURSIVE :
C'est tout l'inverse du mode ITERATIF, elle demande plus de travail à votre DNS, car celui-ci doit tout mettre en oeuvre pour résoudre une requête. Au final, si dans sa mémoire cache il ne trouve aucune information, il demande directement à l'une des racines (TLD). Il lui demande quels sont les serveurs DNS qui hébergent/gèrent cette zone. Si le domaine existe, et l'information demandée interne à cette zone existe, votre DNS doit la trouver, et la transmettre au RESOLVER.
Dans un réseau avec accès internet, ce type de requête est réservée aux membres de ce propre réseau, hormis les cas particuliers.
Table des matières
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
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
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 #
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
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.
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é
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... |
named.conf
.Table des matières
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.
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;
};
//////////////////////////////////
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 |
---|---|
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 |
server-id none; |
Identique à |
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 |
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 |
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 : |
Lié à l'option précédente
|
|
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 |
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
|
recursion yes; |
Le DNS est autorisé à faire de la résolution
RECURSIVE. Attention à l'emploi
de cette option avec la valeur |
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 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 |
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 Pour le cache positif, il existe l'option similaire
|
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
J'ai aussi croisé plusieurs configurations qui
utilisent cette configuration, exemple : |
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 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. |
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 La valeur Une valeur de zéro représente une valeur sans limite. |
|
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. |
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...
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
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 |
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 : Vous pouvez nommer le fichier pour cette zone comme vous bon
il vous semble grace à cette option : Aucune notification ne sera faite : |
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.
Je prend comme exemple, les données de la zone précédente (localhost).
$TTL 1W
Obligatoire avec les Bind récents, cette option définie le temps de vie par défaut pour la zone. Ce temps est exprimé souvent en secondes, les valeurs (D) pour jour, (W) pour semaine et (M) pour mois sont acceptées.
@ IN SOA serveur.archi.amt. root.localhost. (
Le caractère « @ »
représente pour Bind votre nom de domaine complet
(archi.amt). Le mot « IN » représente
la classe INternet, il en existe d'autres, mais seul cette classe
est utilisée (DNS classique). Cette valeur est facultative,
Bind la place automatiquement si elle est manquante. Ensuite nous
trouvons le serveur désigné comme SOA, « Start
Of Authority » ou en Français le responsable de la
zone (master/primaire). Est suivi de l'adresse mél pour
joindre l'administrateur. Elle ne doit pas comporter de signe « @ »,
il est remplacé par un point. Ensuite Bind interprétera
automatiquement le 1er point (!) rencontré en « @ ».
Pour préserver une adresse composé de plusieurs
points, il suffit de placer le signe \
devant le point; comme ceci :dns\.admin.serveur.archi.amt.
.
2007102801 ; serial
Il s'agit uniquement d'un numéro de
série qui peut être librement exprimé sous
différentes formes, à condition qu'il s'agisse de
chiffres. La norme ou plutôt la méthode la plus
utilisée est la forme AAAAMMJJNN
.
Les lettres A représentent l'année, suivie du mois
puis du jour, et terminé par un numéro de série
de 1 à 99. C'est ce numéro qui est à la base
des transferts de zones entres les serveurs. Si vous oubliez de
mettre à jour ce « serial », Bind
interprétera ceci comme une zone n'ayant pas été
modifié.
Si vous devez un jour inclure un serveur DNS Microsoft, celui-ci implémente sa propre solution. Le numéro de série est différent, il débute souvent à 1, puis 2...etc. Et il est utile de savoir que si Bind en tant que secondaire rencontre un numéro de série différent, il demande un transfert de zone(s). Bind est très souple, la solution du numéro de série commençant par le chiffre un ou autre est faisable, et vous évitera des transferts inutiles.
2D ; refresh
C'est la durée avant vérification de la zone par un serveur secondaire(s). Une petite valeur surcharge inutilement le primaire. Cette valeur doit être grande, car le primaire lors de changement (serial = modifié !), notifie de lui-même les secondaires.
12H ; retry
C'est la durée pour le prochain test de connexion suite à une erreur de connexion.
1W ; expiry
Si pas de contact avec le serveur primaire pendant la durée de cette valeur (1W), le secondaire(s) rejettera cette zone. Ce qui veut dire qu'il ne connaîtra plus cette zone. Néanmoins Bind va continuer de joindre le primaire. Cette valeur doit être grande mais raisonnable.
1D ) ; minimum
Représente la valeur de durée minimales de vie pour la zone complète.
C'est aussi le RR TTL pour certains...
$TTL 2D
A titre d'exemple, paramètre pour changer la valeur d'un TTL pour un champ(s). Il faut juste après placer une autre balise identique pour reprendre éventuellement des valeurs différentes ou par défaut. Elle veut bien dire « à compte d'ici le TTL est ... ».
@ IN NS serveur.archi.amt.
Déclaration d'un serveur secondaire, autant de lignes que de serveurs, sans répéter le caractère @...
@ IN A 127.0.0.1
Permet de déclarer un nom de machine
vers une adresse IP, l'inverse est réalisé par le
paramètre 11 IN PTR
serveur.archi.amt.
pour la
zone 1.168.192.in-addr.arpa.
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.
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 )
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...
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.
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.
|
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 |
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; }; » |
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 :
critical (compatible avec syslog)
error (compatible avec syslog)
warning (compatible avec syslog)
notice (compatible avec syslog)
info (compatible avec syslog)
debug [level]
dynanic
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 :
versions 0...99
Représente pour Bind combien de fichier
(+1) au total, vous souhaitez conserver. La valeur par défaut
est de 99 et aussi la maximale. Ce paramètre est être
lié à l'option obligatoirement size...
size 0...x
k|K m|M g|G
Représente pour Bind une taille qu'il
ne doit pas dépasser. Dès cette limite atteinte,
celui-ci va automatiquement créer un autre fichier, à
condition que la directive version
l'autorise.
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 /////////
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
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...
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.
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).
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; } }
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 ; ... ]
}; ]
...
};
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....
NS
Permet et c'est une obligation dans une zone de définir qui gère cette zone, les DNS primaire et secondaire sont confondus.
@ IN NS serveur.archi.amt. IN NS second.archi.amt.
A
Permet de lier un nom de machine et son domaine et son adresse IP.
serveur IN A 192.168.1.11
. L'inverse est le type PTR
.
MX
Permet de déclarer un serveur de méls pour un domaine. Le nom de se serveur peut être différent de celui du domaine. Le champ MX impose un chiffre de 1 à ... pour permettre de joindre par ordre de grandeur un ou plusieurs serveurs en cas d'échec.
wikimedia.org. 3600 IN MX 10 mchenry.wikimedia.org. wikimedia.org. 3600 IN MX 50 lists.wikimedia.org.
Pour cette exemple, le serveur possédant le chiffre 10 sera contacté le premier, si un problème est rencontré (refus, échec...), le serveur de mél distant procédera à une connexions sur l'autre avec le numéro « 50 »(plus grand).
Il est possible de fixer les même valeurs pour plusieurs serveurs (redondance).
AAAA
Identique au type « A » mais concerne les adresses IPv6.
PTR
Permet la liaison entre l'adresse IP et un nom de machine. La ligne doit se terminer obligatoirement par un point pour « fixer » le domaine.
11 IN PTR serveur.archi.amt.
TXT
Permet d'inclure un texte libre dans une zone, la limitation est fixée à 255 caractères.
@ IN TXT "Serveur DNS de Archi"
@ IN TXT "01.02.03.0512 De 10h00 a 10h05"
SRV
Utilisé énormément avec Active directory, se présente sous la forme « »_sip._udp SRV 0 1 5060 sip.mondomaine.com.
CNAME
Permet de créer un autre nom par rapport à une machine déjà déclarée, c'est une forme d'alias.
serveur IN CNAME smpt.archi.amt.
www IN CNAME mapageperso.monfai.com.
search IN CNAME www.google.com.
RP
Permet de donner des informations sur le responsable(s) de la zone. Ce champ est facultatif.
@ IN RP Jean.Paul.domain.com.archi.amt Admin-pour-Bind-archi.amt.
@ IN RP Maurice.domain.com.archi.amt. Mise-a-jour-des-donnees.archi.amt.
Table des matières
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é.
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
$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.
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.
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
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.
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.
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.
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 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)
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.
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
Table des matières
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.
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}]
Le mode -m affiche des données difficilement compréhensibles ...
-4 | -6
Permet d'activer uniquement un protocole
particulier IPv4 avec -4
,
et 6 pour IPv6. Bind par défaut écoute les 2
protocoles, l'usage de -4 est conseillé (pour encore quelques
temps).
-c conf_file
Paramètre pour identifier ou se trouve
le fichier named.conf
.
Ce paramètre peut être omis si compilé avec les
bons paramètres, comme dans ma situation. Sinon il suffit de
placer ceci en option : -c
/etc/bind/named.conf
-d level
Permet de passer le programme en mode « bogue » (debug) verbeux. A utiliser si vraiment Bind ne veut pas se lancer.
-f et -g
Différents paramètres pour lancer le programme non pas en mode résident, mais seulement comme un programme classique.
-n 1....x
Le paramètre -n
x
ou « x »
représente un chiffre supérieur à 1, il
identifie le nombre de processeur. Attention tout de même au
version de named « empacter » par une
distribution. Il semble que ce paramêtre ne soit pas forcement
pris en compte (option de compilation --enable-threads
)
manquante probablement. Avec un seul processeur il est inutile de le
préciser... Bind par défaut prend en compte
automatiquement tous les processeurs, sinon votre Bind n'est pas
optimisé pour cela.
-p
Normalement -p
53
, signifie le port d'écoute
du service DNS.
-s
A utiliser uniquement lors de debuggage...
-t chroot_dir
Permet d'isoler le programme dans un environnement spécifique pour plus de sécurité.
-u named
A utiliser dans tous les cas, avec
théoriquement cette valeur -u
named
. Identifie l'utilisateur
qui fait tourner le programme. C'est surtout une question de droits
d'accès sur le système et sur les fichiers. A savoir
que l'utilisateur named
,
du groupe également du même nom; ne doit pas faire
grand chose sur le système dans sa globalité, à
l'exception des fichiers de zones accessibles, des logs, le pid...
-m {usage|trace|record|size|mctx}
non documenté, car peut compréhensible à l'exception des developpeurs ...
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.
Table des matières
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...
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 (!))
EXTERNE : comporte les adresses hors de mon réseau, donc d'internet me concernant.
INTERNE : à l'inverse, comporte ma plage d'adresses internes.
ESCLAVE : réservé au serveur secondaire(s).
ADMIN : réservé aux adresses IP qui peuvent interroger BIND sans limitation pour l'administrattion/supervision...
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; }; }
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 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 :
match-recursive-only yes | no ;
Qui peut utiliser la récursion.
additional-from-auth yes | no;
Si cette option est non activée (no), Bind ne cherchera pas les valeurs demandées pour un CNAME/DNAME (double nommage dans une zone). Bind ne cherchera pas non plus dans les zones additionelles ni dans le cache. Cette option est valide si la récursion est non activée. A activer pour une vue depuis votre réseau local (autorisé).
additional-from-cache yes | no;
Similaire à la précédente mais pour les caches
match-recursive-only yes | no ;
A utiliser avec les options match-clients
Table des matières
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.
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 :
Recherche des serveurs DNS d'une zone :
serveur ~ # nslookup
-> set type=ns
-> archi.amt
Server: 127.0.0.1
Address: 127.0.0.1#53
archi.amt nameserver = second.archi.amt.
archi.amt nameserver = serveur.archi.amt.
Mes 2 serveurs sont bien présents.
AXFR (récupération) d'une zone (si autorisé !)
set type=axfr > archi.amt Server: 127.0.0.1 Address: 127.0.0.1#53 ------------ QUESTIONS: archi.amt, type = AXFR, class = IN ANSWERS: -> archi.amt origin = serveur.archi.amt mail addr = laurent.serveur.archi.amt serial = 2007110208 refresh = 43200 retry = 7200 expire = 604800 minimum = 3600 -> archi.amt nameserver = serveur.archi.amt. -> archi.amt nameserver = second.archi.amt. -> archi.amt text = "Serveur DNS de Archi" -> archi.amt mail exchanger = 10 serveur.archi.amt. -> dm.archi.amt internet address = 192.168.1.100 -> fh.archi.amt internet address = 192.168.1.20 -> pop.archi.amt canonical name = serveur.archi.amt. -> second.archi.amt internet address = 192.168.1.15 -> serveur.archi.amt internet address = 192.168.1.11 -> smtp.archi.amt canonical name = serveur.archi.amt. -> test.archi.amt internet address = 192.168.1.22 -> archi.amt origin = serveur.archi.amt mail addr = laurent.serveur.archi.amt serial = 2007110208 refresh = 43200 retry = 7200 expire = 604800 minimum = 3600 AUTHORITY RECORDS: ADDITIONAL RECORDS: ------------ archi.amt origin = serveur.archi.amt mail addr = laurent.serveur.archi.amt serial = 2007110208 refresh = 43200 retry = 7200 expire = 604800 minimum = 3600 archi.amt nameserver = serveur.archi.amt. archi.amt nameserver = second.archi.amt. archi.amt text = "Serveur DNS de Archi" archi.amt mail exchanger = 10 serveur.archi.amt. Name: dm.archi.amt Address: 192.168.1.100 Name: fh.archi.amt Address: 192.168.1.20 pop.archi.amt canonical name = serveur.archi.amt. Name: second.archi.amt Address: 192.168.1.15 Name: serveur.archi.amt Address: 192.168.1.11 smtp.archi.amt canonical name = serveur.archi.amt. Name: test.archi.amt Address: 192.168.1.22 archi.amt origin = serveur.archi.amt mail addr = laurent.serveur.archi.amt serial = 2007110208 refresh = 43200 retry = 7200 expire = 604800 minimum = 3600 >
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 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.
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 ».
Recherche d'une adresse IP pour « serveur.archi.amt » depuis mon DNS en local :
La réponse attendue est inscrite dans
la section ;; ANSWER SECTION
et également par la valeur ANSWER:
1
dig @127.0.0.1 serveur.archi.amt
; DiG 9.4.1-P1 >> @127.0.0.1 serveur.archi.amt
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER - opcode: QUERY, status: NOERROR, id: 53772
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; QUESTION SECTION:
;serveur.archi.amt. IN A
;; ANSWER SECTION:
serveur.archi.amt. 43200 IN A 192.168.1.11
;; AUTHORITY SECTION:
archi.amt. 86400 IN NS second.archi.amt.
archi.amt. 86400 IN NS serveur.archi.amt.
;; ADDITIONAL SECTION:
second.archi.amt. 86400 IN A 192.168.1.15
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Nov 4 09:24:00 2007
;; MSG SIZE rcvd: 102
La commande dig serveur.archi.amt est similaire.
Recherche d'un nom d'après une adresse IP :
dig -x 192.168.1.11
; DiG 9.4.1-P1 > -x 192.168.1.11
;; global options: printcmd
;; Got answer:
;; ->HEADER - opcode: QUERY, status: NOERROR, id: 63236
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;11.1.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
11.1.168.192.in-addr.arpa. 86400 IN PTR serveur.archi.amt.
;; AUTHORITY SECTION:
1.168.192.in-addr.arpa. 43200 IN NS second.archi.amt.
1.168.192.in-addr.arpa. 43200 IN NS serveur.archi.amt.
;; ADDITIONAL SECTION:
serveur.archi.amt. 43200 IN A 192.168.1.11
second.archi.amt. 86400 IN A 192.168.1.15
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Nov 4 09:28:26 2007
;; MSG SIZE rcvd: 141
Recherche d'un type particulier (NS|MX|SOA...) :
dig google.fr soa
; DiG 9.4.1-P1 > google.fr soa
;; global options: printcmd
;; Got answer:
;; ->HEADER - opcode: QUERY, status: NOERROR, id: 23787
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0
;; QUESTION SECTION:
;google.fr. IN SOA
;; ANSWER SECTION:
google.fr. 86400 IN SOA ns1.google.com. dns-admin.google.com. 2007090400 21600 3600 1209600 300
;; AUTHORITY SECTION:
. 102692 IN NS i.root-servers.net.
. 102692 IN NS m.root-servers.net.
. 102692 IN NS a.root-servers.net.
. 102692 IN NS b.root-servers.net.
. 102692 IN NS g.root-servers.net.
. 102692 IN NS d.root-servers.net.
. 102692 IN NS e.root-servers.net.
. 102692 IN NS h.root-servers.net.
. 102692 IN NS j.root-servers.net.
. 102692 IN NS c.root-servers.net.
. 102692 IN NS l.root-servers.net.
. 102692 IN NS k.root-servers.net.
. 102692 IN NS f.root-servers.net.
;; Query time: 121 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Nov 4 09:29:47 2007
;; MSG SIZE rcvd: 298
Recherche sous forme condensé :
dig @127.0.0.1 serveur.archi.amt +nocomment +nostats +nocmd +noquestion
serveur.archi.amt. 43200 IN A 192.168.1.11
archi.amt. 86400 IN NS serveur.archi.amt.
archi.amt. 86400 IN NS second.archi.amt.
second.archi.amt.
C'est le stricte minimum, mais répond à
notre question, et pour encore moins de données, il suffit de
placer uniquement -short
.
Recherche ITERATIVE :
Vous devez voir apparaître toutes les demandes une par une, et au final parvenir à votre résultat. Ce mode ne profite pas du cache DNS (!), rien de tel pour vérifier une mise à jour...
dig www.europa.eu +trace
; DiG 9.4.1-P1 - www.europa.eu +trace
;; global options: printcmd
. 96706 IN NS I.ROOT-SERVERS.NET.
. 96706 IN NS K.ROOT-SERVERS.NET.
. 96706 IN NS M.ROOT-SERVERS.NET.
. 96706 IN NS D.ROOT-SERVERS.NET.
. 96706 IN NS J.ROOT-SERVERS.NET.
. 96706 IN NS H.ROOT-SERVERS.NET.
. 96706 IN NS A.ROOT-SERVERS.NET.
. 96706 IN NS B.ROOT-SERVERS.NET.
. 96706 IN NS E.ROOT-SERVERS.NET.
. 96706 IN NS L.ROOT-SERVERS.NET.
. 96706 IN NS C.ROOT-SERVERS.NET.
. 96706 IN NS G.ROOT-SERVERS.NET.
. 96706 IN NS F.ROOT-SERVERS.NET.
;; Received 308 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
eu. 172800 IN NS a.eu.dns.be.
eu. 172800 IN NS b.eu.dns.be.
eu. 172800 IN NS l.eu.dns.be.
eu. 172800 IN NS l.nic.eu.
eu. 172800 IN NS m.nic.eu.
eu. 172800 IN NS p.nic.eu.
;; Received 236 bytes from 128.63.2.53#53(H.ROOT-SERVERS.NET) in 125 ms
europa.eu. 86400 IN NS ns1bru.europa.eu.
europa.eu. 86400 IN NS ns1lux.europa.eu.
europa.eu. 86400 IN NS ns2bru.europa.eu.
europa.eu. 86400 IN NS ns2lux.europa.eu.
europa.eu. 86400 IN NS ns2.nl.ignite.net.
europa.eu. 86400 IN NS ns2eu.bt.net.
europa.eu. 86400 IN NS auth00.ns.be.uu.net.
europa.eu. 86400 IN NS auth50.ns.be.uu.net.
;; Received 284 bytes from 193.194.136.29#53(a.eu.dns.be) in 55 ms
www.europa.eu. 1800 IN A 147.67.4.45
www.europa.eu. 1800 IN A 147.67.4.25
;; Received 63 bytes from 194.7.1.19#53(auth00.ns.be.uu.net) in 60 ms
C'est un bon exemple, il permet de découvrir comment une requête est résolue...et par qui. Mon DNS ne connaissant pas le domaine EU, il à demandé directement à l'une des racines, celui-ci à envoyé une liste de serveurs (type NS) pouvant répondre... et ainsi de suite en descendant d'un niveau à chaque fois, jusqu'au serveur hébergeant la zone (réponse de type A).
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
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
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.
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 (!).
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.
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.
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 :
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;
-b source-address
Adresse IP source, ou adresse IP ou est exécuté à distance rndc.
-c config-file
Si votre fichier /etc/rndc.conf n'est pas présent à cette place, c'est ici qu'il faut le déclarer explicitement.
-k key-file
Même remarque que la précédente, mais pour le fichier de clé (/etc/rndc.key)
-s server
Désigne le serveur sur lequel la commande rndc sera exécutée.
-p port
Permet de préciser un port autre que le 953 (valeur par défaut).
-V
Passe en mode verbeux.
-y keyid
Désigne le nom d'une clé à utiliser et qui doit être connu là ou sera exécutée la commande rndc.
reload | reload zone
Cette commande permet de recharger les zones ou une zone spécifique si spécifiée.
refresh zone [class [view]]
Comme la commande reload
,
mais concerne une zone(s) esclave ou stub. Il est possible de
spécifier une zone.
retransfer zone [class [view]]
Permet de transférer une zone de force, sans aucun test (nr de série).
freeze | freeze zone [class [view]]
Suspend les mises à jour pour les zones ou une zone (DHCP).
thaw | thaw zone [class [view]]
A utiliser avec le protocole DHCP, active la mise à jour dynamique et recharge la zone.
notify zone [class [view]]
Transmet au secondaire(s) une notification(s).
reconfig
Recharge la configuration et charge la nouvelle zone(s).
stats
Ecrit dans le fichier spécifié
statistics-file
"/var/run/named/named.stats";
des statistiques sur les requêtes. Pour avoir les statistiques
en plus par zone, il faut activer toujours dans le même
fichier (named.conf) l'option zone-statistics
yes;
. En exemple : avec mes 5
zones au total, le fichier fait 160 lignes, mais est fortement
intéressant à éplucher de temps en temps.
querylog
(non testé ni utilisé) Apparemment joue sur le système des historiques par inversion (toggle)...?
dumpdb [-all|-cache|-zones] [view ...]
Commande très intéressante, car
elle permet une représentation mémoire de tout ce Bind
à gérer. Cette commande écrit dans un fichier
spécifique et définie dans named.conf
par la valeur dump-file
"/var/run/named/named-dump.db";
Le résultat dépend des zones, du trafic, des requêtes,
mais c'est un moyen de vérification performant. C'est le seul
moyen de visualiser ce que contiennent vos caches. A mon avis aussi,
il doit pouvoir représenter la place approximative occupée
en mémoire pour les caches.
stop | stop -p
C'est une commande non brutale pour arrêter le serveur.
halt | halt -p
C'est la commande brutale pour arrêter le serveur.
trace | trace level
Comme expliqué dans le chapitre des
historiques, permet de monter de niveaux, ou de descendre dans
l'échelle de debuggage. A condition que le paramètre
dynamic
soit activé (!). Il suffit de faire rndc
trace 2 pour faire passer les
historiques en debuggage de niveau 2 (max 5 niveaux)...
notrace
Supprimer le debuggage au niveau des historiques, commande liée à « trace »
flush [view]
Elimine les données dans les caches ou pour une « view » spécifique.
flushname name [view]
Elimine du cache les données d'un domaine spécifié.
status
Affiche à l'écran l'état et d'autres paramètres intéressants, comme les connexions, les récursion en cours.
recursing
(Non testé). Apparemment stocke dans un
fichier named.recursing
,
les requêtes récursives ...Nécessite apparemment
une option pour y parvenir.
validation newstate [view]
Active ou supprimer le protocole d'authentification DNSsec (Voir la section intitulée « DNSsec. »).
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
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)
success
Correspond au nombre de requêtes positives ou résolus.
referral
Correspond au nombre de requêtes dont la réponse est une référence.
nxrrset
Correspond au nombre de requêtes dont le type (A, MX...) qui ne sont pas présentes dans la zone.
nxdomain
Correspond au nombre de requêtes négatives liés à un domaine.
recursion
Correspond au nombre de requêtes récursives.
failure
Correspond au nombre de requêtes tombées en échec.
duplicate
Nouveau paramètre (?), peut-être lié au directives DOS (client-per-query).
dropped
Correspond au nombre de requêtes sautées suite à des limitations, voir les paramètres pour plus d'informations : Named et DOS
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...
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
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
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 :
Comment savoir si une zone est à jour (ou "up to date"), inutile de commenter, c'est propre et net.
serveur named # host -C archi.amt
Nameserver serveur.archi.amt:
archi.amt has SOA record serveur.archi.amt. laurent.serveur.archi.amt. 2007121202 86400 3600 604800 86400
Nameserver second.archi.amt:
archi.amt has SOA record serveur.archi.amt. laurent.serveur.archi.amt. 2007121202 86400 3600 604800 86400
Comment connaitre si un alias est présent, et vers quel serveur il est renvoyé :
serveur named # host smtp.archi.amt
smtp.archi.amt is an alias for serveur.archi.amt.
serveur.archi.amt has address 192.168.1.11
Table des matières
dnssec-keygen
.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.
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 veut dire « Transaction SIGnature », et donc sa mission principale consiste à renforcer les transactions (transferts de zone et mises à jour dynamique).
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.
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.
-a HMAC-MD5
Pour
TSIG vous n'avez pas le choix, c'est la bonne valeur et l'unique.
-b 256
Correspond
aux nombre de bytes pour la fabrication de la clé, paramètre
lié au mode (HMAC-MD5).
-n HOST
Pour
TSIG, c'est la bonne et l'unique valeur possible.
serveur-second.
Est
conforme à la RFC approprié car les noms des 2
serveurs concernés sont écrits dans la clé. Il
est possible d'inclure ensuite la zone, mais la clé s'allonge
également de cette même longueur. C'est donc la clé
TSIG dans le sens serveur
(primaire)
vers second
(secondaire)
. Pour plusieurs
secondaires, il suffirait d'écrire slaves
...
Aucun test de cohérence est basé sur les noms.
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=
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'
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...
Attention aux droits sur les fichiers de clés, ils doivent être accessibles uniquement à l'utilisateur « named ».
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.
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à...
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.
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...
KSK : cette clé concerne la zone complète. Donc elle intervient à ce niveau lors des changements, des échanges vers le ou les secondaires...Cette clé est liée à la zone parente.
ZSK : cette clé intervient sur les enregistrements de ressources (RRset), donc sur les données d'une zone. A chaque modification dans une zone une nouvelle clé doit être créer. Cette clé n'est pas liée à la zone parente.
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.
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.
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
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.
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.
A la lecture du lien ci-dessous, Microsoft viendrait à inclure DNSsec dans son architecture...à suivre.
http://www.dnssec-deployment.org/news/200611-Microsoft.html
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.
Table des matières
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
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.
Avec ce lien, vous pouvez trouver beaucoup de programmes lié aux DNS.http://www.bind9.net/dns-tools
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 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 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
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/
Le site ISIC.org ou pour BIND : http://www.isc.org/index.pl?/sw/bind/index.php
Les sources de la version 9.4.2 sont disponibles ici : http://www.isc.org/index.pl?/sw/bind/view/?release=9.4.2#DOWNLOADS
Egalement la liste de toutes les versions disponibles : ftp://ftp.isc.org/isc/bind9/
Les options de configuration pour Bind 9.x : http://www.isc.org/sw/bind/arm93/Bv9ARM.ch06.html#options.
Il existe également ce site très similaire : http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.html
La documentation en ligne de « Bind and Bind fourth Ed » http://www.unix.org.ua/orelly/networking_2ndEd/dns/index.htm
Beaucoup de RFC liées au service DNS (ils sont tous présents dans les sources de Bind): http://www.iro.umontreal.ca/~kropf/ift-6052/notes/DNS/dns-rfc.html
Toutes les versions de Bind en FTP : ftp://ftp.isc.org/isc/bind9/
La référence et le manuel pour Bind : http://www.isc.org/sw/bind/arm93/Bv9ARM.ch06.html#options
Et l'explication de l'EDNS selon Microsoft, qui apporte une explication intéressante, je me suis arrêter là ... : http://www.microsoft.com/technet/prodtechnol/windowsserver2003/fr/library/ServerHelp/5316d9cb-6118-4d5f-834a-88f61a72ce3a.mspx?mfr=true
Un peu de sécurité pour le DNS : http://www.sans.org/top20/2006/?portal=85bfd4dba47db673e9f5f86d96acf155#c6
Un HowTo pour Bind et DNSsec :http://www.nlnetlabs.nl/dnssec_howto/
Un mini HowTo pour DNSsec : http://mboucey.free.fr/article.php3?id_article=1
Un libre sur Bind (en anglais) « Pro Dns And Bind » : http://www.amazon.fr/Pro-Dns-Bind-Ron-Aitchison/dp/1590594940
Un autre llivre sur Bind (O'Reilly) : http://www.oreilly.com/catalog/dns5/
Pour télécharger la dernière version du « named.ca » : ftp://rs.internic.net/domain/named.root
named.conf
C'est assez énorme ... il est difficile de parler de tout ...
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); ... };
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/////////////////
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.
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.
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 /////////
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.