Plage de vérification d’un domaine

Un serveur DNS renvoie un certain nombre d’informations. Il renvoie notamment la liste des serveurs de noms (enregistrements NS), la liste des serveurs de messageries (enregistrements MX), la liste des adresses IP des hôtes (enregistrements A), la liste des alias (enregistrements CNAME), le fichier d’autorité (enregistrement SOA). Les valeurs renvoyées par un serveur DNS ne sont pas prises au hasard et nécessitent une réflexion sur leur pertinence. Il peut également exister des conflits notamment pour les enregistrements CNAME. Afin de vérifier la valeur de ces champs dans notre outil dnslookup.fr, nous avons décidé de faire une étude sur ces valeurs. Nous comparerons donc 3 types de sources. La première source est représentée par l’ensemble des RFC fournies par l’IETF. Cette source est la source la plus officielle et constitue donc notre point de comparaison. La seconde source est un outil d’analyse DNS construit par Vitalie Cherpec, dnsvalidation. Cet outil n’est pas une source officielle mais offre un grand nombre de vérifications qui sont faites sur les réponses DNS, il est donc intéressant d’établir la pertinence de ces vérifications. La dernière source de comparaison est l’outil fourni par l’AFNIC pour l’analyse de domaine, ZoneCheck. Cet outil est une source officielle car l’AFNIC (Association française pour le nommage Internet en coopération) est une association d’après la loi de 1901 créée par la volonté conjointe de l’INRA et de l’état Français. L’AFNIC gère également les TLD .fr, .re et .tf.

Voici un tableau comparatif des valeurs retenues dans dnsvalidation, zonecheck (ex service de l’Afnic) et les RFC :

Les champs SOA

La périodicité de la vérification de version par les serveurs secondaires est définie par des paramètres marqués dans le RR SOA attribué à la zone, qui définissent l’intervalle minimum entre deux vérifications. Ces paramètres sont appelés REFRESH, RETRY, et EXPIRE. Lorsqu’une zone est enregistrée dans un serveur secondaire, celui-ci attendra REFRESH secondes avant de vérifier sur le primaire si un nouveau numéro de série a été donné pour la zone. Si cette vérification ne peut être effectuée, des nouvelles tentatives seront faites toutes les RETRY secondes. La vérification est une requête simple visant le RR SOA de la zone sur le serveur principal. Si le numéro de série dans la copie hébergée par le secondaire est égal au numéro de série indiqué dans le RR retourné par la requête, alors aucune remise à jour n’est nécessaire, et la temporisation REFRESH doit être réactivée. Si le serveur secondaire n’arrive pas à faire la vérification après que l’intervalle EXPIRE se soit écoulé, il doit alors admettre que sa copie de la zone est obsolète et  la supprime.

On en déduit donc la formule suivante afin d’assurer la cohérence de la périodicité de la vérification:    RETRY < REFRESH < EXPIRE.

Les valeurs des champs « expire », « retry », « refresh » et « minimum TTL » marquées ci-dessus sont des recommandations et n’engagent aucunement l’utilisateur à les respecter. Cependant ces champs sont codés sur 32 bits. Les champs acceptent donc des valeurs entre 0 et 2147483647 (valeur en seconde, soit environ 24855 jours, soit environ 68 ans). Le maximum est la valeur de 2^31 – 1 car le bit de signe est fixé à 0.

Les enregistrements CNAME

D’après la RFC 1912, un enregistrement CNAME ne peut pas coexister avec d’autres données. Autrement dit, si toto.domaine.tld est un alias pour server.domaine.tld, alors il ne peut pas y avoir d’enregistrement A, NS, MX ou même TXT pour toto.domaine.tld. Par exemple il est interdit d’avoir :

toto.domaine.tld     IN           CNAME           server.domaine.tld
toto.domaine.tld     IN           A               1.2.3.4

Il faut inscrire les champs comme suit :

toto.domaine.tld     IN           CNAME           server.domaine.tld
server.domaine.tld   IN           A               1.2.3.4

Il faut éviter de combiner les CNAME avec les NS comme suit :

domaine.tld          IN           NS              ns1
domaine.tld          IN           NS              ns2
domaine.tld          IN           CNAME           toto
toto                 IN           A               1.2.3.4

Si vous voulez que votre nom de domaine soit défini comme un hôte il faudra l’écrire comme cela :

domaine.tld          IN           NS              ns1
domaine.tld          IN           NS              ns2
domaine.tld          IN           A               1.2.3.4
toto                 IN           A               1.2.3.4

Comme aucun autre enregistrement ne peut coexister avec les enregistrements CNAME, l’enregistrement A du premier exemple et les enregistrements NS du deuxième exemple seront ignorés. Cependant, les CNAME sont utiles (et même recommandés) pour les noms génériques de serveurs : ‘ftp’ pour le serveur FTP, ‘www’ pour le serveur Web …

D’autre part, il ne faut pas que les enregistrements CNAME pointent vers d’autres noms comme MX, CNAME, PTR et NS. Par exemple il est fortement déconseillé de faire :

domaine.tld           IN          MX              mail
mail                  IN          CNAME           toto
toto                  IN          A               1.2.3.4

La correspondance valide à ces enregistrements serait :

domaine.tld           IN          MX              mail
mail                  IN          A               1.2.3.4

De plus, dans la RFC 1034, section 3.6.2, il est stipulé que cela est interdit. Et la RFC 974 prévoit explicitement que les enregistrements MX ne doivent pas pointer vers un alias défini comme un CNAME.

Cependant, la RFC 2821 contredit cela. Cette RFC décrit l’aspect technique du protocole SMTP. La section 5 nous intéresse car elle décrit l’aspect technique de la résolution d’adresse de la messagerie. Lors d’une résolution de messagerie, le client SMTP doit identifier lexicalement le domaine pour lequel du courrier sera livré.

Une recherche DNS doit être effectuée pour résoudre le nom de domaine. La recherche vise d’abord à localiser un enregistrement MX associé au nom de domaine.

Cependant, si un enregistrement CNAME est trouvé à la place, le nom résultant est traité comme si celui-ci représentait le nom de domaine.

Si aucun enregistrement MX n’existe mais qu’un enregistrement A est trouvé, ce dernier enregistrement est traité comme s’il était associé à un enregistrement MX implicite, avec une préférence de 0, pointant sur cet hôte.

Si un ou plusieurs enregistrements MX sont trouvés pour un nom donné, les systèmes SMTP ne doivent utiliser aucun enregistrement A associé à ce nom de domaine. Si des enregistrements MX sont présents, mais qu’aucun d’eux n’est utilisable, cette situation doit être rapportée comme une erreur.

Pour conclure, les valeurs « EXPIRE », « REFRESH », « RETRY » et « Minimum TTL » du SOA sont semblables entres les différentes sources. Comme aucune source ne nous indique que ces valeurs sont à respecter à la lettre ou qu’elles provoquent des erreurs, nous trouverons donc un compromis afin d’établir la vérification dans notre outil dnslookup.fr. Cependant, l’ordre  EXPIRE  >  RETRY  >  REFRESH   est commun à toutes les sources et permet d’éviter les erreurs de mise à jour des serveurs DNS secondaires.

Pour le respect des enregistrements CNAME, nous prendrons comme référence les RFC les plus récentes. Ainsi nous vérifierons qu’aucun enregistrement correspondant au nom de domaine ne coexiste avec les enregistrements CNAME et que les données des enregistrements NS et MX ne sont pas utilisées dans les enregistrements CNAME.