DNS BIND9 · 8 min read · Oct 02, 2025
Servidor DNS todo en uno con BIND9
Este tutorial te muestra cómo configurar el servidor DNS BIND9 para servir una red interna y una red externa al mismo tiempo con diferentes conjuntos de información. Para lograr ese objetivo, se utiliza una nueva función de BIND9 llamada vista. Como tutorial, te guiará a través de toda la configuración, pero se requiere un conocimiento inicial de BIND y DNS, hay muchos documentos que cubren esa información en Internet.
Continúa leyendo en el sitio original o descarga el PDF.
Contenidos
- 1 El problema
- 2 Configuración inicial
- 3 Internos y externos
- 4 Seguridad
- 5 Archivos de configuración - 5.1 /etc/bind/named.conf.local
- 5.2 /etc/bind/externals/db.example.com
- 5.3 /etc/bind/internals/db.example.com
- Bibliografía
1 El problema
Es un problema típico en organizaciones que están creciendo que tienen que resolver dos problemas a la vez:
- Tener un servidor DNS para la red interna de la empresa porque hace mucho tiempo ya había demasiadas computadoras para recordar sus IPs 1 y hasta demasiadas computadoras para mantener un conjunto de archivos de hosts 2.
- Tener un servidor DNS para los servidores externos, para clientes externos, etc.
a resolver estos problemas se convierte en un problema mayor cuando la organización en crecimiento no puede proporcionar más recursos que un servidor DNS 3. Es un problema mayor porque si solo configuras tu servidor con todos tus nombres, públicos y privados, terminarás contaminando Internet con direcciones privadas, algo que es muy malo, y también mostrando al mundo parte de la topología de tu red interna. Algo que no quieres que un posible atacante/cracker tenga.
La otra parte del problema es que por eficiencia puede que desees resolver a IPs internas cuando estás dentro y a IPs externas cuando estás fuera. Aquí estoy hablando de computadoras que tienen conexiones públicas y privadas.
Hay muchas soluciones diferentes a este problema y recuerdo haberlo resuelto incluso con BIND4, pero ahora voy a usar BIND9 para hacer una solución que es muy limpia. Esto se implementó en un servidor Debian GNU/Linux 3.1, pero también debería funcionar para otros sistemas operativos que ejecutan BIND9, solo asegúrate de cambiar tus rutas apropiadamente.
2 Configuración inicial
Imaginemos que la organización para la que trabajo hace ejemplos… ¿de qué? No lo sé, pero puedes ordenarlos en example.com. La Corporación Ejemplos ha sido asignada a la red 192.0.2.0/24 y internamente estamos usando 10.0.0.0/24.
Comencemos a servir los nombres y IPs externos, editamos /etc/bind/named.conf.local 4 y añadimos:
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
};y luego creamos /etc/bind/db.example.com con el siguiente contenido:
; example.com
$TTL 604800
@ IN SOA ns1.example.com. root.example.com. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
@ IN NS ns1
IN MX 10 mail
IN A 192.0.2.1
ns1 IN A 192.0.2.1
mail IN A 192.0.2.128 ; Tenemos nuestro servidor de correo en otro lugar.
www IN A 192.0.2.1
client1 IN A 192.0.2.201 ; Nos conectamos a client1 muy a menudo.Como puedes ver, nuestra configuración inicial tiene una computadora para servir a todos, excepto el correo, incluso mantiene el reenvío de IP y un par de bases de datos.
Ahora, una buena configuración de DNS tiene al menos un servidor secundario y de hecho, algunos registradores (donde registras nombres de dominio) imponen esto. Dado que no tenemos una segunda computadora, vamos a XName, abrimos una cuenta y registramos example.com como secundario con 192.0.2.1 como IP para transferir. Ahora necesitamos permitir que la IP de XName realice la transferencia; somos una pequeña organización, pero dado que queremos ser una startup exitosa, intentamos hacer todo de la manera más inteligente posible. Así que usamos la directiva de configuración de BIND9 acl para definir un identificador que se alias a las direcciones IP de XName; al principio de /etc/bind/named.conf.local añadimos:
acl slaves {
195.234.42.0/24; // XName
193.218.105.144/28; // XName
193.24.212.232/29; // XName
};y cambiamos la declaración de zona a:
zone "example.com" {
type master;
file "/etc/bind/db.example.com";
allow-transfer { slaves; };
};Podríamos haber escrito simplemente las IPs donde escribimos “slaves”.
3 Internos y externos
Ahora que tenemos una base sólida, podemos comenzar a pensar en servir diferentes contenidos a la red interna y externa, pero primero, tenemos que definir qué es interno y qué es externo.
En /etc/bind/named.conf.local añadimos la siguiente definición (en la parte superior o debajo de la definición de slaves):
acl internals {
127.0.0.0/8;
10.0.0.0/24;
};Si tuviéramos más redes internas, podríamos simplemente añadirlas allí. No definimos externos porque todo lo que no es interno es externo. Puedes, si lo deseas, definir conjuntos de diferentes externos si quieres servir contenido diferente a diferentes partes de Internet.
Usaremos una nueva función de BIND9 llamada vistas. Una vista nos permite poner un fragmento de configuración dentro de una condición que puede depender de varias cosas, en este caso solo dependeremos de internos. Reemplazamos la declaración de zona en /etc/bind/named.conf.local con:
view "internal" {
match-clients { internals; };
zone "example.com" {
type master;
file "/etc/bind/internals/db.example.com";
};
};
view "external" {
match-clients { any; };
zone "example.com" {
type master;
file "/etc/bind/externals/db.example.com";
allow-transfer { slaves; };
};
};La directiva de configuración match clients nos permite mostrar condicionalmente esa vista basada en un conjunto de IPs, “any” significa cualquier IP. Las IPs internas serán almacenadas en caché por la vista interna y el resto serán descartadas en la vista externa. El mundo exterior no puede ver la vista interna, y eso incluye a XName, nuestro proveedor de DNS secundario, pero eliminamos el allow-transfer de la vista interna ya que no queremos que nadie pueda transferir bajo ninguna circunstancia el contenido de la vista interna.
También cambiamos la ruta, tendremos que crear el directorio /etc/bind/externals y /etc/bind/internals y mover /etc/bind/db.example.com a /etc/bind/externals/.
En /etc/bind/internals/db.example.com ponemos un archivo de zona similar al de la contraparte externa pero conteniendo las IPs internas:
; example.com
$TTL 604800
@ IN SOA ns1.example.com. root.example.com. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
@ IN A 10.0.0.1
boss IN A 10.0.0.100
printer IN A 10.0.0.101
scrtry IN A 10.0.0.102
sip01 IN A 10.0.0.201
lab IN A 10.0.0.103Genial, ahora podemos hacer ping a la computadora de nuestro jefe con
ping boss.example.comy tratar de alcanzar mail.example.com nos decepcionará, ¿qué pasó? No hay referencia a mail.example.com en el archivo de zona interno y dado que estamos en la red interna, podemos resolver mail.example.com. Bien, simplemente copiemos el contenido del archivo de zona externo al archivo de zona interno. Eso funcionará.
Pero somos una pequeña y astuta startup, podemos hacer mejor que copiar y pegar cada modificación al archivo de zona, además, eso es muy propenso a errores (¿siempre recordarás modificar el archivo de zona interno cuando modifiques el externo, o olvidarás y pasarás algunos días depurando problemas de red?).
Lo que haremos es incluir el archivo de zona externo en el archivo interno de esta manera:
$include "/etc/bind/external/db.example.com"
@ IN A 10.0.0.1
boss IN A 10.0.0.100
printer IN A 10.0.0.101
scrtry IN A 10.0.0.102
sip01 IN A 10.0.0.201
lab IN A 10.0.0.103y ¡voilà! Encontrar la directiva $include en la documentación actual fue difícil… Solo recuerda cambiar el serial del archivo de zona externo cada vez que cambies el interno, pero no es un gran problema, si olvidas, nada malo sucederá ya que no es probable que tengas servidores de caché dentro de tu propia pequeña red.
4 Seguridad
No se recomienda usar el mismo servidor DNS como primario para algún dominio (en nuestro caso example.com) y como servidor DNS de caché, pero en nuestro caso estamos obligados a hacerlo. Desde el mundo exterior, 192.0.2.1 es el servidor DNS primario para example.com, desde nuestra propia red interna, 192.0.2.1 (o su dirección privada, 10.0.0.1) es nuestro servidor de nombres de caché que debería estar configurado como el servidor de nombres a usar en cada estación de trabajo que tenemos.
Uno de los problemas es que alguien podría comenzar a usar nuestro servidor de nombres de caché desde el exterior, hay un ataque llamado envenenamiento de caché y muchas otras cosas desagradables que se pueden hacer y están documentadas en [SINS] (incluyendo cómo evitarlas).
Para mejorar un poco nuestra seguridad, añadiremos un par de directivas al archivo de configuración:
view "internal" {
match-clients { internals; };
recursion yes;
zone "example.com" {
type master;
file "/etc/bind/internals/db.example.com";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "example.com" {
type master;
file "/etc/bind/externals/db.example.com";
allow-transfer { slaves; };
};
};Eso evitará que cualquiera en el peligroso Internet use nuestro servidor recursivamente mientras que nosotros, en nuestra propia red, aún podemos hacerlo.
5 Archivos de configuración
5.1 /etc/bind/named.conf.local
acl slaves {
195.234.42.0/24; // XName
193.218.105.144/28; // XName
193.24.212.232/29; // XName
};
acl internals {
127.0.0.0/8;
10.0.0.0/24;
};
view "internal" {
match-clients { internals; };
recursion yes;
zone "example.com" {
type master;
file "/etc/bind/internals/db.example.com";
};
};
view "external" {
match-clients { any; };
recursion no;
zone "example.com" {
type master;
file "/etc/bind/externals/db.example.com";
allow-transfer { slaves; };
};
};5.2 /etc/bind/externals/db.example.com
; example.com
$TTL 604800
@ IN SOA ns1.example.com. root.example.com. (
2006020201 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
@ IN NS ns1
IN MX 10 mail
IN A 192.0.2.1
ns1 IN A 192.0.2.1
mail IN A 192.0.2.128 ; Tenemos nuestro servidor de correo en otro lugar.
www IN A 192.0.2.1
client1 IN A 192.0.2.201 ; Nos conectamos a client1 muy a menudo.5.3 /etc/bind/internals/db.example.com
$include "/etc/bind/external/db.example.com"
@ IN A 10.0.0.1
boss IN A 10.0.0.100
printer IN A 10.0.0.101
scrtry IN A 10.0.0.102
sip01 IN A 10.0.0.201
lab IN A 10.0.0.103Bibliografía
SINS
Asegurando un Servidor de Nombres de Internet
Notas al pie
… IPs
1
Para mí, dos computadoras ya califican como demasiadas computadoras para recordar sus IPs.
… archivos
2
El archivo de hosts reside en /etc/hosts y es un simple mapeo para la computadora local de nombres a IP. Fue la primera forma de resolver nombres a IPs y hace mucho tiempo se mantenía un gran archivo de hosts central, luego distribuido por FTP o similar. Creció rápidamente hasta convertirse en un problema que fue resuelto por la invención de DNS. Intenta no dejar que tu archivo de hosts crezca hasta convertirse en un problema antes de convertirlo en DNS, ¡aprende de los pioneros!
… servidor
3
O cuando eres un perfeccionista y crees que esto debería poder hacerse con solo un servidor.
…/etc/bind/named.conf.local
4
Puede ser solo /etc/bind/named.conf en tu sistema operativo si no es Debian.
Recibe nuevas publicaciones en tu bandeja de entrada.
No spam. Cancela la suscripción en cualquier momento.