Perché i record NS non contengono indirizzi IP?

Il punto di un record NS è dire al client quale server dei nomi saprà per certo l'indirizzo IP effettivo per un nome di dominio. Quindi, ad esempio, la seguente query ti dice che se vuoi ottenere una risposta autorevole su di facebook.comte devi chiedere 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

Sembra interessante e utile, ma mi chiedo perché la ANSWERsezione contenga il nome host e non l'IP della fonte autorevole? Non sarebbe più facile per il client ottenere l'indirizzo IP effettivo della fonte autorevole e non il nome host?

Voglio dire se ottiene il nome host dovrà fare un'altra query per risolvere questo nome host in un IP e quindi chiedere a questo nuovo IP il facebook.comdominio iniziale che stava cercando. Non è inefficiente?

Sarei interessato a una risposta che mi faccia riferimento ad alcuni paragrafi in alcuni RFC che spiegano questo problema.

La soluzione al problema sono i record di colla DNS, descritti in Cos'è un record di colla? .

RFC 1035 Sezione 3.3.11 afferma

"... Nota che la classe potrebbe non indicare la famiglia di protocolli che dovrebbe essere usata per comunicare" con l'host, sebbene sia tipicamente un forte suggerimento. "

La restituzione di un indirizzo IP equivarrebbe a indicare il metodo con cui l'host può essere contattato, il che va contro la RFC.

Jason ha fornito il meccanismo DNS che aggira il problema che hai descritto, ma non abbiamo ancora dato uno sguardo al perché le cose vengano fatte in questo modo.

Diciamo che lo possiedo example.come ho contratto parte del contenuto del mio sito Web a una società di distribuzione di contenuti di nome Contoso . La loro piattaforma ci richiede di delegare sub.example.comai loro nameserver in modo che possano controllare quali risposte vengono restituite.

; 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

Come hai notato, non abbiamo specificato gli indirizzi IP dei nameserver di Contoso. Tutto ciò che il nostro server sa è dire a Internet "non riusciamo sub.example.com, chiediamo invece a Contoso" . Questo è molto importante, perché:

• Non possediamo Contoso.com.
• Non possiamo aspettarci che Contoso coordini una modifica degli IP dei nameserver con tutti i suoi clienti. Questo è esattamente ciò che dovrebbe accadere se il nostro server fornisse tali IP.

Fin qui tutto bene. Passa un anno e, a nostra insaputa, Contoso sta cambiando gli indirizzi IP dei loro nameserver CDN. Poiché il DNS funziona in questo modo, tutto ciò che devono fare è aggiornare i Arecord per cui restituiscono ns1.cdne ns2.cdn.contoso.com..

Questo ci porta ad un punto importante: i record di colla descritti da Jason esistono per gestire scenari "pollo e uova" nel DNS, come google.comdire al mondo che i loro server dei nomi sono ns1.google.come ns2.google.com. Non dovresti mai creare record di colla che indicano infrastrutture che non possiedi a meno che non esistano per risolvere un problema come questo:

@           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

Questo evita lo scenario di pollo e uova, ma lo rende anche in modo che Contoso debba coordinare con noi ogni cambiamento IP di quei server dei nomi. Questo è molto incline al rischio e indesiderabile.