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


Le but d'un enregistrement NS est d'indiquer au client quel serveur de noms saura 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é à propos de facebook.com 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 le ANSWER section contient le nom d'hôte et pas l'adresse 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 si elle obtient le nom d’hôte, elle devra faire une autre requête pour résoudre ce nom d’hôte en une adresse IP, puis demander à cette nouvelle adresse IP la valeur initiale. facebook.com domaine qu'il cherchait. N'est-ce pas inefficace?

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


17
2018-03-20 19:02


origine


"cela explique ce problème." laquelle? Voulez-vous dire une requête supplémentaire? - ALex_hha
ouais @ALex_hha je veux dire requête supplémentaire - Pawelmhm


Réponses:


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

RFC 1035 Section 3.3.11 États

"... Notez que la classe peut ne pas indiquer la famille de protocoles à utiliser 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 de la RFC.


16
2018-03-20 19:16



merci Jason, donc si un enregistrement NS contenait une adresse IP, cela indiquerait la famille de protocoles, et la RFC l’interdit, est-ce exact? Cela signifie-t-il que le client peut utiliser différentes familles de protocoles lors de l'exécution d'une requête DNS? Je pensais qu'il ne pouvait utiliser que UDP / TCP? - Pawelmhm
La famille de protocole fait référence à IPv4, IPv6 - sendmoreinfo
Si vous savez que la question est un doublon, vous ne pouvez pas voter pour une dupe et vous devez le signaler comme tel. - Iain
Je pense que la RFC utilise "peut pas" dans le sens de "pourrait ne pas", pas dans le sens d'une interdiction. (Il est antérieur à la RFC2119, qui normalisait ce type de langage pour réduire les ambiguïtés.) - David


Jason a fourni le mécanisme DNS qui résout le problème que vous avez décrit, mais nous n'avons toujours pas examiné Pourquoi les choses se font de cette façon.

Disons que je possède example.comet 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 les réponses 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 indiqué, nous n'avons pas spécifié les adresses IP des serveurs de noms Contoso. Tout ce que notre serveur sait, c'est dire à Internet "nous ne gérons pas sub.example.com, demandez à Contoso à la place ". Ceci est très important car:

  • Nous ne possédons pas Contoso.com.
  • Nous ne pouvons pas nous attendre à ce que Contoso coordonne un changement d'adresse IP de serveur de noms avec tous ses clients. C’est exactement ce qui devrait se passer si notre serveur fournissait ces adresses IP.

Jusqu'ici tout va bien. Un an passe et à notre insu, Contoso modifie les adresses IP de leurs serveurs de noms CDN. Parce que le DNS fonctionne comme il le fait, tout ce qu’ils ont à faire est de mettre à jour le A enregistrements qu'ils retournent pour ns1.cdn et ns2.cdn.contoso.com..

Cela nous amène à un point important: les enregistrements de colle décrits par Jason existent pour traiter des scénarios de "poule et d'oeuf" dans le DNS, tels que google.com dire au monde que leurs serveurs de noms sont ns1.google.com et ns2.google.com. Vous devriez jamais créez des enregistrements collés pointant sur 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 de la poule et de l'œuf, mais permet également à Contoso de se coordonner chaque changement de propriété intellectuelle de ces serveurs de noms avec nous. Ceci est très sujet au risque et indésirable.


37
2018-03-20 21:00



Ah, cela a beaucoup de sens lorsque les serveurs de noms ne sont pas auto-hébergés. - Jason Martin