Principes de Synchronisation DNS

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 figure suivante illustre le concept de zone :

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.

retryindique 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.

Les serveurs racines qui utilisent la technique Anycast propagent également ces mises à jour vers leurs miroirs Anycast. Pour plus de détails, veuillez consulter l’article sur le fonctionnement détaillé du protocole DNS : https://www.altospam.com/actualite/2011/01/principe-de-fonctionnement-detaille-du-service-dns/