¿Por qué los registros NS no contienen direcciones IP?

El objetivo de un registro NS es decirle al cliente qué servidor de nombres sabrá con seguridad la dirección IP real de un nombre de dominio. Entonces, por ejemplo, la siguiente consulta le dice que si desea obtener una respuesta autorizada sobre esto facebook.com, debe preguntar 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

Esto parece genial y útil, pero me pregunto por qué la ANSWERsección contiene el nombre de host y no la IP de la fuente autorizada. ¿No sería más fácil para el cliente obtener la dirección IP real de la fuente autorizada y no el nombre de host?

Es decir, si obtiene el nombre de host, tendrá que hacer otra consulta para resolver este nombre de host en una IP y luego preguntarle a esta nueva IP sobre el facebook.comdominio inicial que estaba buscando. ¿No es esto ineficiente?

Me interesaría una respuesta que me señale algunos párrafos en algunos RFC que explican este problema.

La solución al problema son los registros de pegamento DNS, que se describen en ¿Qué es un registro de pegamento? .

RFC 1035 Sección 3.3.11 estados

"... Tenga en cuenta que la clase puede no indicar la familia de protocolos que debe usarse para comunicarse" con el host, aunque generalmente es una pista fuerte ".

Devolver una dirección IP equivaldría a indicar el método por el cual se puede contactar al host, lo que va en contra del RFC.

Jason proporcionó el mecanismo de DNS que soluciona el problema que describió, pero aún no hemos analizado por qué las cosas se hacen de esta manera.

Digamos que soy el propietario example.comy he contratado parte del contenido de mi sitio web a una empresa de distribución de contenido llamada Contoso . Su plataforma requiere que deleguemos sub.example.comen sus servidores de nombres para que puedan controlar qué respuestas se devuelven.

; 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

Como ha notado, no hemos especificado las direcciones IP de los servidores de nombres de Contoso. Todo lo que nuestro servidor sabe es decirle a Internet "que no gestionamos sub.example.com, pregunte a Contoso" . Esto es muy importante porque:

• No somos dueños de Contoso.com.
• No podemos esperar que Contoso coordine un cambio de sus IP de servidores de nombres con todos sus clientes. Eso es exactamente lo que tendría que suceder si nuestro servidor proporcionara esas IP.

Hasta aquí todo bien. Pasa un año, y sin que nosotros lo sepamos, Contoso está cambiando las direcciones IP de sus servidores de nombres CDN. Debido a que DNS funciona de la manera que lo hace, todo lo que tienen que hacer es actualizar los Aregistros para los que regresan ns1.cdny ns2.cdn.contoso.com..

Esto nos lleva a un punto importante: los registros de pegamento descritos por Jason existen para lidiar con escenarios de "huevo y gallina" en DNS, como google.comdecirle al mundo que sus servidores de nombres son ns1.google.comy ns2.google.com. Usted debe no crear registros de cola apuntando a la infraestructura que no posee a menos que existan para resolver un problema como este:

@           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

Esto evita el escenario del huevo y la gallina, pero también hace que Contoso tenga que coordinar cada cambio de IP de esos servidores de nombres con nosotros. Esto es muy propenso al riesgo e indeseable.