Академический Документы
Профессиональный Документы
Культура Документы
Este documenta trata la configuración básica de un servidor DNS en Linux fedora 9, con el paquete BIND
9.5.esta configuración representa un ejemplo en una LAN, y solo trata la configuración del servidor DNS,
posterior mente se tratara la configuración de otros servicios como correo electrónico y un servidor web,
pero esto será en la segunda entrega.
BIND 9.5 Servidor DNS en Fedora…….
9 2009
Índice
Índice…………………………………………………………………………………………………………...2
Introducción……………………………………………………………………………………………………3
1.Conceptos previos……………………………………………………………………………………………4
1.1.¿Qué significa DNS? ………………………………………………………………………………………4
1.2.¿Porque usar un servidor DNS? ……………………………………………………………………...……4
1.3.¿Cómo funciona el DNS? …………………………………………………………………………….……4
1.3.1.El Espacio de Nombres de Dominio………………………………………………………………..……4
1.3.2.El Espacio de Nombres de Dominio en Internet…………………………………………………………5
1.3.3.Delegación…………………………………………………………………………………………..……6
2. Componentes de un DNS……………………………………………………………………………………6
2.1. Clientes DNS………………………………………………………………………………………………6
2.2. Servidores DNS……………………………………………………………………………………………6
2.3. Zonas de Autoridad…………………………………………………………………………………..……7
2.3.1. Zonas de Reenvío…………………………………………………………………………………..……8
2.3.2. Zonas de Resolución Inversa……………………………………………………………………………8
3. Instalación de los paquetes……………………………………………………………………………..……8
3.1. Paquetes necesarios para la configuración…………………………………………………………...……8
3.2. Comprobando que los paquetes estén instalados. …………………………………………………...……9
3.3. Instalar los paquetes necesarios. …………………………………………………………………….……9
4. Configuración del servidor……………………………………………………………………………..……9
4.1. Archivos de configuración. ……………………………………………………………………….……..10
4.1.1. El archivo named.conf …………………………………………………………………………...……10
4.1.2. El archivo named.rfc1912.zones ………………………………………………………………………10
4.1.3. Archivos de zonas. ……………………………………………………………………………….……10
4.1.3.1. Archivo de zona de reenvió (nitsugario.com.zone) ………………………………………………….11
4.1.3.2. Archivo de zona de resolución inversa (192.168.1 )…………………………………………………11
4.2. Configuración de los archivos y creación del los archivos de zonas…………………………………….11
4.2.1. Creación de archivos de zonas. ………………………………………………………………………..11
4.2.1.1. Zona de reenvió nitsugario.com……………………………………………………………………...11
4.2.1.1.1. Descripción del archivo nitsugario.com.zone……………………………………………………..12
4.2.1.2. Zona de resolución inversa 1.168.192.in-addr.arpa…………………………………………………14
4.2.1.2.1. Descripción del archivo 192.168.1…………………………………………………………...……15
4.2.2. Configuración del archivo named.rfc1912.zones………………………………………………...……15
4.2.2.1. Descripción del archivo named.rfc1912.zones………………………………………………………16
4.2.3. Configuración del archivo named.conf…………………………………………………………...……17
4.2.3.1 Descripción del contenido del archivo named.conf……………………………………………….…17
5. Comprobando que funcione la configuración………………………………………………………...……18
5.1. Iniciando el servidor…………………………………………………………………………………...…18
5.2. Parando el servidor ………………………………………………………………………………………19
5.3. Reiniciando el servidor: …………………………………………………………………………………19
5.4. Añadir el servidor al arranque del sistema…………………………………………………………….…19
5.5. Depuración de la configuración………………………………………………………………………….19
5.6. Pruebas con ping………………………………………………………………………………………20
Bibliografía………………………………………………………………………………………………21
El sistema de nombres de dominio “DNS” (Domain Name System), cuya función es saber quién es cada host
con respecto a una dirección IP y un Nombre único en la red.
El otro elemento es el sistema de enrutamiento de internet, que se encarga de conocer cómo están conectadas
entre sí todas estas computadoras y equipos.
Este documento solo abarcaremos la parte concerniente al Sistema de nombres de dominio. Estudiaremos sus
definiciones, elementos características, y el modo de configurar uno en nuestra casa.
Utilizaremos el sistema operativo Linux Fedora 9 y el paquete por excelencia para hacer esta tarea BIND en
su versión 9.5.
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:
El Servidor DNS BIND es ampliamente utilizado en la Internet (99% de los servidores DNS)
proporcionando una robusta y estable solución.
“Recuerda que si te equivocas o cometes un erro en algo, recuerda has aprendido una forma de
cómo no hacerlo (Agustín Ríos)”.
DNS acrónimo de Domain Name System que interpretado en español es Sistema de Nombres de Dominio.
Al comienzo de TCP/IP, puesto que las redes no eran muy extensas, o en otras palabras que el número de
equipos conectados a la misma red era bajo, los administradores de red crearon archivos llamados tablas de
conversión manual. Estas tablas de conversión manual eran archivos secuenciales, por lo general llamados
hosts o hosts.txt, y asociaban en cada línea la dirección IP del equipo con el nombre literal relacionado,
denominado nombre del ordenador.
Sin embargo, el anterior sistema de tablas de conversión exigía una actualización manual de las tablas para la
totalidad de los equipos en caso de incluir o modificar el nombre de una máquina. Por lo tanto, con el
aumento en tamaño de las redes y sus interconexiones, fue necesario implementar un sistema de gestión para
los nombres que fuese jerárquico y fácil de administrar. El sistema llamado Sistema de Nombres de Dominio
(DNS) fue desarrollado en noviembre de 1983 por Paul Mockapetris (RFC 882 y RFC 883) y luego revisado
en 1987 en las RFC 1034 y 1035. El DNS ha sido sometido a varias RFC.
un sistema de servidores de distribución que permite que el espacio de nombre esté disponible.
un sistema de cliente que permite "resolver" nombres de dominio, es decir, interrogar a los
servidores para encontrar la dirección IP que corresponde a un nombre.
El Sistema de Nombres de Dominio permite a los usuarios de una red TCP/IP utilizar nombres jerárquicos y
descriptivos para localizar fácilmente ordenadores (hosts) y otros recursos en dicha red, evitando de esta
manera tener que recordar la dirección IP de cada ordenador al que se desea acceder. En esencia, DNS es una
base de datos distribuida que contiene asociaciones de nombres simbólicos (de hosts) a direcciones IP. El
hecho de que sea distribuida permite delegar el control sobre diferentes segmentos de la base de datos a
distintas organizaciones, pero siempre de forma que los datos de cada segmento están disponibles en toda la
red, a través de un esquema cliente-servidor.
Los programas denominados servidores de nombres (name servers) constituyen la parte servidora del
esquema cliente-servidor. Los servidores de nombres contienen información sobre algunos segmentos de la
base de datos y los ponen a disposición de los clientes, llamados solucionadores o resolvers.
La base de datos distribuida de DNS está indexada por nombres de dominio. Cada nombre de dominio es
esencialmente una trayectoria en un árbol invertido denominado espacio de nombres de dominio. La
estructura jerárquica del árbol es similar a la estructura del sistema de ficheros UNIX. El árbol tiene una
única raíz en l nivel superior llamada raíz (root). Cada nodo del árbol puede ramificarse en cualquier número
de nodos de nivel inferior. La profundidad del árbol está limitada a 127 niveles.
Como ejemplo: suponiendo que se tiene un dispositivo cuyo nombre de anfitrión es «maquina1» y un
dominio «dominio.com», el FQDN sería «maquina1.dominio.com.», de modo define de modo único 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 de un dominio 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.
En el esquema jerárquico de nombres DNS, se denomina dominio a cualquier subárbol del espacio de
nombres de dominio. De esta forma, cada dominio puede contener, a su vez, otros dominios. Generalmente,
los hosts están representados por las hojas del árbol, aunque es posible nombrar a un host con una etiqueta
correspondiente a un nodo intermedio del árbol (en este caso, tendríamos un dominio y un nodo que se
llaman igual).
La información sobre los nombres de dominio DNS se guarda mediante los denominados registros de
recursos en los servidores DNS de la red. Concretamente, cada servidor DNS contiene los registros de
recursos necesarios para responder a las consultas sobre la parte del espacio de nombres en la que tiene
autoridad.
El estándar DNS no impone muchas reglas sobre las etiquetas de los nombres de dominio, ni tampoco asocia
un significado determinado a las etiquetas de un determinado nivel del espacio de nombres.
Cuando manejamos una parte de este espacio, podemos decidir el significado y la sintaxis de nuestros
nombres de dominio. Sin embargo, en el espacio de nombres Internet existente, se ha impuesto una
estructura de nombres bien definida, especialmente en los dominios de primer nivel.
Los dominios originales de primer nivel dividían originalmente el espacio de nombres de Internet en siete
dominios: com, edu, gov, mil, net, org, e int. Posteriormente, para acomodar el crecimiento y la
internacionalización de Internet, se reservaron nuevos dominios de primer nivel que hacían referencia a
países individuales.
Actualmente, los dominios originales se denominan dominios de primer nivel genéricos y han surgido
nuevos nombres que se ajustan a los tiempos que corren.
Es importante resaltar que el objetivo principal del diseño del sistema de nombres de dominio fue su
administración descentralizada. Este objetivo se consigue a través de la delegación. La delegación de
dominios funciona de forma parecida a la delegación de tareas en una organización. Un responsable de
proyecto divide el proyecto en pequeñas tareas y asigna (delega) la responsabilidad de las mismas a
diferentes empleados.
De la misma forma, una organización que administra un dominio puede dividirla en subdominios. Cada
subdominio puede ser delegado a diferentes organizaciones, lo cual implica que esa organización será
responsable de mantener los datos (registros de recursos) de ese subdominio. Esa organización puede
libremente cambiar los datos e incluso volver a dividir el dominio delegado en subdominios y delegarlos. El
dominio padre solamente contiene enlaces a los responsables del subdominio delegado, de forma que pueda
hacer referencia a ellos cuando se le planteen consultas sobre nombres en dicho subdominio delegado.
2. Componentes de un DNS
Los DNS operan a través de tres componentes: Clientes DNS, Servidores DNS y Zonas de Autoridad.
Un gran número de problemas de operación de servidores DNS se atribuyen a las pobres opciones de
servidores secundarios para las zonas 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 la 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.
6 Ing. Agustín Ríos Reyes nitsugario@gmail.com
BIND 9.5 Servidor DNS en Fedora…….
9 2009
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 Recursivas
El Servidor DNS asume toda la carga de proporcionar la 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 lograr la respuesta.
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:
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: 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.
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.
bind:
Este paquete incluye el Servidor DNS (named) y herramientas para verificar su funcionamiento.
bind-libs:
Este paquete contiene Bibliotecas 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:
Este paquete contiene una 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.
Si se utiliza de Red HatTM Enterprise Linux 4, o versiones posteriores, se puede instalar utilizando lo
siguiente:
Nota: para la utilización del comando yum y up2date, se requiere tener acceso a internet.
Nota: recuerda que para poder instalar paquetes, debes tener privilegios de súper usuario.
Una vez instalado todo lo necesario, podemos empezar a configurar nuestro servidor.
Primero voy explicar cómo se conformara el ejemplo que vamos a utilizar. Se esta utilizando Fedora 9, el
servidor está conectado a una red privada (LAN),el cual tiene una dirección IP que es la 192.168.1.2 y en la
red están otras dos maquinas que son las PCs de mi hermano Cesar (IP 192.168.1.1, SO. Windows XP) y la
PC de mi hermana Luz Elena (IP 192.168.1.3, SO Windows XP). Para esta red he escogido el dominio
“nitsugario.com”, el cual tendrá los servicios y www, pop3, smtp, ftp, estor servicios serán configurados
posterior mente.
Se encuentra en el directorio /etc. Para acceder a él, usamos el comando “cd ” de la siguiente forma.
Se encuentra en el directorio /etc. Para acceder a el, usamos el comando “cd ” de la siguiente forma.
[root@nitsugario ~]# cd /etc
Los siguientes corresponderían a los contenidos para los ficheros de zona requeridos para la red local
(dominio nitsugario.com) 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 o lo que quiera hacer.
$TTL 86400
@ IN SOA nitsugario.com. nitsugario@gmail.com. (
2009021701; 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
)
nitsugario.com. IN NS ns1.nitsugario.com.
nitsugario.com. IN MX 10 ns1.nitsugario.com.
localhost IN A 127.0.0.1
nitsugario.com. IN A 192.168.1.2
ns1 IN A 192.168.1.2
cesar IN A 192.168.1.1
luz IN A 192.168.1.3
www IN A 192.168.1.2
pop3 IN A 192.168.1.2
smtp IN A 192.168.1.2
ftp IN A 192.168.1.2
Nota: 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.
Nota: un punto y coma, ";", en el archivo indica que todo lo que hay a su derecha es un comentario.
11 Ing. Agustín Ríos Reyes nitsugario@gmail.com
BIND 9.5 Servidor DNS en Fedora…….
9 2009
4.2.1.1.1. Descripción del archivo nitsugario.com.zone
A continuación desmenuzaremos el contenido del archivo nitsugario.com.zone, indicando para que sirve
cada línea escrita en el.
El campo <serial−number> es un número que se incrementa cada vez que se modifica un fichero de una
zona, de forma que Bind se dé cuenta de que tiene que recargar esta zona. Se recomienda usar la fecha de
modificación en formato AAAAMMDD, donde AAAA es el año en formato de cuatro cifras, MM es el mes
en dos cifras, y DD es el día de mes en dos cifras, seguido de un número de dos cifras, empezando por el 01.
De este modo se podrán realizar hasta cien cambios por día.
El campo <time−to−refresh> le dice a los servidores secundarios (esclavos) cuánto tiempo deben esperar
antes de preguntar a su servidor principal (maestro) si se ha hecho algún cambio en la zona.
El valor del campo <serial−number> es usado por los esclavos para determinar si se está usando información
anticuada que deba actualizarse.
El campo <time−to−retry> especifica a los servidores esclavos el intervalo de tiempo a esperar antes de
solicitar una actualización en el caso de que el servidor de nombres principal no esté respondiendo. Si el
servidor maestro no ha respondido a la petición de actualización antes de que expire el tiempo del campo
<time−to−expire>, el esclavo dejará de actuar como servidor el autorizado de ese espacio de nombres (zona).
cesar IN A 192.168.1.1
luz IN A 192.168.1.3
www IN A 192.168.1.2
pop3 IN A 192.168.1.2
smtp IN A 192.168.1.2
ftp IN A 192.168.1.2
A propósito del concepto de alias (www, pop3, smtp y ftp son de hecho el mismo host) existe una
controvertida discusión sobre si es mejor usar el tipo de registro CNAME (del inglés, Canonical NAME) o
IN A. Muchos gurús de Bind recomiendan no usar registros CNAME en absoluto, si bien esa discusión se
escapa de los objetivos de este artículo. En cualquier caso, es muy recomendable seguir la regla de que los
registros MX, CNAME y SOA nunca deben referenciar un registro CNAME, sino exclusivamente algo con
un registro tipo "A".
$TTL 86400
@ IN SOA nitsugario.com. nitsugario@gmail.com. (
2009021701 ; 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 ns1.nitsugario.com.
2 IN PTR ns1.nitsugario.com.
1 IN PTR cesar.nitsugario.com.
3 IN PTR luz.nitsugario.com.
2 IN PTR www.nitsugario.com.
2 IN PTR pop3.nitsugario.com.
2 IN PTR smtp.nitsugario.com.
2 IN PTR ftp.nitsugario.com.
Nota: 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.
Nota: un punto y coma, ";", en el archivo indica que todo lo que hay a su derecha es un comentario.
De nuevo, los conceptos son los mismos (la "@" − arroba − indica el dominio de la zona nitsugario.com., el
"." − punto − del final hace referencia al servidor de nombres raíz y el registro "SOA" tiene exactamente la
misma estructura y funcionalidad), excepto las dos últimas líneas:
Línea @ IN NS ns1.nitsugario.com. :
Indican a qué servidores de nombres debe preguntarse por la traducción inversa de una dirección IP de esta
zona.
Es obvio que aquí "falta información", pues la dirección IP 192.168.1.2 equivale, en realidad, a más hosts, tal
y como hemos especificado en el fichero 192.168.1. Esto es cierto los cuales son:
2 IN PTR www.nitsugario.com.
2 IN PTR pop3.nitsugario.com.
2 IN PTR smtp.nitsugario.com.
2 IN PTR ftp.nitsugario.com.
También falta mencionar las demás IP de las otras dos maquinas que están en la red. Y para estas cambia el
número inicial que es el que corresponde a su IP.
1 IN PTR cesar.nitsugario.com.
3 IN PTR luz.nitsugario.com.
Estos dos son diferentes por sus IPs que serian, para cesar la dirección 192.168.1.1 y para Luz 192.168.1.2.
zone "nitsugario.com" {
type master;
file "nitsugario.com.zone";
allow-update { none; };
};
zone "1.168.192.in-addr.arpa" {
type master;
file "192.168.1";
allow-update { none; };
};
En este archivo puede a ver más para metro, los cuales son usados para aumentar la seguridad del servidor.
Los cuales pueden ser.
allow−query { any; }; :
Significa que se permiten consultas (del inglés, queries) externas a la zona.
Esto es algo útil y necesario, a menos que se quiera ser muy paranoico con la seguridad. Simplemente se
ofrece de forma técnicamente ordenada la información que es públicamente accesible.
allow−transfer { slaves; }; :
Posibilita la transferencia automática de esta configuración a los servidores secundarios de las zonas bajo
nuestro control que se especifiquen en la lista slaves. Se profundizará más en el punto de transferencia de
zonas.
Se han usado dos palabras especiales, any y slaves, que requieren una mención especial. Efectivamente,
además de hacer notar la sintaxis similar a la del lenguaje de programación C, con la que se debe ser
extremamente cuidadoso, hay dos comentarios extras que hacer:
1. any es una palabra reservada de la sintaxis de bind que significa "cualquier dirección IP", como era
lógico. Su uso es muy común y necesario. Otras palabras reservadas importantes son none, que
significa "ningún host", localhost, que significa el host local desde cualquiera de las interfaces del
sistema, y localnets, que representa a todos los hosts de las redes para las cuales el sistema tiene una
interfaz.
2. slaves, en cambio, no es ninguna palabra reservada de bind, sino que corresponde al concepto de lista
de control de acceso (ACL, del inglés, Access Control List). Estas listas de direcciones IP nos ahorran trabajo
pues, de este modo, tan sólo tenemos que especificarlas una vez y, dado que les asginamos un identificador
de grupo, podemos referenciarlas de forma más simple y rápida. Este es el código de la ACL usada en el
ejemplo que, por supuesto, debe especificarse en algún lugar del documento antes de ser usada:
acl "slaves" {
213.96.79.79;
};
El lector se habrá dado cuenta en seguida de las grandes ventajas de usar estas listas, aún cuando, como en
este caso, no gane materialmente excepto en previsión de un tercer servidor de nombres secundario. Nótese
que en los identificadores de las ACL se diferencian mayúsculas y minúsculas (en inglés, case sensitive).
options {
listen-on port 53 { 192.168.1.2; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { any;};
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
include "/etc/named.rfc1912.zones";
La clausula options:
Agrupa declaraciones que controlan el comportamiento general o global y tiene alcance en todas las zonas,
vistas y en otras clausulas. Esta clausula puede tomar una gran cantidad de declaraciones.
Sintaxis:
options {
// Declaraciones de opciones
};
La clausula logging:
Define las características comportamiento y formato de BIND’s extensive logging.
La clausula zone:
Contiene declaraciones que definen el comportamiento para una zona en específico. El alcance de
La Declaración es limitada a esa zona solamente.
La clausula include:
La declaración de inclusión es única y puede estar en cualquier lugar del archivo de named.conf, no puede
estar declarada dentro o fuera de una cláusula. Lo que hace esta clausula es leer el contenido del archivo
especificad para procesar lo que este escrito. Su declaración tiene la siguiente forma:
El nombre de archivo es una cadena dada y puede ser una ruta total, por ejemplo, /var/named/file.name,
O respectivo, por ejemplo, file.name, en este caso donde no se declaró un directorio, se da por hecho que es
el directorio donde esta named.conf que es normalmente /etc.
2. Para aislar y dividir los cambios y las actualizaciones: por ejemplo, si las cláusulas de acl cambian
frecuentemente, Puede ser deseable separarlos en archivos que pueden estar incluidos, a saber
Minimizar la necesidad de editar el archivo de named.conf principal.
3. Controlar los permisos: puede ser deseable limitar el acceso usando permisos restringidos.
Lo anterior, si está funcionando correctamente, debería devolver algo parecido a lo mostrado a continuación:
Como se puede ver en las imágenes se el servidor ya está funcionando correctamente. Y ya con esto tenemos
un servidor DNS básico para un pequeña LAN.