Una vez que me enfrenté a la tarea de darle a uno de los clientes el derecho de editar los registros PTR de la subred asignada a él / 28. No tengo automatización para editar la configuración de BIND desde el exterior. Así que decidí ir hacia otro lado: delegar al cliente una parte de la zona de subred PTR / 24.
Parecería: ¿qué podría ser más fácil? Simplemente prescribimos la subred de la manera correcta y la dirigimos al NS deseado como se hace con el subdominio. Pero no No es tan simple (aunque en realidad es generalmente primitivo, pero la intuición no ayudará), es por eso que estoy escribiendo este artículo.
Quien quiera resolverlo por sí mismo puede leer el
RFC¿Quién quiere una solución preparada? Bienvenido a Cat.
Para no retrasar a los que aman el método de copiar y pegar, primero publicaré la parte práctica y luego la parte teórica.
1. Practica. Zona de delegación / 28Digamos que tenemos una subred de
7.8.9.0/24 . Necesitamos delegar la subred
7.8.9.240/28 al cliente dns
7.8.7.8 (
ns1.client.domain ).
En el DNS del proveedor, debe buscar un archivo que describa la zona inversa de esta subred. Que sea
9.8.7.in-addr.arpa .
Se comentan las publicaciones de 240 a 255, si las hay. Y al final del archivo, escriba lo siguiente:
255-240 IN NS 7.8.7.8 $GENERATE 240-255 $ CNAME $.255-240
no olvides aumentar las zonas seriales y hacer
rndc reload
En esto, la parte del proveedor ha terminado. Pasamos al cliente dns.
Primero, cree el archivo
/etc/bind/master/255-240.9.8.7.in-addr.arpa con el siguiente contenido:
$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.
Y en
named.conf, agregue la descripción de nuestro nuevo archivo:
zone "255-240.9.8.7.in-addr.arpa." IN { type master; file "master/255-240.9.8.7.in-addr.arpa"; };
B reinicia el proceso de enlace.
/etc/init.d/named restart
Eso es todo. Ahora puedes consultar.
#> 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.
Tenga en cuenta que no solo se proporciona el registro PTR, sino también CNAME. Debería ser así. Si te preguntas por qué, entonces bienvenido al próximo capítulo.
2. Teoría. Como funcionaEs difícil configurar y depurar un cuadro negro. Mucho más fácil si entiendes lo que está sucediendo dentro.
Cuando delegamos un subdominio en el dominio del
dominio , escribimos algo como esto:
client.domain. NS ns1.client.domain. ns1.client.domain. A 7.8.7.8
Les decimos a todos que soliciten que no seamos responsables de este sitio y decimos quién es responsable. Y todas las solicitudes a
client.domain se redirigen a 7.8.7.8. Al verificar, vemos la siguiente imagen (omita lo que el cliente tiene allí. No importa):
# host test.client.domain test.client.domain has address 7.8.9.241
Es decir nos informaron que existe un registro A y su ip 7.8.9.241. No hay información innecesaria.
Pero, ¿cómo se puede hacer lo mismo con una subred?Porque Dado que nuestro servidor DNS está registrado en RIPE, cuando solicite una dirección IP PTR de nuestra red, la primera solicitud aún nos será enviada. La lógica es la misma que con los dominios. ¿Pero cómo ingresar la subred en el archivo de zona?
Intentamos ingresarlo así:
255-240 IN NS 7.8.7.8
Y ... no ocurrió un milagro. No recibimos ninguna solicitud de redireccionamiento. Lo que pasa es que bind no es consciente de que estas entradas en el archivo de zona inversa son direcciones IP y aún más, no entienden la entrada de rango. Para él, esto es solo un subdominio simbólico. Es decir para bind no habrá diferencia entre "
255-240 " y "
nuestro supercliente ". Y la solicitud de la solicitud para ir a donde debería estar, la dirección en la solicitud debería verse así:
241.255-240.9.8.7.in-addr.arpa . O así, si usamos un subdominio de caracteres:
241.oursuperclient.9.8.7.in-addr.arpa . Esto es diferente de lo habitual:
241.9.8.7.in-addr.arpa .
Manos tal pedido será problemático. Y si funciona, todavía no está claro cómo aplicarlo en la vida real. Después de todo, a pedido de
7.8.9.241 , el proveedor DNS, y no el cliente, todavía nos responde.
Y aquí entra en juego
CNAME .
En el lado del proveedor, debe crear un alias para todas las direcciones IP de la subred en un formato que reenvíe la solicitud al DNS del cliente.
255-240 IN NS ns1.client.domain. 241 IN CNAME 241.255-240 242 IN CNAME 242.255-240 ..
Esto es para trabajadores =).
Y para los perezosos, el diseño a continuación es más adecuado:
255-240 IN NS ns1.client.domain. $GENERATE 240-255 $ CNAME $.255-240
Ahora la solicitud de información en
7.8.9.241 de
241.9.8.7.in-addr.arpa en el servidor dns del proveedor se convertirá a
241.255-240.9.8.7.in-addr.arpa y se dirigirá al cliente dns.
El cliente deberá procesar tales solicitudes. En consecuencia, creamos una zona de
255-240.9.8.7.in-addr.arpa . En él, básicamente podemos publicar registros inversos para cualquier ip de toda la subred / 24, pero solo se nos preguntará sobre aquellos que el proveedor nos redirigirá, por lo que no podrá jugar =).
Para ilustrar, daré un ejemplo del contenido del archivo de zona inversa en el lado del 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.
Esto se debe al hecho de que usamos CNAME por parte del proveedor y, en respuesta a una solicitud de datos en la dirección IP, obtenemos dos registros, no uno.
#> 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.
Y no olvide configurar correctamente la ACL. Porque no tiene sentido tomar una zona PTR para usted y no responder a nadie desde afuera =).