Un día afrontei a tarefa de darlle a un dos meus clientes o dereito de editar os rexistros PTR da subrede /28 que se lle asignou. Non teño automatización para editar a configuración de BIND desde fóra. Polo tanto, decidín tomar unha ruta diferente: delegar no cliente un anaco da zona PTR da subrede /24.
Parece que - que podería ser máis sinxelo? Simplemente rexistramos a subrede segundo sexa necesario e dirixímola ao NS desexado, como se fai cun subdominio. Pero non. Non é tan sinxelo (aínda que en realidade é xeralmente primitivo, pero a intuición non axuda), por iso escribo este artigo.
Quen queira descubrilo por si mesmo pode ler
Quen quere unha solución preparada, benvido ao gato.
Para non demorar aos que lles gusta o método copiar-pegar, publicarei primeiro a parte práctica, e despois a parte teórica.
1. Práctica. Zona delegada /28
Digamos que temos unha subrede 7.8.9.0/24. Necesitamos delegar a subrede 7.8.9.240/28 ao cliente dns 7.8.7.8 (ns1.cliente.dominio).
No DNS do provedor cómpre atopar un ficheiro que describa a zona inversa desta subrede. Déixao estar 9.8.7.en-addr.arpa.
Comentamos as entradas do 240 ao 255, se as hai. E ao final do ficheiro escribimos o seguinte:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240non se esqueza de aumentar a zona de serie e facer
rndc reloadIsto completa a parte do provedor. Pasemos ao cliente dns.
Primeiro, imos crear un ficheiro /etc/bind/master/255-240.9.8.7.in-addr.arpa o seguinte contido:
$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 dentro nomeado.conf engadir unha descrición do noso novo ficheiro:
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};B reinicia o proceso de vinculación.
/etc/init.d/named restartTodos. Agora podes comprobar.
#> 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.Teña en conta que non só se proporciona o rexistro PTR, senón tamén o CNAME. Así debe ser. Se estás a preguntar por que, benvido ao seguinte capítulo.
2. Teoría. Cómo funciona.
É difícil configurar e depurar unha caixa negra. É moito máis doado se entendes o que está a pasar dentro.
Cando delegamos un subdominio nun dominio dominio, entón escribimos algo así:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Dicímoslle a todos os que nos preguntan que non somos responsables desta área e de quen é o responsable. E todas as solicitudes para cliente.dominio redireccionar a 7.8.7.8. Ao comprobar, vemos a seguinte imaxe (omitiremos o que o cliente ten alí. Non importa):
# host test.client.domain
test.client.domain has address 7.8.9.241Eses. informáronnos de que existe un rexistro A e que a súa ip é 7.8.9.241. Sen información innecesaria.
Como se pode facer o mesmo cunha subrede?
Porque o noso servidor DNS está rexistrado en RIPE, entón cando solicite un enderezo IP PTR da nosa rede, a primeira solicitude seguirá sendo para nós. A lóxica é a mesma que cos dominios. Pero como se introduce unha subrede nun ficheiro de zona?
Imos tentar introducilo así:
255-240 IN NS 7.8.7.8E... o milagre non ocorreu. Non estamos recibindo ningunha solicitude de redirección. O caso é que bind nin sequera sabe que estas entradas do ficheiro de zona inversa son enderezos IP, e aínda máis non entende a entrada do intervalo. Para el, isto é só unha especie de subdominio simbólico. Eses. para vincular non haberá diferenza entre "255-240"E"o noso supercliente". E para que a solicitude vaia onde ten que ir, o enderezo da solicitude debe ser así: 241.255-240.9.8.7.in-addr.arpa. Ou así se usamos un subdominio de caracteres: 241.o noso supercliente.9.8.7.in-addr.arpa. Isto é diferente do habitual: 241.9.8.7.en-addr.arpa.
Será difícil facer tal solicitude manualmente. E aínda que funcione, aínda non está claro como aplicalo na vida real. Despois de todo, a petición 7.8.9.241 O DNS do provedor aínda nos responde, non o do cliente.
E aquí é onde entran en xogo CNAME.
Por parte do provedor, cómpre facer un alias para todos os enderezos IP da subrede nun formato que reenviará a solicitude 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 traballadores =).
E para os preguiceiros, o seguinte deseño é máis axeitado:
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240Agora solicita información en 7.8.9.241 de 241.9.8.7.en-addr.arpa no servidor DNS do provedor converterase a 241.255-240.9.8.7.in-addr.arpa e vai ao cliente dns.
O lado do cliente terá que xestionar tales solicitudes. En consecuencia, creamos unha zona 255-240.9.8.7.in-addr.arpa. Nel, podemos, en principio, colocar entradas inversas para calquera ip de toda a subrede /24, pero só nos preguntarán sobre as que nos envía o provedor, polo que non poderemos xogar =).
Para ilustralo, vou dar unha vez máis un exemplo do contido dun ficheiro de zona inversa 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 usamos CNAME por parte do provedor e, en resposta a unha solicitude de datos por enderezo IP, recibimos dous rexistros, non un.
#> 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 non esquezas configurar a ACL correctamente. Porque non ten sentido tomar unha zona PTR para ti e non responder a ninguén de fóra =).
Fonte: www.habr.com