Cualquiera que tenga una red de servidores con direcionamiento privado (RFC 1918), a los que se tenga también acceso desde internet se enfrenta con un dilema a la hora de definir los servidores de nombres (DNS). ¿Un servidor DNS en la DMZ para resolver los nombres a direcciones públicas y un servidor DNS en la red privada para resolver los nombres a direcciones privadas? Esto es una posibilidad (de hecho, la que más se utiliza) pero plantea el problema de administrar lo que conceptualmente es un único servicio en dos máquinas distintas.

A mi me gusta más la solución de usar un único servidor DNS en la red interna, accesible desde internet, y que resuelva de forma distinta los nombres que le sean consultados en función de si el que pide el servicio está en Internet o en la red interna: si el que consulta el DNS está en Internet se le da una dirección pública, si el que pide está en la red interna se le da la dirección interna del servidor.

Así, si hago un ping a mi dominio desde la red interna obtengo esto:

$ ping creativecodeworks.com
PING creativecodeworks.com (192.168.0.90): 56 data bytes
64 bytes from 192.168.0.90: icmp_seq=0 ttl=255 time=0.567 ms
64 bytes from 192.168.0.90: icmp_seq=1 ttl=255 time=0.445 ms
--- creativecodeworks.com ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.445/0.506/0.567/0.061 ms

Y si hago el mismo ping desde una máquina en Internet el resultado sería:

$ ping creativecodeworks.com
PING creativecodeworks.com (80.37.203.191): 56 data bytes
64 bytes from 80.37.203.191: icmp_seq=0 ttl=250 time=34.417 ms
64 bytes from 80.37.203.191: icmp_seq=1 ttl=250 time=32.818 ms
--- creativecodeworks.com ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 32.818/33.617/34.417/0.820 ms

¿Cómo se consigue hacer esto usando un único servidor DNS? Mediante el uso de views en la configuración del DNS. Vamos a ver ejemplos de cómo configurar views en DNS usando BIND versión 9.3.1.

Fichero named.conf

En el fichero named.conf, que en mi OpenBSD está en /var/named/etc/named.conf) hay que definir dos cosas:
1.- Qué direcciones son locales (las demás serán usuarios de Internet). Esto lo definiremos en una ACL (Access Control List).
2.- Qué ficheros de configuración de dominios se aplican a las direcciones locales y cuáles a las direcciones de Internet.

El truco está en que tendremos DOS ficheros de configuración por cada dominio, uno para la red interna y otro para internet, y el DNS usará uno u otro en función de la ACL que se le aplique al que consulta en función de su dirección IP.

Vamos a editar (como root o usando el comando sudo) el fichero named.conf y creamos una ACL para definir las direcciones internas:

acl "interna" {
      127.0.0.1; 192.168.0.0/16; 10.10.0.0/24;
};

Con esta definición, cualquier máquina que consulte este DNS y cuya dirección IP comience por 192.168 o por 10.10.0 (observese la diferente máscara de subred) será catalogada como interna y consultará el fichero de configuración del dominio para la red interna, que contiene solo IPs privadas. El resto de máquinas que consulten este DNS y que no tengan estas direcciones IP serán consideradas máquinas de Internet y se les darán los datos del fichwero de configuración del dominio para internet.

Ficheros de configuración del dominio

Vamos a crear los DOS ficheros que necesitamos para cada dominio, uno para la red interna y otro para las direcciones públicas. El dominio que vamos a definir es "creativecodeworks.com" y los ficheros que crearemos son:

db.creativecodeworks.com              para ser consultado desde internet
db.creativecodeworks.com.local        para ser consultado desde la red interna

En mi sistema estos ficheros están en /var/named/master, ya que este servidor es el servidor maestro para este dominio. El contenido de los dos ficheros será:

$ cd /var/named/master
$ cat db.creativecodeworks.com
$ORIGIN creativecodeworks.com.
$TTL 6h
@   IN      SOA     ns0.creativecodeworks.com. boss.creativecodeworks.com.   (
                         2008020500 ; serial
                         3h         ; refresh after 3 hours
                         1h         ; retry after 1 hour
                         1w         ; expire after 1 week
                         1h )       ; negative caching TTL of 1 hour
                NS      ns0.creativecodeworks.com.
                NS      ns0.xname.org.
                MX      10 smtp.creativecodeworks.com.

creativecodeworks.com.  IN  A  80.37.203.191
www        IN      A       80.37.203.191
smtp       IN      A       80.37.203.191
ns0        IN      A       80.37.203.191

$ cd /var/named/master
$ cat db.creativecodeworks.com.local
$ORIGIN creativecodeworks.com.
$TTL 6h
@   IN      SOA     ns0.creativecodeworks.com. boss.creativecodeworks.com.   (
                         2008020500 ; serial
                         3h         ; refresh after 3 hours
                         1h         ; retry after 1 hour
                         1w         ; expire after 1 week
                         1h )       ; negative caching TTL of 1 hour
                NS      ns0.creativecodeworks.com.
                NS      ns0.xname.org.
                MX      10 smtp.creativecodeworks.com.

creativecodeworks.com.  IN  A  192.168.0.90
www        IN      A       192.168.0.90
smtp       IN      A       192.168.0.90
ns0        IN      A       192.168.0.90

Como puede verse, ambos ficheros son exactamente iguales con la excepcción de la dirección IP asociada a cada nombre, que en un caso es pública y en el otro es privada.

Creación del "view"

Ahora lo que nos falta es la forma de "asociar" cada uno de los dos ficheros de configuración a la ACL que le corresponda. Hemos creado solo una ACL, que define las direcciones privadas, y se sobreentiende que todas las IPs que no figuren en una ACL explícitamente corresponden a una ACL implícita, llamada "any". Osea, que, en principio, todas las direcciones IP pertenecen a la ACL implícita "any", y lo que hacemos definiendo ACL explícitas es "sacar" de "any" a ese grupo de direcciones.

Vamos a crear dos vistas, o "views", una para los clientes asociados a la ACL que hemos llamado "interna", y a esa vista la llamaremos "interna" en un alarde de originalidad, y vamos a crear una segunda vista, que llamaremos "internet" y a la que asociaremos la ACL implícita "any":

// ------------------------------------------------------------------------
// Vista para la red interna
// ------------------------------------------------------------------------

view "interna" {

    match-clients   { "interna"; };
    recursion       yes;   

    zone "." {
            type hint;
            file "standard/root.hint";
    };

    zone "localhost" {
            type master;
            file "standard/localhost";
            allow-transfer { localhost; };
    };

    zone "127.in-addr.arpa" {
            type master;
            file "standard/loopback";
            allow-transfer { localhost; };
    };

    zone "10.in-addr.arpa" {
            type master;
            file "standard/db.10";
            allow-transfer { localhost; };
    };

    zone "creativecodeworks.com" {
         type master;
         file "master/db.creativecodeworks.com.local";
         };

}

La instrucción match-clients define la ACL que corresponde a esta vista. Aquí asociamos a esta vista la ACL "interna".

Dentro de la zona hemos metido el fichero de configuración "db.creativecodeworks.com.local" para resolver los nombres del dominio "creativecodeworks.com", y además he metido los ficheros de configuración inversa que me permiten resolver los nombres cuando le pregunte al servidor por una dirección.

El parámetro recursion puede activarse, o no, en función de lo que necesitemos. Si está activado, nuestro servidor DNS podrá resolver cualquier nombre del mundo mundial, pues escalará la pregunta a los servidores DNS globales; y si ponemos recursion no solamente resolverá los nombres de los dominios que tenga definido este servidor, en este caso solamente creativecodeworks.com.

Yo he puesto para la vista interna recursion yes, lo que me permite definir en mis máquinas internas a este servidor como DNS para los PC's clientes, y usando ese servidor DNS poder consultar cualquier dirección de internet.

El otro "view", el que define qué hacer si nos consultan desde internet es:

// ------------------------------------------------------------------------
// Vista para Internet  
// ------------------------------------------------------------------------

view "internet" {

    match-clients   { any; };
    recursion       no;

    zone "." {
            type hint;
            file "standard/root.hint";
    };

    zone "creativecodeworks.com" {
         type master;
         file "master/db.creativecodeworks.com";
         allow-transfer {  195.234.42.0/24; 193.218.105.144/28; 87.98.164.164; };
         };
}

Observe que aquí he quitado la posibilidad de hacer búsquedas recursivas, esto significa que no quiero que usen desde internet este servidor como servidor DNS para máquinas. Solo se consultará este servidor cuando el sistema DNS global necesite resolver direcciones de los dominios que yo alojo en mis máquinas.

Activar las nuevas configuraciones

Una vez definido todo lo anterior, recargamos tanto la configuración del servicio DNS como la configuración de los dominios:

~ # rndc reconfig   
~ # rndc reload   
server reload successful

rndc reconfig hace efectivos los cambios en el fichero de configuración del servicio DNS (named.conf)
rndc reload carga de nuevo las definiciones de los dominios (ficheros en /var/named/master definidos en named.conf)

Podemos comprobar si ha habido algun error consultando el fichero de log /var/log/messages.