Uma vez, enfrentei a tarefa de conceder a um dos clientes o direito de editar os registros PTR da sub-rede atribuída a ele / 28. Não tenho automação para editar as configurações do BIND do lado de fora. Então, decidi seguir o outro caminho - delegar ao cliente uma parte da zona de sub-rede PTR / 24.
Parece - o que poderia ser mais fácil? Apenas prescrevemos a sub-rede da maneira correta e a direcionamos para o NS desejado, como é feito com o subdomínio. Mas não. Não é tão simples (embora na realidade seja geralmente primitivo, mas a intuição não ajude), é por isso que estou escrevendo este artigo.
Quem quer descobrir por si mesmo pode ler o
RFCQuem quer uma solução pronta, bem-vindo ao gato.
Para não atrasar quem gosta do método copiar e colar, primeiro postarei a parte prática e depois a parte teórica.
1. Prática. Zona de delegação / 28Digamos que temos uma sub-rede
7.8.9.0/24 . Precisamos delegar a sub-rede
7.8.9.240/28 ao cliente dns
7.8.7.8 (
ns1.client.domain ).
No DNS do provedor, você precisa encontrar um arquivo que descreva a zona reversa dessa sub-rede. Que seja
9.8.7.in-addr.arpa .
As postagens de 240 a 255 são comentadas, se houver. E no final do arquivo, escreva o seguinte:
255-240 IN NS 7.8.7.8 $GENERATE 240-255 $ CNAME $.255-240
não se esqueça de aumentar as zonas seriais e fazer
rndc reload
Com isso, a parte do provedor acabou. Passamos para o cliente DNS.
Primeiro, crie o arquivo
/etc/bind/master/255-240.9.8.7.in-addr.arpa com o seguinte conteúdo:
$ORIGIN 255-240.9.8.7.in-addr.arpa. $TTL 1W @ 1D IN SOA ns1.client.domain. root.client.domain. ( 2008152607 ; serial 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum @ IN NS ns1.client.domain. @ IN NS ns2.client.domain. 241 IN PTR test.client.domain. 242 IN PTR test2.client.domain. 245 IN PTR test5.client.domain.
E no
named.conf, adicione a descrição do nosso novo arquivo:
zone "255-240.9.8.7.in-addr.arpa." IN { type master; file "master/255-240.9.8.7.in-addr.arpa"; };
B reinicie o processo de ligação.
/etc/init.d/named restart
Só isso. Agora você pode conferir.
#> host 7.8.9.245 245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa. 245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.
Observe que não apenas o registro PTR é fornecido, mas também CNAME. Deveria ser assim. Se você se pergunta por que, então seja bem-vindo ao próximo capítulo.
2. Teoria. Como isso funciona?É difícil configurar e depurar uma caixa preta. Muito mais fácil se você entender o que está acontecendo lá dentro.
Quando delegamos um subdomínio no domínio do
domínio , escrevemos algo como isto:
client.domain. NS ns1.client.domain. ns1.client.domain. A 7.8.7.8
Dizemos a todos que pedem que não somos responsáveis por este site e dizemos quem é responsável. E todas as solicitações para
client.domain são redirecionadas para 7.8.7.8. Ao verificar, vemos a seguinte imagem (omita o que o cliente tem lá. Não importa):
# host test.client.domain test.client.domain has address 7.8.9.241
I.e. fomos informados de que existe um registro A e seu ip 7.8.9.241. Nenhuma informação desnecessária.
Mas como a mesma coisa pode ser feita com uma sub-rede?Porque Como nosso servidor DNS está registrado no RIPE, ao solicitar um endereço IP PTR em nossa rede, a primeira solicitação ainda será enviada para nós. A lógica é a mesma que nos domínios. Mas como entrar na sub-rede no arquivo de zona?
Tentamos inseri-lo assim:
255-240 IN NS 7.8.7.8
E ... um milagre não aconteceu. Não recebemos nenhum redirecionamento de solicitação. O problema é que o bind não sabe que essas entradas no arquivo da zona reversa são endereços IP e, mais ainda, para que eles não entendam a entrada do intervalo. Para ele, este é apenas um subdomínio simbólico. I.e. para ligação, não haverá diferença entre "
255-240 " e "
nosso supercliente ". E a solicitação para a solicitação ir para onde deveria estar, o endereço na solicitação deve ter a seguinte aparência:
241.255-240.9.8.7.in-addr.arpa . Ou assim, se usarmos um subdomínio de caractere:
241.oursuperclient.9.8.7.in-addr.arpa . Isso é diferente do usual:
241.9.8.7.in-addr.arpa .
Mãos tal pedido será problemático. E se der certo, ainda não está claro como aplicá-lo na vida real. Afinal, a pedido de
7.8.9.241 , o DNS do provedor, e não o cliente, ainda nos responde.
E aqui
CNAME entra em jogo.
No lado do provedor, você precisa criar um alias para todos os endereços IP da sub-rede em um formato que encaminhará a solicitação ao DNS do cliente.
255-240 IN NS ns1.client.domain. 241 IN CNAME 241.255-240 242 IN CNAME 242.255-240 ..
Isto é para trabalhador =).
E para os preguiçosos, o design abaixo é mais adequado:
255-240 IN NS ns1.client.domain. $GENERATE 240-255 $ CNAME $.255-240
Agora, a solicitação de informações em
7.8.9.241 de
241.9.8.7.in-addr.arpa no servidor DNS do provedor será convertida em
241.255-240.9.8.7.in-addr.arpa e irá para o cliente DNS.
O cliente precisará processar essas solicitações. Assim, criamos uma zona
255-240.9.8.7.in-addr.arpa . Nele, podemos basicamente postar registros reversos para qualquer ip de toda a sub-rede / 24, mas seremos questionados apenas sobre aqueles que o provedor redirecionará para nós, para que você não possa brincar =).
Para ilustrar, darei um exemplo do conteúdo do arquivo de zona reversa no lado do cliente:
$ORIGIN 255-240.9.8.7.in-addr.arpa. $TTL 1W @ 1D IN SOA ns1.client.domain. root.client.domain. ( 2008152607 ; serial 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum @ IN NS ns1.client.domain. @ IN NS ns2.client.domain. 241 IN PTR test.client.domain. 242 IN PTR test2.client.domain. 245 IN PTR test5.client.domain.
Isso se deve ao fato de usarmos CNAME por parte do provedor e, em resposta a uma solicitação de dados no endereço IP, obtemos dois registros, não um.
#> host 7.8.9.245 245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa. 245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.
E não se esqueça de configurar corretamente a ACL. Porque não faz sentido usar uma zona PTR para si mesmo e não responder a ninguém de fora =).