Por que os registros NS não contêm endereços IP?

Question

O ponto de um registro NS é dizer ao cliente qual servidor de nomes saberá com certeza o endereço IP real de um nome de domínio. Assim, por exemplo, a consulta a seguir informa que, se você deseja obter uma resposta autoritativa sobre facebook.com , deverá solicitar 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

Isso parece legal e útil, mas estou me perguntando por que a seção ANSWER contém o nome do host e não o IP da origem autoritativa? Não seria mais fácil para o cliente obter o endereço IP real da fonte autoritativa e não o nome do host?

Quero dizer, se ele receber o nome do host, ele terá que fazer outra consulta para resolver esse nome de host em um IP e, em seguida, perguntar a esse novo IP sobre o domínio facebook.com inicial que estava procurando. Isso não é ineficiente?

Eu estaria interessado em responder que me aponta para alguns parágrafos em alguns RFC que explica este problema.

    

Answer 1

A solução para o problema são os registros de glue de DNS, que são descritos em O que é um registro de cola

RFC 1035 Seção 3.3.11 declara

"... Note that the class may not indicate the protocol family which should be used to communicate" with the host, although it is typically a strong hint."

Retornar um endereço IP seria o mesmo que indicar o método pelo qual o host pode ser contatado, o que vai contra o RFC.

    

Answer 2

Jason forneceu o mecanismo de DNS que funciona em torno do problema que você descreveu, mas ainda não analisamos por que as coisas são feitas dessa maneira.

Digamos que eu possua example.com e contratei parte do conteúdo do meu site para uma empresa de entrega de conteúdo chamada Contoso . A plataforma deles exige que nós delegemos sub.example.com a seus servidores de nomes para que eles possam controlar quais respostas serão retornadas.

; 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 você observou, não especificamos os endereços IP dos servidores de nomes da Contoso. Todos os nossos servidores sabem é dizer à internet "nós não gerenciamos sub.example.com , pergunte ao Contoso" . Isso é muito importante porque:

• Não somos proprietários da Contoso.com.
• Não podemos esperar que a Contoso coordene uma alteração de seus IPs de servidor de nomes com todos os seus clientes. Isso é exatamente o que teria que acontecer se nosso servidor estivesse fornecendo esses IPs.

Até aí tudo bem. Passa um ano e, sem o conhecimento de nós, a Contoso está alterando os endereços IP de seus servidores de nomes CDN. Como o DNS funciona da maneira como funciona, tudo o que eles precisam fazer é atualizar os registros A que retornam para ns1.cdn e ns2.cdn.contoso.com. .

Isso nos leva a um ponto importante: os registros de cola descritos por Jason existem para lidar com cenários de "galinha e ovo" no DNS, como google.com dizendo ao mundo que seus servidores de nomes são ns1.google.com e ns2.google.com . Você deve nunca criar registros de cola apontando para a infraestrutura que você não possui, a menos que eles existam para resolver um 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

Isso evita o cenário "ovo e galinha", mas também faz com que a Contoso coordene todas as mudanças de IP desses servidores de nomes conosco. Isso é muito propenso a riscos e indesejável.