Comprendre le fonctionnement des serveurs DNS

Le DNS est le système qui traduit un nom de domaine en adresse IP. En effet, sans lui, aucun navigateur ne saurait où envoyer sa requête, car les machines ne s'adressent qu'à des numéros. Cet article décrit le mécanisme réel, puis la façon de le configurer, et enfin ce qui casse quand il est mal réglé.

Cependant, le DNS souffre d'une réputation trompeuse. On le présente souvent comme un annuaire, alors qu'il s'agit en réalité d'une base de données distribuée, hiérarchique et mise en cache à chaque étage. Cette nuance explique ainsi la plupart des incidents observés sur le terrain, à commencer par les délais de propagation que personne ne comprend.

Par ailleurs, cet article suit un ordre volontairement technique. D'abord le chemin d'une requête, ensuite la zone et ses enregistrements, puis la configuration et ses pièges, et enfin la sécurité et le diagnostic. Chaque affirmation chiffrée renvoie de surcroît à une source publique, à savoir une RFC ou une documentation d'éditeur.

Définition

Le DNS : l'annuaire qui traduit les noms en adresses

Le DNS, pour Domain Name System, associe un nom lisible par un humain à une adresse utilisable par une machine. Néanmoins, réduire son rôle à cette conversion serait inexact, puisque le même système publie aussi les serveurs de messagerie, les clés de signature et diverses informations de service.

Pourquoi un nom de domaine ne suffit jamais, à lui seul, à joindre un serveur

Un nom de domaine n'est qu'une étiquette. De fait, il ne contient aucune information de routage, et il ne désigne aucune machine par lui-même. Seule la consultation du DNS permet d'obtenir l'adresse IP à laquelle le navigateur ouvrira ensuite une connexion.

Cette séparation est volontaire. En effet, elle permet de changer de serveur, d'hébergeur ou de pays sans changer l'adresse que vos clients tapent. À l'inverse, publier une adresse IP dans vos supports de communication vous enferme dans une infrastructure précise.

Ce que le DNS ne fait pas, alors qu'on le lui attribue pourtant

Le DNS ne transporte aucune donnée de votre site. Il n'héberge rien, il ne ralentit ni n'accélère les pages une fois la connexion établie, et il n'intervient plus après la résolution du nom. Par conséquent, un site lent n'est presque jamais un problème de DNS.

De même, le DNS n'authentifie pas le contenu servi. Certes, une extension de sécurité existe, et nous y venons plus bas. Toutefois, dans sa forme d'origine, le protocole fait confiance à la réponse qu'il reçoit, ce qui constitue sa faiblesse historique.

Champ couvert

La zone DNS : le périmètre que vous administrez

Une zone DNS est la portion de l'arborescence dont une entité assume l'administration. Elle regroupe notamment les enregistrements d'un domaine et, le cas échéant, de ses sous-domaines non délégués.

Ce que contient une zone et où s'arrête exactement sa responsabilité

La zone s'arrête à la première délégation. Dès qu'un sous-domaine reçoit ses propres serveurs de noms, il sort du périmètre de la zone parente et devient une zone distincte. De ce fait, une erreur commise dans la zone parente n'affecte pas nécessairement le sous-domaine délégué.

Cette frontière compte beaucoup en entreprise. En particulier, elle permet de confier un sous-domaine applicatif à une équipe technique sans lui ouvrir l'accès au domaine principal, et sans risquer que le site de production tombe à la suite d'une manipulation.

Le fichier de zone et l'enregistrement SOA qui l'ouvre toujours

Le fichier de zone est la forme texte de cette base. Il commence invariablement par un enregistrement SOA, à savoir Start of Authority. La RFC 1035 en fixe les champs, c'est-à-dire le serveur primaire, l'adresse de contact, un numéro de série, puis les valeurs de rafraîchissement, de nouvelle tentative, d'expiration et de minimum.

Le champ minimum a changé de sens. En effet, la RFC 2308 en a fait la durée de cache des réponses négatives, et elle observe que des valeurs d'une à trois heures fonctionnent bien, tandis que des valeurs dépassant une journée se révèlent problématiques. Beaucoup de zones héritées portent pourtant encore une valeur trop haute.

Inventaire

Les types d'enregistrements : à quoi sert chaque ligne

Chaque ligne d'une zone est un enregistrement de ressource. Le tableau ci-dessous récapitule en outre les types que vous rencontrerez réellement, avec le défaut de configuration qui leur est propre.

Les enregistrements d'adresse et d'alias, à savoir A, AAAA et CNAME

A et AAAA sont les seuls à désigner une machine. Le premier porte une adresse IPv4, alors que le second porte une adresse IPv6. Les adresses employées ici relèvent des plages réservées à la documentation par la RFC 5737, de sorte qu'elles ne joignent aucun serveur réel.

Le CNAME, quant à lui, renvoie vers un autre nom. Toutefois, la RFC 2181 est formelle, puisqu'un nom porteur d'un alias ne peut porter aucune autre donnée, hors enregistrements de signature. C'est pourquoi un CNAME est impossible à la racine du domaine, laquelle porte obligatoirement ses NS et son SOA.

Les enregistrements de service, à savoir MX, TXT, SRV et NS

Le MX gouverne la messagerie entrante. Il s'accompagne également d'une valeur de priorité, la plus basse étant la préférée. Par ailleurs, la RFC 2181 précise que la cible d'un MX doit être un nom porteur d'adresse, et non un alias.

Le TXT sert aujourd'hui surtout à publier les politiques d'authentification du courrier. Effectivement, SPF, DKIM et DMARC s'y logent, et une erreur à ce niveau se traduit plutôt par des messages en indésirable que par une panne visible. Le sujet est ainsi traité en détail dans l'article consacré à SPF, DKIM et DMARC.

Mise en pratique

Configurer une zone : la manipulation et ses pièges

Venons-en désormais à la manipulation. Une zone se règle depuis une interface, mais cette interface dépend de qui héberge réellement vos serveurs de noms, ce qui n'est pas toujours celui que vous croyez.

Où se règle une zone, selon votre registrar et selon votre hébergeur

Les NS déclarés au registre déterminent l'interface qui fait foi. Lorsque vos NS pointent vers votre hébergeur, l'interface du registrar n'a plus aucun effet sur la résolution. À l'inverse, si vos NS restent chez le registrar, c'est son panneau qui compte.

Cette confusion est de loin la première cause de modification sans effet. D'ailleurs, un contrôle simple lève le doute, à savoir interroger les NS publiés pour votre domaine, puis vérifier qu'ils correspondent à l'interface que vous éditez. Un hébergement infogéré évite généralement ce flottement, puisqu'un seul acteur tient les deux bouts.

Le TTL, ou plutôt la valeur qui décide réellement du délai de propagation

Le TTL est une durée en secondes, et non un délai imposé par les registres. La RFC 2181 le définit comme un nombre non signé compris entre zéro et 2 147 483 647. Il indique en conséquence combien de temps un résolveur a le droit de conserver la réponse avant de la redemander.

Par conséquent, la méthode d'une migration propre tient en trois temps. D'abord abaisser le TTL plusieurs heures avant l'opération, ensuite basculer les enregistrements, enfin le remonter une fois la bascule vérifiée. Notons toutefois une limite, car Google indique dans sa foire aux questions que ses caches sont généralement bornés à six heures, même lorsque le TTL annoncé est plus long. Une migration de site internet se prépare de ce fait à l'avance, jamais le jour même.

Exemple de zone minimale pour un domaine de démonstration

Voici une zone réduite mais complète, pour un domaine fictif. Les adresses proviennent du reste des plages de documentation, et les durées sont exprimées en secondes.

Deux détails méritent l'attention. Premièrement, le sous-domaine de messagerie porte un A et non un alias, précisément afin de rester une cible MX valide. Deuxièmement, les NS portent un TTL plus long que les autres lignes, car ils changent rarement et leur mise en cache soulage la chaîne entière.

Acteurs

Les registrars en France : qui vend, qui gère, qui arbitre

Le vocabulaire du marché entretient une confusion utile à certains. Trois rôles distincts existent pourtant, et les mélanger conduit à s'adresser au mauvais interlocuteur le jour d'un incident.

La différence entre registre, bureau d'enregistrement et hébergeur DNS

Le registre gère l'extension, le bureau d'enregistrement vend le nom, l'hébergeur DNS sert la zone. Pour le .fr, l'Afnic tient le registre et accrédite elle-même les bureaux d'enregistrement, en vertu du droit français. En revanche, l'accréditation ICANN, souvent citée comme gage universel, concerne les extensions génériques et non le .fr.

Ces trois rôles se cumulent fréquemment chez un même prestataire, ce qui simplifie la facturation mais masque la répartition des responsabilités. Dès lors qu'ils sont séparés, il faut savoir lequel contacter, sous peine de perdre plusieurs heures lors d'une panne de site internet.

Choisir un bureau d'enregistrement et anticiper un éventuel transfert

Plusieurs acteurs couvrent globalement le marché français. Le tableau suivant en présente quatre, avec ce qu'il faut surveiller dans chaque cas.

Un transfert ne s'improvise pas. Pour les extensions génériques, la politique de transfert de l'ICANN impose en effet un verrouillage de soixante jours après un changement de titulaire, et elle autorise le refus d'un transfert demandé dans les soixante jours suivant la création du nom. Ainsi, mieux vaut transférer avant d'engager une refonte, jamais pendant.

Cas particulier

La recherche inversée : quand on part de l'adresse IP

La résolution inverse part d'une adresse IP et cherche le nom associé. Elle repose de ce fait sur une arborescence dédiée et sur un type d'enregistrement unique.

Les domaines in-addr.arpa et ip6.arpa, puis l'enregistrement PTR

La recherche inversée n'est pas la lecture à l'envers d'un enregistrement A. La RFC 1035 définit en effet le domaine in-addr.arpa pour la correspondance d'une adresse vers un nom, l'équivalent IPv6 étant ip6.arpa. L'adresse y est écrite à l'envers, puis complétée par le suffixe.

L'enregistrement qui porte la réponse est le PTR. Toutefois, une zone inverse se gère chez l'opérateur qui détient le bloc d'adresses, c'est-à-dire chez votre hébergeur ou chez votre fournisseur d'accès. En d'autres termes, vous ne pouvez pas créer un PTR depuis l'interface de votre registrar.

Ce que la résolution inverse conditionne réellement pour la messagerie

Un serveur de messagerie sans PTR cohérent voit ses envois dégradés. De nombreux filtres vérifient de fait que le nom annoncé par le serveur expéditeur correspond bien au PTR de son adresse IP. Cette vérification est ancienne, mais elle reste appliquée.

En revanche, le PTR ne remplace ni SPF, ni DKIM, ni DMARC. De fait, il constitue un signal parmi d'autres, et son absence explique rarement à elle seule une mise en quarantaine. Pour des envois en volume, une configuration complète s'impose également, comme celle mise en place lors d'un projet de newsletter et emailing.

Dépannage

Diagnostiquer une panne : la méthode en quatre contrôles

Terminons par la méthode. Une panne attribuée au DNS se tranche en quelques vérifications, et l'ordre de ces vérifications évite justement de perdre du temps.

Les quatre contrôles à mener, et dans cet ordre précis

Commencez toujours par les NS publiés, plutôt que par l'enregistrement suspect. En premier lieu, vérifiez quels serveurs font autorité pour le domaine. En second lieu, interrogez directement l'un d'eux, ce qui court-circuite tous les caches intermédiaires.

Ensuite, comparez cette réponse avec celle d'un résolveur public. Si les deux diffèrent, le problème est un cache non encore expiré, c'est-à-dire une question de patience. Enfin, lorsque les deux concordent et restent fausses, la zone elle-même est en cause, et la correction se fait à la source. Un dispositif de monitoring et maintenance détecte du reste ces écarts avant vos visiteurs.

Les trois erreurs que l'on retrouve le plus souvent sur le terrain

La première est le TTL laissé à une valeur élevée avant une bascule. La deuxième est l'alias posé à la racine du domaine, que l'interface accepte parfois sans avertir, alors qu'il produit ensuite des réponses incohérentes. La troisième est la zone modifiée au mauvais endroit, à savoir chez le registrar quand les NS pointent ailleurs.

À ces trois cas s'ajoute une situation plus sournoise. En effet, un domaine expiré continue de répondre tant que les caches n'ont pas expiré, si bien que la panne semble arriver plusieurs jours après l'événement réel. C'est pourquoi la date d'expiration mérite une surveillance au même titre qu'un certificat, notamment au sein d'un audit technique périodique.

Sur le terrain

Cas d'usage

• Abaisser d'abord le TTL des enregistrements A, deux jours avant une migration de serveur.
• Vérifier ensuite quels serveurs de noms font autorité, sinon la zone sera modifiée sans aucun effet.
• Déclarer également SPF, DKIM et DMARC lors de la mise en place d'une messagerie professionnelle.
• Surveiller enfin la date d'expiration du domaine, car une expiration coupe le site et le courrier.

Vos questions

Questions fréquentes

Combien de temps dure réellement la propagation DNS ?

La durée dépend du TTL de l'enregistrement modifié, et de rien d'autre. Un TTL de 3 600 secondes signifie par conséquent qu'un résolveur ayant déjà la réponse la conservera au maximum une heure. Autrement dit, la propagation n'est pas un délai administratif imposé par un registre.

Toutefois, deux facteurs allongent cette durée. D'une part, certains résolveurs appliquent leurs propres bornes, et Google indique borner généralement ses caches à six heures. D'autre part, les caches du navigateur et du système s'ajoutent à celui du résolveur, si bien que l'utilisateur ressent un retard supplémentaire.

Pourquoi ne peut-on pas mettre un CNAME à la racine du domaine ?

Parce que la RFC 2181 interdit à un nom porteur d'alias de porter d'autres données, hors enregistrements de signature. Or la racine d'une zone porte obligatoirement son SOA et ses NS. Ces deux règles sont incompatibles, si bien que l'alias y devient impossible.

Plusieurs hébergeurs proposent cependant un contournement sous des appellations variées, qui consiste à résoudre l'alias de leur côté et à répondre un A. Cela fonctionne, mais cela vous lie à ce prestataire, puisque le mécanisme n'appartient pas au standard et ne se transfère donc pas tel quel.

Faut-il activer DNSSEC sur un simple site vitrine ?

Ce n'est pas indispensable, et il serait malhonnête de le présenter comme une urgence. En effet, DNSSEC protège contre la falsification des réponses, un risque réel quoique peu fréquent sur un site institutionnel sans transaction ni authentification.

En revanche, il devient pertinent dès qu'un domaine porte de la messagerie professionnelle ou des accès à des outils internes. Notons cependant un effet de bord, car une signature mal renouvelée rend le domaine injoignable, alors qu'une absence de signature ne casse rien. Le dispositif exige donc une surveillance.

Quelle différence entre un serveur DNS et un hébergeur web ?

Le serveur DNS publie l'adresse, tandis que l'hébergeur web sert les pages. Les deux fonctions sont souvent vendues ensemble, mais elles restent techniquement indépendantes. De fait, vous pouvez conserver votre hébergeur DNS actuel tout en changeant d'hébergeur web, et l'inverse est vrai également.

Cette indépendance a une conséquence pratique lors d'une refonte. Puisque la zone peut rester en place, la bascule se limite à modifier les enregistrements A et AAAA, ce qui réduit fortement le risque. Le choix d'un prestataire se prépare en amont, comme l'explique par ailleurs l'article consacré au fait de choisir son hébergeur.

Mon site est inaccessible, comment savoir si le DNS est en cause ?

Un test simple tranche généralement la question. Lorsque le site répond en joignant directement son adresse IP, le contenu est servi et le problème se situe dans la résolution du nom. À l'inverse, si l'adresse IP ne répond pas davantage, le DNS est hors de cause.

Ce test a cependant une limite qu'il faut connaître. En effet, un serveur mutualisé n'affiche pas votre site quand on l'interroge par son adresse IP, car il distingue les sites par le nom demandé. Dans ce cas, seule l'interrogation directe des serveurs faisant autorité permet de conclure, ce que couvre une prestation de support et gestion d'urgence.

Faut-il changer de résolveur DNS pour accélérer sa navigation ?

Le gain existe, mais il reste modeste et il ne concerne que la première connexion à un domaine non encore mis en cache. Globalement, un résolveur public rapide économise quelques dizaines de millisecondes par domaine inédit, ce qui se remarque peu sur un site déjà visité.

En revanche, ce changement a des effets qui dépassent largement la vitesse. Il modifie le filtrage appliqué, il déplace la visibilité de votre trafic vers un autre acteur, et enfin il peut contourner des restrictions internes à une entreprise. Ces conséquences méritent d'être arbitrées avant la bascule, car elles n'améliorent en rien les performances du site lui-même.