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

Tout in­ter­naute sait qu’il lui suffit de taper l’URL d’un site Internet dans son na­vi­ga­teur pour accéder au site qu’il souhaite consulter. Il ne se doute pas que pour se faire, son or­di­na­teur 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é­so­lu­tion de noms. Cette fonction permet de traduire le nom d’un domaine en une suite de chiffres. Pour que ce système puisse fonc­tion­ner, le serveur de noms dispose de fichiers de zone. Ce sont de simples fichiers textes qui ren­fer­ment toute une série d’en­re­gis­tre­ments SOA DNS (DNS SOA records en anglais) qui cons­ti­tuent la base du DNS.

Les plus connus d’entre eux sont cer­tai­ne­ment les en­re­gis­tre­ments A qui per­met­tent la véritable ré­so­lu­tion de noms. On a aussi les en­re­gis­tre­ments PTR qui per­met­tent une recherche DNS inversée, et les en­re­gis­tre­ments MX qui fa­vo­ri­sent la com­mu­ni­ca­tion par email. Mais à quoi servent les records SOA ?

Le DNS est un système hié­rar­chique dé­cen­tra­lisé. Les serveurs de noms ne délivrent pas d’in­for­ma­tions à 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 en­re­gis­tre­ments DNS de la zone. Pour que ces res­pon­sa­bi­li­tés soient clai­re­ment définies, on doit né­ces­sai­re­ment attribuer à chaque zone un record SOA. SOA signifie Start of Authority. Cet en­re­gis­tre­ment vous donne donc des in­for­ma­tions et vous indique si le serveur qui est interrogé a bel et bien la charge de cette zone.

Un en­re­gis­tre­ment SOA joue un rôle par­ti­cu­liè­re­ment 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é­gu­liè­re­ment à un transfert de zone. Pour ce faire, les serveurs se­con­daires (c’est à dire d’ordre inférieur dans la hié­rar­chie) comparent leurs données avec celles du serveur primaire. C’est l’en­re­gis­tre­ment SOA qui définit la manière dont se fait le transfert de zone. Cet en­re­gis­tre­ment DNS renferme donc plusieurs in­for­ma­tions.

Les records DNS ren­fer­ment gé­né­ra­le­ment plusieurs champs. Ces champs con­tien­nent toutes sortes d'in­for­ma­tions per­ti­nentes. Comparé à d’autres en­re­gis­tre­ments, le record SOA comprend beaucoup de champs :

• <name> : nom de la zone
• <class> : classe du réseau
• <type> : type d’en­re­gis­tre­ment
• <mname> : nom du serveur principal
• <rname> : adresse email de l’ad­mi­nis­tra­teur res­pon­sable
• <serial> : numéro de série in­cré­menté, per­met­tant d’iden­ti­fier la version du fichier de zone
• <refresh> : in­ter­valle précisant à quel moment un serveur se­con­daire doit in­ter­ro­ger la version du serveur primaire
• <retry> : in­ter­valle précisant à quel moment un serveur se­con­daire doit re­nou­ve­ler sa requête en cas d’échec
• <expire> : in­ter­valle précisant à quel moment les in­for­ma­tions DNS ne doivent plus être délivrées en cas d’absence de réponse de la part du serveur primaire
• <minimum> : in­ter­valle précisant combien de temps les in­for­ma­tions peuvent être con­ser­vées dans le cache

Les trois premiers champs sont re­pré­sen­ta­tifs 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 plei­ne­ment qualifiés). À la dif­fé­rence des URL, cette in­for­ma­tion est en­re­gis­trée avec un point final. Pourquoi ? Un FQDN présente toute la structure hié­rar­chique du domaine avec, à son extrémité, le ré­per­toire-racine. Celui-ci étant vide, il ne reste plus que le point de sé­pa­ra­tion. 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 sig­ni­fi­ca­tion his­to­rique. 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 ex­clu­si­ve­ment la mention IN. Le Type renvoie au type d’en­re­gis­tre­ment DNS. Ici, il s’agit d’un en­re­gis­tre­ment 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 se­con­daire. Cette in­for­ma­tion permet à un serveur su­bor­donné de savoir vers quel serveur il doit se tourner pour le transfert de zones. Il y a quelques pré­cau­tions à prendre quant au format de l’adresse email dans le champ RNAME. L’en­re­gis­tre­ment ne doit pas comporter le signe @. Pour séparer la partie locale (ex. le nom de l’uti­li­sa­teur) du domaine, vous devez utiliser le point. Dans le cas où l’adresse email originale com­pren­drait un point avant le signe @, vous devrez remplacer ce point par un backslash (\).

Le numéro de série doit être in­cré­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 mo­di­fi­ca­tion. Cette option est assez courante. Elle permet de voir combien de mo­di­fi­ca­tions ont été apportées.

L’autre option consiste à choisir un format de date : AAAAMM­J­JVV 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’iden­ti­fier la date à laquelle la version a été modifiée. Pour chaque mo­di­fi­ca­tion apportée le même jour, le numéro de version sera in­cré­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’en­re­gis­tre­ment SOA se termine par trois, voire quatre in­di­ca­tions de temps, exprimées en secondes. Le premier champ (« Refresh ») donne au serveur se­con­daire l’in­ter­valle de temps entre deux vé­ri­fi­ca­tions 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é­rar­chie ne reçoit pas de réponse, la troisième valeur tem­po­relle (« 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é­li­vrance d’in­for­ma­tions DNS. Si le serveur con­ti­nuait à fournir à des clients re­qué­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 cor­res­pond au Time to Live qu’on rencontre dans les autres en­re­gis­tre­ments DNS. Ce champ précise combien de temps un client peut conserver les données dans le cache avant de devoir re­nou­ve­ler sa requête. Gé­né­ra­le­ment le TTL est en­re­gis­tré 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 en­re­gis­tre­ment. Le nom de la zone peut être défini au début du fichier au moyen de la mention $ORIGIN.

L’en­re­gis­tre­ment se fait toujours au début du fichier de zone.

Les champs peuvent tout sim­ple­ment être saisis à la suite, sur une même ligne. Tandis que l’en­re­gis­tre­ment est gé­né­ra­le­ment assez simple dans les autres types de records, l’en­re­gis­tre­ment SOA est quant à lui un peu plus complexe. Pour une meilleure li­si­bi­lité, on dispose ha­bi­tuel­le­ment les champs de manière imbriquée et su­bor­don­née.

Quand on les en­re­gistre de cette manière, les TTL et Domain-Name sont en­re­gis­trés par avance. Le signe @ au début d’un en­re­gis­tre­ment renvoie à l’in­di­ca­tion d’origine. Pour pouvoir imbriquer plusieurs valeurs tem­po­relles et les répartir sur plusieurs lignes, on utilise des pa­ren­thèses.

Un fichier de zone ne peut pas être valide sans un en­re­gis­tre­ment SOA. Les records SOA se pré­sen­tent de la manière suivante :

Dans cet extrait de fichier de zone donné à titre d’exemple, nous avons inséré des in­for­ma­tions autres que le record SOA, pour mieux expliquer son po­si­tion­ne­ment. Le fichier commence par des in­di­ca­tions portant sur le nom du domaine (ici example.org) et le champ TTL. Vient ensuite l’en­re­gis­tre­ment SOA. Comme nous avons déjà nommé la zone dans l’in­di­ca­tion $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 con­cer­nent la classe du réseau et le type d’en­re­gis­tre­ment. Suit l’adresse email de l’ad­mi­nis­tra­teur. Le point est rendu possible grâce au backslash qui re­pré­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 pa­ren­thèse ouvre la zone à im­bri­ca­tions, per­met­tant 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 in­di­ca­tion quant à leur uti­li­sa­tion. Il s’agit sim­ple­ment de com­men­taires qui sont donnés à titre purement indicatif et que vous pouvez au besoin supprimer. De telles an­no­ta­tions dans les en­re­gis­tre­ments DNS, uni­que­ment destinées à être lues par des personnes, sont marquées par un point-virgule.

La pa­ren­thèse doit être refermée à la fin d’un record SOA.

Pour finir, nous avons ajouté un en­re­gis­tre­ment NS et un en­re­gis­tre­ment A dans le fichier de zone de notre exemple. On voit donc que l’en­re­gis­tre­ment SOA doit être placé avant tous les autres en­re­gis­tre­ments, mais pas avant les in­di­ca­tions con­cer­nant le domaine et le TTL.

Pour connaître le record SOA d’un site internet, on peut soit installer des logiciels spé­cia­li­sés, soit recourir à un service internet dédié. Le service Google Public DNS qui est le serveur DNS de Google permet de retrouver fa­ci­le­ment et ra­pi­de­ment 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’in­di­ca­tion qui concerne l’en­re­gis­tre­ment A. Choi­sis­sez 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 con­nexions 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 pro­vien­nent réel­le­ment de son auteur. Les données envoyées sans cette mesure de sécurité peuvent en principe être ma­ni­pu­lées par des tiers. Pour une con­sul­ta­tion de record SOA, on peut laisser ces deux options in­chan­gées.