		*Últimos Cambios*
	Blog personal: El hilo del laberinto

¿Cómo configurar el DNS Inverso?

Última Actualización: 4 de Febrero de 2.000 - Viernes

La responsabilidad de configurar correctamente un DNS inverso corresponde al administrador del ISP propietario de la red. Dicho administrador debe asignar un nombre válido a cada una de las máquinas posibles bajo su responsabilidad, incluyendo las máquinas que entran desde Infovía o nodos locales. No es necesario que los nombres sean muy imaginativos; cosas como "infovia186.dominio" sirven también, y se pueden generar con un simple script.

Para ello debe crear un dominio nuevo, conteniendo toda la equivalencia inversa de su clase C. Si el ISP dispone de varias clases C, hay que crear tantos dominios como clases se posean. Veamos el ejemplo con la clase C 194.235.99.*, que se corresponde a *.argo.es:

Lo primero es crear el fichero de configuración para el dominio "99.235.194.in-addr.arpa". Obsérvese el uso de la IP de la clase C, escrita al revés. El dominio "in-addr.arpa" es el dominio estándar del que cuelgan las inversas. Los pasos a seguir para crear los ficheros dependen de cada sistema operativo, y se supone que el administrador está famirializado con ellos. Se hace exactamente igual que un dominio normal. Lo único que hay que tener en cuenta es que los registros contenidos en este dominio son PTR, y que el nombre de dominio final debe terminar con un punto. Por ejemplo:

@       IN SOA  corinto.argo.es. root.argo.es. (
                1998022601              ; Serial Number
                14400                   ; Refresh (4 horas)
                7200                    ; Retry (2 horas)
                2592000                 ; Expire (30 dias)
                28800 )                 ; Minimum TTL (8 horas)

        IN NS   corinto.argo.es.
        IN NS   galileo.global-one.es.

1       IN PTR  gateway.argo.es.
2       IN PTR  corinto.argo.es.
3       IN PTR  polux.argo.es.
4       IN PTR  castor.argo.es.
5       IN PTR  atalanta.argo.es.
6       IN PTR  diomedes.argo.es.
7       IN PTR  jason.argo.es.
8       IN PTR  quiron.argo.es.

...etc...

109     IN PTR  infovia109.argo.es.
110     IN PTR  infovia110.argo.es.
111     IN PTR  infovia111.argo.es.
112     IN PTR  infovia112.argo.es.
113     IN PTR  infovia113.argo.es.

...etc...

252     IN PTR  infovia252.argo.es.
253     IN PTR  infovia253.argo.es.
254     IN PTR  infovia254.argo.es.

En los registros NS deben aparecer los servidores de DNS que se hacen responsables del dominio. En este caso nosotros (primario) y el servidor de DNS de Global One (secundario). Todo esto es lo mismo que un dominio normal y corriente.

Configuramos nuestro servidor de DNS para que se haga responsable primario del dominio. Si usamos un named antiguo, añadimos una línea "primary 99.235.194.in-addr.arpa db.99.235.194" en el fichero "/etc/named.boot". Si se trata de un named moderno, añadimos lo siguiente al fichero "/etc/named.conf":
```
zone "99.235.194.in-addr.arpa" {
        type master;
        file "db.99.235.194";
};
```
Naturalmente, "99.235.194.in-addr.arpa" debe cambiarse por la IP (escrita al revés) de nuestra clase C. "db.99.235.194" es el nombre del fichero que hemos creado en el punto "a", y dependerá de la nomenclatura de cada administrador.
Ahora debemos reiniciar el servidor DNS, y verificar si la traducción se realiza correctamente de forma local. Para ello podemos usar el comando nslookup, por ejemplo. Si no funciona el DNS inverso, debemos repasar los pasos anteriores con detenimiento.
En este momento tenemos en funcionamiento el DNS inverso, pero de forma exclusivamente local. Ahora es necesario que la organización que gestiona el dominio "235.194.in-addr.arpa" nos delegue el subdominio "99.235.194.in-addr.arpa" para que nuestras inversas sean visibles para el resto de internet. Normalmente la administración de dicha red la hará el "carrier" (RedIris, Ibernet, Global One, BT...). Los pasos para lograr la delegación dependerán de cada caso:
- Con Global One, simplemente telefonear a la persona de contacto técnico.
- Con Ibernet (Telefónica) hay que dar la orden al comercial que nos corresponda.
En caso de desconocer la identidad que nos debe delegar el dominio, basta con ponerse en contacto en la dirección que aparece en el SOA de nivel superior, el "235.194.in-addr.arpa", cambiando el 235 y el 194 por lo que corresponda en nuestro caso, por supuesto.
El último paso, normalmente asociado al anterior, consiste en dar la orden a quien corresponda (al que hayamos nombrado como secundario en el NS) de que se haga cargo del nuevo dominio, como secundario. Este paso es exactamente el mismo que si se tratase de un dominio "normal".
Para quedarnos tranquilos podemos conectarnos a algún sitio externo (fuera de nuestra organización) que nos liste nuestros datos: un servidor de IRC, una página web, un FTP o un amiguete en otra red. También se puede hacer utilizando el nslookup, siempre y cuando tengamos la precaución de resolver las direcciones tomando como servidor un DNS remoto que no sea ni el primario ni el secundario del dominio.

Un último detalle a considerar, muy importante, es el mantener la coherencia entre DNS inverso y directo. Es decir, que si decimos que "194.235.99.86" es "infovia86.argo.es", por ejemplo, al resolver "infovia86.argo.es" debe salir "194.235.99.86". Ello puede suponer la necesidad de modificar también el DNS directo:

...

infovia67       IN A    194.235.99.67
                IN MX   10 corinto
infovia68       IN A    194.235.99.68
                IN MX   10 corinto
infovia69       IN A    194.235.99.69
                IN MX   10 corinto

...

¿Qué pasa si no tengo delegada una clase C entera?

Desde la aparición del "Classless routing" para hacer frente al agotamiento de direcciones IP, así como a la explosión de tamaño de las tablas de rutado, hace unos años, el concepto de clase ha perdido vigencia. Actualmente es bastante habitual utilizar de forma rutinaria lo que tradicionalmente eran clases A y B, tratadas como si fueran clases C.

Mientras las delegaciones se realicen en fronteras de "bytes" (16 millones de máquinas, 65536 máquinas o 256 máquinas), A.x.x.x, B.B.x.x o C.C.C.x, no tiene mayor importancia a nivel de DNS inverso. El problema surge cuando la delegación se realiza en unidades menores (por ejemplo, 32 máquinas).

Tradicionalmente se ha realizado esto haciendo una delegación NS (Name Server) IP por IP. Se sugieren otras posibilidades en el siguiente RFC:

RFC 2317
Classless IN-ADDR.ARPA delegation.
H. Eidnes, G. de Groot, P. Vixie. March 1998.

El esquema propuesto en el documento de arriba no requiere la modificación de software ya en explotación.

Recientemente se ha añadido un nuevo tipo de registro al sistema DNS, explícitamente diseñado para servir de anclaje. Se trata del registro DNAME. La difusión de este tipo de registro requiere la modificación de los servidores de DNS. Los clientes pueden consultar dicho registro, pero si en su petición no indican su capacidad para procesarlo, el servidor sintetizará registros CNAME automáticamente, de forma que el cambio sea transparente.

Más información en:

RFC2672
Non-Terminal DNS Name Redirection
M. Crawford. August 1999

Más información sobre los OpenBadges

Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS