[GTER] Glue at parent nameservers X registro.br

Frederico A C Neves fneves at registro.br
Thu Dec 17 15:45:52 -02 2009


Fernando,

On Thu, Dec 17, 2009 at 11:56:48AM -0200, Fernando Ulisses dos Santos wrote:
> Olá,
> 
> Na ferramenta DNSReport ( http://www.dnsstuff.com/ ) ele faz uma série 
> de checagens em um determinado domínio e aponta problemas existentes, em 
> tons de amarelo ou vermelho, dependendo da gravidade do problema.
> 
> Um dos problemas que tenho em alguns domínios é o "Glue at parent 
> nameservers", a descrição completa do problema é:
> "WARNING. The parent servers (I checked with b.dns.br.) are not 
> providing glue for all your nameservers. This means that they are 
> supplying the NS records (host.example.com), but not supplying the A 
> records (192.0.2.53), which can cause slightly slower connections, and 
> may cause incompatibilities with some non-RFC-compliant programs. This 
> is perfectly acceptable behavior per the RFCs. This will usually occur 
> if your DNS servers are not in the same TLD as your domain (for example, 
> a DNS server of "ns1.example.*org*" for the domain "example.*com*"). In 
> this case, you can speed up the connections slightly by having NS 
> records that are in the same TLD as your domain."

Esta é uma questão que já foi mais controversa mas hoje já se encontra
na prática pacificada devido as consequências perversas das políticas
muitas vezes arbitrárias da coleta de glue records.

Existe um draft, já expirado há um bom tempo, que fala sobre o que já
foi publicado sobre o assunto,

http://tools.ietf.org/id/draft-koch-dns-glue-clarifications-03.txt

Se olhar com cuidado a RFC1034 (4.2.1), único documento ainda válido
em standard-track citado, você verá que a política recomendada é
exatamente a aplicada no .br.

Há muito tempo que servidores DNS autoritativos por default seguem
esta política.

Consistência e simplicidade em uma zona ainda são a melhor forma de
garantia de resolução DNS correta.

> Ou seja, no cadastro do domínio  cliente.com.br, estão cadastrados os 
> servidores dns1.provedor.com.br e dns2.provedor.com.br, mas não estão 
> cadastrados os IPs referentes.
> 
> Preenchendo os IPs no Registro.br, e clicando em Salvar no domínio, ele 
> não chega a apresentar erro, mas também não salva o IP (erro silencioso).
> 
> Isso é até explicado na FAQ do Registro.br, em 
> https://registro.br/faq/faq5.html#6, item 5.6:
> "5.6 Quando é necessário o preenchimento dos campos de endereço IP e IPv6 ?
> Os campos de endereço IP e IPv6 devem ser preenchidos somente nos casos 
> em que o domínio do servidor DNS seja igual ou esteja contido no que 
> está sendo delegado. Nestes casos, o endereço IP é obrigatório e o IPv6 
> opcional. O campo endereço IPv6 deve ser preenchido caso o servidor 
> possua conectividade neste protocolo."

Você não transcreveu o FAQ 5.6 por completo, em especial a última
frase. A informação por não ser necessária é simplesmente ignorada.

"Exemplo: No caso do domínio XYZ.COM.BR delegado para os servidores
FOO.XYZ.COM.BR, NS1.BAR.XYZ.COM.BR e NS1.KZX.COM.BR, para os dois
primeiros servidores, o preenchimento do campo endereço IP é
obrigatório e o campo endereço IPv6 opcional. Já para o terceiro
servidor, não é necessário preencher os campos IP e IPv6 e caso sejam
informados, os mesmos serão descartados."

> Ok, entendo as vantagens e desvantagens dos dois modelos:
> - Apontando para o dns.provedor.com.br, numa eventual troca de IPs do 
> provedor (como ocorreu recentemente com um membro da lista), basta 
> trocar os IPs no domínio principal que está tudo resolvido.
> - Cadastrando o nome e o IP (usando cola :-)), uma consulta recursiva 
> para alcançar um host tende a fazer consultas a menos (não precisa 
> resolver o dns1.provedor.com.br para só depois resolver o 
> www.cliente.com.br), estou certo em presumir isso?

Sim, mas não se esqueça que DNS é uma base de dados distribuída e se
você escolher os TTLs corretamente, em especial para registros de
infra-estrutura como este, na prática esta consulta extra irá ocorrer
esporadicamente. Devido a isto este aviso desta serviço de verificação
DNS é totalmente descabido.

> - Cadastrando o IP, numa eventual troca de IPs é necessário alterar em 
> todos os domínios.
> - Cadastrando apenas o nome, numa eventual falha do domínio principal 
> (falta de pagamento, falha de energia, queda de aeronave), os domínios 
> que dependem dele ficariam fora do ar.

Você não precisa depender de uma única zona, e também muito menos de
um única rede.

> É justamente para essa última situação que quero cadastrar os IPs, não 
> quero que uma falha no domínio principal afete os domínios que dependam 
> dele. Eventualmente vou resolver isso "em casa" mesmo, cadastrando mais 
> um DNS apontando para o próprio domínio e preenchendo o IP. Mas:
> 
> O registro.br não poderia flexibilizar isso? Se eu quero preencher os 
> IPs, permita-me. Se for para ser rígido, que seja então completo, não dê 
> erro silencioso, apresente uma mensagem negando o cadastro de nome e IP 
> em conjunto.
> 
> Entendo que isso obriga a outras checagens de consistência, se o DNS 
> apontado é o IP, inclusive com checagens periódicas a respeito, mas não 
> seria um benefício?

Estas verificações e avisos periódicos já são feitos, mas o que
importa é a consistência do "Zone cut", ou seja resolução real do nome
dos servidores presentes no parent e a existência dos mesmos na zona
com autoridade, o filho.

> Como que funciona em outros TLD?

No passado políticas mais permissivas de glue eram aplicadas em alguns
GTLDs, hoje praticamente todos eles seguem a recomendação presente na
1034. Os que não seguem já apresentaram planos de mudarem antes de
implementarem DNSSEC.

[]s
Fred



More information about the gter mailing list