En réalité, c’est plus compliqué que cela – plutôt qu’un seul « registre central (qui) contient une table qui fait correspondre les domaines (www.mysite.com) aux serveurs DNS », il y a plusieurs niveaux de hiérarchie.
Il y a un registre central (les serveurs racines) qui ne contient qu’un petit ensemble d’entrées : les enregistrements NS (serveur de noms) pour tous les domaines de premier niveau - .com, .net, .org, .uk, .us, .au, et ainsi de suite.
Ces serveurs ne contiennent que des enregistrements NS pour le niveau suivant. Pour prendre un exemple, les serveurs de noms pour le domaine .uk n’ont que des entrées pour .co.uk, .ac.uk, et les autres zones de second niveau utilisées au Royaume-Uni.
Ces serveurs ne contiennent que des enregistrements NS pour le niveau suivant – pour continuer l’exemple, ils vous indiquent où trouver les enregistrements NS pour google.co.uk. C’est sur ces serveurs que vous trouverez enfin une correspondance entre un nom d’hôte comme www.google.co.uk et une adresse IP.
En guise de complication supplémentaire, chaque niveau servira également des enregistrements « glue ». Chaque enregistrement NS fait correspondre un domaine à un nom d’hôte – par exemple, les enregistrements NS pour .uk listent nsa.nic.uk comme l’un des serveurs. Pour accéder au niveau suivant, nous devons trouver quels sont les enregistrements NS pour nic.uk, et il s’avère qu’ils incluent également nsa.nic.uk. Nous avons donc maintenant besoin de l’IP de nsa.nic.uk, mais pour la trouver nous devons faire une requête à nsa.nic.uk, mais nous ne pouvons pas faire cette requête tant que nous ne connaissons pas l’IP de nsa.nic.uk…
Pour résoudre ce paradoxe, les serveurs pour .uk ajoutent l’enregistrement A de nsa.nic.uk dans la ADDITIONAL SECTION de la réponse (réponse ci-dessous abrégée pour la lisibilité) :
jamezpolley@li101-70:~$dig nic.uk ns
; <<>> DiG 9.7.0-P1 <<>> nic.uk ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21768
;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 14
;; QUESTION SECTION:
;nic.uk. IN NS
;; ANSWER SECTION:
nic.uk. 172800 IN NS nsb.nic.uk.
nic.uk. 172800 IN NS nsa.nic.uk.
;; ADDITIONAL SECTION:
nsa.nic.uk. 172800 IN A 156.154.100.3
nsb.nic.uk. 172800 IN A 156.154.101.3
Sans ces enregistrements glue supplémentaires, nous ne pourrions jamais trouver les serveurs de noms pour nic.uk. et nous ne pourrions donc jamais résoudre les domaines qui y sont hébergés.
Pour revenir à vos questions…
a) Quel est l’avantage ? Pourquoi ne pas faire correspondre directement à une adresse IP ?
D’une part, cela permet de distribuer les modifications de chaque zone individuelle. Si vous voulez mettre à jour l’entrée pour www.mydomain.co.uk, vous n’avez qu’à modifier les informations sur le serveur de noms de votre mydomain.co.uk. Il n’est pas nécessaire de notifier les serveurs centraux .co.uk, ni les serveurs .uk, ni les serveurs de noms racines. S’il n’y avait qu’un seul registre central qui faisait correspondre tous les niveaux de la hiérarchie et qui devait être notifié de chaque changement d’entrée DNS tout au long de la chaîne, il serait absolument submergé de trafic.
Avant 1982, c’était en fait ainsi que la résolution de noms fonctionnait. Un registre central était notifié de toutes les mises à jour, et il distribuait un fichier appelé hosts.txt qui contenait le nom d’hôte et l’adresse IP de chaque machine sur Internet. Une nouvelle version de ce fichier était publiée toutes les quelques semaines, et chaque machine sur Internet devait télécharger une nouvelle copie. Bien avant 1982, cela commençait à devenir problématique, et le DNS a donc été inventé pour fournir un système plus distribué.
D’autre part, ce serait un point unique de défaillance – si le registre central unique tombait en panne, l’Internet tout entier serait hors ligne. Avoir un système distribué signifie que les pannes n’affectent que de petites sections d’Internet, pas l’ensemble.
(Pour fournir une redondance supplémentaire, il y a en fait 13 grappes de serveurs distinctes qui servent la zone racine. Toute modification des enregistrements de domaine de premier niveau doit être poussée vers les 13 ; imaginez devoir coordonner la mise à jour des 13 pour chaque changement de nom d’hôte partout dans le monde…)
b) Si le seul enregistrement qui doit changer lorsque je configure un serveur DNS pour pointer vers une adresse IP différente est situé sur le serveur DNS, pourquoi le processus n’est-il pas instantané ?
Parce que le DNS utilise beaucoup de mise en cache pour à la fois accélérer les choses et diminuer la charge sur les serveurs de noms. Sans mise en cache, chaque fois que vous visiteriez google.co.uk, votre ordinateur devrait aller sur le réseau pour chercher les serveurs pour .uk, puis .co.uk, puis .google.co.uk, puis www.google.co.uk. Ces réponses ne changent pas vraiment beaucoup, donc les chercher à chaque fois est un gaspillage de temps et de bande passante. Au lieu de cela, lorsque le serveur de noms retourne des enregistrements à votre ordinateur, il inclut une valeur TTL, qui indique à votre ordinateur de mettre en cache les résultats pendant un certain nombre de secondes.
Par exemple, les enregistrements NS pour .uk ont un TTL de 172800 secondes – 2 jours. Google est encore plus conservateur – les enregistrements NS pour google.co.uk ont un TTL de 4 jours. Les services qui comptent sur la possibilité de mettre à jour rapidement peuvent choisir un TTL beaucoup plus bas – par exemple, telegraph.co.uk a un TTL de seulement 600 secondes sur ses enregistrements NS.
Si vous voulez que les mises à jour de votre zone soient quasi instantanées, vous pouvez choisir de baisser votre TTL autant que vous le souhaitez. Plus vous le baissez, plus vos serveurs verront de trafic, car les clients rafraîchiront leurs enregistrements plus souvent. Chaque fois qu’un client doit contacter vos serveurs pour faire une requête, cela causera un certain délai car c’est plus lent que de chercher la réponse dans leur cache local, donc vous voudrez aussi considérer le compromis entre des mises à jour rapides et un service rapide.
c) Si la seule raison du délai sont les caches DNS, est-il possible de les contourner, afin que je puisse voir ce qui se passe en temps réel ?
Oui, c’est facile si vous testez manuellement avec dig ou des outils similaires – il suffit de lui indiquer quel serveur contacter.
Voici un exemple de réponse mise en cache :
jamezpolley@host:~$dig telegraph.co.uk NS
; <<>> DiG 9.7.0-P1 <<>> telegraph.co.uk NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36675
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;telegraph.co.uk. IN NS
;; ANSWER SECTION:
telegraph.co.uk. 319 IN NS ns1-63.akam.net.
telegraph.co.uk. 319 IN NS eur3.akam.net.
telegraph.co.uk. 319 IN NS use2.akam.net.
telegraph.co.uk. 319 IN NS usw2.akam.net.
telegraph.co.uk. 319 IN NS use4.akam.net.
telegraph.co.uk. 319 IN NS use1.akam.net.
telegraph.co.uk. 319 IN NS usc4.akam.net.
telegraph.co.uk. 319 IN NS ns1-224.akam.net.
;; Query time: 0 msec
;; SERVER: 97.107.133.4#53(97.107.133.4)
;; WHEN: Thu Feb 2 05:46:02 2012
;; MSG SIZE rcvd: 198
La section flags ici ne contient pas le drapeau aa, nous pouvons donc voir que ce résultat provient d’un cache plutôt que directement d’une source faisant autorité. En fait, nous pouvons voir qu’il provient de 97.107.133.4, qui se trouve être l’un des résolveurs DNS locaux de Linode. Le fait que la réponse ait été servie depuis un cache très proche de moi signifie qu’il a fallu 0 ms pour obtenir une réponse ; mais comme nous le verrons dans un instant, le prix que je paie pour cette rapidité est que la réponse est presque périmée de 5 minutes.
Pour contourner le résolveur de Linode et aller directement à la source, il suffit de choisir l’un de ces serveurs de noms et de dire à dig de le contacter directement :
jamezpolley@li101-70:~$dig @ns1-224.akam.net telegraph.co.uk NS
; <<>> DiG 9.7.0-P1 <<>> @ns1-224.akam.net telegraph.co.uk NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23013
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;telegraph.co.uk. IN NS
;; ANSWER SECTION:
telegraph.co.uk. 600 IN NS use2.akam.net.
telegraph.co.uk. 600 IN NS eur3.akam.net.
telegraph.co.uk. 600 IN NS use1.akam.net.
telegraph.co.uk. 600 IN NS ns1-63.akam.net.
telegraph.co.uk. 600 IN NS usc4.akam.net.
telegraph.co.uk. 600 IN NS ns1-224.akam.net.
telegraph.co.uk. 600 IN NS usw2.akam.net.
telegraph.co.uk. 600 IN NS use4.akam.net.
;; Query time: 9 msec
;; SERVER: 193.108.91.224#53(193.108.91.224)
;; WHEN: Thu Feb 2 05:48:47 2012
;; MSG SIZE rcvd: 198
Vous pouvez voir que cette fois, les résultats ont été servis directement depuis la source – notez le drapeau aa, qui indique que les résultats proviennent d’une source faisant autorité. Dans mon exemple précédent, les résultats provenaient de mon cache local, donc ils n’ont pas le drapeau aa. Je peux voir que la source faisant autorité pour ce domaine définit un TTL de 600 secondes. Les résultats que j’ai obtenus précédemment depuis un cache local avaient un TTL de seulement 319 secondes, ce qui m’indique qu’ils étaient dans le cache depuis (600-319) secondes – presque 5 minutes – avant que je ne les voie.
Bien que le TTL ici ne soit que de 600 secondes, certains FAI tenteront de réduire encore leur trafic en forçant leurs résolveurs DNS à mettre en cache les résultats plus longtemps – dans certains cas, pendant 24 heures ou plus. Il est traditionnel (dans un esprit de prudence du type « nous-ne-savons-pas-si-c’est-vraiment-nécessaire-mais-soyons-prudents ») de supposer que tout changement DNS que vous effectuez ne sera pas visible partout sur Internet pendant 24 à 48 heures.