O que é um registro de cola?

Um registro de cola é um termo para um registro que é servido por um servidor DNS que não tem autoridade para a zona, para evitar uma condição de dependências impossíveis para uma zona DNS.

Digamos que eu possuo uma zona DNS para example.com. Eu quero ter servidores DNS que estejam hospedando a zona autoritativa para este domínio para que eu possa realmente usá-lo - adicionando registros para a raiz do domínio, www, mailetc. Então, eu coloco os servidores de nomes no registro para delegar eles - esses são sempre nomes, então vamos colocar ns1.example.come ns2.example.com.

Aí está o truque. Os servidores do TLD delegarão aos servidores DNS no registro whois - mas eles estão dentro de example.com. Eles tentam encontrar ns1.example.com, perguntam aos .comservidores e são encaminhados de volta para... ns1.example.com.

O que os registros de cola fazem é permitir que os servidores do TLD enviem informações extras em sua resposta à consulta da example.comzona - para enviar também o endereço IP configurado para os servidores de nomes. Não é autoritativo, mas é um ponteiro para os servidores autoritativos, permitindo que o loop seja resolvido.

Solicitei que esta resposta fosse mesclada de uma pergunta duplicada, pois as respostas existentes não explicavam o papel da ADDITIONALseção.

Para ver como funciona, digite isto: dig +trace +additional google.com SOA

Isso rastreará a autoridade do servidor de nomes a partir dos servidores raiz ( +trace). A adição +additionaltambém mostrará a ADDITIONALseção de cada resposta do servidor DNS. Normalmente, a maioria das pessoas pensa no DNS em termos das seções QUESTIONe das ANSWERseções, mas ADDITIONALtambém desempenha um papel importante: se o servidor de nomes souber as respostas para quaisquer consultas relacionadas à resposta, ele poderá fornecer preventivamente essas respostas na ADDITIONALseção sem exigir consultas adicionais do seu cliente.

Observe que os servidores de nomes autoritativos google.comestão enraizados no domínio para o qual são autoritativos. ( ns1.google.com, ns2.google.com, etc.)

Quando você pede a um servidor de nomes para fornecer a lista de servidores de nomes para um domínio, eles geralmente fornecem uma lista de Aregistros do tipo (endereços IP) na ADDITIONALseção, não apenas as NSrespostas do tipo: eles são chamados de registros de cola , usados ​​para evitar dependências. Nesse caso, esses Aregistros são servidos pelos servidores de nomes TLD (.com, .org, etc.) com base nos endereços IP que alguém forneceu ao registrador DNS responsável pelo domínio. Eles geralmente podem ser alterados fazendo login na interface da Web de administração que eles fornecem a você.

(disclaimer: AAAAregistros contendo endereços IPV6 também podem ser fornecidos como parte da cola, mas deixei isso de fora para simplificar.)

Depois de pesquisar muito e ler muito sobre discos de cola e ainda não entender o que eram ou como você pode fazê-los, finalmente encontrei uma resposta e é muito simples.

Pelo que entendi, não há informações extras mágicas enviadas de algum lugar, é assim que funciona.

Digamos que seu domínio seja example.com e você queira usar seus próprios servidores de nomes ns1.example.com e ns2.example.com, você precisa de pelo menos dois servidores DNS.

• ns1.example.com tem IP 192.0.2.10
• ns2.example.com tem IP 192.0.2.20

Para que isso funcione agora, você precisa que o principal proprietário do domínio coloque os seguintes registros em seu DNS.

example.com NS ns1.example.com
example.com NS ns2.example.com

ns1.example.com A 192.0.2.10 
ns2.example.com A 192.0.2.20

Esses dois registros A são os registros de cola e precisam estar no domínio superior, neste caso .com, e nem todos os registradores podem fazer isso para você.

Se isso estiver errado por favor me corrija. Eu apenas pensei em tentar explicar de uma maneira simples para outras pessoas que não conseguem encontrar a resposta correta.

Há uma explicação precisa (e concisa) na wikipedia .
Citar:

Dependências circulares e registros de cola

Os servidores de nomes nas delegações são identificados pelo nome, e não pelo endereço IP. Isso significa que um servidor de nomes de resolução deve emitir outra solicitação de DNS para descobrir o endereço IP do servidor ao qual foi encaminhado.
Se o nome fornecido na delegação for um subdomínio do domínio para o qual a delegação está sendo fornecida, há uma dependência circular. Nesse caso, o servidor de nomes que fornece a delegação também deve fornecer um ou mais endereços IP para o servidor de nomes autoritativo mencionado na delegação. Essa informação é chamada de cola.

. . .

Por exemplo, se o servidor de nomes autorizado para example.org for ns1.example.org, um computador tentando resolver www.example.org primeiro resolve ns1.example.org. Como ns1 está contido em example.org, isso requer a resolução de example.org primeiro, que apresenta uma dependência circular.
Para quebrar a dependência, o servidor de nomes para o domínio de nível superior da organização inclui cola junto com a delegação para example.org. Os registros de cola são registros de endereço que fornecem endereços IP para ns1.example.org. O resolvedor usa um ou mais desses endereços IP para consultar um dos servidores autorizados do domínio, o que permite concluir a consulta DNS.

Bem, essas são três perguntas:

1. O que exatamente (mas brevemente) é um registro de cola DNS?
2. Por que eles são necessários e
3. como eles funcionam?

A resposta breve à primeira pergunta provavelmente fará pouco sentido sem contexto, dada por uma resposta um tanto prolixa às duas últimas perguntas. Aqui, então, está uma explicação alternativa com referências históricas às RFCs para dar algum contexto à terminologia, especialmente:
RFC 822 "Padrão para o formato de mensagens de texto da Internet ARPA" 1982, https://www.rfc-editor.org /rfc/rfc822.html , agora obsoleto por;
RFC 5322 "Formato de mensagem da Internet" 2008, https://www.rfc-editor.org/rfc/rfc5322 ;
RFC 882 "Nomes de Domínio - Conceitos e Instalações" 1983, https://www.rfc-editor.org/rfc/rfc882 , que precede e é obsoleto por;
RFC 1034 "Nomes de Domínio - Conceitos e Instalações" 1987,https://www.rfc-editor.org/rfc/rfc1034 e;
RFC 1035 "Nomes de Domínio - Implementação e Especificação" 1987, https://www.rfc-editor.org/rfc/rfc1035 ; o interveniente
RFC 952 "DoD Internet Host Table Specification" 1985, https://www.rfc-editor.org/rfc/rfc952.html ;
RFC 1123 "Requirements for Internet Hosts -- Application and Support" 1989, https://www.rfc-editor.org/rfc/rfc1123.html , especialmente;
RFC 2181 "Clarifications to the DNS Specification" 1997, https://www.rfc-editor.org/rfc/rfc2181 e;
RFC 2535 "Extensões de segurança do sistema de nomes de domínio" 1999, https://www.rfc-editor.org/rfc/rfc2535 .

Agora, brevemente, à primeira pergunta: Um "registro de cola" DNS é um termo coloquial - não definido em um RFC - para um tipo de registro de recurso de endereço IP de DNS, um registro "A" ou "AAAA". Um registro de endereço IP também é um "registro de cola" quando esse registro de endereço IP fornece um endereço que vincula um caminho ao servidor de protocolo DNS secundário público de uma "zona filha"/"nome de domínio" delegada, onde, em particular, esse registro público servidor de protocolo DNS secundário "nome de domínio" para essa "zona filha" delegada também está em , e imediatamente sob a autoridade dentro, essa zona filho. E aqui - como não encontrei isso explicitamente declarado em um RFC - espera-se que o Administrador de Rede simplesmente infira que, quando a "zona filho" delegada também estiver e imediatamente sob a autoridade dentro dessa zona filho, o pai A zona também deve fornecer um ou mais registros de endereço IP que, no final, se vinculam aos servidores de protocolo DNS autoritativos da zona filho . "Glue records" são todos sobre a interação de servidores "autoritários" e "não autorizados", onde, por design , uma "zona pai" não tem autoridade para uma "zona filho".

E então, há uma ressalva, levantada em Qual é a diferença entre os registros NS e os registros de cola? , por Ladadada, que há uma incerteza na prática, talvez não muito esclarecida nas RFCs, sobre se algum cliente de protocolo DNS específico seguirá ou não um caminho e, em seguida, verificará se um servidor de protocolo DNS de zona filho vinculada também está o servidor autoritativo para essa zona filha, verificando efetivamente se os endereços IP correspondem. Existe a possibilidade de que um endereço IP de "registro de cola" possa levar a um servidor autoritativo com um registro de recurso "Servidor de nomes" levando a um endereço IP diferente , portanto inconsistente, para um ou maisServidores de protocolo DNS para essa zona filha. Talvez o endereço do servidor seja verificado. Talvez o endereço do servidor não seja verificado, e o endereço IP esteja desatualizado, e talvez o arquivo de zona deste servidor também esteja "meio caminho" desatualizado, com os registros corretos do "Servidor de Nomes", mas servindo -of-date ou respostas erradas para outros recursos. Obviamente, essa circunstância implica em erros administrativos de DNS, portanto, é apenas uma ressalva. Esse "não deveria" acontecer na prática.

As respostas através das RFCs para as duas últimas questões tornam-se complicadas quando o "conhecimento comum" é esperado do leitor e a terminologia "sobrecarregada" é frequentemente usada, onde, na prática, no uso comum, o mesmo termo é usado em referência a duas, às vezes mais, coisas diferentes ou abstrações diferentes. Outra coisa a reconhecer aqui é a associação inicial no desenvolvimento do Internet Messaging e do Domain Name System e, em seguida, a forma como essa associação influenciou o uso da terminologia de Internet Messaging nas RFCs do Domain Name System, como "conhecimento comum", para aqueles tempos.

Em particular, isso leva a um uso muito inconsistente do termo "nome de domínio" nas várias RFCs, um termo que, em diferentes contextos, pode se referir a:

1. Um "nome de domínio do host", ou
2. Um "nome de domínio de subzona".

Esses termos podem ser inferidos historicamente das RFCs. Como "conhecimento comum", um "host" em si é 1) uma máquina com uma interface de rede física e 2) uma interface de "soquete" IP do sistema operacional à qual um endereço IP foi atribuído. O termo "nome de domínio do host" vem da RFC 1123, que usa o termo explicitamente.

O termo "nome de domínio de subzona" pode ser inferido em vários RFCs. Vemos "nome de domínio" de um "domínio filho", como originalmente no RFC 822, ou "zona filho" posteriormente no RFC 2181, ou "subzona", um "nome de domínio de subzona", conforme implícito em outros RFCs, especialmente RFC 1035 e RFC 2535.

Esses "nomes de domínio" são duas coisas muito diferentes, ambas podem ser usadas como:

1. valores para "um nome de proprietário" em um pacote de dados de protocolo DNS e o "proprietário" do lado esquerdo de um registro de recurso "arquivo mestre" ou "arquivo de zona", ou também como
2. o valor de "nome conônico" RDATA em um registro de recurso NS, MX ou CNAME, ou como o "nome conônico" MNAME em um registro de recurso SOA, em um pacote de dados e no lado direito de um arquivo de zona, como em RFC 1034 e RFC 1035.

Especialmente no início do RFC 952, vemos que esses dois conceitos diferentes de "domínio" são simplesmente "agrupados":

GRAMMATICAL HOST TABLE SPECIFICATION

  A. Parsing grammar
  ...
     <domainname> ::= <hname>
     <official hostname> ::= <hname>

Outra provável área de confusão é o "NS Resource Record", que também tem dois significados muito diferentes, dependendo do contexto. Podemos ler na RFC 2181, Seção 6.1, abaixo https://www.rfc-editor.org/rfc/rfc2181#section-6 :

6.1. Autoridade de zona
Os servidores autoritativos de uma zona são enumerados nos registros NS para a origem da zona, que, juntamente com um registro de início de autoridade (SOA) são os registros obrigatórios em cada zona. Esse servidor tem autoridade para todos os registros de recursos em uma zona que não estão em outra zona. Os registros NS que indicam um corte de zona são de propriedade da zona filha criada, assim como quaisquer outros registros para a origem dessa zona filha, ou quaisquer subdomínios dela. Um servidor para uma zona não deve retornar respostas autorizadas para consultas relacionadas a nomes em outra zona, que inclui os registros NS e talvez A em uma zona cortada, a menos que também seja um servidor para a outra zona.

e observe particularmente a frase "Os registros NS ... são os registros obrigatórios em todas as zonas" e observe adicionalmente:

Além dos casos DNSSEC mencionados imediatamente abaixo, os servidores devem ignorar dados que não sejam registros NS e registros A necessários para localizar os servidores listados nos registros NS, que podem estar configurados em uma zona em uma zona cortada.

Ao mesmo tempo, porém, também lemos na Seção 6 anterior:

... A existência de um corte de zona é indicada na zona pai pela existência de registros NS especificando a origem da zona filho. Uma zona filho não contém nenhuma referência explícita a seu pai.

Assim, o leitor pode inferir, por conta própria, que existem duas classes muito diferentes de NS Resource Record em um arquivo de zona:

1. esses registros obrigatórios com exatamente o mesmo "rótulo" que o próprio domínio de "origem" da zona, fornecendo os "nomes de domínio do host" dos servidores de protocolo DNS secundários públicos autoritativos autodescritivos. Referem-se a esta zona e têm autoridade . E
2. esses registros opcionais com rótulos que não correspondem exatamente ao domínio de origem da zona e, portanto, especificam os domínios de origem da zona filho, agora estendidos, e vinculam um caminho aos nomes de servidor de protocolo DNS secundário público para a zona filho. Referem-se a alguma outra zona e não têm autoridade . Esses registros são apenas um "melhor palpite", lembrando particularmente que essa zona pai não pode ter autoridade para a zona filho.

Devemos tomar um momento aqui e perceber que esta segunda classe de registros NS também pode exigir a inclusão de registros de endereço correspondentes, como "registros cola", quando a "zona filho" delegada também está e imediatamente sob a autoridade dentro, essa zona filho, conforme discutido anteriormente. Também devemos perceber que esses mesmos registros NS e seus "registros de cola" associados devem ser incluídos - pode ser suposto "incluídos de forma redundante" - no arquivo de zona da zona filho, para o "nome de domínio da subzona" , como a expressão oficial dos servidores de protocolo DNS secundários públicos do domínio da subzona e seus endereços IP. Novamente, lembre-se, a zona "pai" nunca éautoritativo para a zona "filho", mesmo que o arquivo de zona pai inclua e já tenha fornecido exatamente as mesmas informações - nunca para os registros NS da zona filho e nunca para qualquer outro tipo de registro de recurso de zona filho.

Então, agora, para a segunda pergunta, " Por que os registros de cola são necessários?", devemos primeiro dizer que, estritamente falando, os registros de cola não são necessários, de forma alguma, desde que :

1. O arquivo de zona não descreve nenhum tipo de "nome de domínio de zona" filho envolvendo registros NS da segunda classe descrita anteriormente, ou
2. O arquivo de zona inclui registros NS que descrevem um "nome de domínio de zona" filho, mas também , os servidores de protocolo DNS secundários públicos para a zona filho não estão imediatamente sob a autoridade dessa zona filho.

A menos que um administrador de rede esteja configurando alguma grande organização que precise de subdomínios delegados, com seus próprios servidores de protocolo DNS autoadministrados, não há necessidade de nenhum "registro de cola". E mesmo assim, uma grande organização pode muito bem distribuir prudentemente seus servidores de protocolo DNS fora de qualquer subdomínio delegado, novamente, possivelmente evitando qualquer necessidade de "registros de cola" se esses endereços de servidor já forem resolvidos em outro lugar, talvez por algum provedor externo.

"Registros de cola" são mais provavelmente algo necessário com um domínio "vaidade" ou com uma pequena organização que deseja administrar seus próprios servidores de protocolo DNS e o arquivo de zona usado pelo provedor de DNS upstream da organização, provavelmente seu registrador de DNS. E mesmo assim, muito provavelmente, apenas o arquivo de zona do registrador terá "registros de cola" vinculados aos servidores de protocolo DNS do próprio cliente, que provavelmente também não estão sendo usados ​​pelo cliente para delegar nomes de domínio de subzona.

Mas, como será abordado na próxima resposta à terceira pergunta, “ como funcionam” – “ por que ” é um pouco mais complicado. A operação do DNS implica seguir um caminho através de uma hierarquia de componentes de domínio, conforme discutido na RFC 882, em "Especificações e terminologia do espaço de nomes", o que, em última análise, requer um endereço IP de "ponte", de um servidor não autoritativo para um servidor autoritativo, em cada "zona cortada". A menos que confinado à zona "raiz", sempre há cortes de zona ao longo do caminho para um "nome de domínio" de destino desejado. Os "registros de cola" fornecem essa "ponte" entre os cortes da zona.

Deve-se mencionar aqui, para o contexto histórico, o mecanismo transitivo do registro NS e do registro Endereço. Observe que o registro NS contém um "nome de domínio de subzona", o "proprietário", no lado esquerdo do registro de recurso, e um "nome de domínio do host", o "nome canônico" RDATA, no lado direito . Não há endereço IP aqui - ainda. Por que é que? Podemos nos referir ao "conhecimento comum", do agora obsoleto RFC 822, na Seção 6.2.3, em https://www.rfc-editor.org/rfc/rfc822.html#section-6.2 , que afirma com destaque:

6.2.3. TERMOS DE DOMÍNIO
Um domínio-ref deve ser o nome oficial de um registro, rede ou host. É uma referência simbólica, dentro de um subdomínio de nome. Às vezes, é necessário ignorar os mecanismos padrão para resolver tais referências, usando informações mais primitivas, como um endereço de host de rede em vez de seu nome de host associado.
...
Os literais de domínio que se referem a domínios dentro da Internet ARPA especificam endereços de Internet de 32 bits, em quatro campos de 8 bits indicados em decimal, conforme descrito em Solicitação de comentários #820, "Números atribuídos". Por exemplo:
[10.0.3.19]

Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.  It
       is  permitted  only  as  a means of bypassing temporary
       system limitations, such as name tables which  are  not
       complete.

Ou, parafraseando, um "nome de domínio" geralmente não é um endereço IP. Assim, o RDATA do registro NS é um "nome de domínio", não um endereço IP, e um registro de endereço separado associa esse "nome de domínio" NS RDATA ao registro de recurso "específico da Internet ARPA" RDATA, o endereço IP real. E então, consequentemente, o registro de endereço, nesse contexto, também pode ser chamado de "registro de cola", e o registro NS não é. Essa segunda classe de registro NS é sempre necessária para marcar um "corte de zona" em uma zona pai, mas o registro de endereço associado talvez seja necessário, ou talvez não , conforme discutido.

Há uma outra observação sobre a terminologia aqui, com relação ao registro de recursos SOA e à distinção de servidor de protocolo DNS "primário" e servidor "secundário público". Na RFC 1035, Seção 3.3.13 "formato SOA RDATA", em https://www.rfc-editor.org/rfc/rfc1035#section-3.3.13 , há:

MNAME           The <domain-name> of the name server that was the
                original or primary source of data for this zone.

SOA records cause no additional section processing.

Tome nota do pretérito, " foi a fonte original ou primária". Novamente, devemos tomar um momento aqui e perceber que, muito comumente, nenhum dos servidores públicos de protocolo DNS é necessariamente também o servidor primário para a zona, e também que a "fonte primária de dados para esta zona" nem precisa ser acessível ao público. Embora seja comum que o servidor primário seja acessível publicamente, isso não é necessário. E embora também seja possível que o servidor primário seja o público e apenasservidor para a zona, é preferível ter servidores redundantes. Para facilitar a administração de vários servidores, um único servidor primário, pode fazer uma "transferência de zona" ou "Transferência Autoritativa", "AXFR", para um grupo de servidores secundários. Para ser pedante, então, o servidor "primário" é especificado no registro SOA MNAME e, consequentemente, os servidores especificados no RDATA da primeira classe necessária de registros de recursos NS são servidores "secundários públicos". Ainda assim, pode ser que o nome SOA MNAME e um nome NS RDATA também se refiram ao mesmo servidor.

Por fim, quanto à terceira questão, " Como funcionam os registros de cola?", é útil refletir sobre a operação implícita do Protocolo DNS nas trocas entre o cliente e vários servidores, discutida na RFC 1034, especialmente na Seção 5 "Resolvers" , sob https://www.rfc-editor.org/rfc/rfc1034.html#section-5 , e RFC 1035, Seção 7 "Implementação do Resolver", em geral, e particularmente observando a Seção 7.2, sob https://www. rfc-editor.org/rfc/rfc1035#section-7.2 :

Alguns pontos finos:

The resolver may encounter a situation where no addresses are available for any of the name servers named in SLIST, and where the servers in the list are precisely those which would normally be used to look up their own addresses. This situation typically occurs when the glue address RRs have a smaller TTL than the NS RRs marking delegation, or when the resolver caches the result of a NS search. The resolver should detect this condition and restart the search at the next ancestor zone, or alternatively at the root.

The client engages in a sequence of queries, working its way through the domain name hierarchy, mostly resolving subdomain components to IP Addresses, typically finding first a "root" server "domain name", then its IP Address, then a "global top level domain" server "domain name", then its IP Address, then a third level "domain name", a "subzone domain name" being delegated by the, at this point, parent global top level domain, and searching for the IP Address for this zone's DNS Protocol server. The server for the global top level domain will authoritatively provide a "zone cut", specifying a "subzone domain name". And then the client will want an IP Address for this third level "subzone domain name" DNS Protocol server. However, as discussed, in every "cut", following the domain name hierarchy, the "parent" zone is not the authoritative source for the IP address of the DNS Protocol server for the "child" zone, by design. Still, the client needs an IP Address - where from?

It may be possible for the client to begin following another path through the domain name hierarchy, searching for this IP Address, which only ends when the client identifies the server with the "Source of Authority" for the IP Address of the DNS Protocol server specified for this child subzone domain name, and any other record sought. But regardless, at every "cut", from zone to subzone, the client must have a "bridge" from a nonauthoritative source for a server IP Address, to an "authoritative" source for this IP Address. That is why a "glue record" may be referred to as only a "hint" about a server's IP Address. The parent zone server offers a "best guess", a "suggestion", redirecting the client from the current server to the "next" server, continuing the client's search for a server with the "Source of Authority" to finally declare authoritatively that this IP Address is the IP Address of the "host domain name" DNS Protocol server for the target "subzone domain name".

The "glue records" provide that IP Address "bridge" from nonauthoritative source server to, eventually, an authoritative source server. Whether the client bothers to verify that the current server's IP Address actually matches an authoritative DNS Name Server IP Address for the target "subzone domain name" is at the discretion of the client. Hope for the best - or do confirm it manually. It might be possible to completely leave out listing the first class of self-descriptive authoritative NS records from the zone file, and still provide the client with any other resource record - as long as the client just "hopes for the best" and doesn't actually check for the NS records and their associated Address records.

See also RFC 8499 "DNS Terminology" 2019, https://www.rfc-editor.org/rfc/rfc8499.html.