É um subdomínio com registros A e registros NS válidos?

Question

Digamos que eu possua example.com .

Eu então crio um registro A em test.example.com to 1.1.1.1 .

Eu, então, crio um registro NS em test.example.com to ns1.anotherdnshost.com .

Em outro host DNS, eu adiciono um registro A para a raiz ( test.example.com ) para 2.2.2.2 .

Quando o cliente consulta test.example.com , qual A será retornado? Qual seria o registro mais "dominante" de A ? Uma configuração como essa é válida?

    

Answer 1

Isso não é válido, não. Ele provavelmente retornará o 1.1.1.1 como seria retornado pelo primeiro servidor que resolve, mas o valor "correto" deve ser o servidor de nomes registrado como primário pelo registro SOA. Mas, o que é retornado pode depender de qual versão do software do servidor de nomes é executada. Veja abaixo, ele apenas irá encaminhá-lo para o próximo servidor de nomes, e 1.1.1.1 nunca será mostrado.

Agora, é correto listar outros registros NS em sua zona, mas os outros NS devem ser servidores de nomes com zonas idênticas. Você pode apontar seus subdomínios para servidores de nomes alternativos.

O exemplo.com do registrador aponta para ns1.example.com e ns2.example.com com os IPs 1.2.3.4 e 2.3.4.5 do servidor de nomes de registradores (cola).

Você teria uma zona com SOA escolhendo ns1 ou ns2 como principal e, em seguida, teria dois registros NS apontando para ns1.example.com e ns2.example.com com os registros A desse domínio (e mx, txt, cname, etc).

Tanto o NS1 quanto o NS2.example.com devem ter zonas idênticas e devem se replicar automaticamente.

Agora é válido, tomar test.example.com e apontar para ns1.somethingelse.com e ns2.somethingelse.com, mas NÃO há registros para test.example.com nos servidores de nomes ns1 e ns2.example.com, exceto ns1 e ns2.example.com devem enviar automaticamente os IPs para ns1 e ns2.somethingelse.com se tiverem cola. (Não será diferente se o TLD for diferente, ou seja, .com e .org)

Espero que tudo tenha feito sentido, posso esclarecer mais, se alguma delas for confusa.

Aqui está um teste do que acontece:

No servidor de nomes do shadowrpg.net:

$ttl 38400
@   IN  SOA shell2.reganw.com. root.shell2.reganw.com. (
            1298345653
            10800
            3600
            604800
            38400 )
@   IN  NS  shell2.reganw.com.
test.shadowrpg.net.     IN  A   127.0.0.1
test.shadowrpg.net. IN  NS  saber.reganw.com.

No servidor de nomes do test.shadowrpg.net (sabre):

$ttl 38400
@   IN  SOA saber.reganw.com. root.shell2.reganw.com. (
            1298345653
            10800
            3600
            604800
            38400 )
@   IN  NS  saber.reganw.com.
test.shadowrpg.net.     IN  A   127.0.0.2
test.shadowrpg.net. IN  NS  saber.reganw.com.

O primeiro resultado, é com sabre não configurado, para mostrar a referência.

[regan@gamma ~]$ dig +trace test.shadowrpg.net

; <<>> DiG 9.7.3-P1-RedHat-9.7.3-2.P1.fc13 <<>> +trace test.shadowrpg.net
;; global options: +cmd
.           518400  IN  NS  G.ROOT-SERVERS.NET.
.           518400  IN  NS  C.ROOT-SERVERS.NET. (snip)
;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 2 ms

net.            172800  IN  NS  a.gtld-servers.net.
net.            172800  IN  NS  m.gtld-servers.net. (snip)
;; Received 493 bytes from 199.7.83.42#53(199.7.83.42) in 55 ms

shadowrpg.net.      172800  IN  NS  ns1.reganw.com.
shadowrpg.net.      172800  IN  NS  ns2.reganw.com.
shadowrpg.net.      172800  IN  NS  ns3.reganw.com.
;; Received 232 bytes from 192.35.51.30#53(192.35.51.30) in 54 ms

test.shadowrpg.net. 38400   IN  NS  saber.reganw.com.
;; Received 110 bytes from 209.161.6.3#53(209.161.6.3) in 2123 ms

test.shadowrpg.net. 38400   IN  NS  saber.reganw.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 110 bytes from 173.45.238.245#53(173.45.238.245) in 81 ms

test.shadowrpg.net. 38400   IN  NS  saber.reganw.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 110 bytes from 173.45.238.245#53(173.45.238.245) in 82 ms

test.shadowrpg.net. 38400   IN  NS  saber.reganw.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 110 bytes from 173.45.238.245#53(173.45.238.245) in 112 ms

E com o sabre configurado:

^C[regan@gamma ~]$ dig +trace test.shadowrpg.net

; <<>> DiG 9.7.3-P1-RedHat-9.7.3-2.P1.fc13 <<>> +trace test.shadowrpg.net
;; global options: +cmd
.           518400  IN  NS  L.ROOT-SERVERS.NET.
.           518400  IN  NS  J.ROOT-SERVERS.NET. (snip)
;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 2 ms

net.            172800  IN  NS  m.gtld-servers.net.
net.            172800  IN  NS  a.gtld-servers.net. (snip)
;; Received 493 bytes from 198.41.0.4#53(198.41.0.4) in 129 ms

shadowrpg.net.      172800  IN  NS  ns1.reganw.com.
shadowrpg.net.      172800  IN  NS  ns2.reganw.com.
shadowrpg.net.      172800  IN  NS  ns3.reganw.com.
;; Received 232 bytes from 192.12.94.30#53(192.12.94.30) in 165 ms

test.shadowrpg.net. 38400   IN  NS  saber.reganw.com.
;; Received 110 bytes from 209.161.6.3#53(209.161.6.3) in 38 ms

test.shadowrpg.net. 38400   IN  A   127.0.0.2
test.shadowrpg.net. 38400   IN  NS  saber.reganw.com.
;; Received 126 bytes from 173.45.238.245#53(173.45.238.245) in 80 ms

[regan@gamma ~]$ 

Portanto, uma vez que você adiciona um registro NS, ele o refere e ignora qualquer consulta para si mesmo. Agora, se você adicionar um registro A para o servidor de nomes, ele passará com o registro NS como uma cola (para que o resolvedor não tenha que procurar o IP para o novo servidor de nomes).

    

Answer 2

Esse problema é um tanto sutil, então deixe-me explicar um por um.

A configuração correta deve ter apenas um dos dois - NS ou qualquer outro registro.

Quando você adiciona um registro NS para test.example.com , você delega tudo de test.example.com e abaixo para outro servidor de nomes. O local normal para o registro A de test.net-me.net seria em ns1.anotherdnshost.com .

Agora, a sua pergunta pode ser reformulada - não há problema em ter a zona test.example.com A ... in the "parent" example.com zone ? The same question may be asked regardless of any records which may exist or not in the delegada em outro host.

Minha resposta será dialética :) 1. Sim, não há problema em ter esses registros na zona "pai". Mas 2. Como test.example.com delegado para ns1.anotherdnshost.com , registra test.example.com e abaixo, que existem (por qualquer motivo) em qualquer servidor que não seja ns1.anotherdnshost.com não é mais autoritativo .

Servidor da zona pai, quando responde a test.example.com query, a) Deve enviar o registro NS apontando para ns1.anotherdnshost.com eb) Pode ou não pode enviar Um registro para test.example.com acontece, c) mesmo que envie o registro, não deve marcá-lo como uma resposta " autoritativa ", d) mesmo se estiver e sinalizar tal resposta como autoritativa, o resolvedor que recebe tal resposta, já que sabe que test.example.com é delagado , deve considerar somente respostas de seu servidor autoritativo - ns1.anotherdnshost.com ).

Eu testei essa configuração com bind9:

• nomeado, nem o named-checkzone não reclama de tal zona - aparentemente esta zona é considerada correta.
• Quando eu consultar o servidor pai para test.example.com, ele retornará registros somente do NS, como se o test.example.com A 1.1.1.1 não existisse.

Outro software de servidores DNS pode se comportar de maneira diferente, mas, de qualquer forma, deve obedecer às regras gerais acima.

Este artigo relacionado da Verisign me ajudou a entender esse problema.

Eu sinto muito por todos os blah blah blah

    

Answer 3

Essa não é uma configuração válida, você nunca saberá para onde será redirecionada.

Quando você define os registros do NS em seu domínio, esse DNS se torna a autoridade. Se alguém solicitar o IP do seu domínio, ele verificará o cache dele e, se não houver nenhum registro, ele perguntará ao DNS listado nos registros do NS.

E o que acontece agora se você criar outro registro A (2.2.2.2) em seu domínio em outro DNS? Então todos os clientes que usam esse DNS, obteriam seu "novo" IP (2.2.2.2) e não o real.

    

Answer 4

É completamente válido, mas não do jeito que você está pensando.

Depois de delegar um subdomínio a outro conjunto de servidores de nomes, eles são autoritativos. Eles podem anunciar legalmente um registro A para o domínio; de fato, é uma prática normal fazer isso, veja, por exemplo, dig google.com .

Eu não tenho idéia do que acontece se você anunciar o registro A nos servidores delegados de nome - nada de bom, eu suspeito, como todo mundo está corretamente aconselhando você. Mas anunciar esse registro é perfeitamente válido nos servidores delegados , o que é provavelmente o motivo pelo qual você não encontra nenhuma proibição nos RFCs.

Portanto, o problema não está na existência de registros A e NS para um domínio; está tentando anunciar ambos os registros dos mesmos nameservers .

    

Answer 5

test.example.com A 2.2.2.2 deve ser retornado, pois é o autoritativo ("dominante").

Esta configuração não viola os RFCs.

Raciocínio na minha resposta mais longa aqui.