Um dia, me deparei com a tarefa de conceder a um dos clientes o direito de editar os registros PTR da sub-rede /28 que lhe foi dada. Não tenho automação para editar as configurações do BIND externamente. Portanto, decidi seguir por outro caminho — delegar ao cliente um pedaço da zona PTR da sub-rede /24.
À primeira vista, poderia parecer simples. Basta escrever a sub-rede da maneira correta e direcioná-la para o NS apropriado, assim como fazemos com subdomínios. Mas não é tão simples. Não é nada complicado na verdade, mas a intuição não ajuda, por isso escrevo este artigo.
Quem quiser entender por conta própria, pode ler.
Quem quer uma solução pronta, fique à vontade para continuar.
Para não atrasar aqueles que adoram o método do copiar e colar, primeiro eu vou apresentar a parte prática, e depois a teórica.
1. Prática. Delegamos a zona /28.
Suponhamos que temos uma sub-rede. 7.8.9.0/24. Precisamos delegar a sub-rede 7.8.9.240/28 para o cliente DNS 7.8.7.8 (ns1.client.domain).
No DNS do provedor, precisamos encontrar o arquivo que descreve a zona reversa dessa sub-rede. Vamos chamá-lo de 9.8.7.in-addr.arpa.
Comentamos os registros de 240 a 255, se houver. E ao final do arquivo, escrevemos o seguinte:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240não esquecemos de aumentar o serial da zona e fazemos
rndc reloadCom isso, a parte do provedor está concluída. Vamos para o DNS do cliente.
Para começar, vamos criar um arquivo /etc/bind/master/255-240.9.8.7.in-addr.arpa users.module.ts
$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 adicionamos 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";
};Reiniciamos o processo do BIND.
/etc/init.d/named restartPronto. Agora podemos verificar.
#> 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 é devolvido, mas também o CNAME. Isso é esperado. Se você está curioso sobre o motivo, continue para o próximo capítulo.
2. Teoria. Como isso funciona.
É complicado configurar e depurar uma caixa-preta. É muito mais fácil se você entender o que acontece por dentro.
Quando delegamos um subdomínio em um domínio domínio, escrevemos algo como isto:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Dizemos a todos que perguntam que não respondemos por esta zona e dizemos quem responde. E todos os pedidos para client.domain são redirecionados para 7.8.7.8. Ao verificar, vemos a seguinte situação (deixemos de lado o que está com o cliente, isso não é importante):
# host test.client.domain
test.client.domain has address 7.8.9.241Ou seja, fomos informados de que existe um registro A e seu IP é 7.8.9.241. Nenhuma informação adicional.
E como posso fazer o mesmo com a sub-rede?
Como nosso servidor DNS está registrado no RIPE, ao solicitar um registro PTR para o endereço IP da nossa rede, o primeiro pedido ainda será para nós. A lógica é a mesma que para domínios. Mas como incluir a sub-rede no arquivo da zona?
Tentamos escrever assim:
255-240 IN NS 7.8.7.8E… não aconteceu nenhum milagre. Não recebemos nenhum redirecionamento do pedido. A questão é que o bind não tem conhecimento de que esses registros no arquivo da zona reversa são endereços IP e muito menos entende o registro de intervalo. Para ele, isso é apenas um subdomínio qualquer. Ou seja, para o bind não haverá diferença entre "255-240” e “oursuperclient". E para que o pedido seja direcionado corretamente, o endereço na solicitação deve parecer assim: 241.255-240.9.8.7.in-addr.arpa. Ou assim, se usarmos um subdomínio simbólico: 241.oursuperclient.9.8.7.in-addr.arpa. Isso é diferente do normal: 241.9.8.7.in-addr.arpa.
Fazer tal pedido manualmente será problemático. E mesmo que funcione, ainda não está claro como aplicar isso na vida real. Pois, ao solicitar, 7.8.9.241 ainda recebemos resposta do DNS do provedor, e não do cliente.
E aqui é onde entra em cena CNAME.
Do lado do provedor, é necessário fazer um alias para todos os endereços IP da sub-rede em um formato que redirecione 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
etc.
Isso é para os trabalhadores =).
E para os preguiçosos, a construção abaixo é mais adequada:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Agora a solicitação de informações para o endereço 7.8.9.241 do 241.9.8.7.in-addr.arpa no servidor DNS do provedor será transformada em 241.255-240.9.8.7.in-addr.arpa e será enviada ao DNS do cliente.
Do lado do cliente, será necessário processar tais pedidos. Assim, criamos uma zona 255-240.9.8.7.in-addr.arpa. Nela, basicamente, podemos colocar registros reversos para quaisquer IPs de toda a sub-rede /24, mas apenas nos perguntarão sobre aqueles que o provedor nos redirecionar, então não podemos brincar muito =).
Para ilustrar, mais uma vez trago um exemplo do conteúdo do arquivo da zona reversa do 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.
É por isso que, do lado do provedor, usamos CNAME, e recebemos em resposta à solicitação de dados por endereço IP duas entradas, e não uma.
#> 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 o ACL. Porque é inútil pegar a zona PTR e não responder a ninguém do lado externo =).
Fonte: habr.com
