Les records SOA : un élément de base dans un fichier de zone

Tout internaute sait qu’il lui suffit de taper l’URL d’un site Internet dans son navigateur pour accéder au site qu’il souhaite consulter. Il ne se doute pas que pour se faire, son ordinateur doit effectuer une connexion vers une adresse IP. Cette connexion est possible grâce au Domain Name System (DNS) et à la fonction baptisée résolution de noms. Cette fonction permet de traduire le nom d’un domaine en une suite de chiffres. Pour que ce système puisse fonctionner, le serveur de noms dispose de fichiers de zone. Ce sont de simples fichiers textes qui renferment toute une série d’enregistrements SOA DNS (DNS SOA records en anglais) qui constituent la base du DNS.

Les plus connus d’entre eux sont certainement les enregistrements A qui permettent la véritable résolution de noms. On a aussi les enregistrements PTR qui permettent une recherche DNS inversée, et les enregistrements MX qui favorisent la communication par email. Mais à quoi servent les records SOA ?

Le DNS est un système hiérarchique décentralisé. Les serveurs de noms ne délivrent pas d’informations à n’importe quel serveur d’Internet, mais seulement à ceux qui se trouvent dans la zone qui a été assignée. Ce sont les fichiers de zone du serveur DNS qui assument ce rôle. Ce sont de simples fichiers texte dans lesquels sont inscrits tous les enregistrements DNS de la zone. Pour que ces responsabilités soient clairement définies, on doit nécessairement attribuer à chaque zone un record SOA. SOA signifie Start of Authority. Cet enregistrement vous donne donc des informations et vous indique si le serveur qui est interrogé a bel et bien la charge de cette zone.

Un enregistrement SOA joue un rôle particulièrement important dans le cadre d’un cluster de serveurs. Au lieu d’endosser la charge de toutes les requêtes, les requêtes sont réparties sur plusieurs appareils. Pour que les fichiers de zone soient mis à jour sur tous les serveurs, il faut procéder régulièrement à un transfert de zone. Pour ce faire, les serveurs secondaires (c’est à dire d’ordre inférieur dans la hiérarchie) comparent leurs données avec celles du serveur primaire. C’est l’enregistrement SOA qui définit la manière dont se fait le transfert de zone. Cet enregistrement DNS renferme donc plusieurs informations.

Les records DNS renferment généralement plusieurs champs. Ces champs contiennent toutes sortes d'informations pertinentes. Comparé à d’autres enregistrements, le record SOA comprend beaucoup de champs :

• <name> : nom de la zone
• <class> : classe du réseau
• <type> : type d’enregistrement
• <mname> : nom du serveur principal
• <rname> : adresse email de l’administrateur responsable
• <serial> : numéro de série incrémenté, permettant d’identifier la version du fichier de zone
• <refresh> : intervalle précisant à quel moment un serveur secondaire doit interroger la version du serveur primaire
• <retry> : intervalle précisant à quel moment un serveur secondaire doit renouveler sa requête en cas d’échec
• <expire> : intervalle précisant à quel moment les informations DNS ne doivent plus être délivrées en cas d’absence de réponse de la part du serveur primaire
• <minimum> : intervalle précisant combien de temps les informations peuvent être conservées dans le cache

Les trois premiers champs sont représentatifs de tous les records DNS. Le nom de la zone est un Domain-Name rédigé sous la forme d’un Fully Qualified Domain Names (FQDN) (noms de domaines pleinement qualifiés). À la différence des URL, cette information est enregistrée avec un point final. Pourquoi ? Un FQDN présente toute la structure hiérarchique du domaine avec, à son extrémité, le répertoire-racine. Celui-ci étant vide, il ne reste plus que le point de séparation. On trouve cette forme de notation dans tous les noms de domaines du DNS, même dans les champs MNAME et RNAME.

Le champ Classe n’a plus qu’une signification historique. Il est donc très souvent laissé de côté. Lorsque le DNS a été développé, il existait, en plus de l’Internet, deux autres projets : Hesiod (HS) et Chaos (CH). Ces deux réseaux n’existent plus de nos jours, ce qui explique que ce champ renferme exclusivement la mention IN. Le Type renvoie au type d’enregistrement DNS. Ici, il s’agit d’un enregistrement SOA.

MNAME, aussi connu sous le nom de Primary Master, est un champ qui précise le nom du serveur primaire par rapport au serveur secondaire. Cette information permet à un serveur subordonné de savoir vers quel serveur il doit se tourner pour le transfert de zones. Il y a quelques précautions à prendre quant au format de l’adresse email dans le champ RNAME. L’enregistrement ne doit pas comporter le signe @. Pour séparer la partie locale (ex. le nom de l’utilisateur) du domaine, vous devez utiliser le point. Dans le cas où l’adresse email originale comprendrait un point avant le signe @, vous devrez remplacer ce point par un backslash (\).

Le numéro de série doit être incrémenté à chaque fois que le fichier de zone est modifié. Deux variantes sont communes. On peut opter pour un simple incrément de 1, en ajoutant 1 au numéro de série à chaque modification. Cette option est assez courante. Elle permet de voir combien de modifications ont été apportées.

L’autre option consiste à choisir un format de date : AAAAMMJJVV On commence par inscrire l’année avec quatre chiffres, suivie du mois et du jour (à deux chiffres chacun) et on termine la saisie par un numéro de version à deux chiffres. Ce format permet d’identifier la date à laquelle la version a été modifiée. Pour chaque modification apportée le même jour, le numéro de version sera incrémenté. Le jour suivant, le numéro de série s’adapte à la nouvelle date, tandis que le numéro de version commence à 00.

L’enregistrement SOA se termine par trois, voire quatre indications de temps, exprimées en secondes. Le premier champ (« Refresh ») donne au serveur secondaire l’intervalle de temps entre deux vérifications du numéro de série de la version du fichier de zone. Si cette requête est laissée sans réponse, c’est le champ « Retry » qui détermine quand doit avoir lieu la première tentative. Il est important que ce délai soit inférieur à la valeur précédente.

Si le serveur de niveau inférieur dans la hiérarchie ne reçoit pas de réponse, la troisième valeur temporelle (« Expire ») prend le relais. C’est elle qui détermine combien de temps on peut continuer à utiliser le fichier de zone, avant que le serveur ne rejette la délivrance d’informations DNS. Si le serveur continuait à fournir à des clients requérants des données provenant de fichiers de zones périmés, on aurait vite des problèmes de validité, avec des problèmes de connexion et des risques sur le plan de la sécurité.

Le champ « Minimum » marque la fin. Ce champ correspond au Time to Live qu’on rencontre dans les autres enregistrements DNS. Ce champ précise combien de temps un client peut conserver les données dans le cache avant de devoir renouveler sa requête. Généralement le TTL est enregistré de manière globale pour l’ensemble de la zone avec la mention $TTL. Dans un tel cas, il est inutile de répéter cette mention dans chaque enregistrement. Le nom de la zone peut être défini au début du fichier au moyen de la mention $ORIGIN.

L’enregistrement se fait toujours au début du fichier de zone.

Les champs peuvent tout simplement être saisis à la suite, sur une même ligne. Tandis que l’enregistrement est généralement assez simple dans les autres types de records, l’enregistrement SOA est quant à lui un peu plus complexe. Pour une meilleure lisibilité, on dispose habituellement les champs de manière imbriquée et subordonnée.

Quand on les enregistre de cette manière, les TTL et Domain-Name sont enregistrés par avance. Le signe @ au début d’un enregistrement renvoie à l’indication d’origine. Pour pouvoir imbriquer plusieurs valeurs temporelles et les répartir sur plusieurs lignes, on utilise des parenthèses.

Un fichier de zone ne peut pas être valide sans un enregistrement SOA. Les records SOA se présentent de la manière suivante :

Dans cet extrait de fichier de zone donné à titre d’exemple, nous avons inséré des informations autres que le record SOA, pour mieux expliquer son positionnement. Le fichier commence par des indications portant sur le nom du domaine (ici example.org) et le champ TTL. Vient ensuite l’enregistrement SOA. Comme nous avons déjà nommé la zone dans l’indication $ORIGIN, il suffit d’y porter le caractère @ comme élément de renvoi.

Vient ensuite le serveur principal (fictif) de cette zone ainsi que les données qui concernent la classe du réseau et le type d’enregistrement. Suit l’adresse email de l’administrateur. Le point est rendu possible grâce au backslash qui représente ici un caractère masqué. Le point suivant remplace le caractère @ de l’adresse réelle, et le suivant permet comme d’habitude de délimiter le Top-Level-Domain (TLD). Une parenthèse ouvre la zone à imbrications, permettant de la répartir sur plusieurs lignes. Il est bien entendu possible d’aligner toutes les valeurs à la suite, séparées d’une simple espace.

Dans cet exemple, nous avons ajouté derrière chaque valeur une indication quant à leur utilisation. Il s’agit simplement de commentaires qui sont donnés à titre purement indicatif et que vous pouvez au besoin supprimer. De telles annotations dans les enregistrements DNS, uniquement destinées à être lues par des personnes, sont marquées par un point-virgule.

La parenthèse doit être refermée à la fin d’un record SOA.

Pour finir, nous avons ajouté un enregistrement NS et un enregistrement A dans le fichier de zone de notre exemple. On voit donc que l’enregistrement SOA doit être placé avant tous les autres enregistrements, mais pas avant les indications concernant le domaine et le TTL.

Pour connaître le record SOA d’un site internet, on peut soit installer des logiciels spécialisés, soit recourir à un service internet dédié. Le service Google Public DNS qui est le serveur DNS de Google permet de retrouver facilement et rapidement le record SOA d’un domaine. Il suffit d’aller sur la page et de taper le nom du domaine concerné. La page suivante vous affichera dans un premier temps l’indication qui concerne l’enregistrement A. Choisissez ensuite le champ SOA, et lancez une nouvelle recherche en cliquant sur le bouton.

Le service Public DNS vous propose d’autres options : EDNS Client Subnet est une fonction qui permet d’établir des connexions plus efficaces avec le DNS. Cette option n’est proposée à ce jour que par Google et OpenDNS. L’option DNSSEC garantit quant à elle que les données obtenues par le DNS proviennent réellement de son auteur. Les données envoyées sans cette mesure de sécurité peuvent en principe être manipulées par des tiers. Pour une consultation de record SOA, on peut laisser ces deux options inchangées.