Um dia me deparei com a tarefa de dar a um de meus clientes o direito de editar os registros PTR da sub-rede /28 atribuída a ele. Não tenho automação para editar configurações do BIND externamente. Portanto, decidi seguir um caminho diferente - delegar ao cliente um pedaço da zona PTR da sub-rede /24.
Ao que parece - o que poderia ser mais simples? Simplesmente registramos a sub-rede conforme necessário e direcionamos para o NS desejado, como é feito com um subdomínio. Mas não. Não é tão simples (embora na realidade seja geralmente primitivo, mas a intuição não ajuda), é por isso que estou escrevendo este artigo.
Qualquer pessoa que queira descobrir por si mesma pode ler
Quem quer uma solução pronta, seja bem-vindo ao gato.
Para não atrasar quem gosta do método copiar e colar, postarei primeiro a parte prática e depois a parte teórica.
1. Pratique. Zona de delegação /28
Digamos que temos uma sub-rede 7.8.9.0/24. Precisamos delegar a sub-rede 7.8.9.240/28 para cliente DNS 7.8.7.8 (ns1.cliente.domínio).
No DNS do provedor você precisa encontrar um arquivo que descreva a zona reversa desta sub-rede. Deixe estar 9.8.7.in-addr.harp.
Comentamos as entradas de 240 a 255, se houver. E no final do arquivo escrevemos o seguinte:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240não esqueça de aumentar a zona serial e fazer
rndc reloadIsso completa a parte do provedor. Vamos passar para o DNS do cliente.
Primeiro, vamos criar um arquivo /etc/bind/master/255-240.9.8.7.in-addr.arpa 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 em nomeado.conf adicione uma 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 restartTodos. Agora você pode 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 é fornecido apenas o registro PTR, mas também o CNAME. É assim que deve ser. Se você está se perguntando por que, seja bem-vindo ao próximo capítulo.
2. Teoria. Como 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 em um domínio domínio, então escrevemos algo assim:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Dizemos a todos que perguntam que não somos responsáveis por este site e dizemos quem é o responsável. E todos os pedidos de cliente.domínio redirecionar para 7.8.7.8. Ao verificar, vemos a seguinte imagem (omitiremos o que o cliente tem ali. Não importa):
# host test.client.domain
test.client.domain has address 7.8.9.241Aqueles. fomos informados de que existe tal registro A e seu ip é 7.8.9.241. Nenhuma informação desnecessária.
Como a mesma coisa pode ser feita com uma sub-rede?
Porque nosso servidor DNS está registrado no RIPE, então ao solicitar um endereço IP PTR da nossa rede, a primeira solicitação ainda será para nós. A lógica é a mesma dos domínios. Mas como você insere uma sub-rede em um arquivo de zona?
Vamos tentar inserir assim:
255-240 IN NS 7.8.7.8E... o milagre não aconteceu. Não estamos recebendo nenhum redirecionamento de solicitação. O problema é que o bind nem sabe que essas entradas no arquivo de zona reversa são endereços IP e, mais ainda, não entende a entrada do intervalo. Para ele, isso é apenas uma espécie de subdomínio simbólico. Aqueles. para bind não haverá diferença entre "255-240"E"nossosupercliente". E para que a solicitação chegue aonde precisa, o endereço na solicitação deve ser assim: 241.255-240.9.8.7.in-addr.arpa. Ou assim se usarmos um subdomínio de caracteres: 241.oursuperclient.9.8.7.in-addr.arpa. Isto é diferente do habitual: 241.9.8.7.in-addr.harp.
Será difícil fazer tal solicitação manualmente. E mesmo que funcione, ainda não está claro como aplicá-lo na vida real. Afinal, mediante solicitação 7.8.9.241 O DNS do provedor ainda responde a nós, não ao do cliente.
E é aqui que eles entram em jogo CNAME.
Do lado do provedor, você precisa criar um alias para todos os endereços IP da sub-rede em um formato que encaminhe 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 os trabalhadores =).
E para os preguiçosos, o design abaixo é mais adequado:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Solicite agora informações em 7.8.9.241 de 241.9.8.7.in-addr.harp no servidor DNS do provedor será convertido para 241.255-240.9.8.7.in-addr.arpa e vai para o cliente DNS.
O lado do cliente precisará lidar com essas solicitações. Assim, criamos uma zona 255-240.9.8.7.in-addr.arpa. Nele podemos, a princípio, colocar entradas reversas para qualquer ip de toda a sub-rede /24, mas eles só vão nos perguntar sobre aqueles que o provedor nos encaminha, então não poderemos brincar =).
Para ilustrar, darei mais uma vez um exemplo do conteúdo de um arquivo de 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.
É porque utilizamos CNAME do lado do provedor, e em resposta a uma solicitação de dados por endereço IP recebemos dois registros, e 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 esqueça de configurar a ACL corretamente. Porque não faz sentido tomar uma zona PTR para si e não responder a ninguém de fora =).
Fonte: habr.com