Système de noms de domaine/Mise en œuvre

Le modèle hiérarchique

Extensions

Système de noms de domaine

Version imprimable

[ Modifier le sommaire ]

Le modèle hiérarchique

Extensions

Types de serveurs

Serveurs primaires
Serveurs secondaires
Serveurs cache.

Serveurs primaires et secondaires

Les serveurs primaires possèdent les données de la zone en local. Les serveurs secondaires se connectent à un serveur primaire pour copier les données de la zone. Un primaire n'envoie pas les données aux secondaires.

Le RFC 2182 définit les bonnes pratiques de gestion des serveurs autoritaires. Il impose plus d'un serveur autoritaire par zone.

Recherches récursives et recherches non récursives.

Gestion du cache dans le DNS

Un cache est un niveau intermédiaire d'accès rapide, en ll lieu de stockage d'une information et celui de son utilisation. La notion de cache ne concerne pas uniquement le DNS mais toute l'informatique.

Dans le cadre du DNS le cache est non seulement positif mais aussi négatif (RFC 2308). Dans le cadre du DNS, une réponse négative peut représenter soit l'absence du domaine (NXDOMAIN), soit l'absence de données (No Data) le domaine est valide mais il n'y a pas d'enregistrements ou de type associé à ce nom.

Les durées de mise dépendent de durée appelée TTL pour Time To Live. Ces durées peuvent atteindre 41 jours sur les enregistrements sur les noms de serveurs de la racine.

BIND et ses alternatives

Présentation

Pour plus de détails voir : Le système d'exploitation GNU-Linux/Le serveur de noms BIND.

BIND est la référence de l'implémentation d'un serveur DNS, il est d'ailleurs le serveur DNS le plus utilisé sur Internet^{(Référence nécessaire)}.

Historique JEEVES implémentation par Paul Mockapetris d'un serveur DNS (1983)
Depuis 1995 BIND

Deux principales versions de BIND sont maintenues.

BIND 8
BIND 9

Pendant longtemps il existait une autre version : BIND version 4. Elle n'est plus maintenue et donc ne doit plus être utilisée.

BIND a connu de nombreuses alertes de sécurité, a tel point que certains acteurs utilisent d'autres logiciels.

Alternatives à BIND

NSD
PowerDNS
MaraDNS
djbDNS
myDNS

Les types d'enregistrements

Pour plus de détails voir : w:Liste des enregistrements DNS.

Le type SOA

SOA définit la zone. Il contient notamment un numéro de série. Ce numéro doit toujours être augmenté en cas d'évolution de la zone. Le format conseillé est AAAAMMJJNN.

AAAA année
MM mois de 01 à 12
JJ jour de 01 à 31
NN numéro de changement du jour de 00 à 99

Exemple de SOA avec les durées conseillées par le RIPE (http://www.ripe.net/ripe/docs/dns-soa.html).

example.com. 3600 SOA dns.example.com. hostmaster.example.com. (
                         1999022301   ; serial YYYYMMDDnn
                         86400        ; refresh (  24 hours)
                         7200         ; retry   (   2 hours)
                         3600000      ; expire  (1000 hours)
                         172800 )     ; minimum (   2 days)

Le type A

A associe le nom d'hôte à l'adresse IP.

Le type PTR

PTR associe l'adresse IP au nom (conversion inverse).

Il n'est généralement utilisé que pour vérifier les serveurs qui envoient des emails (dans la lutte antispam).

Le type NS

NS donne la liste les serveurs autoritaires pour la zone.

Le type CNAME

CNAME définit des alias de nom de serveur.

Le type DNAME

Ce type est très proche de CNAME. Il définit des alias de noms de domaine, tandis que CNAME définit des alias de nom de serveur. Il est défini dans le RFC 2672.

Il est relativement rare. Il a été utilisé lors de la refonte de certains domaines, lors du passage de ip6.int à ip6.arpa par exemple. Ces domaines sont utilisés lors de la conversion inverse des adresses IPv6 en noms de domaine. Voir le document http://www.isc.org/index.pl?/pubs/tn/index.pl?tn=isc-tn-2002-1.html

Le type MX

Il est utilisé pour la messagerie électronique. Les enregistrements MX définissent les hôtes "Mail eXchanger". Il permet de définir des serveurs principaux et de serveurs de secours. Dans l'exemple suivant le serveur de messagerie sera de préférence celui avec le poids le plus petit donc rex1.ouaf.com.

petit-teckel.fr IN MX 0 rex1.ouaf.com
petit-teckel.fr IN MX 10 rex2.ouaf.com
petit-teckel.fr IN MX 30 rex3.ouaf.com

Auparavant, il existait deux types d'enregistrement MD (Mail Destination) et MF (Mail Forwarder). MD représentaient les machines principales et MF les machines de secours. Le RFC 973 dans sa page 4 explique la raison du changement de gestion : une gestion plus efficace du cache.

Maintenant le type SRV généralise la notion de MX à tout type de service lié au domaine.

Le type HINFO

Cet enregistrement donne des informations sur le matériel et le système d'exploitation utilisé. Il est généralement masqué pour des raisons de sécurité.

Le type TXT

Il contient tout texte descriptif, notamment les règles SPF.

Il n'est généralement utilisé que pour vérifier les serveurs qui envoient des emails (dans la lutte antispam).

Le type SRV

Il s'agit d'une généralisation du type MX. Il est défini dans le RFC 2782, mais pour avoir des exemples supplémentaires on peut également regarder l'ancien RFC 2052. Il s'agit de définir les liens entre services et noms de machine.

Les enregistrements SRV peuvent permettre de retrouver la liste des serveurs HTTP ou bien encore des contrôleurs de domaines. Il est possible de donner une priorité différente à chaque enregistrement SRV. Ce type d'enregistrement est utilisé par le DNS dans le cadre d'Active Directory.

Le type WINS

WINS et WINS-R sont deux types d'enregistrement qui permettent la cohabitation entre WINS et un serveur DNS.

WINS : les enregistrements de ressources de type WINS indiquent au serveur DNS l'adresse IP d'un serveur WINS a contacter en cas d'échec lors de la résolution de nom d'hôte. Les enregistrements WINS ne peuvent être créés que dans une zone de recherche directe.

WINS-R : les enregistrements de ressources de type WINS-R ne peuvent être créés que dans une zone de recherche inversée.

Type LOC

Voir la RFC 1876 (expérimental). Ce type définit la position géographique (longitude, latitude et altitude) du serveur. Il est très peu utilisé. le seul cas d'utilisation est sur le site : http://www.ckdhr.com/dns-loc

Le message DNS

le DNS utilise UDP par défaut sauf si le message est supérieur à 512 octets. Dans ce cas, il utilise TCP. Ceci est un argument pour limiter le nombre de serveurs racine à treize.

Outils d'interrogation du DNS

nslookup
dig

La commande nslookup existe sous Windows, mais elle n'est pas pratique ni complète. Dig est conseillé pour travailler avec le DNS, mais elle n'existe pas par défaut sous Windows. Pour avoir cette commande sous ce système il faut récupérer la version pour Windows de BIND (http://www.isc.org/index.pl?/sw/bind/bind9.php).

Nslookup

nslookup

Dig

Cette commande est très riche. La page "man" est ici http://www.bind9.net/dig.1.

la commande "dig @192.168.1.11 txt chaos version.bind nom_serveur" permet de connaitre la version du serveur BIND. En général, cette version est masquée. Il s'agit d'un des rares cas où on utilise une classe différente de IN.

dig @192.168.1.11 txt chaos version.bind

; <<>> DiG 9.3.2 <<>> @192.168.1.11 txt chaos version.bind
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 582
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;version.bind. CH TXT

;; ANSWER SECTION:
version.bind. 0 CH TXT "9.3.2"

;; AUTHORITY SECTION:
version.bind. 0 CH NS version.bind.

;; Query time: 1265 msec
;; SERVER: 192.168.1.11#53(192.168.1.11)
;; WHEN: Thu Jun 29 20:54:52 2006
;; MSG SIZE rcvd: 62

Pour masquer cette version, il faut modifier le fichier named.conf

options {
../..
version "le numero de version est masque";
../..
};

L'option x de commande dig (ex dig -x adresse_ip) permet de faire la recherche inverse simplement, sans utiliser le in-addr.arpa.

dig -x 81.91.232.1
; <<>> DiG 9.3.2 <<>> @192.168.1.1 -x 81.91.232.1
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 404
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;1.232.91.81.in-addr.arpa. IN PTR

;; ANSWER SECTION:
1.232.91.81.in-addr.arpa. 86400 IN CNAME 1.0-127.232.91.81.in-addr.arpa.
1.0-127.232.91.81.in-addr.arpa. 86400 IN PTR ben02.gouv.bj.

L'option +trace de commande dig permet de faire la recherche en parcourant l'arborescence depuis la racine jusqu'à la réponse.

dig @192.168.1.1 +trace www.tiscali.co.uk

; <<>> DiG 9.3.2 <<>> @192.168.1.1 +trace www.tiscali.co.uk
; (1 server found)
;; global options: printcmd
. 142221 IN NS B.ROOT-SERVERS.NET.
. 142221 IN NS C.ROOT-SERVERS.NET.
. 142221 IN NS D.ROOT-SERVERS.NET.
. 142221 IN NS E.ROOT-SERVERS.NET.
. 142221 IN NS F.ROOT-SERVERS.NET.
. 142221 IN NS G.ROOT-SERVERS.NET.
. 142221 IN NS H.ROOT-SERVERS.NET.
. 142221 IN NS I.ROOT-SERVERS.NET.
. 142221 IN NS J.ROOT-SERVERS.NET.
. 142221 IN NS K.ROOT-SERVERS.NET.
. 142221 IN NS L.ROOT-SERVERS.NET.
. 142221 IN NS M.ROOT-SERVERS.NET.
. 142221 IN NS A.ROOT-SERVERS.NET.
;; Received 228 bytes from 192.168.1.1#53(192.168.1.1) in 2218 ms

uk. 172800 IN NS NS1.NIC.uk.
uk. 172800 IN NS NS2.NIC.uk.
uk. 172800 IN NS NS3.NIC.uk.
uk. 172800 IN NS NS4.NIC.uk.
uk. 172800 IN NS NS5.NIC.uk.
uk. 172800 IN NS NS6.NIC.uk.
uk. 172800 IN NS NS7.NIC.uk.
uk. 172800 IN NS NSA.NIC.uk.
uk. 172800 IN NS NSB.NIC.uk.
uk. 172800 IN NS NSC.NIC.uk.
uk. 172800 IN NS NSD.NIC.uk.
;; Received 497 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 171 ms

tiscali.co.uk. 172800 IN NS ns0.tiscali.co.uk.
tiscali.co.uk. 172800 IN NS ns0.as9105.com.
;; Received 97 bytes from 195.66.240.130#53(NS1.NIC.uk) in 78 ms

www.tiscali.co.uk. 300 IN A 212.74.99.30
tiscali.co.uk. 3600 IN NS ns0.as9105.com.
tiscali.co.uk. 3600 IN NS ns0.tiscali.co.uk.
;; Received 129 bytes from 212.74.114.132#53(ns0.tiscali.co.uk) in 62 ms