DNS : relier votre domaine à votre VPS

Qu’est-ce que le DNS et pourquoi votre domaine n’atteint-il pas encore votre VPS ?

Le DNS (Domain Name System) convertit un nom comme example.com en adresse IP (Internet Protocol) comme 203.0.113.10. Un navigateur ne peut pas se connecter à un nom. Il se connecte à une adresse. Chaque chargement de page commence donc par une requête DNS et une réponse. Si vous venez d’acheter un domaine et un VPS à vous, et que rien ne se charge, deux situations sont possibles : aucun enregistrement ne relie encore le nom à l’adresse de votre serveur, ou un enregistrement existe, mais un élément du chemin fournit encore une ancienne réponse.

Ces deux situations sont normales. Elles ne signifient pas qu’un élément est défaillant. Les sections ci-dessous présentent les éléments dans l’ordre où vous les rencontrerez, en commençant par celui qui fait perdre le plus de temps : quel panneau de contrôle contient réellement vos enregistrements.

Toutes les vérifications présentées ici utilisent dig, qui n’est pas installé par défaut sur une machine Ubuntu ou Debian fraîchement installée.

sudo apt update && sudo apt install -y bind9-dnsutils

Registrar, nameservers, hébergeur DNS : lequel modifier ?

Ces trois termes désignent des fonctions différentes. Les confondre est la raison la plus fréquente pour laquelle une modification ne change rien.

• Le registrar est l’entreprise auprès de laquelle vous avez acheté le domaine. Sa fonction essentielle est la délégation : il indique au registre qui gère votre TLD (domaine de premier niveau, la partie .com) quels nameservers font autorité pour votre domaine.
• Les nameservers faisant autorité contiennent les enregistrements réels de votre zone. Une zone correspond à votre domaine et aux noms qui en dépendent.
• L’hébergeur DNS est l’opérateur de ces nameservers. Il peut s’agir du registrar, d’un fournisseur distinct ou de bind9 exécuté sur un serveur que vous contrôlez.

Vous achetez le domaine auprès du registrar. Vous le modifiez chez l’hébergeur DNS. Si vous avez délégué votre domaine aux nameservers d’un autre fournisseur, le panneau DNS du registrar affiche toujours une zone, enregistre toujours vos modifications, mais personne sur Internet ne consulte jamais cette zone. Les enregistrements sont réels. Ils ne sont simplement jamais utilisés.

Déterminez où les requêtes sont réellement envoyées :

dig example.com NS +short
dig +trace example.com

La première commande affiche les nameservers qui répondent actuellement pour le domaine. La seconde remonte la chaîne depuis les serveurs racine et affiche la délégation fournie par les serveurs du TLD, c’est-à-dire la délégation contrôlée par votre registrar. Si ces noms appartiennent à un fournisseur que vous ne reconnaissez pas, c’est le panneau de ce fournisseur que vous devez utiliser.

Comment une seule résolution DNS se déroule

Quatre parties interviennent, et chacune conserve une copie de ce qu’elle apprend.

1. Le stub resolver de votre machine. Il n’effectue aucune recherche. Il interroge un seul serveur configuré et fait confiance à la réponse. Sur Ubuntu, /etc/resolv.conf est généralement un lien symbolique vers /run/systemd/resolve/stub-resolv.conf et désigne 127.0.0.53, qui est systemd-resolved exécuté localement avec son propre cache.
2. Le recursive resolver. Il s’agit du resolver de votre FAI (fournisseur d’accès à Internet), d’un resolver public tel que 1.1.1.1, ou d’un resolver que vous exécutez vous-même. Il effectue la recherche nécessaire pour trouver la réponse.
3. Les serveurs root et TLD. Le recursive resolver interroge un serveur root. Celui-ci ne connaît pas votre adresse, mais répond en renvoyant vers les serveurs .com. Ces derniers renvoient vers vos nameservers.
4. Le authoritative nameserver. Il n’interroge aucun autre serveur. Il répond à partir de votre zone et marque la réponse comme faisant autorité.

dig +trace example.com vous montre ce déroulement. Il commence directement à la racine et affiche chaque renvoi au lieu d’interroger un cache. C’est le moyen le plus rapide de vérifier que la délégation et la zone concordent.

Les enregistrements DNS importants lorsque vous exploitez un serveur

• A : associe un nom à une adresse IPv4. example.com. A 203.0.113.10. C’est l’enregistrement qui dirige votre domaine vers votre VPS.
• AAAA : associe un nom à une adresse IPv6, par exemple 2001:db8::10. Publiez-le uniquement si votre service écoute réellement sur cette adresse. Les clients des réseaux IPv6 essaient d’abord la réponse AAAA. Une adresse qui ne répond pas ajoute donc un délai à chaque visite.
• CNAME : crée un alias d’un nom vers un autre nom. www.example.com. CNAME example.com. redirige les visiteurs de www vers la cible vers laquelle résout le domaine racine. Un CNAME ne peut pas être utilisé à l’apex (le example.com racine), car celui-ci doit contenir ses propres enregistrements SOA (start of authority) et NS. De plus, un CNAME ne peut pas partager son nom avec un autre enregistrement. Les fournisseurs proposent des solutions de contournement appelées ALIAS, ANAME ou CNAME flattening.
• MX : indique où les e-mails du domaine sont remis. Il contient un hostname et un nombre de préférence. Le nombre le plus faible est essayé en premier. Un MX doit pointer vers un nom qui possède un enregistrement d’adresse. Pointer vers un CNAME est invalide et certains serveurs d’envoi le rejettent.
• TXT : contient du texte libre utilisé pour les preuves et les règles. Les enregistrements d’authentification des e-mails (SPF, DKIM, DMARC) y sont stockés, tout comme le token ACME (automatic certificate management environment) qui permet d’émettre un certificat wildcard.
• NS : indique quels nameservers servent la zone. La copie qui détermine où le monde extérieur effectue ses requêtes se trouve dans la zone parente et provient de la délégation de votre registrar, pas de la copie située dans votre propre zone.

Deux détails causent davantage de confusion que les types d’enregistrements eux-mêmes. Un nom qui se termine par un point est absolu. Ainsi, www.example.com. désigne exactement ce nom, et rien de plus. La plupart des panels attendent un nom relatif et ajoutent le domaine automatiquement. Saisir www.example.com dans le champ du nom produit donc www.example.com.example.com, qui ne résout pour personne. L’autre détail concerne @, qui désigne l’apex dans presque tous les panels : le domaine seul, sans sous-domaine.

Pointez un enregistrement A vers votre VPS

Commencez par obtenir l’adresse que voit Internet pour votre serveur :

curl -4 https://ifconfig.me
ip -brief -4 address show

Créez ensuite un enregistrement chez votre hébergeur DNS : type A, nom @, valeur correspondant à cette adresse, TTL (durée de vie) 300. Ajoutez un second enregistrement pour www : soit un autre enregistrement A avec la même adresse, soit un enregistrement CNAME pointant vers l’apex.

Vérifiez ensuite sa résolution, idéalement depuis votre ordinateur portable plutôt que depuis le serveur lui-même :

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

La première commande utilise le chemin réseau habituel de votre machine, caches compris. La deuxième ignore votre cache local et interroge un résolveur récursif public. La troisième interroge directement votre serveur de noms faisant autorité. Sa réponse correspond donc à la valeur actuelle, sans cache sur le chemin. Si la troisième commande renvoie votre adresse alors que la première ne la renvoie pas, votre DNS est correctement configuré. Vous devez simplement attendre l’expiration d’une copie en cache de l’ancienne réponse.

La résolution ne charge rien

La résolution d’un nom prouve que le DNS fonctionne. Elle ne prouve rien concernant votre serveur web. Une fois que dig renvoie la bonne adresse, testez la connexion :

curl -I http://example.com

curl: (6) Could not resolve host: example.com est un problème DNS. curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused n’est pas un problème DNS : le nom a été résolu et le paquet est arrivé. Le problème vient donc du fait qu’aucun service n’écoutait sur ce port. Une requête qui reste bloquée puis expire signifie généralement qu’un pare-feu a ignoré le paquet sans répondre, au lieu de refuser la connexion. C’est à ce moment que le DNS cesse d’être le sujet, et que les ports et les sockets en écoute ainsi que les règles du pare-feu ufw sur votre VPS prennent le relais. Une fois la connexion établie, le reste du chargement de la page relève de HTTP qui traite la requête.

Pourquoi le navigateur affiche encore l’ancien hôte

Rien ne se propage. Aucun serveur n’envoie votre modification aux autres. Votre serveur de noms faisant autorité contient la nouvelle valeur dès que vous l’enregistrez, et chaque copie en cache de l’ancienne réponse reste valide jusqu’à l’expiration de son propre délai. Ce délai est le TTL, en secondes, indiqué par l’enregistrement lorsqu’il a été distribué.

Les copies se trouvent dans plus d’endroits qu’on ne le pense : le cache local du navigateur, le stub resolver de la machine, le resolver récursif utilisé par ce réseau et tout resolver installé par un VPN sur le client. Chacun conserve sa copie pendant une durée maximale égale au TTL reçu. Deux personnes connectées à deux réseaux différents peuvent voir deux réponses différentes pendant plusieurs heures, et les deux machines fonctionnent correctement.

Surveillez le compte à rebours avec un resolver qui utilise le cache :

dig @1.1.1.1 example.com +noall +answer

Exécutez la commande deux fois, à quelques secondes d’intervalle. Le TTL de la réponse diminue. Lorsqu’il atteint zéro, le resolver supprime l’enregistrement et interroge de nouveau votre serveur de noms.

Il existe un deuxième cache dont presque personne ne tient compte : les réponses négatives. Lorsqu’un resolver apprend qu’un nom n’existe pas, il met également cette réponse NXDOMAIN en cache, pendant la durée définie par le dernier champ de l’enregistrement SOA de votre zone.

dig example.com SOA +short

Le dernier nombre de cette ligne est le TTL négatif, souvent 3600. Ainsi, rechercher staging.example.com avant de le créer peut masquer l’enregistrement pendant une heure complète après sa création. Créez d’abord l’enregistrement, puis interrogez-le.

Changer de serveur de noms est plus lent que modifier un enregistrement, pour une raison purement mécanique. Les enregistrements de délégation de la zone .com sont servis avec un TTL de 172800 secondes, soit deux jours. Un resolver qui a mis en cache vos anciens serveurs de noms peut donc continuer à les interroger pendant cette durée. C’est l’origine du conseil « prévoyez jusqu’à 48 heures ». Il concerne les changements de serveurs de noms, pas les modifications ordinaires d’enregistrements.

Planifiez une migration en fonction du TTL au lieu de lutter contre lui :

1. Réduisez le TTL de l’enregistrement à 300 et enregistrez la modification.
2. Attendez plus longtemps que l’ancien TTL, afin que toutes les copies en cache contenant l’ancienne valeur aient expiré.
3. Modifiez l’adresse.
4. Une fois le trafic basculé, rétablissez le TTL à 3600 ou plus, car un TTL faible oblige chaque resolver à interroger vos serveurs de noms beaucoup plus souvent.

Pour vider ce que votre propre machine conserve :

resolvectl flush-caches
resolvectl statistics

resolvectl statistics affiche une section de cache avec des compteurs de réussites et d’échecs. Juste après un flush, la requête suivante apparaît donc comme un échec de cache. Les navigateurs disposent d’un cache distinct. Chrome peut ainsi encore utiliser une ancienne réponse après la vidange du cache système. Videz également ce cache dans chrome://net-internals/#dns. Vérifiez aussi /etc/hosts, car une ligne résiduelle à cet endroit prend le pas sur DNS sur cette machine, et uniquement sur cette machine. getent hosts example.com affiche la réponse que le système utilisera réellement, y compris /etc/hosts.

Les certificats wildcard sont validés par un enregistrement TXT

Une CA (autorité de certification) vérifie le contrôle d’un nom avant de délivrer un certificat. Le challenge HTTP-01 publie un fichier sur le port 80 pour ce nom d’hôte précis, ce qui convient bien à un nom unique. Un certificat wildcard couvre *.example.com, c’est-à-dire un ensemble potentiellement illimité de noms d’hôte depuis lesquels la CA ne peut pas récupérer de fichier. Let’s Encrypt délivre donc les certificats wildcard uniquement avec le challenge DNS-01. Vous publiez un enregistrement TXT à l’emplacement _acme-challenge.example.com, avec un token fourni par la CA. Le contrôle de la zone DNS constitue la preuve.

Votre hébergeur DNS intervient donc dans le renouvellement du certificat. Certbot doit créer et supprimer cet enregistrement TXT à chaque renouvellement, sans intervention de votre part. Il a donc besoin d’une API et du plugin correspondant pour votre fournisseur. Lorsque la validation échoue, le message habituel est DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com. Cela signifie que la CA a effectué sa vérification avant que l’enregistrement soit visible : soit il n’a jamais été enregistré, soit une réponse négative était encore en cache. La procédure complète se trouve dans le guide des certificats wildcard avec le challenge DNS-01.

Quand un VPN prend le contrôle de votre résolveur

Un client VPN (virtual private network) remplace généralement le résolveur du système pendant la connexion. Sinon, les requêtes seraient envoyées au réseau local, qui pourrait connaître le nom de chaque site que vous consultez. Ce comportement est normal, mais deux problèmes peuvent se produire.

Si le tunnel est établi et que les noms ne sont plus résolus alors que les adresses restent accessibles, le résolveur installé par le client est inaccessible depuis le tunnel. ping 1.1.1.1 réussit et curl https://example.com renvoie curl: (6) Could not resolve host: example.com. Si, au contraire, le tunnel est établi mais que les requêtes continuent d’être envoyées au réseau auquel vous êtes connecté, votre trafic passe dans le tunnel tandis que le résolveur local continue de voir chaque nom demandé.

resolvectl status

Cette commande affiche le résolveur utilisé pour chaque liaison. Vous pouvez ainsi vérifier celui que le tunnel a installé et confirmer qu’il s’agit bien de celui attendu. Un tunnel WireGuard définit ce résolveur à partir de la ligne DNS = dans la configuration du client. L’article corriger le DNS lorsque WireGuard prend le contrôle du résolveur détaille les cas systemd-resolved et resolvconf.

Les codes de réponse et ce qu’ils indiquent

• NXDOMAIN : un serveur faisant autorité indique que le nom n’existe pas. Vérifiez l’orthographe, la présence éventuelle d’un suffixe de domaine en double et le fait que vous avez bien modifié la zone vers laquelle pointe votre délégation.
• NOERROR avec un ANSWER SECTION vide : le nom existe, mais il ne possède aucun enregistrement du type demandé. Demander un AAAA alors que seul un A existe produit exactement ce résultat.
• SERVFAIL : le resolver a tenté de produire une réponse, mais n’y est pas parvenu. Les deux causes habituelles sont des serveurs faisant autorité qui ne répondent jamais et un échec de la validation DNSSEC (domain name system security extensions). Testez avec dig @1.1.1.1 example.com A +cd, qui désactive la validation. Si vous obtenez alors une réponse avec +cd et SERVFAIL, le problème vient des signatures. Cela se produit après un changement de nameserver lorsque le parent publie encore l’ancien enregistrement DS (delegation signer).
• REFUSED : le serveur interrogé ne répondra pas à cette question, généralement parce que vous avez configuré dig vers un serveur faisant autorité pour un domaine qu’il ne sert pas.
• ;; connection timed out; no servers could be reached : dig n’a jamais atteint de resolver. Le problème concerne votre réseau ou votre resolver local, pas le domaine.

ping: example.com: Temporary failure in name resolution correspond à la même catégorie d’échec, mais signalée par glibc plutôt que par dig.

Faut-il exécuter des serveurs DNS sur votre propre VPS ?

C’est possible. bind9, knot ou nsd peuvent servir votre zone depuis le serveur, et cela vous en apprendra davantage sur le DNS que n’importe quel panel. Les objections sont d’ordre pratique. Un domaine doit avoir au moins deux serveurs DNS sur des réseaux distincts. Un seul VPS devient donc un point de défaillance unique pour tous les services du domaine, y compris la messagerie. Les serveurs DNS dont le nom appartient au domaine qu’ils servent ont besoin d’enregistrements glue chez le registrar. Il s’agit de l’adresse de ns1.example.com enregistrée dans la zone parente. Sans cela, la résolution ne peut pas démarrer. Lorsqu’un resolver ne peut pas joindre votre serveur DNS, il ne se rabat pas sur votre site web : le domaine entier devient inaccessible pour cet utilisateur. Pour la plupart des utilisateurs, un service DNS hébergé avec une API est le choix le moins risqué. Exécuter un resolver cache sur votre VPS pour vos propres machines est un autre usage, qui implique un engagement bien moindre.

FAQ

Pourquoi ma modification DNS n’est-elle pas encore propagée ?

Rien ne se propage. Vos serveurs de noms faisant autorité détiennent la nouvelle valeur dès que vous l’enregistrez, et chaque resolver qui l’a déjà demandée conserve sa copie en cache jusqu’à l’expiration du TTL reçu. Interrogez directement le serveur faisant autorité avec dig @ns1.your-dns-host.net example.com A +short. S’il renvoie la nouvelle adresse, la modification est effective et seul le cache reste à attendre. Si vous avez modifié les serveurs de noms plutôt que les enregistrements, prévoyez un délai beaucoup plus long, car les délégations des TLD sont distribuées avec un TTL de deux jours.

Comment savoir quels serveurs de noms mon domaine utilise réellement ?

dig example.com NS +short affiche les serveurs de noms qui répondent actuellement pour le domaine, et dig +trace example.com affiche la chaîne de délégation depuis la racine, y compris la délégation fournie par les serveurs du TLD. Si ces noms ne correspondent pas au fournisseur dont vous avez modifié le panneau, c’est la cause du problème. Modifiez les enregistrements chez le fournisseur indiqué dans la délégation, ou modifiez la délégation chez votre registrar pour qu’elle pointe vers l’emplacement souhaité.

Mon domaine se résout, mais le site ne se charge toujours pas. Que faire ?

Le DNS est opérationnel dès que dig example.com A +short renvoie l’adresse de votre serveur. Ensuite, le problème concerne la connexion. Si curl -I http://example.com renvoie Connection refused, cela signifie que rien n’écoute sur ce port. Une requête qui reste bloquée jusqu’à expirer indique qu’un firewall a rejeté le paquet. Vérifiez que votre serveur web fonctionne et écoute sur l’adresse publique, puis contrôlez le firewall du serveur et le firewall réseau distinct disponible dans le panneau de contrôle de votre fournisseur.

Pourquoi ne puis-je pas placer un CNAME sur mon domaine racine ?

Un CNAME indique qu’un nom est un alias d’un autre nom. Un nom qui possède un CNAME ne peut contenir aucun autre enregistrement. Votre domaine racine doit contenir des enregistrements SOA et NS pour exister en tant que zone. Il ne peut donc pas être également un CNAME. Utilisez un enregistrement A contenant l’adresse au niveau racine, ou utilisez la fonctionnalité proposée par le fournisseur sous les noms ALIAS, ANAME ou CNAME flattening. Elle stocke un nom et répond aux requêtes avec l’adresse vers laquelle ce nom se résout actuellement.