Como corrijo o problema "sem cola" nas pesquisas de DNS?

Quando procuro meu domínio em http://www.intodns.com , aqui está um problema:

O GLUE não foi enviado quando solicitei aos seus servidores de nomes seus registros NS. Tudo bem, mas você deve saber que, nesse caso, é necessária uma pesquisa de registro extra para obter os IPs dos seus registros NS. Você pode corrigir isso, por exemplo, adicionando registros A aos seus servidores de nomes para as zonas listadas acima.

Mas tenho entradas A para todos os meus servidores de nomes em cada entrada de zona:

ns1.example.com. IN A <IP>
ns2.example.com. IN A <IP>

Como faço para corrigir esse problema de COLA?

Os registros de cola são registros A especiais, necessários quando o servidor de nomes para um domínio DNS está no mesmo domínio.

Por exemplo, se seu domínio for example.com e seu servidor de nomes for ns.example.com, será necessário criar um registro "cola" para "ns.example.com" na próxima zona DNS mais alta, nesse caso no diretório zona "com". Isso deve ser feito através do seu registrador.

Isso é necessário porque as solicitações de DNS para servidores de nomes (registros NS) sempre são respondidas com um nome, não um IP.

Sem um registro de cola, se uma solicitação fosse feita para os registros A www.example.com, um servidor de nomes servindo "com" retornaria o registro NS para example.com como ns.example.com (não um IP) e o a solicitação original não teria como ser resolvida, pois qualquer tentativa adicional de resolver o ns.example.com se referiria apenas a ns.example.com.

O problema com o GLUE dos servidores DNS raiz é quando você tem a seguinte situação:

example.com possui os registros DNS ns1.example.net e ns2.example.net como servidores NS. A autoridade .com, onde o resolvedor DNS procurará o nome do domínio, NÃO PODE fornecer os endereços IP para ns1.example.net e ns2.example.net, porque eles não estão em sua autoridade.

A maneira de corrigir isso é que um domínio .com use servidores NS originados. Portanto, o example.com usaria o ns1.example-2.com e o ns2.example-2.com e tudo ficará bem, pois a autoridade .com pode fornecer o endereço IP do servidor de nomes. Isso economiza várias viagens de ida e volta para os servidores DNS raiz, pois no seu caso, para obter o example.com, ele também precisa perguntar ao .net sobre o example.net.

No meu caso, todos os meus domínios têm suas próprias entradas NS, por exemplo, eu tenho a.ns.example.com e b.ns.example.com e, para o meu domínio example.net, tenho a.ns.example .net e b.ns.example.net.

Requer mais configuração, e nem todos os hosts podem estar dispostos a permitir isso. Você pode estar preso ao que tem atualmente!

Tentando a ferramenta pessoalmente e vendo o que ela relata com alguns domínios com os quais estou familiarizado, eu diria que pode haver várias coisas que levam a essa mensagem informativa (observe que é um 'i' para obter informações, não um '!')

Por exemplo, uma das minhas zonas possui servidores de nomes fora da zona e, dos servidores de nomes autoritativos da zona, nem todos eles têm registros A em seus dados autoritativos para serem retornados em uma resposta.

Mas tudo bem - qualquer servidor de nomes consultante não deve confiar nesses dados de qualquer maneira. Há muito tempo, você teria se safado disso, mas hoje em dia todo servidor de nomes pode estar tentando mentir e esgueirar-se dos dados da zona para o cache.

Então não se preocupe. No momento em que a consulta chega ao seu servidor de nomes, ele já encontrou pelo menos alguns dos endereços IP dos servidores de nomes. Preocupe-se com as delegações serem iguais aos seus próprios dados de zona (a próxima entrada, "Registros NS Incompatíveis") e que nenhum seja 'coxo' ("Os servidores de nomes são coxos: todos os servidores de nomes listados nos servidores pais respondem com autoridade por seus domínio "- com palavras incorretas, mas você deseja garantir que haja uma marca lá.)