[Linux-DNS] Vistas DNS e INCLUDE: dos increíbles aliados

Este artículo debería llamarse “El DNS para los pobres”, se trata de una situación que realmente es “bastante común”, como lo es, que un servidor “resolver recursivo” gestione varios DNS de una misma institución y que, además, resuelva direcciones “internas” y “externas” en un mismo ambiente.

Un amigo fué quien me hizo la consulta, me preguntó ¿cómo hago para que el servidor DNS, resuelva direcciones internas si está en mi red local, pero externas, si me consultan desde afuera? y además,  “solo tengo una máquina virtual y administro unas 5 cooperativas, ¿cómo hago para *facilitar* la administración de mi DNS?”, si tienes una situación similar con tus DNS, deberías leer el artículo.

La situación

Mi amigo tiene un servidor DNS en una máquina virtual, resuelve las direcciones “externas” (es autoritativo de su dominio) pero también las internas, además, debe gestionar los dominios de varias cooperativas, todas ellas comparten un único servidor Web, luego de explicarle me dijo “¿por qué no publicas esa ayuda?” y pues, aquí está.

Todas las cooperativas comparten servidor DNS y Servidor de correo y existen una serie de “hosts internos” (como el antivirus) comunes dentro del datacenter para servirle a las 5 cooperativas que comparten el edificio.

¿Cómo simplificar al máximo la administración?

Definir mis “amigos”

Lo primero que debemos hacer es crear en el archivo “named.conf” (si se encuentran usando Debian, es preferible hacerlo en “/etc/bind/named.conf.options”) una “ACL” (Access Control List) definiendo “quien” es mi red interna.

En este caso, he agregado lo siguiente:

archivo: /etc/named.conf.options
// definicion de mi red DMZ
acl internas {
 127.0.0.0/8;
 192.168.20.0/24;
 localnets;
};

Donde 192.168.20.0/24 constituye la sub-red de nuestra DMZ, además, en localnets (otra ACL) incorporé la lista de sub-nets dentro de la empresa:

// definicion de mi red interna
acl localnets {
 172.16.20.0/24;
 192.168.1.0/24;
};

De esta manera, cada vez que se incorpore una nueva sub-red, simplemente la agrego a “localnets” y recargo el servidor.

Interna y Externa

Las vistas son la manera de definir qué verá la red de internas y que verán los usuarios “externos”, para ello, incorporo al “named.conf” la definición de las vistas, la “interna” y la “externa”, de la siguiente manera:

view "interna" {
 match-clients { internal; };
 additional-from-auth yes; 
 additional-from-cache yes;
zone "." {
 type hint;
 file "/etc/bind/db.root";
};
zone "localhost" {
 type master;
 file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
 type master;
 file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
 type master;
 file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
 type master;
 file "/etc/bind/db.255";
};
zone "coopera.net" {
 type master;
 file "/etc/bind/zonas/internas/coopera.net.zone";
 allow-query { internas; };
};
zone "servicioscoopera.net" {
 type master;
 file "/etc/bind/zonas/internas/servicioscoopera.net.zone";
 allow-query { internas; };
};
zone "20.16.172.in-addr.arpa" {
 type master;
 file "/etc/bind/zonas/internas/20.16.172.zone";
 allow-query { internas; };
};
};

La vista “interna”, incorpora la zona “punto”, mis zonas internas, además, se permite consultarlas únicamente a personas que hagan “match” con clientes que estén en las subredes especificadas en la acl “internas”, evitando así que cualquier cliente obtenga “por error” una IP interna.

Por el contrario, la vista “externa” permite que cualquiera (excepto redes “internas”) la consulte:

view "external" {
 match-clients { !internal; any; };
 recursion no;
 zone "servicioscoopera.net" {
   type master;
   file "/etc/bind/zonas/servicioscoopera.net.zone";
   allow-query { any; };
 };
 zone "coopera.net" {
   type master;
   file "/etc/bind/zones/coopera.net.zone";
   allow-query { any; };
 };
};

Las zonas internas serán definidas en la carpeta “/etc/bind/zonas/internas” y las externas en “/etc/bind/zonas”.

Definiendo y compartiendo Zonas

Para simplificar, debemos decidir cual dominio será el autoritativo para el resto (en nuestro caso, el falso dominio “coopera.net” será el autoritativo para el resto, y se realizarán los cambios en el NIC registrar para que “dns1.coopera.net” y “dns2.coopera.net” sean los autoritativos para el resto de las zonas.

Así, el resto de valores (MX, HINFO, puntero A @ y WWW, y NS) serán compartidos por el resto de las zonas.

La zona primaria de COOPERA.NET quedará de la siguiente manera:

;
; coopera.net
;
$ORIGIN coopera.net.
$TTL    86400
@       IN      SOA     dns1.coopera.net. hostmaster.coopera.net. (
                         2011051701     ; Serial
                         86400          ; Refresh
                          7200          ; Retry
                        2419200         ; Expire
                         60480 )       ; Negative Cache TTL
; definicion de Nameservers
       IN      NS      dns1.coopera.net.
       IN      NS      dns2.coopera.net.
; punteros A de los DNS
dns1.coopera.net. IN A 144.76.25.227
dns2.coopera.net. IN A 144.76.25.228
; puntero de la zona
@       IN      A       144.76.25.228
www     IN      A       144.76.25.228
; informacion de hardware de este DNS
        IN      HINFO   VM-XEN "Debian Wheezy 7.0"
; puntero de intercambio de correo
        IN      MX      5    correo.coopera.net.
correo IN A 144.76.25.229

En este caso, lo más básico de la zona fué definido, NS (nameservers), puntero MX (Mail Exchange) e incluso WWW, pero, ¿qué les parece si usamos “INCLUDE” para compartir la información común de esta zona?

Compartiendo información de Zona

Imaginen este caso, el día de mañana cambio de servidor de correo, o en su defecto, incorporo otro servidor adicional, o cambio de proveedor para cambiar los DNS, si tengo 5 zonas, tendría que cambiar 5 archivos para cambiar las IPs, agregar un segundo servidor web ó un nuevo servidor de correo, ¿cómo simplificarlo?, en nuestra ayuda viene “INCLUDE”.

Si utilizamos “INCLUDE” (parte de bind9) podemos separar el archivo en “partes” que incluiremos después, en este caso, utilizando INCLUDE, la zona queda así:

archivo: /etc/bind/zonas/coopera.net.zone
;;
;; coopera.net
;;
$ORIGIN coopera.net.
$TTL    86400
@       IN      SOA     dns1.coopera.net. hostmaster.coopera.net. (
                         2011051701     ; Serial YYYYMMDDXX
                         86400          ; Refresh
                          7200          ; Retry
                        2419200         ; Expire
                         60480 )       ; Negative Cache TTL
; definicion de Nameservers
$INCLUDE /etc/bind/zonas/ns.coopera
; puntero de la zona
$INCLUDE /etc/bind/zonas/www.coopera
; puntero de intercambio de correo
$INCLUDE /etc/bind/zonas/mx.coopera
; informacion del administrador del dominio
$INCLUDE /etc/bind/zonas/adm.coopera

Si nos damos cuenta, se ha “simplificado” bastante el archivo, creando 3 archivos “aparte” para NS, WWW y MX y uno adicional para RP (opcional)

archivo: /etc/bind/zonas/ns.coopera
       IN      NS      dns1.coopera.net.
       IN      NS      dns2.coopera.net.
; punteros A de los DNS
dns1 IN A 144.76.25.227
dns2 IN A 144.76.25.228
archivo: /etc/bind/zonas/www.coopera
@       IN      A       144.76.25.228
www     IN      A       144.76.25.228
; informacion de hardware de este DNS
IN      HINFO   VM-XEN "Debian Wheezy 7.0"
archivo: /etc/bind/zonas/mx.coopera
        IN      MX      5    correo
correo IN A 144.76.25.229
archivo: /etc/bind/zonas/adm.coopera
        IN      RP      jesuslara
jesuslara IN TXT        "Jesus Lara, (58) 555-5555"
Se preguntarán ¿y cómo funciona eso?, la declaración de $ORIGIN al inicio de la zona primaria, hace qué en todos los archivos INCLUIDOS, la zona sea utilizada para “reemplazar” el dominio, entonces, en el archivo “mx.coopera”, si en $ORIGIN dice “coopera.net” eso se traducirá en “correo.coopera.net”, si estás en la zona “servicioscoopera.net” entonces reemplazará por “correo.servicioscoopera.net” y así suscesivamente.
Como verán, si cambio las IPs de los NS en el archivo “ns.coopera”, se cambiará en absolutamente TODAS las zonas que incluyan este archivo.

Entonces, crear una nueva zona, será tan sencillo como, copiar el archivo de zona COOPERA.NET.ZONE y reemplazar el dominio “coopera.net” por el que corresponda, si usan VIM esto es tan fácil como abrir el archivo y escribir:

:%s/coopera.net/servicioscoopera.net/g

(NOTA: se lee “dos puntos”, luego %s (sustitución), /{lo que se quiere reemplazar}/{reemplazo}/g de manera “global”)

¿Y el serial de la zona?, si usan VIM, pueden “reemplazar” el serial de la zona “original” con:

:%s/\<\d\{10}/\=strftime("%Y%m%d00")/

Esto, tomará el primer grupo de 10 dígitos y los reemplazará con la fecha actual, seguida de “00” (puede cambiar ese número, por un incremental por cada zona).

Conclusiones

La zona interna serían los mismos archivos, pero obviamente, respondiendo a IPs de la zona interna (e incorporando, por ejemplo, una lista de hosts donde se declaren punteros A comunes, como “antivirus” o “directorio”), la administración se ha simplificado al máximo y por ejemplo, agregar un nuevo servidor MX a TODAS las zonas declaradas, pasa por simplemente editar UN SOLO ARCHIVO (mx.coopera) y se cambiarán TODAS las zonas, quedando únicamente el cambio del serial de todas ellas y como estamos en LINUX, esto es tan fácil como ejecutar “SED”:

sed -i 's/20[0-1][0-9]\{7\}/'`date +%Y%m%d%I`'/g' /etc/bind/zonas/*.zone

Esto, cambiará en todos los archivos “.zone” el serial existente, por la fecha actual, preservando el serial, solamente quedaría ejecutar:

rndc reload

Y todas las zonas se verán cambiadas, ¿fácil, no? …

Recordando el hecho de ver DNS “oficiales” tan mal configurados (por allí vi uno de una institución pública que tenía un puntero que resolvía como dirección “127.0.0.1” (there is no place like localhost!) y otras donde el hostname del SOA no correspondía a ningún servidor, creo que comenzar con artículos que ayudan a la mejor configuración de nuestros DNS es lo mejor para apoyar …

Acerca de phenobarbital

http://about.me/phenobarbital

Publicado el 20 abril 2013 en Blogeando!, Cultura Libre, La nota del día, Linux, PlanetaLinux y etiquetado en , , , , , , , , , , . Guarda el enlace permanente. 2 comentarios.

  1. Muy buen artículo!!! Felicidades por tu blog!!! No se si a alguien más le ha pasado, pero CANTV me ha bloqueado desde hace 2 días el acceso a páginas nacionales o gubernamentales y eso que no estoy en el exterior. Me parece muy extraño eso.

  1. Pingback: DNS: Haciendo las cosas bien | Phenobarbital con Soda!

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: