Principes de Synchronisation DNS

Synchronisation des serveurs DNS d’un domaine

Le système DNS permet de diviser l’espace des noms en zones. Ces zones stockent des informations relatives à un ou plusieurs domaines. Avant tout, une zone est une base de données de stockage contenant des enregistrements RR (Resource Records) concernant un nom de domaine DNS. Si un sous-domaine est créé, il peut être géré par la zone du domaine parent ou par une zone qui lui est propre.

La création du sous-domaine sample nécessite son enregistrement dans la zone oktey.com ou sa délégation à la zone sample.oktey.com. La zone sample.oktey.com doit être créée pour la délégation.

Principe de réplication DNS

A chaque zone, correspond un serveur DNS principal (unique) qui aura le droit de lecture-écriture sur les données originales de la zone et servira de point de mise à jour de la zone. Cette zone sera répliquée dans son intégralité par les serveurs dit secondaires.

Les serveurs DNS secondaires d’une zone assurent l’équilibrage de la charge et la tolérance de panne. Ils conservent une copie en lecture seule des données de zone qui sont transférées régulièrement à partir du serveur DNS principal. Il est tout à fait possible de configurer les clients DNS pour qu’ils interrogent les serveurs DNS secondaires au lieu de ou en plus du serveur DNS principal d’une zone, ce qui réduit la demande vis-à-vis du serveur principal et garantit une réponse aux requêtes DNS pour la zone même si le serveur principal n’est pas disponible. En général, les requêtes sont réparties sur l’ensemble des serveurs.

Dans la synchronisation DNS, le serveur DNS principal de la zone va jouer le rôle de source pour la zone (processus A). Cela signifie qu’il pourra autoriser la mise à jour : il sera qualifié de serveur maître.

La demande de synchronisation est toujours faite par un serveur DNS secondaire au serveur maître puisqu’il ne peut pas mettre à jour les données de la zone de lui-même en raison de ses droits de lecture seule. Ce serveur demandeur sera qualifié de serveur esclave.

Remarque : il est possible que le même serveur secondaire qui a joué le rôle d’esclave soit serveur maître dans un autre processus de réplication DNS (processus B).

Processus de réplication

Une requête SOA (Start Of Authority) sous protocole UDP (1) est envoyé du serveur esclave. Le serveur maître lui répond en lui adressant une copie de son enregistrement SOA. Le serveur esclave compare le numéro de version de son enregistrement SOA avec celui qu’il a reçu. S’il est différent, il fait alors une requête de transfert de zone sous protocole TCP (2) auprès du serveur maître pour la synchronisation DNS.

L’utilisation du protocole de sécurité TSIG (Transaction SIGnature) permet d’authentifier la transaction maître/esclave et d’assurer l’intégrité des données reçues.

Il existe deux types de transfert de zone : total (AXFR) où une copie complète de la zone est faite et incrémentiel (IXFR) où seulement les modifications sont répliquées.

Le processus de transfert incrémentiel sera privilégié car il génère moins de trafic sur le réseau et se révèle plus rapide.

Une zone doit être présente sur plusieurs serveurs DNS afin de garantir la disponibilité et la tolérance de pannes lors de la résolution de requêtes de noms. C’est la raison pour laquelle il est important de répliquer la zone sur d’autres serveurs et de synchroniser toutes les copies sur chaque serveur.

Un problème de désynchronisation DNS par exemple au niveau des champs MX pourrait conduire à l’envoi de mails vers des serveurs de mail différents. La synchronisation DNS entre le serveur principal et le serveur secondaire permet donc de garantir la cohérence de l’information c’est-à-dire l’unicité de la réponse lors d’une requête DNS.

Il est possible de mettre en œuvre un mécanisme de diffusion pour avertir un ensemble spécifique de serveurs secondaires pour une zone d’une mise à jour grâce à la fonction DNS notify. Les serveurs avertis peuvent alors lancer un transfert de zone ce qui permet de leur éviter d’attendre l’expiration du temps refresh.

Serveur DNS principal et SOA

Le champ SOA précédemment cité est un des enregistrements RR présents dans la zone et fournit des informations sur le serveur DNS principal qui a autorité sur la zone, l’adresse mail du contact technique (avec @ remplacé par un point) et des paramètres d’expiration.

Il existe d’autres enregistrements RR tels que A pour le nom d’hôte de la machine, CNAME pour l’alias, NS pour le serveur de noms et MX pour le serveur de mail. La liste de tous les enregistrements RR se trouve sur le site de l’IANA : http://www.iana.org/assignments/dns-parameters

Un exemple d’enregistrement SOA avec la commande nslookup sera :
> nslookup
> set querytype=SOA
> oktey.com
primary name server = ns1.oktey.com
responsible mail addr = info.oktey.com
serial = 2009032780
refresh = 7200 (2 hours)
retry = 1800 (30 mins)
expire = 604800 (7 days)
default TTL = 86400 (1 day)

Explication des différents paramètres d’un enregistrement SOA :

• serial indique le numéro de la version de la base de donnée de la zone. Ce numéro doit être incrémenté si il y a modifications de la base de données. Dans le cas général, ce numéro sera composé de la date dans le format AAAAMMJJ suivi d’un nombre à deux chiffres.
• refresh indique le temps d’attente avant une nouvelle demande de mise à jour de la part du serveur secondaire de la zone. Avant l’expiration de ce temps, le serveur secondaire demande une copie de l’enregistrement SOA au serveur principal. Une comparaison du numéro de version avec son propre enregistrement SOA est faite pour voir s’il y a nécessité de transfert de zone.
• retry indique le temps d’attente avant un nouvelle tentative de transfert de zone qui a échoué.
• expire indique le temps de validité de la base de donnée pendant lequel aucune mise à jour a pu être lancée (comprenant donc le refresh et x retry), c’est-à-dire pendant lequel au moins un transfert de zone a été réalisé. Si ce délai expire, le serveur secondaire ne répond alors plus aux requêtes DNS car il considèrera que sa base de données n’est plus fiable.
• default TTL indique le temps de validité appliqué par défaut à tous les RR qui correspond au temps de conservation dans le cache des données DNS. Il est cependant possible de définir un TTL particulier pour un RR spécifique. Dans ce cas, on parlera simplement de TTL. Parmi les TTL définis, le plus petit caractérise le ‘Minimum TTL’ qui devient la limite inférieure du champ TTL.

L’enregistrement SOA de la zone racine est donné par :
> nslookup
> set querytype=SOA
> .
primary name server = a.root-servers.net
responsible mail addr = nstld.verisign-grs.com
serial  = 2011010900
refresh = 1800 (30 mins)
retry   = 900 (15 mins)
expire  = 604800 (7 days)
default TTL = 86400 (1 day)

Lors de l’interrogation de la zone racine pour l’enregistrement SOA, il est intéressant de remarquer que le serveur principal qui sert de maître pour la réplication DNS est désigné par le serveur racine a.root-servers.net dont la gestion est attribuée à Verisign, de même que l’adresse email du responsable de la zone racine : nstld@verisign-grs.com. En fait, cela était le cas auparavant c’est-à-dire que les serveurs racines obtenaient leur mise à jour de la part du serveur racine A. A présent, il existe un serveur maître caché non public à partir duquel tous les autres serveurs racine (y compris le serveur A) récupèrent la copie de la zone racine.

Le service DNS (Domain Name Services) dans le détail

Le service DNS signifiant Domain Name Services est né de la volonté de faciliter et de standardiser le processus d’identification des ressources connectées aux réseaux informatiques tels que l’Internet. Les machines ne sachant communiquer qu’à travers l’échange d’adresses IP difficiles à mémoriser pour l’homme, le DNS agit comme un annuaire téléphonique en fournissant la correspondance entre le nom de la machine et son adresse IP.

Ainsi, lorsque l’on veut se connecter à un ordinateur dont on connaît le nom d’hôte, on interroge un serveur DNS qui nous renvoie l’adresse IP correspondant à ce nom.

Le DNS est un modèle réparti hiérarchisé, sa mise en œuvre requiert plusieurs serveurs qui prennent en charge individuellement la traduction de parties complémentaires de l’espace des noms afin de rendre plus souple le traitement des sollicitations. Ces parties appelées zones sont en fait des domaines de noms dont l’administration est définie et attribuée à un ou plusieurs serveurs.

Le domaine source d’où découlent les domaines de noms est appelé domaine Racine. Le domaine Racine est géré par les 13 serveurs DNS nommés « <x>.root-servers.net », où <x> est une lettre comprise entre ‘a’ à ‘m’. Ces serveurs racines sont gérés par des organisations différentes nommées par l’ICANN (VeriSign, USC-ISI, Cogent, UMD, NASA-ARC, ISC, DOD-NIC, ARL, Autonomica, RIPE, ICANN et WIDE). Afin d’assurer le bon maintien du service, ces serveurs sont en réalité redondés, soit localement, soit de manière répartie. Dans ce dernier cas, la technique de routage Anycast est utilisée afin d’associer l’adresse IP d’un serveur racine à plusieurs machines éloignées géographiquement permettant de répartir la charge des requêtes en toute transparence. Par exemple, le serveur racine « c.root-servers.org » est géré par la société Cogent et est en réalité composé de 6 serveurs répartis sur la planète. Pour plus d’information sur les serveurs roots vous pouvez consulter le site http://root-servers.org/

Les domaines adjacents au domaine racine sont les domaines dits de premier niveau ou TLD (Top Level Domain). Ils définissent la nature des organisations et leur provenance géographique. Le TLD ‘com’, le plus répandu, est géré par la société Vérisign sur 13 serveurs DNS. L’AFNIC gère actuellement 3 TLD : ‘fr’, ‘re’ et ‘tf’. La liste des 295 TLD existants est connue de tous les serveurs racines.

Enfin, les domaines de second niveau (SLD) décrivent plus précisément leur nom ou leur titre. Au niveau des domaines de second niveau, des milliers d’autres serveurs sont sollicités pour répondre aux besoins de traduction en adresse IP.

Le niveau terminal (le plus éloigné de la racine) désigne le nom d’hôte de la machine. Ainsi, une machine sur Internet est facilement repérable grâce à son nom d’hôte et à la chaîne d’appartenance à laquelle elle est reliée. La concaténation de la racine, du TLD, du SLD, des sous-domaines et du nom d’hôte séparés par un point est appelée nom FQDN (Fully Qualified Domain Name). La taille limite d’un FQDN est de 255 caractères. Par exemple : la machine qui sert de serveur mail dans l’entreprise Oktey s’appelle mail au sein d’Oktey et « mail.oktey.fr. » sur Internet.

L’ICANN justifie la limitation du nombre des serveurs racines à 13 par un argument technique : utiliser plus de 13 serveurs racines entraînerait des réponses à certaines requêtes DNS de plus de 512 octets. Or le protocole applicatif DNS fonctionne au-dessus du protocole de transport UDP limité à 512 octets de données. La généralisation de l’utilisation de TCP au lieu d’UDP, utilisé pour la synchronisation entre serveurs DNS, entrainerait une surcharge des serveurs DNS.

Pour bien comprendre le mécanisme présenté, la figure suivante décrit le principe d’une requête DNS. Dans l’exemple, l’utilisateur symbolisé en haut à gauche, souhaite accéder au serveur web présent sur la machine : « mail.oktey.fr ». Nous n’analyserons que le trafic DNS dans cet exemple et considérons que le serveur DNS local, n’a pas l’information requise en cache (en mémoire), sans quoi ce dernier répond directement à la demande.

Les commandes utilisées pour requêter le service DNS sont ‘nslookup’ sous Windows et ‘dig’ ou ‘host’ sous Linux. A défaut de connaitre l’IP de la machine contactée via le fichier de nom « /etc/hosts », le resolver DNS utilise le ou les serveurs DNS mentionnés dans « /etc/resolv.conf » (ou la configuration réseau sous Windows) pour effectuer ses requêtes. Pour chacune des étapes, nous allons détailler les commandes sous Linux de la forme : #commande et l’équivalent sous Windows avec le formalisme : >commande. Les réponses seront produites pour les commandes sous Windows, pour éviter d’alourdir l’article inutilement.

1) Le poste de l’utilisateur est configuré pour utiliser le resolver qui orientera sa requête vers le « Serveur DNS local », correspondant généralement à l’IP du serveur DNS de l’entreprise.

# dig mail.oktey.com
> nslookup
> mail.oktey.com

Si le serveur DNS local, possède la réponse en cache, il répondra immédiatement le résultat, sinon il se chargera de poursuivre en interrogeant successivement tous les serveurs DNS, les phases décrites ci-dessous : (2) Racine, (3) DNS de FR, puis (4) DNS de oktey.fr.

2) Le serveur DNS local n’a pas la connaissance sur l’IP affecté au serveur « mail.oktey.fr ». Il doit donc retrouver l’information auprès des serveurs de « oktey.fr. ». Pour cela, il va d’abord contacter les serveurs racine pour savoir qui gère « fr ». La liste des serveurs racine est connue de tous les serveurs DNS, c’est la seule information configurée en dur sur les serveurs DNS.
Pour avoir la liste des serveurs racines :

# dig . NS
> nslookup
> set q=NS
> .

(root)  nameserver = g.root-servers.net
(root)  nameserver = l.root-servers.net
(root)  nameserver = b.root-servers.net
(root)  nameserver = c.root-servers.net
(root)  nameserver = j.root-servers.net
(root)  nameserver = h.root-servers.net
(root)  nameserver = a.root-servers.net
(root)  nameserver = f.root-servers.net
(root)  nameserver = d.root-servers.net
(root)  nameserver = e.root-servers.net
(root)  nameserver = m.root-servers.net
(root)  nameserver = k.root-servers.net
(root)  nameserver = i.root-servers.net
a.root-servers.net      internet address = 198.41.0.4
a.root-servers.net      AAAA IPv6 address = 2001:503:ba3e::2:30
b.root-servers.net      internet address = 192.228.79.201
c.root-servers.net      internet address = 192.33.4.12
d.root-servers.net      internet address = 128.8.10.90
e.root-servers.net      internet address = 192.203.230.10
f.root-servers.net      internet address = 192.5.5.241
f.root-servers.net      AAAA IPv6 address = 2001:500:2f::f
g.root-servers.net      internet address = 192.112.36.4
h.root-servers.net      internet address = 128.63.2.53
h.root-servers.net      AAAA IPv6 address = 2001:500:1::803f:235
i.root-servers.net      internet address = 192.36.148.17
i.root-servers.net      AAAA IPv6 address = 2001:7fe::53
j.root-servers.net      internet address = 192.58.128.30

Pour information, on voit apparaitre dans la réponse que 4 serveurs root sur 13 possèdent un adressage IPv6. Pour la prochaine requête un serveur root sera utilisé au hasard parmi les 13 disponibles, dans notre exemple nous utiliserons c.root-servers.net [192.33.4.12].
Requête auprès d’un serveur racine pour savoir qui gère ‘fr’ :

# dig @192.33.4.12 fr NS

> nslookup
> set q=NS
> server 192.33.4.12
> fr
fr      nameserver = d.ext.nic.fr
fr      nameserver = f.ext.nic.fr
fr      nameserver = e.ext.nic.fr
fr      nameserver = d.nic.fr
fr      nameserver = a.nic.fr
fr      nameserver = g.ext.nic.fr
fr      nameserver = c.nic.fr
a.nic.fr        internet address = 192.93.0.129
a.nic.fr        AAAA IPv6 address = 2001:660:3005:3::1:1
c.nic.fr        internet address = 192.134.0.129
c.nic.fr        AAAA IPv6 address = 2001:660:3006:4::1:1
d.ext.nic.fr    internet address = 192.5.4.2
d.ext.nic.fr    AAAA IPv6 address = 2001:500:2e::2
d.nic.fr        internet address = 194.0.9.1
d.nic.fr        AAAA IPv6 address = 2001:678:c:1::1
e.ext.nic.fr    internet address = 193.176.144.6
e.ext.nic.fr    AAAA IPv6 address = 2a00:d78:0:102:193:176:144:6
f.ext.nic.fr    internet address = 194.146.106.46
f.ext.nic.fr    AAAA IPv6 address = 2001:67c:1010:11::53
g.ext.nic.fr    internet address = 204.61.216.39
g.ext.nic.fr    AAAA IPv6 address = 2001:500:14:6039:ad::1

L’AFNIC utilise 7 serveurs DNS, 3 sont physiquement sur les réseaux de l’AFNIC en France, et 4 (les sous-domaine en ‘ext’) se trouvent à l’extérieur du réseau de l’AFNIC.

3) Une requête est ensuite envoyée auprès des serveurs DNS de l’AFNIC pour savoir quels sont les DNS de la zone : ‘oktey.fr’. Dans l’exemple, nous utiliserons au hasard le serveur d.nic.fr [194.0.9.1].

# dig @194.0.9.1 oktey.fr NS
> nslookup
> set q=ns
> server 194.0.9.1
> oktey.fr
oktey.fr        nameserver = dns.oktey.net
oktey.fr        nameserver = ns.oktey.net

4) Pour finir, la requête DNS finale est effectuée directement auprès d’un des serveurs DNS gérant le domaine ‘oktey.fr’, les DNS « faisant autorité ». Le type d’enregistrement qui nous intéresse n’est plus NS mais A (ou CNAME). L’adresse IP de : ‘dns.oktey.net’ est 213.251.128.136, d’où la requête ci-dessous.

# dig @213.251.128.136 mail.oktey.fr A

> nslookup
> set q=A
> server 213.251.128.136
> mail.oktey.fr
Nom : mail.oktey.fr
Address: 87.248.120.148

Pour effectuer cette dernière requête, il a été nécessaire de retrouver l’IP du serveur ‘dns.oktey.net’, si l’information n’était pas dans le cache cela a nécessité de contacter les DNS, racine pour savoir qui gère .net, puis oktey.net, puis dns.oktey.net soit 3 requêtes supplémentaires.
A chaque étape, un des serveurs DNS retourné était pris au hasard afin d’effectuer la requête suivante. Il est donc vital que tous les serveurs DNS renvoient systématiquement la même réponse à une requête identique. Les serveurs DNS d’une même zone doivent donc impérativement être synchronisés entre eux.
Le découpage en étapes que nous venons de décomposer peut être affiché directement via la commande dig suivante : #dig +trace +all mail.oktey.fr

Nous vous avons présenté le fonctionnement du service DNS dans cet article, car la messagerie (tout comme le web) utilise comme fondation le service DNS. Nous remarquons que très souvent les problèmes de messagerie électronique proviennent en réalité de soucis DNS. Une bonne compréhension du fonctionnement des DNS permet bien souvent d’appréhender un grand nombre de soucis de messagerie électronique.