No DNS, um IN NS pode apontar para um CNAME?

17

É permitido que um registro NS seja um CNAME? Por exemplo:

subdomain.example.com.       IN NS  ns1.example.com.
ns1.example.com.             CNAME  foo.example.com.
foo.example.com.             IN A   10.1.1.1

Isso não parece funcionar no bind, mas isso (é claro):

subdomain.example.com.       IN NS  foo.example.com.
foo.example.com.             IN A   10.1.1.1

Quaisquer indicadores para RFCs que proíbem essa configuração serão apreciados.

domain-name-system cname-record ns-record Mark Wagner
fonte

Respostas:

20

A RFC real que define o NS RR ( RFC1035 ) apenas diz que é um nome de domínio sem especificar o tipo RR do destino (embora deixe claro que não pode ser um IP). Ele é mencionado especificamente no RFC1912 , seção 2.4:

Ter registros NS apontando para um CNAME é ruim e pode entrar em conflito com os servidores BIND atuais. De fato, as implementações atuais do BIND ignoram esses registros, possivelmente levando a uma delegação fraca. Há uma certa quantidade de verificação de segurança feita no BIND para impedir a falsificação de registros DNS DNS. Além disso, os servidores BIND mais antigos supostamente serão pegos em um loop de consulta infinito, tentando descobrir o endereço do servidor de nomes com alias, fazendo com que um fluxo contínuo de solicitações de DNS seja enviado.

Não é um DEVE NÃO, mas certamente se encaixa no comportamento que você está vendo

jj33
fonte
5
E o RFC1034 diz: "Os nomes de domínio nos RRs que apontam para outro nome sempre devem apontar para o nome primário e não o alias. Isso evita indiretos extras no acesso às informações ... É claro que, pelo princípio da robustez, o software de domínio não deve falhar. quando apresentados com cadeias ou loops CNAME; as cadeias CNAME devem ser seguidas e os loops CNAME sinalizados como um erro. "
Larsks
10
Descobri que a RFC 2181 10.3 diz claramente que é inválida, mas sua resposta foi boa o suficiente.
Mark Wagner
1
Para maior clareza: a MUST NOTverborragia não importa aqui porque a RFC 1912 é informativa e não define um padrão. Marque está correto que RFC 2181 é a referência correta. (RFC 1034 foi escrito antes dos padrões de linguagem solidificado, daí a imprecisão)
Andrew B