Não tenho certeza sobre bind, mas o DNS do Windows sobe (example.com é avaliado primeiro) e como a zona não redelega o test.example.com - que é o fim (ou seja, test.example.com nunca é perguntado) .
Estou tentando entender como (ou se) um servidor DNS diferencia entre uma configuração de subdomínio como uma zona e uma configuração como um registro em uma zona de domínio no mesmo servidor.
Digamos que eu crie uma zona DNS em um servidor DNS para um domínio, por exemplo example.com.
O que impede alguém de criar outra zona, test.example.com, no mesmo servidor e "seqüestrar" esse subdomínio do domínio?
Quando uma solicitação de DNS é feita ao servidor de nomes para test.example.com, o servidor DNS retornará:
(e se o registro de test.example.com não existir em example.com, ele não retornará nenhum registro ou continuará na zona de test.example.com)
Existe alguma maneira de impedir que a zona de subdomínio responda sem mover os domínios para seu próprio servidor de nomes exclusivo? Como os gostos do ZoneEdit e do Amazon Route53 lidam com isso?
(Se um subdomínio fosse hospedado em um servidor separado, a zona principal de example.com teria que delegar o subdomínio a esse servidor separado, correto? (conforme este artigo da Technet ).
Não tenho certeza sobre bind, mas o DNS do Windows sobe (example.com é avaliado primeiro) e como a zona não redelega o test.example.com - que é o fim (ou seja, test.example.com nunca é perguntado) .
"O que impede alguém de criar outra zona, test.example.com, no mesmo servidor e 'sequestrar' esse subdomínio do domínio?"
Bem, se eles podem fazer isso, eles também podem apenas alterar o arquivo de zona original; em geral, se alguém tiver acesso ao seu servidor DNS, eles poderão alterar o DNS para o que quiserem.
"Quando uma solicitação de DNS é feita ao servidor de nomes para test.example.com, o servidor DNS retornará:
The main A record of the test.example.com zone or
The test.example.com A record in the example.com zone"
Como sempre, a resposta é "Depende de como você configurou". Se o servidor for autoritativo para example.com e não tiver delegado test.example.com, ele responderá, mas está configurado para responder; do ponto de vista do protocolo, não há diferença na zona test.example.com com um registro @ A e a zona example.com tendo um registro test A. Se você está perguntando o que acontece se houver colisões (por exemplo, você definiu test.example.com no arquivo de zona example.com e seu interloper nefasto definiu um arquivo de zona test.example.com, bem, novamente, ele Teria que ser capaz de escrever named.conf para obter BIND para lê-lo para começar, em que ponto ele poderia apenas fazer o que quisesse de qualquer maneira). IIRC O DNS do Windows se recusará a carregar colisões e o BIND será executado com o que for carregado por último (eu posso ter isso de trás para frente, no entanto). Mas em ambos os casos, para alguém ter sua definição de zona em um servidor de nomes em execução, ele precisa ter acesso suficiente para poder fazer o que quiser com seu DNS.
Esse controle precisaria ser externo ao BIND, já que o próprio BIND não tem esses controles de acesso.
Estou procurando os documentos oficiais, mas acredito que o bind corresponda à zona mais específica, conforme definido no named.conf.
Assim, as zonas serão processadas na ordem mais específica. Se você tivesse zonas únicas para cada uma delas:
host.sub.domain.com
sub.domain.com
domain.com
Em seguida, uma pesquisa para a.host.sub.domain.com será usada preferencialmente nas outras zonas.
Portanto, para responder à sua pergunta, você precisaria criar essa segurança em um editor de zona ou restringir o acesso para que os usuários possam editar apenas seus próprios arquivos de zona.
Eu trabalho em sistemas cPanel / WHM e eles usam arquivos de zona para cada subdomínio. O painel WHM reforça a segurança necessária para impedir que um usuário roube outra zona de usuários.