Fenix par Takeda11
Beaucoup de gens ne savent pas comment mettre à jour les enregistrements DNS lorsqu'ils changent l'adresse IP de leur site. Pourquoi ces enregistrements sont-ils mis à jour lentement? Avez-vous vraiment besoin d'attendre deux jours pour que tout soit mis à jour? Pourquoi certains visiteurs voient-ils la nouvelle adresse IP, tandis que d'autres voient l'ancienne?
L'équipe de Mail.ru Cloud Solutions atraduit un article du développeur et auteur d'articles Julia Evans, dans lequel elle répond à ces questions et raconte généralement ce qui se passe lors d'une mise à jour DNS d'un point de vue frontal.
Voici une exploration rapide de ce qui se passe dans les coulisses lorsque vous mettez à jour un enregistrement DNS.
Fonctionnement du DNS: serveurs DNS récursifs et faisant autorité
Tout d'abord, nous devons expliquer un peu le système DNS. Il existe deux types de serveurs DNS: faisant autorité et récursifs . Les serveurs DNS faisant
autorité (également appelés serveurs de noms ) maintiennent une base de données d'adresses IP pour chaque domaine dont ils sont responsables. Par exemple, actuellement, le serveur DNS faisant autorité pour github.com est
ns-421.awsdns-52.com. Vous pouvez lui demander l'adresse IP de github.com avec cette demande:
dig @ns-421.awsdns-52.com github.com
Les serveurs DNS récursifs eux-mêmes ne savent rien sur qui possède quelle adresse IP. Ils calculent l'adresse IP d'un domaine en l'interrogeant auprès des serveurs DNS faisant autorité appropriés, puis mettent en cache cette adresse IP au cas où on leur demanderait à nouveau. Donc 8.8.8.8 est un serveur DNS récursif.
Lorsque les gens visitent votre site Web, ils effectuent probablement des recherches DNS sur un serveur DNS récursif. Alors, comment fonctionnent les serveurs DNS récursifs? Jetons un coup d'oeil!
Comment un serveur DNS récursif interroge l'adresse IP de github.com
Voyons un exemple de ce que fait un serveur DNS récursif (par exemple 8.8.8.8) lorsque vous lui demandez l'adresse IP (enregistrement A) pour github.com. Premièrement, s'il a déjà un résultat mis en cache, il le délivrera. Mais que faire si tous les caches sont expirés? Voici ce qui se passe.
Étape 1 : Les adresses IP des serveurs DNS racine sont codées en dur dans leur code source. Vous pouvez le voir dans le code source indépendant . Disons qu'il sélectionne 198.41.0.4 pour commencer. Voici la source officielle de ces adresses IP codées en dur, également connues sous le nom de «fichier d'indices de racine».
Étape 2 : interrogez les serveurs de noms root sur github.com.
Nous pouvons reproduire grossièrement ce qui se passe avec la commande
dig... Cela nous donne un nouveau serveur de noms faisant autorité à demander: un serveur de noms pour .comavec une adresse IP de 192.5.6.30.
$ dig @198.41.0.4 github.com
...
com. 172800 IN NS a.gtld-servers.net.
...
a.gtld-servers.net. 172800 IN A 192.5.6.30
...
Les détails de la réponse DNS sont un peu plus compliqués - dans ce cas, il existe une section d'autorité avec certains enregistrements NS et une section supplémentaire avec des enregistrements A, vous n'avez donc pas besoin de faire une recherche supplémentaire pour obtenir les adresses IP de ces serveurs de noms.
En pratique, 99,99% du temps, il y aura déjà une adresse de serveur de noms en cache
.com, mais nous prétendons que nous partons vraiment de zéro.
Étape 3 :
.comRenseignez-vous sur github.com aux serveurs de noms .
$ dig @192.5.6.30 github.com
...
github.com. 172800 IN NS ns-421.awsdns-52.com.
ns-421.awsdns-52.com. 172800 IN A 205.251.193.165
...
Nous avons une nouvelle adresse IP pour envoyer la demande! C'est l'un des serveurs de noms de github.com.
Étape 4 : Demandez aux serveurs de noms github.com l'adresse github.com.
Nous avons presque fini!
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
Nous avons donc un enregistrement A pour github.com. Le serveur récursif a maintenant l'adresse IP github.com et peut vous la renvoyer. Et il a pu parcourir tout le processus, en commençant par seulement quelques adresses IP codées en dur: les adresses des serveurs de noms racine.
Comment voir toutes les étapes d'un serveur DNS récursif: dig + trace
Pour voir ce que le serveur DNS récursif fera pour résoudre le domaine, vous pouvez exécuter:
$ dig @8.8.8.8 +trace github.com
Cette commande affiche tous les enregistrements DNS que le serveur récursif demande, en commençant par les serveurs DNS racine, ce qui correspond aux quatre étapes que nous venons de franchir.
Mettre à jour les enregistrements DNS
Maintenant que nous connaissons les bases du fonctionnement du DNS, mettons à jour certains enregistrements DNS et voyons ce qui se passe.
Lors de la mise à jour des enregistrements DNS, il existe deux options principales:
- garder les mêmes serveurs de noms;
- changer les serveurs de noms.
Parlons TTL
Mais nous avons oublié quelque chose d'important. C'est TTL. Comme nous l'avons dit précédemment, un serveur DNS récursif mettra en cache les enregistrements jusqu'à leur expiration. Il décide si un enregistrement expire en fonction de son TTL (time to live).
Dans cet exemple, le serveur de noms GitHub renvoie un TTL de 60 pour son enregistrement DNS, ce qui signifie 60 secondes:
$ dig @205.251.193.165 github.com
github.com. 60 IN A 140.82.112.4
C'est un TTL assez court. En théorie, si toutes les implémentations DNS suivaient la norme DNS , cela signifierait que si GitHub décidait de changer l'adresse IP de github.com, tout le monde recevrait une nouvelle adresse IP dans les 60 secondes. Voyons comment cela se passe dans la pratique.
Option 1: mettre à jour l'enregistrement DNS sur les mêmes serveurs de noms
Tout d'abord, j'ai mis à jour mes serveurs de noms (Cloudflare) pour obtenir un nouvel enregistrement DNS, l'enregistrement A, qui correspond
test.jvns.caà 1.2.3.4:
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 299 IN A 1.2.3.4
Cela a fonctionné immédiatement! Il n'était pas du tout nécessaire d'attendre, car avant cela, il n'y avait pas d'enregistrement DNS
test.jvns.caqui pouvait être mis en cache. Excellent. Mais il semble que le nouvel enregistrement soit mis en cache pendant environ cinq minutes (299 secondes).
Alors que faire si nous essayons de changer cette adresse IP? Je l'ai changé en 5.6.7.8 puis j'ai exécuté la même requête DNS:
$ dig @8.8.8.8 test.jvns.ca
test.jvns.ca. 144 IN A 1.2.3.4
Il semble que sur ce serveur DNS, l'enregistrement 1.2.3.4 soit toujours mis en cache pendant 144 secondes. Fait intéressant, si vous interrogez 8.8.8.8 plusieurs fois, vous obtiendrez des résultats contradictoires - parfois cela vous donnera une nouvelle adresse IP et parfois une ancienne. Le 8.8.8.8 distribue probablement la charge sur un tas de backends différents, chacun avec son propre cache.
Après cinq minutes d'attente, tous les caches 8.8.8.8 ont été mis à jour et renvoyaient toujours une nouvelle entrée 5.6.7.8. Incroyable. C'est assez rapide!
Vous ne pouvez pas toujours compter sur TTL
Comme avec la plupart des protocoles Internet, tout ne suit pas les spécifications DNS. Certains serveurs DNS ISP mettront en cache les enregistrements pendant plus longtemps que la durée de vie spécifiée. Par exemple, dans les deux jours au lieu de cinq minutes. Et les gens peuvent toujours coder en dur l'ancienne adresse IP dans leur fichier
/etc/hosts.
En pratique, lors de la mise à jour d'un enregistrement DNS avec un TTL de cinq minutes, vous pouvez vous attendre à ce qu'un grand pourcentage de clients passe rapidement à de nouvelles adresses IP (par exemple, dans les 15 minutes), puis il y aura un tas de retardataires qui se mettront à jour lentement au cours des prochains jours.
Option 2: mettre à jour vos serveurs de noms
Ainsi, nous avons vu que lorsque vous renouvelez une adresse IP sans changer vos serveurs de noms, de nombreux serveurs DNS obtiennent une nouvelle adresse IP assez rapidement. Excellent. Mais que se passe-t-il si vous changez vos serveurs de noms? Essayons!
Je ne voulais pas mettre à jour les serveurs de noms de mon blog, j'ai donc choisi un domaine différent du mien et l'ai utilisé dans les exemples du journal HTTP , examplecat.com.
Auparavant, mes serveurs étaient définis sur
dns1.p01.nsone.net. J'ai décidé de les changer en serveurs Google avec des adresses ns-cloud-b1.googledomains.comet ainsi de suite.
Quand j'ai fait le changement, mon registraire de domaine a fait clignoter le message quelque peu inquiétant: «Les modifications apportées à examplecat.com ont été enregistrées. Ils entreront en vigueur dans les 48 prochaines heures. " Ensuite, j'ai créé un nouvel enregistrement A pour le domaine pour qu'il pointe vers 1.2.3.4.
D'accord, voyons si quelque chose a changé:
$ dig @8.8.8.8 examplecat.com
examplecat.com. 17 IN A 104.248.50.87
Aucun changement. Si je demande à un autre serveur DNS, il connaît la nouvelle adresse IP:
$ dig @1.1.1.1 examplecat.com
examplecat.com. 299 IN A 1.2.3.4
Mais 8.8.8.8 ne sait toujours rien. La raison pour laquelle 1.1.1.1 voit une nouvelle adresse IP même si je viens de la changer il y a cinq minutes est probablement parce que personne n'a jamais demandé à 1.1.1.1 à propos de cet examplecat.com auparavant - donc il n'a rien dans son cache C'était.
Les serveurs de noms ont beaucoup plus de TTL
La raison pour laquelle mon registraire a dit: «Cela prendra 48 heures», c'est parce que le TTL sur les enregistrements NS (à quel serveur de noms le serveur récursif doit accéder) est beaucoup plus grand.
Le nouveau serveur de noms renvoie définitivement une nouvelle adresse IP pour examplecat.com:
$ dig @ns-cloud-b1.googledomains.com examplecat.com
examplecat.com. 300 IN A 1.2.3.4
Mais rappelez-vous ce qui s'est passé lorsque nous avons interrogé les serveurs de noms github.com plus tôt:
$ dig @192.5.6.30 github.com
...
github.com. 172800 IN NS ns-421.awsdns-52.com.
ns-421.awsdns-52.com. 172800 IN A 205.251.193.165
...
172800 secondes, c'est 48 heures! Ainsi, la mise à jour du serveur de noms prend généralement beaucoup plus de temps. Il faut du temps pour que les caches expirent et propagent la nouvelle adresse. Cela prend beaucoup plus de temps que de simplement mettre à jour votre adresse IP sans changer votre serveur de noms.
Comment vos serveurs de noms sont mis à jour
Lorsque je mets à jour les serveurs de noms pour
examplecat.com, le serveur de noms .comobtient un nouvel enregistrement NS avec un nouveau domaine. Comme ça:
dig ns @j.gtld-servers.net examplecat.com
examplecat.com. 172800 IN NS ns-cloud-b1.googledomains.com
Mais comment ce nouveau record NS y parvient-il? En fait, je dis à mon registraire de domaine à quoi je veux que les nouveaux serveurs de noms ressemblent en les mettant à jour sur le site Web, puis mon registraire de domaine dit aux serveurs
.comde noms de faire la mise à jour.
Car
.comces mises à jour sont assez rapides (en quelques minutes), mais je pense que pour certaines autres zones TLD, les serveurs de noms peuvent ne pas appliquer les mises à jour aussi rapidement.
La bibliothèque de résolution DNS de votre programme peut également mettre en cache les enregistrements DNS
Une autre raison pour laquelle le TTL peut ne pas être observé dans la pratique est que de nombreux programmes doivent résoudre les noms DNS, et certains programmes mettront également en cache les enregistrements DNS en mémoire indéfiniment (jusqu'à ce que le programme soit redémarré).
Par exemple, il existe un article sur la configuration de JVM TTL pour les recherches de noms DNS . Je n'ai pas écrit beaucoup de code JVM pour les recherches DNS moi-même, mais une petite recherche sur Internet sur JVM et DNS donne l'impression que vous pouvez configurer la JVM pour mettre en cache chaque recherche DNS pendant une durée infinie (voir ce ticket ElasticSearch par exemple ) ...
C'est tout!
J'espère que cela vous aidera à comprendre ce qui se passe lorsque vous mettez à jour votre DNS.
Je ferai une réserve que toute l'histoire de la propagation DNS est déterminée non seulement par TTL. Certains serveurs DNS récursifs ne respectent probablement pas les TTL, même les principaux serveurs comme 8.8.8.8. Ainsi, même si vous mettez simplement à jour l'enregistrement A avec un petit TTL, il est possible qu'en pratique, vous receviez toujours des demandes pour l'ancienne adresse IP dans un délai d'un jour ou deux.
Après avoir publié cet article, j'ai changé les serveurs de noms pour examplecat.com à leurs anciennes valeurs.
Quoi d'autre à lire: