Pourquoi les enregistrements NS ne contiennent-ils pas d'adresses IP?

Le point d'un enregistrement NS est de dire au client quel serveur de noms connaîtra avec certitude l'adresse IP réelle d'un nom de domaine. Ainsi, par exemple, la requête suivante vous indique que si vous souhaitez obtenir une réponse faisant autorité à facebook.comvotre sujet, vous devez demander a.ns.facebook.com:

> dig ns facebook.com                                                                                                                                       19:58:27

; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> ns facebook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32063
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;facebook.com.          IN  NS

;; ANSWER SECTION:
facebook.com.       65000   IN  NS  a.ns.facebook.com.
facebook.com.       65000   IN  NS  b.ns.facebook.com.

;; Query time: 13 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sun Mar 20 19:58:40 CET 2016
;; MSG SIZE  rcvd: 65

Cela semble cool et utile, mais je me demande pourquoi la ANSWERsection contient le nom d'hôte et non l'IP de la source faisant autorité? Ne serait-il pas plus facile pour le client d'obtenir l'adresse IP réelle de la source faisant autorité et non le nom d'hôte?

Je veux dire que s'il obtient le nom d'hôte, il devra faire une autre requête pour résoudre ce nom d'hôte en IP, puis demander à cette nouvelle IP le facebook.comdomaine initial qu'il recherchait. N'est-ce pas inefficace?

Je serais intéressé par une réponse qui me pointe vers certains paragraphes de certains RFC qui expliquent ce problème.

La solution au problème réside dans les enregistrements de collage DNS, qui sont décrits dans Qu'est-ce qu'un enregistrement de collage? .

RFC 1035 Section 3.3.11 indique

"... Notez que la classe peut ne pas indiquer la famille de protocoles qui devrait être utilisée pour communiquer" avec l'hôte, bien qu'il s'agisse généralement d'un indice fort. "

Renvoyer une adresse IP reviendrait à indiquer la méthode par laquelle l'hôte peut être contacté, ce qui va à l'encontre du RFC.

Jason a fourni le mécanisme DNS qui contourne le problème que vous avez décrit, mais nous n'avons toujours pas cherché à savoir pourquoi les choses se font de cette façon.

Disons que je suis propriétaire example.comet que j'ai sous-traité une partie du contenu de mon site Web à une société de diffusion de contenu nommée Contoso . Leur plate-forme nous oblige à déléguer sub.example.comà leurs serveurs de noms afin qu'ils puissent contrôler quelles réponses sont retournées.

; SOA and MX omitted from this example
$ORIGIN example.com.

@           IN      NS            ns1
@           IN      NS            ns2

; delegate sub.example.com to Contoso's nameservers
sub         IN      NS            ns1.cdn.contoso.com.
sub         IN      NS            ns2.cdn.contoso.com.

; this is ours, not Contoso's
www         IN      A             198.51.100.1

Comme vous l'avez noté, nous n'avons pas spécifié les adresses IP des serveurs de noms de Contoso. Tout ce que notre serveur sait, c'est de dire à Internet "nous ne gérons pas sub.example.com, demandez plutôt à Contoso" . Ceci est très important, car:

• Nous ne sommes pas propriétaires de Contoso.com.
• Nous ne pouvons pas nous attendre à ce que Contoso coordonne un changement de leurs adresses IP de serveur de noms avec tous leurs clients. C'est exactement ce qui devrait se produire si notre serveur fournissait ces adresses IP.

Jusqu'ici tout va bien. Une année s'écoule, et à notre insu, Contoso modifie les adresses IP de ses serveurs de noms CDN. Parce que DNS fonctionne comme il le fait, il leur suffit de mettre à jour les Aenregistrements qu'ils renvoient pour ns1.cdnet ns2.cdn.contoso.com..

Cela nous amène à un point important: les enregistrements de colle décrits par Jason existent pour traiter les scénarios "poulet et œuf" dans DNS, comme google.comdire au monde que leurs serveurs de noms sont ns1.google.comet ns2.google.com. Vous ne devez jamais créer des enregistrements de collage pointant vers une infrastructure que vous ne possédez pas, sauf s'ils existent pour résoudre un problème comme celui-ci:

@           IN      NS            ns1
@           IN      NS            ns2

; delegate sub.example.com to ns1 and ns2.sub.example.com
sub         IN      NS            ns1.sub
sub         IN      NS            ns2.sub

; provide the IP addresses of ns1 and ns2 so that nameservers
; on the internet can find them.
;
; these IP addresses are owned by Contoso, not us, and they must
; coordinate changes to these IPs with us
ns1.sub     IN       A            203.0.113.10
ns1.sub     IN       A            203.1.113.10

Cela évite le scénario du poulet et des œufs, mais permet également à Contoso de coordonner avec nous tous les changements IP de ces serveurs de noms. Ceci est très sujet aux risques et indésirable.