Resolución Inversa de Zonas en el DNS con subredes.

Configuración de Bind-9 para resolución de zonas inversas.

Esto lo he sacado del rfc2317 que esta en el sitio www.rfc-es.org

como nuestra red esta dividida en subredes es necesario que nuestro DNS pueda resolver y consultar los otros DNS para encontrar quien es cada IP, de no ser asi, tendríamos que tener cada uno en nuestra zona inversa la definición de TODAS las maquinas de la red entera, serian como mínimo 255 entradas... mmm un poco pesado de mantener esto.

quedaria algo asi.

$ORIGIN 159.168.192.in-addr.arpa.

1 IN PTR host1.sub.rimed.cu
2 IN PTR host2.sub.rimed.cu
3 IN PTR host3.sub.rimed.cu
...
255 IN PTR host255.sub.rimed.cu

y eso es solo para trabajar con las redes de los pedagógicos, imagínense que incluyamos al de los IPI o todas las redes que tenemos en estos momentos.
Pero bueno, como se dice que todo tiene solución solo que hay que dedicarle un poco de tiempo, encontré esta.
Se van a declarar dos zonas, una que va a identificar la red entera y la otra, que va a ser la que estará en cada uno de los servidores de los nodos que van a ser autoritativos en la subred que le corresponde.
La declaración de la red completa seria así

$ORIGIN 159.168.192.in-addr.arpa.
$TTL 604800
@ IN SOA host.rimed.cu. hostmaster.rimed.cu. (
07062009 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL

NS ns.rimed.cu.

; Red CMW
32/28 NS ns.cmw.rimed.cu.
$GENERATE 33-47 $ CNAME $.32/28.159.168.192.in-addr.arpa.

; Red CFG
112/28 NS ns1.cfg.rimed.cu.
$GENERATE 112-127 $ CNAME $.112/28.159.168.192.in-addr.arpa.

así mismo se declaran todas las subredes que correspondan.
que es lo que hace el registro $GENERATE
bueno, pero si se oye clarito clarito; genera entradas a partir de un patrón, en este caso pondría cosas como esta

$GENERATE 33-47 $ CNAME $.32/28.159.168.192.in-addr.arpa.

33.159.168.192.in-addr.arpa CNAME 33/28.159.168.192.in-addr.arpa
34.159.168.192.in-addr.arpa CNAME 34/28.159.168.192.in-addr.arpa

y así sucesivamente, va poniendo todos los registros necesarios asociados e las diferentes subredes con el servidor DNS que la resolverá.
ahora, como se declara la zona en los servidores de los subnodos

$ORIGIN 32/28.159.168.192.in-addr.arpa.
$TTL 604800
@ IN SOA strike.cmw.rimed.cu. admin-red.cmw.rimed.cu. (
07062003 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL

@ NS ns.cmw.rimed.cu.
33 IN PTR frelay.cmw.rimed.cu.
34 IN PTR batfeld.cmw.rimed.cu.
35 IN PTR strike.cmw.rimed.cu.
36 IN PTR serv1.cmw.rimed.cu.
37 IN PTR archer.cmw.rimed.cu.
38 IN PTR hard.cmw.rimed.cu.
39 IN PTR nicolas.cmw.rimed.cu.
40 IN PTR sephiroth.cmw.rimed.cu.

esta zona de declara normal, que es lo que se ve diferente la declaración de el $ORIGIN que debe coincidir con el que esta definido en la zona de la red completa.
la otra parte es la declaración de la zona en el archivo named.conf; quedaría así

zone "32/28.159.168.192.in-addr.arpa" {
type master;
file "frelay/db.fr.192.168.159.32";
};

y por supuesto en cada forward para cada dominio se hará un forward de la zona inversa también, junto con la de resolución, como por ejemplo:

zone "cfg.rimed.cu" IN {
type forward;
forwarders {192.168.159.114;};
};

zone "112/28.159.168.192.in-addr.arpa" IN {
type forward;
forwarders {192.168.159.114;};
};

y con esto me esta funcionando, hice una prueba contra cfg y funcionó, ahora, la cuestión esta en donde debe ir definida la zona que domina la red entera. yo pienso que el ISP de carácter mas global, que en nuestro caso es RIMED.

aquí pongo la respuesta a las consultas de resolución inversa desde un servidor de camaguey

# host 192.168.159.114
114.159.168.192.in-addr.arpa is an alias for 114.112/28.159.168.192.in-addr.arpa.
114.112/28.159.168.192.in-addr.arpa domain name pointer hermes.cfg.rimed.cu.

# dig +short -x 192.168.159.114
114.112/28.159.168.192.in-addr.arpa.
hermes.cfg.rimed.cu.

# dig +short hermes.cfg.rimed.cu
192.168.159.114

saludos y nos mantenemos en contacto