Un día se me presentó el desafío de conceder a uno de los clientes el derecho a editar los registros PTR de la subred que se le había asignado /28. No tengo automatización para editar la configuración de BIND desde afuera. Por lo tanto, decidí tomar otro camino: delegar al cliente un fragmento de la zona PTR de la subred /24.
Aparentemente, ¿qué podría ser más sencillo? Simplemente especificamos la subred de la manera correcta y la dirigimos al NS adecuado, como se hace con un subdominio. Pero no. No es tan sencillo (aunque en realidad es bastante primitivo, pero la intuición no ayudará), por eso escribo este artículo.
Quien quiera entenderlo por sí mismo puede leer
Quien busque una solución lista, bienvenido al post.
Para no hacer esperar a aquellos que prefieren el método de copiar y pegar, primero publicaré la parte práctica y después la teórica.
1. Práctica. Delegamos la zona /28
Supongamos que tenemos una subred 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 hay que encontrar el archivo que describe la zona inversa de esta subred. Supongamos que es 9.8.7.in-addr.arpa.
Comentamos los registros del 240 al 255, si los hay. Y al final del archivo escribimos lo siguiente:
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240no olvidemos aumentar el serial de la zona y ejecutar
rndc reloadCon esto, la parte del proveedor concluye. Pasamos al DNS del cliente.
Primero, crearemos el archivo /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.
Y en named.conf añadimos 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";
};Reiniciamos el proceso bind.
/etc/init.d/named restartTodo. Ahora se puede 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.Tenga en cuenta que se devuelve no solo el registro PTR sino también el CNAME. Así debe ser. Si le interesa saber por qué, bienvenido al siguiente capítulo.
2. Teoría. Cómo funciona.
Es difícil configurar y depurar una caja negra. Es mucho más fácil si entiendes qué está sucediendo por dentro.
Cuando delegamos un subdominio en el dominio dominio, escribimos algo como esto:
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8Decimos a todos los que preguntan que no somos responsables de este segmento y decimos quién es el responsable. Y todas las solicitudes a client.domain se redirigen a 7.8.7.8. Al verificar, vemos la siguiente situación (omitimos lo que hay en el cliente, no es importante):
# host test.client.domain
test.client.domain has address 7.8.9.241Es decir, se nos comunicó que hay un registro A y su IP es 7.8.9.241. No hay información adicional.
¿Y cómo se puede hacer lo mismo con una subred?
Dado que nuestro servidor DNS está registrado en RIPE, al solicitar un registro PTR de una dirección IP de nuestra red, el primer pedido será siempre hacia nosotros. La lógica es la misma que con los dominios. Pero, ¿cómo se puede escribir la subred en el archivo de zona?
Intentamos escribir así:
255-240 IN NS 7.8.7.8Y... no ocurrió ningún milagro. No recibimos ninguna redirección de la solicitud. Todo se debe a que bind no tiene idea de que estos registros en el archivo de zona inversa son direcciones IP y mucho menos entiende la entrada de rango. Para él, esto es solo un subdominio simbólico. Es decir, para bind no habrá diferencia entre «255-240» y «oursuperclient«. Y para que la solicitud se dirija a donde debe, la dirección en la solicitud debe verse así: 241.255-240.9.8.7.in-addr.arpa. O así, si usamos un subdominio simbólico: 241.oursuperclient.9.8.7.in-addr.arpa. Esto difiere del habitual: 241.9.8.7.in-addr.arpa.
Hacer tal solicitud manualmente será problemático. Y si se logra, no está claro cómo aplicarlo en la vida real. Después de todo, la solicitud sigue siendo respondida por el DNS del proveedor, y no por el del cliente. 7.8.9.241 Aquí es donde entra en juego
CNAME Del lado del proveedor, es necesario crear un alias para todas las direcciones IP de la subred en un formato que redirija 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 etc.
Esto es para los trabajadores =).
Y para los perezosos, la siguiente construcción es más adecuada:
255-240 IN NS ns1.client.domain. $GENERATE 240-255 $ CNAME $.255-240
Ahora la solicitud de información a la direcciónen el servidor DNS del proveedor se transformará en 7.8.9.241 de 241.9.8.7.in-addr.arpa y se enviará al DNS del cliente. 241.255-240.9.8.7.in-addr.arpa Del lado del cliente, será necesario manejar tales solicitudes. Por lo tanto, creamos una zona
255-240.9.8.7.in-addr.arpa . En ella, en principio, podemos colocar registros inversos para cualquier IP de toda la subred /24, pero solo nos preguntarán sobre aquellos que el proveedor nos redirija, así que no habrá mucho juego =).Para ilustrar, una vez más daré un ejemplo del contenido del archivo de zona inversa del lado del cliente:
Para ilustrar, aquí hay un ejemplo del contenido del archivo de la zona inversa desde 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.
Debido a que usamos CNAME por parte del proveedor, recibimos como respuesta datos sobre dirección IP 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 olviden configurar correctamente ACL. Porque no tiene sentido tomar la zona PTR y no responder a nadie del exterior =).
Fuente: habr.com
