A delegação de um / 22 é fácil, é delegação dos 4 / 24s. A / 14 é delegação dos 4 / 16s, etc.
RFC2317 abrange os casos especiais com uma máscara de rede superior a / 24. Basicamente não há uma maneira super-limpa de fazer delegação de zonas in-addr.arpa em nada além de limites de octetos, mas você pode contornar isso. Digamos que eu queira delegar 172.16.23.16/29, que seriam os endereços IP 172.16.23.16 - > 172.16.23.23.
Como o proprietário da zona 23.16.172.in-addr.arpa, eu poderia colocar isso no meu arquivo de zona 23.16.172.rev para delegar esse intervalo ao meu cliente:
16-29 IN NS ns1.customer.com
16-29 IN NS ns2.customer.com
16 IN CNAME 16.16-29.23.16.172.in-addr.arpa.
17 IN CNAME 17.16-29.23.16.172.in-addr.arpa.
18 IN CNAME 18.16-29.23.16.172.in-addr.arpa.
19 IN CNAME 19.16-29.23.16.172.in-addr.arpa.
20 IN CNAME 20.16-29.23.16.172.in-addr.arpa.
21 IN CNAME 21.16-29.23.16.172.in-addr.arpa.
22 IN CNAME 22.16-29.23.16.172.in-addr.arpa.
23 IN CNAME 23.16-29.23.16.172.in-addr.arpa.
Assim, você pode ver que estou definindo uma nova zona (16-29.23.16.172.in-addr.arpa.) e delegando-a aos servidores de nome do meu cliente. Então, estou criando CNAMEs dos IPs a serem delegados ao número correspondente na nova zona delegada.
Como o cliente a quem foram delegados, eu faria algo parecido com o seguinte no named.conf:
zone "16-29.23.16.172.in-addr.arpa" {
type master;
file "masters/16-29.23.16.172.rev";
};
E, em seguida, no arquivo .rev, gostaria de fazer PTRs como qualquer zona in-addr.arpa normal:
17 IN PTR office.customer.com.
18 IN PTR www.customer.com.
(etc)
Esse é o modo mais limpo de fazer isso e deixa o cliente mais inteligente satisfeito, porque eles têm uma zona in-addr.arpa para colocar os PTRs, etc. Uma forma mais curta de fazer isso para o cliente que deseja controlar o DNS reverso mas não quer configurar uma zona inteira é apenas o registro individual CNAME para nomes semelhantes em sua zona principal.
Nesse caso, nós, como delegadores, teríamos algo assim em nosso arquivo 23.16.172.rev:
16 IN CNAME 16.customer.com.
17 IN CNAME 17.customer.com.
18 IN CNAME 18.customer.com.
19 IN CNAME 19.customer.com.
20 IN CNAME 20.customer.com.
21 IN CNAME 21.customer.com.
22 IN CNAME 22.customer.com.
23 IN CNAME 23.customer.com.
Portanto, é semelhante em conceito à outra ideia, mas em vez de criar uma nova zona e delegá-la ao cliente, você está CNAMEnizando os registros para nomes na zona principal já existente do cliente.
O cliente teria algo assim em seu arquivo de zona customer.com:
office IN A 172.16.23.17
17 IN PTR office.customer.com.
www IN A 172.16.23.18
18 IN PTR www.customer.com.
(etc)
Depende apenas do tipo de cliente. Como eu disse, só depende do tipo de cliente. Um cliente experiente preferirá configurar sua própria zona in-addr.arpa e achará muito estranho ter PTRs em uma zona de nome de domínio. Um cliente pouco experiente vai querer "apenas trabalhar" sem ter que fazer uma tonelada de configuração extra.
Existem outros métodos, apenas detalhando os dois que eu conheço.
Eu estava apenas pensando sobre minha declaração sobre como / 22 e / 14 são fáceis e pensando no porquê isso é verdade, mas qualquer coisa entre 25 e 32 é difícil. Eu não testei isso, mas eu vaguei se você pudesse delegar o / 32 inteiro para o cliente assim:
16 IN NS ns1.customer.com.
17 IN NS ns1.customer.com.
(etc)
Então, no lado do cliente, você pega todo o / 32:
zone "16.23.16.172.in-addr.arpa" { type master; file "masters/16.23.16.172.rev"; };
zone "17.23.16.172.in-addr.arpa" { type master; file "masters/17.23.16.172.rev"; };
(etc)
E, no arquivo individual, você teria algo assim:
@ IN PTR office.customer.com.
A desvantagem óbvia é que um arquivo por / 32 é meio bruto. Mas aposto que funcionaria.
Todas as coisas que mencionei são DNS puro, se algum servidor DNS não permitir que você faça isso, é porque está restringindo a funcionalidade completa do DNS. Meus exemplos estão obviamente usando o BIND, mas fizemos o lado do cliente usando o DNS do Windows e o BIND. Não vejo uma razão para não funcionar com qualquer servidor.