Autor: Joel Barrios Dueñas
Correo electrónico:
jbarrios arroba
linuxparatodos punto net
Sitio de Red:
http://www.linuxparatodos.net/
Creative
Commons
Reconocimiento-NoComercial-CompartirIgual 2.1
© 1999-2006 Linux Para
Todos. Algunos Derechos Reservados 2007 Factor Evolución SA de CV. Usted es
libre de copiar, distribuir y comunicar públicamente la obra y hacer obras
derivadas bajo las condiciones siguientes: a) Debe reconocer y citar al
autor original. b) No puede utilizar esta obra para fines comerciales.
c) Si altera o transforma esta obra, o genera una obra derivada, sólo puede
distribuir la obra generada bajo una licencia idéntica a ésta. Al reutilizar
o distribuir la obra, tiene que dejar bien claro los términos de la licencia
de esta obra. Alguna de estas condiciones puede no aplicarse si se obtiene
el permiso del titular de los derechos de autor. Los derechos derivados de
usos legítimos u otras limitaciones no se ven afectados por lo anterior.
Licencia completa en
castellano. La información contenida en este documento y los derivados
de éste se proporcionan tal cual son y los autores no asumirán
responsabilidad alguna si el usuario o lector hace mal uso de éstos.
Introducción.
Bind (Berkeley Internet Name Domain).
BIND (acrónimo de Berkeley Internet Name Domain)
es una implementación del protocolo DNS y provee una implementación libre de los
principales componentes del Sistema de Nombres de Dominio, los cuales incluyen:
| • |
Un servidor de sistema de nombres de dominio (named). |
| • |
Una biblioteca resolutoria de sistema de nombres de dominio. |
| • |
Herramientas para verificar la operación adecuada del servidor
DNS (bind-utils). |
El Servidor DNS BIND es ampliamente utilizado en la Internet (99% de los
servidores DNS) proporcionando una robusta y estable solución.
DNS (Domain Name System).
DNS (acrónimo de Domain Name System) es una base
de datos distribuida y jerárquica que almacena la información necesaria para los
nombre de dominio. Sus usos principales son la asignación de nombres de dominio
a direcciones IP y la localización de los servidores de correo electrónico
correspondientes para cada dominio. El DNS nació de la necesidad de
facilitar a los seres humanos el acceso hacia los servidores disponibles a
través de Internet permitiendo hacerlo por un nombre, algo más fácil de recordar
que una dirección IP.
Los Servidores DNS utilizan TCP y UDP en el puerto 53
para responder las consultas. Casi todas las consultas consisten de una sola
solicitud UDP desde un Cliente DNS seguida por una sola respuesta
UDP del servidor. TCP interviene cuando el tamaño de los datos de
la respuesta exceden los 512 bytes, tal como ocurre con tareas como
transferencia de zonas.
NIC (Network Information Center).
NIC (acrónimo de Network Information Center o Centro
de Información sobre la Red) es una institución encargada de asignar los nombres
de dominio en Internet, ya sean nombres de dominio genéricos o por países,
permitiendo personas o empresas montar sitios de Internet mediante a través de
un ISP mediante un DNS. Técnicamente existe un NIC por cada país
en el mundo y cada uno de éstos es responsable por todos los dominios con la
terminación correspondiente a su país. Por ejemplo:
NIC México es la entidad encargada de gestionar todos los dominios con
terminación .mx, la cual es la terminación correspondiente asignada a los
dominios de México.
FQDN (Fully Qualified Domain Name).
FQDN (acrónimo de Fully Qualified Domain Name
o Nombre de Dominio Plenamente Calificado) es un Nombre de Dominio ambiguo que
especifica la posición absoluta del nodo en el árbol jerárquico del DNS. Se
distingue de un nombre regular porque lleva un punto al final.
Como ejemplo: suponiendo que se tiene un dispositivo cuyo nombre de anfitrión
es «maquina1» y un dominio llamado «dominio.com», el FQDN sería «maquina1.dominio.com.»,
asi es que se define de forma única al dispositivo mientras que pudieran existir
muchos anfitriones llamados «maquina1», solo puede haber uno llamado «maquina1.dominio.com.».
La ausencia del punto al final definiría que se pudiera tratar tan solo de un
prefijo, es decir «maquina1.dominio.com» pudiera ser un dominio de otro
más largo como «maquina1.dominio.com.mx».
La longitud máxima de un FQDN es de 255 bytes, con una restricción
adicional de 63 bytes para cada etiqueta dentro del nombre del dominio. Solo se
permiten los caracteres A-Z de ASCII, dígitos y el carácter «-». No se
distinguen mayúsculas y minúsculas.
Desde 2004, a solicitud de varios países de Europa, existe el estándar IDN
(acrónimo de Internationalized Domain Name) que permite
caracteres no-ASCII, codificando caracteres Unicode dentro de cadenas de
bytes dentro del conjunto normal de caracteres de FQDN. Como resultado,
los limites de longitud de los nombres de dominio IDN dependen
directamente del contenido mismo del nombre.
Componentes de un DNS.
Los DNS operan a través de tres componentes: Clientes DNS, Servidores DNS y
Zonas de Autoridad.
Clientes DNS.
Son programas que ejecuta un usuario y que generan peticiones de consulta
para resolver nombres. Básicamente preguntan por la dirección IP que corresponde
a un nombre determinado.
Servidores DNS.
Son servicios que contestan las consultas realizadas por los Clientes DNS.
Hay dos tipos de servidores de nombres:
| • |
Servidor Maestro: También
denominado Primario. Obtiene los datos del dominio a partir
de un fichero hospedado en el mismo servidor. |
| • |
Servidor Esclavo: También
denominado Secundario. Al iniciar obtiene los datos del
dominio a través de un Servidor Maestro (o primario), realizando un
proceso denominado transferencia de zona. |
Un gran número de problemas de operación de servidores DNS se atribuyen a las
pobres opciones de servidores secundarios para las zona de DNS. De acuerdo al
RFC 2182, el DNS requiere
que al menos tres servidores existan para todos los dominios delegados (o
zonas).
Una de las principales razones para tener al menos tres servidores
para cada zona es permitir que la información de la zona misma esté disponible
siempre y forma confiable hacia los Clientes DNS a través de Internet
cuando un servidor DNS de dicha zona falle, no esté disponible y/o esté
inalcanzable.
Contar con múltiples servidores también facilita la propagación de la
zona y mejoran la eficiencia del sistema en general al brindar opciones a los
Clientes DNS si acaso encontraran dificultades para realizar una consulta en
un Servidor DNS. En otras palabras: tener múltiples servidores para una
zona permite contar con redundancia y respaldo del servicio.
Con múltiples servidores, por lo general uno actúa como Servidor Maestro o
Primario y los demás como Servidores Esclavos o Secundarios.
Correctamente configurados y una vez creados los datos para una zona, no será
necesario copiarlos a cada Servidor Esclavo o Secundario, pues éste se
encargará de transferir los datos de manera automática cuando sea necesario.
Los Servidores DNS responden dos tipos de consultas:
| • |
Consultas Iterativas (no
recursivas): El cliente hace una consulta al Servidor DNS
y este le responde con la mejor respuesta que pueda darse basada
sobre su caché o en las zonas locales. Si no es posible dar una
respuesta, la consulta se reenvía hacia otro Servidor DNS
repitiéndose este proceso hasta encontrar al Servidor DNS que
tiene la Zona de Autoridad capaz de resolver la consulta. |
| • |
Consultas Recursivas: El
Servidor DNS asume toda la carga de proporcionar una respuesta
completa para la consulta realizada por el Cliente DNS. El
Servidor DNS desarrolla entonces Consultas Iterativas
separadas hacia otros Servidores DNS (en lugar de hacerlo el
Cliente DNS) para obtener la respuesta solicitada. |
Zonas de Autoridad.
Permiten al Servidor Maestro o Primario cargar la información de una
zona. Cada Zona de Autoridad abarca al menos un dominio y posiblemente
sus sub-dominios, si estos últimos no son delegados a otras zonas de autoridad.
La información de cada Zona de Autoridad es almacenada de forma local
en un fichero en el Servidor DNS. Este fichero puede incluir varios tipos
de registros:
| Tipo de Registro. |
Descripción. |
| A (Address) |
Registro de dirección que resuelve un nombre de un anfitrión
hacia una dirección IPv4 de 32 bits. |
| AAAA |
Registro de dirección que resuelve un nombre de un anfitrión
hacia una dirección IPv6 de 128 bits. |
| CNAME (Canonical Name) |
Registro de nombre canónico que hace que un nombre sea alias de
otro. Los dominios con alias obtiene los sub-dominios y registros
DNS del dominio original. |
| MX (Mail Exchanger) |
Registro de servidor de correo que sirve para definir una lista
de servidores de correo para un dominio, así como la prioridad entre
éstos. |
| PTR (Pointer) |
Registro de apuntador que resuelve direcciones IPv4 hacia
el nombre anfitriones. Es decir, hace lo contrario al registro A.
Se utiliza en zonas de Resolución Inversa. |
| NS (Name Server) |
Registro de servidor de nombres que sirve para definir una lista
de servidores de nombres con autoridad para un dominio. |
| SOA (Start of Authority) |
Registro de inicio de autoridad que especifica el Servidor
DNS Maestro (o Primario) que proporcionará la información con
autoridad acerca de un dominio de Internet, dirección de correo
electrónico del administrador, número de serie del dominio y
parámetros de tiempo para la zona. |
| SRV (Service) |
Registro de servicios que especifica información acerca de
servicios disponibles a través del dominio. Protocolos como SIP
(Session Initiation Protocol) y XMPP (Extensible
Messaging and Presence Protocol) suelen
requerir registros SRV en la zona para proporcionar
información a los clientes. |
| TXT (Text) |
Registro de texto que permite al administrador insertar texto
arbitrariamente en un registro DNS. Este tipo de registro es muy
utilizado por los servidores de listas negras DNSBL (DNS-based
Blackhole List) para la filtración de Spam. Otro
ejemplo de uso son las VPN, donde suele requerirse un registro
TXT para definir una llave que será utilizada por los clientes. |
Las zonas que se pueden resolver son:
- Zonas de Reenvío.
- Devuelven direcciones IP para las búsquedas hechas para nombres
FQDN (Fully Qualified Domain Name).
En
el caso de dominios públicos, la responsabilidad de que exista una Zona
de Autoridad para cada Zona de Reenvío corresponde a la autoridad
misma del dominio, es decir, y por lo general, quien esté registrado como
autoridad del dominio tras consultar una base de datos WHOIS. Quienes
compran dominios a través de un NIC (por ejemplo ejemplo: www.nic.mx)
son quienes se hacen cargo de las Zonas de Reenvío, ya sea a través
de su propio Servidor DNS o bien a través de los Servidores DNS
de su ISP.
Salvo que se trate de un dominio para uso en una red local, todo dominio
debe ser primero tramitado con un NIC como requisito para tener
derecho legal a utilizarlo y poder propagarlo a través de Internet.
- Zonas de Resolución Inversa.
- Devuelven nombres FQDN (Fully Qualified Domain
Name) para las búsquedas hechas para direcciones IP.
En el
caso de segmentos de red públicos, la responsabilidad de que exista de que
exista una Zona de Autoridad para cada Zona de Resolución Inversa
corresponde a la autoridad misma del segmento, es decir, y por lo general,
quien esté registrado como autoridad del segmento tras consultar una base de
datos WHOIS.
Los grandes ISP, y en algunos casos algunas empresas, son quienes
se hacen cargo de las Zonas de Resolución Inversa.
Herramientas de búsqueda y consulta.
Mandato host.
El mandato host una herramienta simple para hacer búsquedas en
Servidores DNS. Es utilizada para convertir nombres en direcciones IP y
viceversa.
De modo predefinido realiza las búsquedas en las Servidores DNS
definidos en el fichero /etc/resolv.conf, pudiendo definirse
opcionalmente el Servidor DNS a consultar.
Lo anterior realiza una búsqueda en los Servidores DNS definidos en el
fichero /etc/resolv.conf del sistema, devolviendo como resultado una
dirección IP.
Lo anterior realiza una búsqueda en los Servidor DNS en la dirección
IP 200.33.146.217, devolviendo una dirección IP como resultado.
Mandato dig.
El mandato dig (domain information groper) es una
herramienta flexible para realizar consultas en Servidores DNS. Realiza
búsquedas y muestra las respuestas que son regresadas por los servidores que
fueron consultados. Debido a su flexibilidad y claridad en la salida es que la
mayoría de los administradores utilizan dig para diagnosticar problemas
de DNS.
De modo predefinido realiza las búsquedas en las Servidores DNS
definidos en el fichero /etc/resolv.conf, pudiendo definirse
opcionalmente el Servidor DNS a consultar. La sintaxis básica sería:
dig @servidor nombre TIPO
|
Donde servidor corresponde al nombre o dirección IP del Servidor
DNS a consultar, nombre corresponde al nombre del registro del
recurso que se está buscando y TIPO corresponde al tipo de consulta
requerido (ANY, A, MX, SOA, NS, etc.)
Ejemplo:
dig @200.33.146.209 linuxparatodos.net MX
|
Lo anterior realiza una búsqueda en el Servidor DNS en la dirección IP
200.33.146.209 para los registros MX para el dominio
linuxparatodos.net.
dig linuxparatodos.net NS
|
Lo anterior realiza una búsqueda en los Servidores DNS definidos en el
fichero /etc/resolv.conf del sistema para los registros NS para el
dominio linuxparatodos.net.
dig @200.33.146.217 linuxparatodos.net NS
|
Lo anterior realiza una búsqueda en los Servidor DNS en la dirección
IP 200.33.146.217 para los registros NS para el dominio
linuxparatodos.net.
Mandato jwhois (whois).
El mandato jwhois es una herramienta de consulta a través de
servidores WHOIS. La sintaxis básica es:
Ejemplo:
jwhois linuxparatodos.net
|
Loa anterior regresa la información correspondiente al dominio
linuxparatodos.net.
Sustento lógico necesario.
| Paquete. |
Descripción. |
| • bind |
Incluye el Servidor DNS (named)
y herramientas para verificar su funcionamiento. |
| • bind-libs |
Biblioteca compartida que consiste en
rutinas para aplicaciones para utilizarse cuando se interactúe con
Servidores DNS. |
| • bind-chroot |
Contiene un árbol de ficheros que
puede ser utilizado como una jaula chroot para named
añadiendo seguridad adicional al servicio. |
| • bind-utils |
Colección de herramientas para
consultar Servidores DNS. |
| • caching-nameserver |
Ficheros de configuración que harán
que el Servidor DNS actúe como un caché para el servidor de
nombres. |
Instalación a través de yum.
Si se utiliza de CentOS 4 o White Box Enterprise Linux 4, o versiones
posteriores, se puede instalar utilizando lo siguiente:
yum -y install bind bind-chroot bind-utils caching-nameserver
|
Instalación a través de Up2date
Si se utiliza de Red Hat™ Enterprise Linux 4, o versiones posteriores, se
puede instalar utilizando lo siguiente:
up2date -i bind bind-chroot bind-utils caching-nameserver
|
Procedimientos.
Preparativos.
Idealmente se deben definir primero los siguiente datos:
| 1. |
Dominio a resolver. |
| 2. |
Servidor de nombres principal (SOA). Éste debe ser un nombre
que ya esté plenamente resuelto, y debe ser un FQDN (Fully
Qualified Domain Name). |
| 3. |
Lista de todos los servidores de nombres (NS) que se utilizarán
para efectos de redundancia. Éstos deben ser nombres que ya estén
plenamente resueltos, y deben ser además FQDN (Fully
Qualified Domain Name). |
| 4. |
Cuenta de correo del administrador responsable de esta zona.
Dicha cuenta debe existir y no debe pertenecer a la misma zona que
se está tratando de resolver. |
| 5. |
Al menos un servidor de correo (MX), con un registro A,
nunca CNAME. |
| 6. |
IP predeterminada del dominio. |
| 7. |
Sub-dominios dentro del dominio (www, mail, ftp, ns, etc.) y las
direcciones IP que estarán asociadas a estos. |
Es importante tener bien en claro que los puntos 2, 3 y 4 involucran datos
que deben existir previamente y estar plenamente resueltos por otro
servidor DNS; Lo anterior quiere decir no pueden utilizar datos que sean parte o
dependan del mismo dominio que se pretende resolver. De igual modo, el servidor
donde se implementará el DNS deberá contar con un nombre FQDN y
que esté previa y plenamente resuelto en otro DNS.
Como regla general se generará una zona de reenvío por cada dominio sobre el
cual se tenga autoridad plena y absoluta y se generará una zona de resolución
inversa por cada red sobre la cual se tenga plena y absoluta autoridad. es
decir, si se es propietario del dominio «cualquiercosa.com», se deberá
generar el fichero de zona correspondiente a fin de resolver dicho dominio. Por
cada red con direcciones IP privadas sobre la cual se tenga control y plena y
absoluta autoridad, se deberá generar un fichero de zona de resolución inversa a
fin de resolver inversamente las direcciones IP de dicha zona. Regularmente la
resolución inversa de las direcciones IP públicas es responsabilidad de los
proveedores de servicio ya que son estos quienes tienen la autoridad plena y
absoluta sobre dichas direcciones IP.
Todos los ficheros de zona deben pertenecer al usuario «named» a fin de que
el servicio named pueda acceder a estos o bien modificarlos en el caso de
tratarse de zonas esclavas.
Creación de los ficheros de zona.
Los siguientes corresponderían a los contenidos para los ficheros de zona
requeridos para la red local y por el NIC con el que se haya registrado el
dominio. Note por favor que en las zonas de reenvío siempre se especifica al
menos un Mail Exchanger (MX) y que se utilizan tabuladores (tecla TAB)
en lugar de espacio. Solo necesitará sustituir nombres y direcciones IP, y
quizá añadir nuevos registros para complementar su red local.
Zona de reenvío red local /var/named/chroot/var/named/red-local.zone
$TTL 86400
@ IN SOA dns.red-local. jperez.red-local. (
2006031601; número de serie
28800 ; tiempo de refresco
7200 ; tiempo entre reintentos de consulta
604800 ; tiempo tras el cual expira la zona
86400 ; tiempo total de vida
)
@ IN NS dns
@ IN MX 10 mail
@ IN A 192.168.1.1
intranet IN A 192.168.1.1
maquina2 IN A 192.168.1.2
maquina3 IN A 192.168.1.3
maquina4 IN A 192.168.1.4
www IN CNAME intranet
mail IN A 192.168.1.1
ftp IN CNAME intranet
dns IN CNAME intranet
|
Zona de resolución inversa red local
/var/named/chroot/var/named/1.168.192.in-addr.arpa.zone
$TTL 86400
@ IN SOA dns.red-local. jperez.red-local. (
2006031601 ; número de serie
28800 ; tiempo de refresco
7200 ; tiempo entre reintentos de consulta
604800 ; tiempo tras el cual expira la zona
86400 ; tiempo total de vida
)
@ IN NS dns.red-local.
1 IN PTR intranet.red-local.
2 IN PTR maquina2.red-local.
3 IN PTR maquina3.red-local.
4 IN PTR maquina4.red-local.
|
Zona de reenvío del dominio /var/named/chroot/var/named/dominio.com.zone
Suponiendo que hipotéticamente se es la autoridad para el dominio
«dominio.com», se puede crear una Zona de Reenvio con un contenido
similar al siguiente:
$TTL 86400
@ IN SOA fqdn.dominio-resuelto. cuenta.email.existente. (
2006031601; número de serie
28800 ; tiempo de refresco
7200 ; tiempo entre reintentos de consulta
604800 ; tiempo tras el cual expira la zona
86400 ; tiempo total de vida
)
@ IN NS dns
@ IN MX 10 mail
@ IN A 148.243.59.1
servidor IN A 148.243.59.1
www IN CNAME servidor
mail IN A 148.243.59.1
ftp IN CNAME servidor
dns IN CNAME servidor
|
Zona de resolución inversa del dominio
/var/named/chroot/var/named/1.243.148.in-addr.arpa.zone
Suponiendo que hipotéticamente se es la autoridad para el segmento de red
148.234.1.0/24, se puede crear una Zona de Resolución Inversa con un
contenido similar al siguiente:
$TTL 86400
@ IN SOA fqdn.dominio-resuelto. cuenta.email.existente. (
2006031601 ; número de serie
28800 ; tiempo de refresco
7200 ; tiempo entre reintentos de consulta
604800 ; tiempo tras el cual expira la zona
86400 ; tiempo total de vida
)
@ IN NS dns.dominio.com.
1 IN PTR servidor.dominio.com.
2 IN PTR maquina2.dominio.com.
3 IN PTR maquina3.dominio.com.
4 IN PTR maquina4.dominio.com.
|
Cada vez que haga algún cambio en algún fichero de zona, deberá cambiar el
número de serie (serial) a fin de que tomen efecto los cambios de
inmediato cuando se reinicie el servicio named, ya que de otro modo
tendría que reiniciar el equipo, algo poco conveniente.
Configuración de parámetros en el fichero /etc/named.conf
options {
directory "/var/named/";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
allow-recursion {
127.0.0.1;
192.168.1.0/24;
};
forwarders {
200.33.146.209;
200.33.146.217;
};
forward first;
};
zone "." {
type hint;
file "named.ca";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "0.0.127.in-addr.arpa.zone";
allow-update { none; };
};
zone "localhost" {
type master;
file "localhost.zone";
allow-update { none; };
};
zone "dominio.com" {
type master;
file "dominio.com.zone";
allow-update { none; };
};
zone "1.243.148.in-addr.arpa" {
type master;
file "1.243.148.in-addr.arpa.zone";
allow-update { none; };
};
zone "red-local" {
type master;
file "red-local.zone";
allow-update { none; };
};
zone "1.168.192.in-addr.arpa" {
type master;
file "1.168.192.in-addr.arpa.zone";
allow-update { none; };
};
|
Seguridad adicional en DNS para uso público.
Un DDoS (Distributed Denial of Service) es
una ampliación del ataque DoS, se efectúa con la instalación de varios
agentes remotos en muchas computadoras que pueden estar localizadas en
diferentes puntos del mundo. El atacante consigue coordinar esos agentes para
así, de forma masiva, amplificar el volumen del saturación de información
(flood), pudiendo darse casos de un ataque de cientos o millares de computadoras
dirigido a una máquina o red objetivo. Esta técnica se ha revelado como una de
las más eficaces y sencillas a la hora de colapsar servidores, la tecnología
distribuida ha ido haciendo más sofisticada hasta el punto de otorgar poder de
causar daños serios a personas con escaso conocimiento técnico.
Un DNS configurado para permitir consultas recursivas indiscriminadamente
puede permitir al servidor sufrir o bien participar de un DDoS. Solución
al problema consiste añadir en el fichero /etc/named.conf, en la sección
de opciones (options), el parámetro allow-recursion definiendo la red,
las redes o bien los ACL que tendrán permitido realizar todo tipo de consultas
en el DNS, sean locales o de otros dominios.
Fichero /etc/named.conf
options {
directory "/var/named/";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
allow-recursion {
127.0.0.1;
192.168.1.0/24;
};
forwarders {
200.33.146.209;
200.33.146.217;
};
forward first;
};
zone "." {
type hint;
file "named.ca";
};
zone "dominio.com" {
type master;
file "dominio.com.zone";
allow-update { none; };
};
zone "1.243.148.in-addr.arpa" {
type master;
file "1.243.148.in-addr.arpa.zone";
allow-update { none; };
};
|
Lo anterior hace que solo 192.168.1.0/24 pueda realizar todo tipo de
consultas en el DNS, ya sea para un nombre de dominio hospedado de forma local y
otros dominios resueltos en otros servidores (ejemplos: www.yahoo.com,
www.google.com, www.linuxparatodos.net, etc.). El resto del mundo solo podrá
realizar consultas sobre las zonas dominio.com y
1.243.148.in-addr.arpa, que están hospedados de forma local.
Seguridad adicional en DNS para uso exclusivo en red local.
Si se va a tratar de un servidor de nombres de dominio para uso exclusivo en
red local, y se quieren evitar problemas de seguridad de diferente índole, puede
utilizarse el parámetro allow-query, el cual servirá para especificar que
solo ciertas direcciones podrán realizar consultas al servidor de nombres de
dominio. Se pueden especificar directamente direcciones IP, redes completas o
listas de control de acceso que deberán definirse antes de cualquier otra cosa
en el fichero /etc/named.conf.
Fichero /etc/named.conf
acl "redlocal" {
127.0.0.1;
192.168.1.0/24;
192.168.2.0/24;
192.168.3.0/24;
};
options {
directory "/var/named/";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
allow-recursion { redlocal; };
forwarders {
200.33.146.209;
200.33.146.217;
};
forward first;
allow-query {
redlocal;
192.168.1.15;
192.168.1.16;
};
};
zone "red-local" {
type master;
file "red-local.zone";
allow-update { none; };
};
zone "1.168.192.in-addr.arpa" {
type master;
file "1.168.192.in-addr.arpa.zone";
allow-update { none; };
};
|
Las zonas esclavas.
Las zonas esclavas se refieren a aquellas hospedadas en servidores de nombres
de dominio secundarios y que hacen las funciones de redundar las zonas maestras
en los servidores de nombres de dominio prima
Cesta
950 62 70 23
