Pourquoi le DNS fonctionne-t-il comme il le fait?

Ceci est une question canonique sur le DNS (service de noms de domaine).

Si ma compréhension du système DNS est correcte, le registre .com contient un tableau qui mappe les domaines (www.example.com) aux serveurs DNS.

1. Quel est l'avantage? Pourquoi ne pas mapper directement à une adresse IP?

2. Si le seul enregistrement qui doit changer lorsque je configure un serveur DNS pour qu'il pointe vers une adresse IP différente se trouve sur le serveur DNS, pourquoi le processus n'est-il pas instantané?

3. Si les caches DNS sont la seule raison du retard, est-il possible de les contourner afin que je puisse voir ce qui se passe en temps réel?

En fait, c'est plus compliqué que cela - plutôt qu'un "registre central (qui) contient un tableau qui mappe les domaines (www.mysite.com) sur des serveurs DNS", il existe plusieurs niveaux de hiérarchie

Il y a un registre central (les serveurs racine) qui contiennent seulement un petit ensemble d'entrées: les enregistrements NS (nameserver) pour tous les domaines de premier niveau supérieur - .com, .net, .org, .uk, .us, .au, et ainsi de suite.

Ces serveurs ne contiennent que des enregistrements NS pour le niveau suivant. Pour choisir un exemple, les serveurs de noms pour le .ukdomaine vient des entrées pour .co.uk, .ac.uket les autres zones de second niveau en usage 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 google.co.uk. C'est sur ces serveurs que vous trouverez enfin un mappage entre un nom d'hôte www.google.co.uket une adresse IP.

Comme couche supplémentaire, chaque couche servira également des disques "collés". Chaque enregistrement NS mappe un domaine à un nom d'hôte - par exemple, les enregistrements NS pour la .ukliste en nsa.nic.uktant que l'un des serveurs. Pour passer au niveau suivant, nous devons trouver les enregistrements NS nic.uk, et ils se révèlent inclure nsa.nic.ukégalement. Alors maintenant, nous devons connaître l'adresse IP de nsa.nic.uk, mais pour le savoir, nous devons faire une requête nsa.nic.uk, mais nous ne pouvons pas le faire avant de connaître l'adresse IP de nsa.nic.uk...

Pour résoudre ce problème, les serveurs ont .ukajouté l’enregistrement A nsa.nic.ukdans ADDITIONAL SECTIONla réponse (réponse ci-dessous réduite pour des raisons de concision):

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 de colle supplémentaires, nous ne serions jamais en mesure de trouver les serveurs de noms nic.uk.et, par conséquent, nous ne pourrions jamais rechercher les domaines hébergés.

Pour revenir à vos questions ...

a) Quel est l'avantage? Pourquoi ne pas mapper directement à une adresse IP?

D'une part, cela permet aux éditions de chaque zone d'être distribuées. Si vous souhaitez mettre à jour l'entrée pour www.mydomain.co.uk, il vous suffit de modifier les informations sur votre mydomain.co.ukserveur de noms. Il n'est pas nécessaire de notifier les .co.ukserveurs centraux , ni les .ukserveurs, ni les serveurs de noms racine. S'il n'y avait qu'un seul registre central qui mappait tous les niveaux de la hiérarchie à notifier à chaque changement d'entrée DNS tout au long de la chaîne, le trafic serait absolument saturé.

Avant 1982, c’était en fait la résolution de noms. Un registre central a été informé de toutes les mises à jour et a distribué un fichier appelé hosts.txtcontenant 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 devrait télécharger une nouvelle copie. Bien avant 1982, cela commençait à devenir problématique et c'est ainsi que DNS a été inventé pour fournir un système plus distribué.

D'autre part, il s'agirait d'un point de défaillance unique: si le registre central unique s'effondrait, tout Internet était hors ligne. Avoir un système distribué signifie que les échecs ne concernent que de petites parties de l'internet, pas le tout.

(Pour offrir une redondance supplémentaire, il existe actuellement 13 clusters de serveurs distincts qui desservent la zone racine. Toute modification apportée aux enregistrements de domaine de niveau supérieur doit être étendue à l'ensemble des 13; imaginez qu'il soit nécessaire de coordonner la mise à jour des 13 d'entre eux pour chaque modification. vers n'importe quel 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 se trouve sur le serveur DNS, pourquoi le processus n'est-il pas instantané?

Parce que DNS utilise beaucoup de cache pour accélérer les choses et réduire la charge sur les NS. Sans la mise en cache, chaque fois que vous visiterez google.co.ukvotre ordinateur, vous devrez vous rendre sur le réseau pour rechercher les serveurs .uk, puis .co.uk, ensuite .google.co.uk, ensuite www.google.co.uk. Ces réponses ne changent pas beaucoup, donc les consulter à chaque fois est une perte de temps et de trafic sur le réseau. Au lieu de cela, lorsque le NS retourne des enregistrements sur votre ordinateur, il inclut une valeur TTL, qui indique à votre ordinateur de mettre en cache les résultats pendant plusieurs secondes.

Par exemple, les enregistrements NS pour .ukun TTL de 172800 secondes - 2 jours. Google est encore plus conservateur - les enregistrements NS pour google.co.ukun TTL de 4 jours. Les services qui dépendent d’une mise à jour rapide peuvent choisir une durée de vie beaucoup plus basse. Par exemple, telegraph.co.ukla durée de vie n’est que de 600 secondes sur leurs enregistrements NS.

Si vous souhaitez que les mises à jour de votre zone soient quasi instantanées, vous pouvez choisir d'abaisser votre durée de vie aussi loin que vous le souhaitez. Plus votre valeur est basse, plus vos serveurs verront de trafic, car les clients actualiseront leurs enregistrements plus souvent. Chaque fois qu'un client doit contacter vos serveurs pour effectuer une requête, cela entraîne un certain retard, car il est plus lent que de rechercher la réponse sur leur cache local. Vous devez donc également prendre en compte le compromis entre mise à jour rapide et service rapide.

c) Si les caches DNS sont la seule raison de ce retard, 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 digdes outils similaires - indiquez-lui simplement le serveur à contacter.

Voici un exemple de réponse 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 aadrapeau, 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 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é notifiée dans une mémoire cache très proche de moi signifie qu'il m'a fallu 0 ms pour obtenir une réponse. mais comme nous le verrons dans un instant, le prix que je paye pour cette vitesse est que la réponse est presque 5 minutes périmée.

Pour contourner le résolveur de Linode et aller directement à la source, sélectionnez simplement l'un de ces NS et dites à 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-ci, les résultats ont été servis directement à partir de la source. Notez l' aaindicateur, 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. Par conséquent, l' aaindicateur leur manquait . Je peux voir que la source faisant autorité pour ce domaine définit une durée de vie de 600 secondes. Les résultats obtenus précédemment d'une mémoire cache locale ne comportaient qu'une durée de vie de 319 secondes, ce qui m'indique qu'ils étaient restés dans la mémoire cache pendant (600 à 319) secondes, presque 5 minutes, avant que je les voie.

Bien que la durée de vie ne soit que de 600 secondes, certains FAI tenteront de réduire davantage leur trafic en forçant leurs résolveurs DNS à mettre les résultats en cache plus longtemps, dans certains cas, pendant 24 heures ou plus. Il est de tradition (de manière générale - de manière générale - de ne pas savoir si ceci est vraiment nécessaire - mais soyons sûrs) de supposer que tout changement de DNS que vous apportez ne sera pas visible partout dans le monde. Internet pendant 24 à 48 heures.

a) Le nombre de mappages IP -> de noms d'hôte dans le monde est VRAIMENT grand. Ce système répartit la responsabilité de l'hébergement de tous les enregistrements de sous-domaine et MX ainsi que de tous les autres enregistrements DNS vers le propriétaire du nom de domaine. C'était à peu près le point du nom de domaine. .comest détenu par un registre où, comme .ukpeut l'être par un autre. De même example.com, ils otherexample.compeuvent être hébergés séparément pour que les ressources puissent être distribuées.

b) Il est mis en cache, ce qui réduit le nombre de hits sur votre hôte DNS à une petite fraction de ce qu'il serait autrement. Par défaut, il enregistre 2 jours dans le cache avant d’être mis au rebut. Cela peut être changé en modifiant la durée de vie de l'enregistrement.

c) Vous pouvez effectivement empêcher la mise en cache des enregistrements en définissant une durée de vie très courte. Ceci n'est PAS recommandé sauf si vous l'utilisez pour un DNS dynamique. La mise en cache laisse beaucoup tomber les hits sur le serveur DNS. Pour choisir un nombre approximatif, nous parlons de supprimer 95% des demandes.

Si vous utilisez un système * nix, téléchargez une copie des djbdns de Dan Bernstein à l' adresse http://cr.yp.to/djbdns.html et exécutez son programme dnstrace pour voir le fonctionnement du système de requête récursif. C'est très instructif.

a) Le nombre de noms de domaine possibles est beaucoup trop grand pour un serveur à gérer. Et il n'y a pas que du .com; il y a .net, .org, .se, .info et un nombre quelconque d'autres. Ajoutez à cela, vous pouvez déléguer la responsabilité d’un sous-domaine (c’est-à-direcom passe). DNS étant moins centralisé, tout cela est plus facile à gérer.

b) Les machines qui se trouvent entre l'utilisateur et vous ont des caches DNS afin de minimiser le nombre de demandes nécessaires. Cela évite, par exemple, de spammer le réseau en demandant l'adresse de "serverfault.com" chaque fois que vous recevez une page de SF. Ces serveurs peuvent même mettre en cache les résultats "le domaine n'existe pas", c'est pourquoi il faut parfois un certain temps pour qu'un nouveau domaine apparaisse.

c) Bien que vous puissiez désactiver votre cache, il existe souvent d'autres serveurs DNS entre votre machine et le serveur DNS de votredomaine.com. Le serveur DNS de votre fournisseur de services Internet, par exemple, essaiera de mettre en cache autant que possible. Les seuls enregistrements mis à jour assez rapidement sur le réseau sont ceux avec un TTL court (qui dit en gros "je ne suis valide que pendant quelques secondes; après cela, demandez-moi à nouveau pour les informations actuelles"). Cependant, la raison pour laquelle les TTL sont si élevées est que le serveur responsable du domaine peut se décharger d'une partie du travail sur d'autres serveurs. Si tout le réseau communiquait avec votre ou vos deux serveurs DNS rinky-dink à chaque visite sur votre site Web, ils seraient pratiquement inutilisables à la seconde où quelqu'un verrait votre site sur /., Digg, etc.