Posted by Le DNS, Domain Name System (Système de Noms de Domaines) constitue l’épine dorsale d’un réseau comme internet. Le DNS permet la résolution des noms alphanumériques que les humains manipulent, www.google.fr par exemple, en adresses IP manipulables par les ordinateurs. Le Reverse DNS constitue le procédé inverse. Nous verrons dans un premier temps comment
le système DNS fonctionne. Ensuite nous aborderons ce mécanisme par l’installation et la configuration de BIND, le serveur DNS le plus répandu sous UNIX.
I Introduction au DNS
1.1 Le principe du DNS
à l’origine d’Arpanet, la résolution de nom se faisait via un fichier /etc/hosts, toujours présent dans les systèmes UNIX. Ce fichier contient une association adresse IP – nom d’hôte et était régulièrement téléchargé par les administrateurs
systèmes. à mesure que le réseau prenait de l’ampleur, il était devenu impossible de maintenir un fichier qui devenait démesurément grand et dont les conflits de noms se multipliaient.
C’est pour résoudre ces problèmes que le système du DNS a été inventé.
Le système DNS repose sur deux concepts fondamentaux. Premièrement, la
correspondance IP/nom d’hôte n’est pas mémorisable par les êtres humains.
Deuxièmement, c’est une base de donnée distribuée. Chaque organisation est
responsable de sa propre branche de nommage indépendament des autres. Troi-sièmement, l’espace de nommage du DNS est hiérarchisé, résolvant ainsi les
conflits de noms entre les organisations.
Le DNS fonctionne sur le principe du client serveur. Le service écoute les requêtes sur
le port UDP 53. Les espaces de noms sont séparés par des ‘.’. A la racine de cette
arborescence se trouvent les serveurs de nom racines. Au nombre de 13, ils sont
au sommet de la hiérarchie. Ensuite, les .org, .com, .fr, .eu constituent ce que l’on
appele des TLD, les Top-Level Domain, autrement dit, les domaines de niveau
supérieur. Un nom de domaine est rattaché à un TLD, par exemple domaine.fr.
Le responsable du DNS peut ensuite librement partitionner masociete.fr en sous
domaines tels que production.domaine.fr et compta.domaine.fr.
1.2 Les champs d’un serveur de nom :
Un hôte effectuant une requête DNS, va généralement porter sur un point précis. Par exemple, un serveur SMTP ayant un message à délivrer un mail à utilisateur@domaine.com, va chercher à savoir qui est responsable du courrier pour le domaine domaine.com. En faisant cela, il va chercher précisément le champs MX du domaine concerné. Voici la liste des champs que l’on retrouve le plus souvent.
A : sert à associer de manière fixe un nom à une IP.
NS : Désigne un serveur DNS pour la zone.
MX : Désigne un serveur de mails pour la zone. Ce champ comporte une priorité indiquée par un numéro. Plus elle est faible, plus le serveur est prioritaire.
PTR : Dans la résolution inverse, sert à faire pointer une IP vers un nom.
CNAME : Permet de faire des alias vers des noms. On ne peut faire des alias vers d’autres alias.
SOA : Start Of Authority, sert à décrire la zone.
Un peu de pratique pour mettre en évidence ce qu’on vient de dire. Lancez la commande
nslookup
depuis un terminal. Je vais parler ici de l’utilisation de nslookup même si dig et host sont plus appropriées, car nslookup est disponible également sous Microsoft Windows. Voici quelques requêtes DNS effectuées avec nslooukp, qui je pense se passent de commentaires mais qui devraient mettre en évidence le fonctionnement des requêtes. J’ai toutefois coupé quelques passages qui n’étaient pas nécessaires.
$ nslookup
> www.google.fr
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
www.google.fr canonical name = www.google.com.
www.google.com canonical name = www.l.google.com.
Name: www.l.google.com
Address: 66.249.93.147
Name: www.l.google.com
Address: 66.249.93.99
Name: www.l.google.com
Address: 66.249.93.104
> set q=soa
> google.fr
Server: 80.247.228.1
Address: 80.247.228.1#53
Non-authoritative answer:
google.fr
origin = ns1.google.com
mail addr = dns-admin.google.com
serial = 2006082400
refresh = 28800
retry = 3600
expire = 1038800
minimum = 60
> set q=ns
> amazon.fr
Server: 80.247.228.1
Address: 80.247.228.1#53
Non-authoritative answer:
amazon.fr nameserver = pdns1.ultradns.net.
amazon.fr nameserver = pdns2.ultradns.net.
amazon.fr nameserver = pdns3.ultradns.org.
amazon.fr nameserver = pdns4.ultradns.org.
amazon.fr nameserver = pdns5.ultradns.info.
amazon.fr nameserver = pdns6.ultradns.co.uk.
amazon.fr nameserver = udns1.ultradns.net.
amazon.fr nameserver = udns2.ultradns.net.
> set q=mx
> morot.info
Server: 80.247.228.1
Address: 80.247.228.1#53
Non-authoritative answer:
morot.info mail exchanger = 1 smtp.morot.info.
morot.info mail exchanger = 5 mail.lovetux.net.
>set q=ptr
> 80.247.231.133
Non-authoritative answer:
133.231.247.80.in-addr.arpa name = galadriel.morot.info.
2 Configuration de Bind 9
2.1 La zone principale
Voici un exemple pour le domaine exemple.com. Placez ce qui suis dans le sous-répertoire indiqué dans le fichier named.conf par la directive
directory
. Il s’agit de
/var/cache/bind/
sous Debian.
# Zone exemple.com
$TTL 3H
@ IN SOA ns.exemple.com. root.exemple.com. (
2006031001 ; Serial
8H ; Refresh
2H ; Retry
1W ; Expiry
1D ) ; Minimum
@ IN NS ns.exemple.com.
@ IN NS ns2.exemple.com.
@ IN MX 10 mx1.exemple.com.
@ IN MX 20 mx2.exemple.com.
ns IN A 192.168.1.10
ns2 IN A 192.168.1.11
mx1 IN A 192.168.1.15
mx2 IN CNAME www
www IN A 192.168.1.30
La première ligne commence par un @. L’arobase est une notation raccourcie pour le nom de domaine. C’est un enregistrement de type SOA, il décrit la zone définie. C’est une zone internet (IN), le serveur de référence est ns.exemple.com et l’administrateur de ce serveur a pour e-mail root@exemple.com. Ensuite, nous avons la valeur serial, le numéro de série de la zone. Cette valeur est à incrémenter à chaque modification de la zone. Elle permet de dire au serveur DNS esclave que la zone a changé et donc qu’il doit récupérer les nouvelles valeurs.
Les 4 valeurs suivantes désignent des durées. 8H (8 hour) désigne 8 heures, 1W une semaine (1 week) et 1D un jour (1 day) mais vous pouvez aussi spécifier des secondes. Ce sont dans l’ordre les valeurs de :
- temps de rafraichissement des valeurs à partir du serveur maître.
- durée pendant laquelle le serveur esclave tentera de joindre le serveur maître si la requête n’aboutit pas.
- temps au bout duquel le serveur esclave vide son cache si les reqêtes auprès du serveur maître échouent.
- temps pour lequel les serveurs esclaves doivent conserver leur cache.
Une remarque importante s’impose sur un point de la notation. Notez que lorque vous définissez une machine complètement, c’est à dire avec le nom du domaine, vous devez terminer ce même nom par un » . » (point). L’absence de point sert à demander au serveur de nom de compléter le nom de machine avec le nom de domaine. Explications : www donnera www.example.com mais www.exemple.com engendrera un ww.exemple.com.exemple.com très probablement non désiré.
2.2 La zone inverse
La zone inverse répond aux requêtes DNS basées sur l’IP. avec une plage comme utilisées ici de type 192.168.1.0/24, notre zone inverse est la zone 1.168.192.in-addr.arpa.
# Zone inverse
$TTL 3H
@ IN SOA ns.exemple.com. hostmaster.exemple.com. (
0001
8H
2H
1W
1D )
@ IN NS ns.exemple.com.
@ IN NS ns.exemple.com.
10 IN PTR ns.exemple.com.
11 IN PTR ns2.exemple.com.
15 IN PTR mx1.exemple.com.
30 IN PTR www.exemple.com.
Peu de choses à dire sur celle-ci après ce que l’on vient de dire à propos du fichier précédent. On utilise cette fois des champs PTR pour associer les adresses IP aux noms de machines. On ne précise dans la partie de gauche que l’élément significatif de l’adresse IP à résoudre.
2.2 Ajouter la zone au fichier de configuration de Bind
Maintenant que les fichiers de zones ont eté écrits, il faut dire à notre serveur DNS qu’il fait autorité pour ces zones. Tout ce place dans le fichier de configuration de bind9 nommé named.conf. Dans ce fichier vous trouverez une première zone « . ». Dans ce fichier, se trouvent les adresses IP des 13 (à l’heure actuelle) serveurs de nom racine de l’Internet.
zone "exemple.com" {
# C'est le serveur maître pour cette zone
type master;
# La zone exemple.com sera décrit dans le fichier /var/cache/bind/exemple.com
file "exemple.com";
# On authorise l'IP 192.168.1.11 à récuperer les informations sur la zone.
# Cette IP est celle du serveur esclave
allow-transfer { 192.168.1.11; } ;
# Lorsque la zone est mise à jour, on en averti le serveur
# esclave qu'il se mette à jour sans attendre le fin du délai refresh.
notify yes;
};
# Zone pour la résolution inverse :
zone "1.168.192.in-addr.arpa" {
type master;
file "192.168.1";
allow-transfer { 192.168.1.11; } ;
notify yes;
};
Une fois bind relancé, vous devriez voir dans les logs qu’il charge bien les fichiers de zone.
2.3 Un serveur DNS secondaire pour plus de fiabilité
L’essentiel sur le serveur DNS de secours consiste à déclarer les zones dans le fichier named.conf que le serveur peut gérer et où aller chercher l’information originelle. Si Bind a les permissions en écriture dans le répertoire indiqué par la directive
directory
alors au redémarrage de bind s’opèrera un transfer de zone (AXFR). En cas de simple changement partiel de la zone sur le maitre, les serveurs DNS savent transférer uniquement la différence (l’incrément) entre les deux zones (IXFR).
zone "exemple.com" {
# Ce serveur est le serveur esclave pour cette zone.
type slave;
# IP du serveur maître de la zone.
masters { 192.168.0.1 ; } ;
file "exemple.com";
};
zone "0.168.192.in-addr.arpa" {
type slave;
masters { 192.168.0.1 ; } ;
file "192.168.0";
};
3 Faire tourner BIND dans une prison
Le chroot d’un démon permet de restreindre la vue du système de fichier que celui-ci aura en redéfinissant la racine du système de fichier pour ce démon. Par conséquent, si un intrus parvient à compromettre le serveur DNS, il sera
emprisonné à l’intérieur de la racine qui lui aura été assignée. Nous allons voir comment mettre au point un chroot pour bind. La racine utilisée pour celui-ci sera /usr/local/bind. Dans un premier temps, il est nécessaire de créer ce répertoire ainsi que les différents fichiers de périphériques du système de fichier que le démon utilise pour son exécution.
# mkdir /usr/local/bind && cd /usr/local/bind # mkdir -p dev etc lib usr/sbin usr/lib var/cache # mkdir -p /usr/local/bind/var/run/bind/run # cd /usr/local/bind/dev # mknod null c 1 3 # mknod random c 1 8 # mknod urandom c 1 9 # mknod tty c 5 0 # mknod zero c 1 5
GrAce à ldd, on sait qulles bibliothèques sont nécessaires à l’exécution de
bind :
ldd /usr/sbin/named
liblwres.so.1 => /usr/lib/liblwres.so.1 (0x4001b000)
libdns.so.16 => /usr/lib/libdns.so.16 (0x4002b000)
libcrypto.so.0.9.7 => /usr/lib/i686/cmov/libcrypto.so.0.9.7 (0x4012b000)
libisccfg.so.0 => /usr/lib/libisccfg.so.0 (0x4022a000)
libisccc.so.0 => /usr/lib/libisccc.so.0 (0x4023a000)
libisc.so.7 => /usr/lib/libisc.so.7 (0x40242000)
libnsl.so.1 => /lib/libnsl.so.1 (0x4027a000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4028f000)
libc.so.6 => /lib/libc.so.6 (0x402e1000)
libdl.so.2 => /lib/libdl.so.2 (0x40414000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Ainsi on peut copier le binaire de bind et les bibliothèques qui lui sont
nécessaires :
# cp /usr/sbin/named /usr/local/bind/usr/sbin # cp /usr/sbin/rndc /usr/local/bind/usr/sbin/ # cp /usr/lib/liblwres.so.1* /usr/lib/libdns.so.16* /usr/local/bind/lib # cp -r /usr/lib/i686/ /usr/lib/libisc* /usr/local/bind/lib # cp /lib/libpthread* /lib/libc.so.6 /lib/libc-2.3.2.so /usr/local/bind/lib # cp /lib/libdl* /lib/ld-linux.so.2 /usr/local/bind/lib # cp /lib/libnss* /lib/libnsl* /usr/local/bind/lib/
Enfin on peut ajouter les fichiers de configuration qui lui sont nécessaires et
un utilisateur non privilégié si ce n’est déja le cas :
# cp /etc/nsswitch.conf /usr/local/bind/etc # cp /etc/ld.so.cache /usr/local/bind/etc # cp -r /var/cache/bind/ /usr/local/bind/var/cache/ # cp -r /etc/bind/ /usr/local/bind/etc/ # echo "bind::69" >> /etc/group # echo "bind:x:69:69:bind:/:/bin/false" >> /etc/passwd # chown -R bind:bind /usr/local/bind/var/cache/bind # chown -R bind:bind /usr/local/bind/etc/bind # chown -R bind:bind /usr/local/bind/var/run/bind/
Le grand moment est arrivé, on peut lancer BIND dans son chroot, assurez-
vous avant que le démon non chrooté soit bien arrêté :
/usr/local/bind/usr/sbin/named -u bind -t /usr/local/bind/ -c /etc/bind/named.conf
4 Le DNS Dynamique :
4.1 Introduction :
Jusqu’à présent nous vivions dans un monde parfait où les adresses IP étaient statiques. Ce qui est incompatible avec du dhcp. Alors dans ce cas comment bénéficier du nommage dns pour des machines dont l’adresse IP change en fonction des disponibilité du serveur dhcp? Et bien la réponse est le DNS Dynamique. Le dns sera informé des mises à jour qu’il doit effectuer en temps réel.
La méthode qui sera expliquée ici se base sur DHCP v3 et BIND 9, les serveurs standards sous UNIX de l’isc. DHCP v2 ne supporte pas directement les mises à jour du serveur dns. Des scripts qui lisent les attributions du dhcp pour mettre à jour le dns existent cependant. Mais il est préalable de se tourner vers l’avenir dans le cadre d’un serveur fraichement mis en route.
4.2 Analyse des possibilités :
Tout d’abord, il faut voir comment le dns sera informé des couples IP/Nom. Nous avons deux possibilité :
Les machines mettent à jour toutes seules le dhcp via leur client dhcp. C’est à dire que tout le réseau sera autorisé à aller bricoler vos fichiers de zone. Pas très sécurisé tout ça…
Ou bien, une seule machine, le serveur dhcp sera authorisé à mettre à jour le serveur dns. C’est bien entendu la meilleure solution.
Ensuite, nous devons observer comment le serveur dns déterminera que la machine qui lui envoie les mises à jour est bien la bonne. Ici aussi, deux possibilités :
On authorise un seule adresse IP à mettre à jour le dns. Pas très sécurisé non plus. Encore que, si votre dns et votre dhcp sont sur la même machine, l’utilisation de l’adresse IP 127.0.0.1 ne créé pas de brêche de sécrité potentielle.
Ou on génère une clé que les serveurs dns et dhcp partageront. Le dns vérifiera que lorsque le dhcp lui soumet une mise à jour, la clé qu’il lui présente correspondra à celle qu’il possède.
Commençons tout de suite par générer notre clé :
# dnssec-keygen -a HMAC-MD5 -b 128 -n USER DHCP_UPDATER
Cette clé s’appellera DHCP_UPDATER, elle est d’une longueur de 128 bits et au format hmac-md5. Le résultat de cette commande est contenu dans deux fichiers Kdhcp_updater*.
4.3Configuration du DHCP :
Fichier /etc/dhcp3/dhcpd.conf :
ddns-update-style interim;
ddns-updates on;
ignore client-updates;
server-identifier dhcp.sims.lan;
authoritative;
# Configuration IP du réseau :
subnet 192.168.5.0 netmask 255.255.255.0 {
default-lease-time 86400;
max-lease-time 86400;
range 192.168.5.10 192.168.5.20;
option domain-name "example.com";
option domain-name-servers 192.168.5.1;
ddns-domainname "example.com";
}
# On informe le dhcp d'une clé :
key DHCP_UPDATER {
algorithm hmac-md5;
secret "ohBGsizK5TbrgT9LwonUMQ==";
};
# Et enfin on demande à notre dhcp de mettre à jour 2 zones
# En utilisant la clé DHCP_UPDATER :
zone example.com. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
zone 5.168.192.in-addr.arpa. {
primary 127.0.0.1;
key DHCP_UPDATER;
}
4.4 Configuration du DNS :
Inutile de passer en revue la configuration d’un DNS. Construisez un simple qui marche. Avec un nom de domaine quelconque et la zone inverse qui l’accompagne. Faîtes des tests avec nslookup pour assurer de son bon fonctionnement. Voyons maintenant les modifications à y apporter :
Fichier : /etc/bind/named.conf
# Déclarons notre clé :
key DHCP_UPDATER {
algorithm hmac-md5;
secret "ohBGsizK5TbrgT9LwonUMQ==";
};
# Et pour chaque zone à mettre à jour, n'authorisons l'accès
# qu'à la machine possédant la clé :
zone "example.com" {
type master;
notify no;
file "master/example.com";
allow-update { key DHCP_UPDATER; };
};
zone "5.168.192.in-addr.arpa" {
type master;
notify no;
file "master/192.168.5";
allow-update { key DHCP_UPDATER; };
};
Je vous remercie beaucoup pour ces informations d’une grande clarté. Bonne continuation. Amicalement
,~` I am really thankful to this topic because it really gives useful information « ;,