Existe uma desvantagem nos registros A e AAAA na seção ADICIONAL?

Question

Estou apenas pedindo a possibilidade de ter configurações de ipv4 e ipv6 em um domínio. Se eu fizer dig <domain> , dentro das SEÇÕES ADICIONAIS, serão exibidos os registros A e AAAA.

Há alguma desvantagem de se referir a ambos os registros para esse domínio?

Atualizado:

Resultados da consulta:

;; ANSWER SECTION:
example.edu.my. 1142    IN  A   202.75.5.xxx

;; AUTHORITY SECTION:
xxx.edu.my.     11626   IN  NS  dns2.xxx.xxx.xxx.
xxx.edu.my.     11626   IN  NS  dns1.xxx.xxx.xxx.

;; ADDITIONAL SECTION:
dns2.xxx.xxx.xxx.   1976    IN  A   202.75.5.xxx
dns2.xxx.xxx.xxx.   3490    IN  AAAA    2400:e800:xxxx:xxxx::xxx

Obrigado.

    

Answer 1

A biblioteca de resolução do cliente solicitará A ou AAAA registros conforme apropriado para o tipo de endereçamento IP em uso pelo sistema operacional. Ter os dois tipos de registro coexistindo entre si para as mesmas entidades de host é comum na Internet.

A seção ADDITIONAL do pacote é um pouco diferente.

• Em um contexto autoritativo ( aa sinalizador no pacote de resposta) está fornecendo a cola necessária para resolver quaisquer entidades que foram nomeadas na seção ANSWER , mas na maioria dos casos o servidor de nomes remoto não tem como saber com base no solicitar se um registro IPv4 ou IPv6 é desejado. Em vez de fazer uma suposição sobre o seu tipo de serviço, ele está fornecendo informações para os dois tipos de endereços IP de uma só vez, e a biblioteca de resolução está livre para usar o que for mais apropriado.
• Se esta for uma resposta não autoritativa ( rd sinalizador definido na consulta, aa ausente na resposta), não entre em pânico se AAAA registros estiverem faltando na seção ADDITIONAL . Isto é normal. Consulte: RHEL5 - Bind não retorna registros IPv6

A única desvantagem real é o aumento do tamanho do pacote de resposta. Em cenários normais, isso não acontece com muita frequência, existem algumas dicas com isso:

• Muitos registros NS podem fazer com que o tamanho de uma resposta SOA seja de > 512 bytes, o que causou a falha nas transferências de zona com o BIND.
• É um fator relevante em ser usado como intermediário em ataques de amplificação de DNS contra IPs de origem falsificados.