Contenido Semana8 VF

Administración de Servicios
SEMANA 8
DNS
Todos los derechos de autor son de la exclusiva propiedad de IACC o de los otorgantes de sus licencias. No está
permitido copiar, reproducir, reeditar, descargar, publicar, emitir, difundir, poner a disposición del público ni 1
ESTE
utilizarDOCUMENTO
los contenidos paraCONTIENE LAdeSEMANA
fines comerciales 8
ninguna clase.
2
ESTE DOCUMENTO CONTIENE LA SEMANA 8
ÍNDICE
DNS ...................................................................................................................................................... 4
OBJETIVOS ESPECÍFICOS ........................................................................................................................... 4
INTRODUCCIÓN ...................................................................................................................................... 4
1. Servidor DNS.................................................................................................................................... 5
1.1. Como funcionan los DNS ...................................................................................................... 9
1.2. Jerarquía de servidores ....................................................................................................... 10
1.3. Roles de servidores DNS ..................................................................................................... 11
1.4. Primario vs esclavo ............................................................................................................. 12
2. Instalando DNS............................................................................................................................... 12
2.1. Archivos de zona ................................................................................................................. 18
2.2. Finalización del ejemplo ..................................................................................................... 21
COMENTARIO FINAL.......................................................................................................................... 25
REFERENCIAS........................................................................................................................................ 26
3
DNS
OBJETIVOS ESPECÍFICOS
 Reconocer los distintos componentes de un servidor DNS.
 Evaluar las distintas opciones de instalación de un servidor DNS.
 Escoger una de las opciones de configuración de un servidor DNS.
INTRODUCCIÓN
Si una persona ha utilizado Internet en su vida, se puede decir que esta persona ha utilizado DNS,
aunque no se hubiera dado cuenta. Internet está compuesta de billones de máquinas conectadas
(si se toma en consideración IPv4 son 4.294.967.296 máquinas o
340.282.366.920.938.463.463.374.607.431.768.211.456 máquinas si se toma en consideración
IPv6).
Es casi imposible memorizar la dirección IP de todos los sitios que las personas visitan
regularmente, de hecho, es probable que la memorización de esa IP no sea relevante para las
personas. Por ejemplo, muchos estudiantes vistan 200.6.18.15 todos los días, pero seguramente
no saben que esa es la dirección IP de www.iacc.cl. Es difícil, recordar números más fácil recordar
palabras.
Es aquí donde entra DNS (Domain Name System por sus sigla en inglés), el cual actúa básicamente
como una gigantesca guía telefónica que se encarga de traducir los dominios que conoce como
www.iacc.cl, www.google.como, www.lun.cl , etc., a sus respectivas direcciones IP.
4
1. Servidor DNS
Antes de iniciar el contenido de esta semana acerca de los servidores de nombres, es conveniente
identificar algunos términos que serán de utilidad:
Sistema de dominio de nombres: Domain Name System en inglés o simplemente DNS, es el

sistema que permite traducir nombres fáciles de recordar para los seres humanos en direcciones
IP.
Fuente: http://www.mastermagazine.info/termino/4714.php
Nombre de dominio: Domain Name en inglés. El nombre de dominio es el nombre amigable que
las personas normalmente asocian con un recurso de internet. Por ejemplo “iacc.cl” es un nombre
de dominio. Algunos argumentan que el segmento “iacc” es el nombre del dominio, pero por lo
general el combinado “iacc.cl” será el nombre del dominio.
Fuente: http://soupupyoursite.com/so-you-wanna-start-a-website/choosing-a-domain-name/
Dirección IP: una dirección IP es el identificador por el cual es posible localizar a un servidor, cada
dirección IP debe ser única dentro de su red. Cuando -se hace referencia- a servidores web, de
email, etc., la red de la que se habla es de Internet, y por lo tanto, la dirección IP debe ser única
dentro de Internet. En la actualidad se utiliza normalmente IPv4 por lo que se hará referencia a
este formato.
5
Una dirección IPv4 está compuesta de cuatro sets de tres dígitos cada uno separados por punto.
Es decir, de la forma “aaa.bbb.ccc.ddd”. Cada segmento va desde el 0 hasta el 256. Una dirección
IPv6 está compuesta de ocho números hexadecimales separados por “:”, un ejemplo de Ipv6 es
por ejemplo 2001:0cb8:85a3:0000:0000:8a2e:0370:7334.
Fuente:http://courses.cs.washington.edu/courses/cse190m/11sp/lectures/slides/lecture01-internet-
html.shtml
Dominio de alto nivel: Top-level Domain en inglés o simplemente TLD. Es la parte más general de
un dominio, el TLD es la porción de más a la derecha dentro de una dirección. Los TLD más
comunes son .com, .net, .org, .edu. Adicionalmente existe un TLD por cada país, en el caso de Chile
el TLD es .cl. Los dominios de alto nivel se encuentran bajo el control de ICANN (Internet
Corporation for Assigned Names and Numbers) que distribuye la administración de algunos TLD a
entes registrantes, en el caso de Chile, el administrador del TLD .cl es NIC Chile.
Fuente: http://www.masterworks.com/2014/07/ngo-the-new-non-profit-domain
Hosts: el propietario de un dominio puede definir equipos individuales. Por lo general, los
administradores eligen utilizar simplemente el dominio (iacc.cl) y hacer referencia a su servidor
web a través de la definición “www”. Otro ejemplo común es habilitar el servidor de ftp bajo la
definición “ftp” por lo que el servidor quedaría disponible bajo ftp.dominio.cl. Los nombres de
hosts pueden ser de cualquier largo mientras sean únicos dentro del dominio.
6
Fuente: http://www.allywebs.com/webhosting.html
Subdominio: DNA funciona de modo jerárquico, un TLD puede tener muchos dominios, por
ejemplo “emol.cl” y “iacc.cl” ambos pertenecen al TLD “.cl” por lo que tanto “iacc” como “emol”
son subdominios de “.cl”. De igual forma un dominio puede tener varios subdominios, en estricto
rigor, si el grupo de finanzas de iacc tuviera su propio servidor web, el administrador del dominio
podría crear el subdominio “finanzas” y apuntar el servidor web del grupo de finanzas mediante
una URL de la forma www.finanzas.iacc.cl
Fuente: http://www.dailyhostnews.com/sub-domain-or-sub-directory
Nombre de dominio completamente calificado: Fully Qualified Domain Name en inglés o

simplemente FQDN es lo que se llama un nombre de dominio absoluto. Los dominios pueden ser
expresados en relación a otros, por lo que, en algunos casos puede ser confuso. Pero un FQDN es
un nombre absoluto que expresa su ubicación en relación a la raíz del sistema de DNS. Esto quiere
decir que un FQDN incluye todos sus dominios padres, hasta llegar al TLD. Un ejemplo de FQDN es
“mail.google.com”.
7
Fuente: http://tsdnet.estudio.com.sg/EIDTSDCMS/Flash13/Windows_Server_TSP_Version/win_server/5-
32.htm
Fuente: http://www.websitepulse.com/blog/how-to-check-a-name-server
8
Servidor de nombres: un servidor de nombres (Name Server en inglés) se encarga de traducir los
nombres de dominio a direcciones IP. La mayoría de los servidores de nombre trabaja dentro del
sistema de DNS, ya que el número de dominios es demasiado grande para que un solo servidor se
encargue de ello, cada servidor puede redirigir las consultas que reciba a otro servidor de nombres
o delegar la responsabilidad de una porción -de los dominios que controle. Los servidores pueden
ser autoritativos (dan respuesta directa sobre dominios bajo su control) o redirigir a otros
dominios o almacenar copia de los datos de otro servidor de nombres.
Archivo de zona: un archivo de zona es simplemente un archivo de texto que contiene una
asociación entre nombre de dominio y direcciones IP. Esta es la forma en la que un servidor DNS
sabe cuál IP debe ser contactada cuando un usuario solicita algún dominio. Los archivos de zona
residen en los servidores de nombre.
Registro: Un registro es una entrada dentro de un archivo de zona, este registro es una asociación
entre un recurso y su nombre.
1.1. ¿CÓMO FUNCIONAN LOS DNS?

Desde un punto de vista macro, el sistema de DNS es my simple, pero a medida que se profundiza
en los detalles se comienza a apreciar la complejidad del sistema. DNS ,es sin lugar, a dudas la base
de datos más consultada del planeta, y es capaz de responder a las consultas mientras miles de
registros de DNS son actualizados en todo el mundo, nuevos registros creados y otros dados de
baja. Muchas de estas cualidades residen en el modelo distribuido de DNS.
Fuente : http://4.bp.blogspot.com/-gkzBLu2Almw/Uux72aXNBKI/AAAAAAAAGOY/y3kjyW7jCEw/s1600/dns-
rev-3.jpg
9
Cuando una aplicación quiere accesar un servidor utilizando su nombre de dominio, lo primero
que se debe hacer es saber cómo traducir el nombre de dominio en una dirección IP a la cual
pueda dirigirse. Sin esta información no se puede enviar ni recibir dato alguno. Algunas
aplicaciones como un navegador y otras, mantienen un registro interno de las direcciones a las
que han accesado recientemente. Este es el primer lugar en donde dicha aplicación buscará
resolver la IP. Si no seencuentra aquí, la aplicación solicitará al resolvedor del equipo que
determine cuál es la IP a la cual debe dirigirse.
Un resolvedor es, en general, cualquier componente que participe en una consulta de DNS en
modo cliente, por lo general los resolvedores los equipos normales son llamados “resolvedores
tontos” pues no van más allá de consultar algunos archivos del sistema como /etc/hosts (recordar
que en semanas anteriores se modificó este archivo para hacer algunos servicios ubicables para el
servidor) y en caso de el registro buscado no se encuentre allí, redireccionar la petición a otro
resolvedor.
La aplicación generó una solicitud de DNS, la cual fue entregada al resolvedor del sistema, este al
no poder resolver la solicitud, se contacta con un servidor DNS para el cual ya conoce su IP. Este
servidor DNS es lo que se conoce como un servidor DNS recursivo. Se llaman de esta forma pues
estos servidores han sido configurados para contactarse con otros servidores DNS hasta que
logren resolver la consulta o retornen un mensaje de error al cliente.
Los servidores recursivos mantienen su propia caché de direcciones, si no la encuentra en lacaché,

revisará si tiene la dirección del servidor que controla la componente superior del dominio. Por
ejemplo, si un servidor DNS no tiene en sus registros www.iacc.cl, revisará si tiene en sus registros
iacc.cl y en caso de ser necesario .”cl”. El servidor intentará enviar su petición al dominio más
específico que pueda encontrar.
Si no logra resolver ningún componente del dominio, el servidor debe comenzar por el tope de la
jerarquía preguntando directamente a los servidores raíz del sistema DNS, estos servidores
conocen las direcciones de todos los servidores TLD que controlan las zonas .com, .net, .cl, etc. En
el ejemplo, al preguntar por www.iacc.cl a un servidor root, este redirigirá la consulta al servidor
TLD de .cl.
De esta forma cada servidor va dirigiendo al cliente hasta el servidor que contiene el registro
exacto que se estaba buscando.
1.2. JERARQUÍA DE SERVIDORES

En el ejemplo anterior se observa que el sistema de DNS es un sistema altamente jerarquizado. A
continuación se detalla la jerarquía existente:
10
Fuente: http://opentodo.net/2011/12/a-bit-of-bind-part-i/
Root servers: existen 13 servidores raíz en todo el mundo. Puede obtener un listado de ellos en:
https://www.iana.org/domains/root/servers. Los servidores raíz en realidad no saben dónde está
ubicado cada dominio, pero sí pueden indicar quién debiera saber dónde se encuentra el TLD del
dominio que se busca.
TLD servers: los servidores de TLD son los que contienen información sobre cada TLD. Un servidor
raíz, por lo general dirigirá las consultas a un servidor TLD. Si una persona busca www.iacc.cl, el
servidor raíz lo dirigirá al servidor TLD de “.cl”. Este, a su vez, no conoce www.iacc.cl, pero si tiene
información de quien es servidor responsable de iacc.cl.
Domain-level name servers: Estos servidores se encargan de responder consultas sobre su

dominio, en el ejemplo, toda consulta sobre iacc.cl puede ser respondida por este servidor, en
particular este servidor contiene la información IP sobre www.iacc.cl.
1.3. ROLES DE SERVIDORES DNS

Dentro de la infraestructura de DNS, los servidores pueden tomar distintos roles, cada uno de ellos
está mejor capacitado para ciertas funciones.
Servidor DNS Autoritativo: los servidores autoritativos solo se preocupan de responder consultas
relacionadas a la zona de la que son responsables, ya que no ayudan a resolver consultas sobre
zonas que no son las suyas, por lo general son muy rápidos y eficientes para responder consultas.
Adicionalmente, los servidores autoritativos no responden consultas recursivas, es decir, única y
11
exclusivamente responden sobre la zona que les corresponde. Por este mismo motivo, no tienen
caché de otras zonas.
Servidores DNS de caché: los servidores de caché se encargan de manejar las consultas recursivas
de los clientes. Mientras los servidores autoritativos son ideales para responder consultas sobre
dominios, los servidores de caché son más útiles para los clientes en general, ya que resuelven y
almacenan los resultados de varias consultas, de esta forma, los clientes no deben pasar por varios
servidores antes de encontrar lo que buscan.
Servidores de redirección: Forwarding DNS Servers en inglés. Se utilizan principalmente para

agregar un salto adicional en la cadena de resolución de nombres. Las ventajas es que permite por
ejemplo, tener un servidor de caché de forma local para agilizar las respuestas de los clientes
locales mientras las consultas a otros dominios se pueden redirigir a servidores DNS públicos.
1.4. PRIMARIO VS. ESCLAVO

Debido a la importancia de DNS en hacer los servidores de una zona accesibles, por lo general los
servidores autoritativos de una zona tienen respaldo, la relación entre un servidor y su respaldo se
conoce comúnmente como maestro-esclavo. Es importante destacar que tanto el esclavo como el
maestro son autoritativos para las zonas que manejan y que el maestro tiene el mismo grade de
“poder” que el esclavo. La única diferencia está en que el maestro es donde los administradores
editan las zonas y esta después es transferida al esclavo.
Es posible que un servidor sea maestro de un dominio y esclavo de otro.
2. INSTALANDO DNS
La instalación de un servidor DNS se facilita enormemente gracias a yum. Adicionalmente, Fedora
tiene la opción de instalar una versión del daemon que corre bajo un chroot. El nombre del
daemon con el cual corre el servidor DNS es named-chroot.
Para proceder con la instalación del servidor DNS, es necesario ejecutar el comando yum con el
nombre del paquete a instalar, en este caso es bind-chroot.
yum install bind-chroot
La salida del comando se detalla a continuación.
12
[root@localhost ~]# yum install bind-chroot
Complementos cargados:langpacks, refresh-packagekit
Bloqueo existente en /var/run/yum.pid: otra copia se encuentra en ejecución como
pid 2202.
Another app is currently holding the yum lock; waiting for it to exit...
La otra aplicación es: PackageKit
Memoria : 289 M RSS (714 MB VSZ)
Iniciado: Mon Nov 10 19:09:19 2014 - 02:59 atrás
Estado : Ininterrumplible, pid: 2202
Resolviendo dependencias
--> Ejecutando prueba de transacción
---> Paquete bind-chroot.x86_64 32:9.9.4-15.P2.fc20 debe ser instalado
--> Procesando dependencias: bind = 32:9.9.4-15.P2.fc20 para el paquete:
32:bind-chroot-9.9.4-15.P2.fc20.x86_64
---> Paquete bind.x86_64 32:9.9.4-15.P2.fc20 debe ser instalado
--> Procesando dependencias: bind-libs = 32:9.9.4-15.P2.fc20 para el paquete:
32:bind-9.9.4-15.P2.fc20.x86_64
---> Paquete bind-libs.x86_64 32:9.9.4-8.fc20 debe ser actualizado
---> Paquete bind-libs.x86_64 32:9.9.4-15.P2.fc20 debe ser una actualización
--> Procesando dependencias: bind-license = 32:9.9.4-15.P2.fc20 para el paquete:
32:bind-libs-9.9.4-15.P2.fc20.x86_64
---> Paquete bind-license.noarch 32:9.9.4-8.fc20 debe ser actualizado
--> Procesando dependencias: bind-license = 32:9.9.4-8.fc20 para el paquete:
32:bind-libs-lite-9.9.4-8.fc20.x86_64
---> Paquete bind-license.noarch 32:9.9.4-15.P2.fc20 debe ser una actualización
---> Paquete bind-libs-lite.x86_64 32:9.9.4-8.fc20 debe ser actualizado
---> Paquete bind-libs-lite.x86_64 32:9.9.4-15.P2.fc20 debe ser una
actualización
--> Resolución de dependencias finalizada
Dependencias resueltas
================================================================================
Package Arquitectura
Versión Repositorio Tamaño
================================================================================
Instalando:
bind-chroot x86_64 32:9.9.4-15.P2.fc20 updates 82 k
Instalando para las dependencias:
bind x86_64 32:9.9.4-15.P2.fc20 updates 1.6 M
Actualizando para las dependencias:
bind-libs x86_64 32:9.9.4-15.P2.fc20 updates 990 k
bind-libs-lite x86_64 32:9.9.4-15.P2.fc20 updates 702 k
bind-license noarch 32:9.9.4-15.P2.fc20 updates 80 k
Resumen de la transacción
================================================================================
Instalar 1 Paquete (+1 Paquete dependiente)
Actualizar ( 3 Paquetes dependientes)
Tamaño total: 3.4 M
13
Tamaño total de la descarga: 1.7 M
Is this ok [y/d/N]: n
Exiting on user command
Su transacción fue guardada, vuelva a ejecutarla con:
yum load-transaction /tmp/yum_save_tx.2014-11-10.19-12.sHrc7z.yumtx
[root@localhost ~]# yum install bind-chroot bind-utils
Complementos cargados:langpacks, refresh-packagekit
Resolviendo dependencias
---> Paquete bind-chroot.x86_64 32:9.9.4-15.P2.fc20 debe ser instalado
--> Procesando dependencias: bind = 32:9.9.4-15.P2.fc20 para el paquete:
32:bind-chroot-9.9.4-15.P2.fc20.x86_64
---> Paquete bind-utils.x86_64 32:9.9.4-8.fc20 debe ser actualizado
---> Paquete bind-utils.x86_64 32:9.9.4-15.P2.fc20 debe ser una actualización
---> Paquete bind.x86_64 32:9.9.4-15.P2.fc20 debe ser instalado
--> Procesando dependencias: bind-libs = 32:9.9.4-15.P2.fc20 para el paquete:
32:bind-9.9.4-15.P2.fc20.x86_64
---> Paquete bind-libs.x86_64 32:9.9.4-8.fc20 debe ser actualizado
---> Paquete bind-libs.x86_64 32:9.9.4-15.P2.fc20 debe ser una actualización
--> Procesando dependencias: bind-license = 32:9.9.4-15.P2.fc20 para el paquete:
32:bind-libs-9.9.4-15.P2.fc20.x86_64
---> Paquete bind-license.noarch 32:9.9.4-8.fc20 debe ser actualizado
--> Procesando dependencias: bind-license = 32:9.9.4-8.fc20 para el paquete:
32:bind-libs-lite-9.9.4-8.fc20.x86_64
---> Paquete bind-license.noarch 32:9.9.4-15.P2.fc20 debe ser una actualización
---> Paquete bind-libs-lite.x86_64 32:9.9.4-8.fc20 debe ser actualizado
---> Paquete bind-libs-lite.x86_64 32:9.9.4-15.P2.fc20 debe ser una
actualización
--> Resolución de dependencias finalizada
Dependencias resueltas
================================================================================
Package Arquitectura
Versión Repositorio Tamaño
================================================================================
Instalando:
bind-chroot x86_64 32:9.9.4-15.P2.fc20 updates 82 k
Actualizando:
bind-utils x86_64 32:9.9.4-15.P2.fc20 updates 356 k
Instalando para las dependencias:
bind x86_64 32:9.9.4-15.P2.fc20 updates 1.6 M
Actualizando para las dependencias:
bind-libs x86_64 32:9.9.4-15.P2.fc20 updates 990 k
bind-libs-lite x86_64 32:9.9.4-15.P2.fc20 updates 702 k
bind-license noarch 32:9.9.4-15.P2.fc20 updates 80 k
Resumen de la transacción
================================================================================
Instalar 1 Paquete (+1 Paquete dependiente)
Actualizar 1 Paquete (+3 Paquetes dependientes)
14
Tamaño total: 3.8 M
Tamaño total de la descarga: 1.7 M
Is this ok [y/d/N]: y
Downloading packages:
(1/2): bind-chroot-9.9.4-15.P2.fc20.x86_64.rpm | 82 kB 00:02
(2/2): bind-9.9.4-15.P2.fc20.x86_64.rpm | 1.6 MB 00:08
--------------------------------------------------------------------------------
Total 194 kB/s | 1.7 MB 00:08
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Actualizando : 32:bind-license-9.9.4-15.P2.fc20.noarch 1/10
Actualizando : 32:bind-libs-9.9.4-15.P2.fc20.x86_64 2/10
Instalando : 32:bind-9.9.4-15.P2.fc20.x86_64 3/10
Instalando : 32:bind-chroot-9.9.4-15.P2.fc20.x86_64 4/10
Actualizando : 32:bind-utils-9.9.4-15.P2.fc20.x86_64 5/10
Actualizando : 32:bind-libs-lite-9.9.4-15.P2.fc20.x86_64 6/10
Limpieza : 32:bind-utils-9.9.4-8.fc20.x86_64 7/10
Limpieza : 32:bind-libs-9.9.4-8.fc20.x86_64 8/10
Limpieza : 32:bind-libs-lite-9.9.4-8.fc20.x86_64 9/10
Limpieza : 32:bind-license-9.9.4-8.fc20.noarch 10/10
Comprobando : 32:bind-libs-9.9.4-15.P2.fc20.x86_64 1/10
Comprobando : 32:bind-libs-lite-9.9.4-15.P2.fc20.x86_64 2/10
Comprobando : 32:bind-license-9.9.4-15.P2.fc20.noarch 3/10
Comprobando : 32:bind-utils-9.9.4-15.P2.fc20.x86_64 4/10
Comprobando : 32:bind-chroot-9.9.4-15.P2.fc20.x86_64 5/10
Comprobando : 32:bind-9.9.4-15.P2.fc20.x86_64 6/10
Comprobando : 32:bind-utils-9.9.4-8.fc20.x86_64 7/10
Comprobando : 32:bind-libs-lite-9.9.4-8.fc20.x86_64 8/10
Comprobando : 32:bind-libs-9.9.4-8.fc20.x86_64 9/10
Comprobando : 32:bind-license-9.9.4-8.fc20.noarch 10/10
Instalado:
bind-chroot.x86_64 32:9.9.4-15.P2.fc20
Dependencia(s) instalada(s):
bind.x86_64 32:9.9.4-15.P2.fc20
Actualizado:
bind-utils.x86_64 32:9.9.4-15.P2.fc20
Dependencia(s) actualizada(s):
bind-libs.x86_64 32:9.9.4-15.P2.fc20
bind-libs-lite.x86_64 32:9.9.4-15.P2.fc20
bind-license.noarch 32:9.9.4-15.P2.fc20
¡Listo!
[root@localhost ~]#
Una vez instalado, se configura para que comience de forma automática al iniciar el servidor:
15
[root@localhost ~]# systemctl enable named-chroot.service
ln -s '/usr/lib/systemd/system/named-chroot.service'
'/etc/systemd/system/multi-user.target.wants/named-chroot.service'
Se puede iniciar el servicio y comprobar su estatus:
[root@localhost ~]# systemctl start named-chroot.service

[root@localhost ~]# systemctl status named-chroot.service
named-chroot.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled)
Active: active (running) since lun 2014-11-10 20:29:36 CET; 9s ago
Process: 2463 ExecStart=/usr/sbin/named -u named -t /var/named/chroot
$OPTIONS (code=exited, status=0/SUCCESS)
Process: 2462 ExecStartPre=/usr/sbin/named-checkconf -t
/var/named/chroot -z /etc/named.conf (code=exited, status=0/SUCCESS)
Main PID: 2465 (named)
CGroup: /system.slice/named-chroot.service
└─2465 /usr/sbin/named -u named -t /var/named/chroot
nov 10 20:29:37 localhost.localdomain named[2465]: error (network

unreachable...
unreachable...
unreachable...
unreachable...
unreachable...
unreachable...
unreachable...
unreachable...
unreachable...
unreachable...
Hint: Some lines were ellipsized, use -l to show in full.
La configuración de Named es distinta del resto de las configuraciones, el archivo está dividido en
secciones. Existe una sección global llamada “options”, en donde todas las configuraciones
aplicarán a todas las zonas, adicionalmente el archivo puede llevar tantas secciones de “zonas”
como se desee.
Las configuraciones dentro de una zona solo aplicarán a dicha zona y tendrán precedencia sobre
las configuraciones globales.
16
El archivo de configuración del servidor DNS se encuentra en /etc/named.conf y al igual que en
semanas anteriores revisaremos algunas de sus opciones de configuración:
[root@localhost ~]# more /etc/named.conf
Es posible que su servidor tenga dos o más tarjetas de red, cada una de ellas en algún bloque
distinto de su red, por ejemplo, una tarjeta podría dar a la red externa, la segunda podía estar
conectada a su DMZ mientras que la tercera podría dar a su red interna. En estos casos es
conveniente limitar a named a que solo permita conexiones en aquellas interfaces que sean
consideradas seguras:
# vi /etc/named.conf
listen-on port 53 { 127.0.0.1; };
Se puede restringir que rango de IP pueden hacer consultas al servidor DNS. En un servidor de
producción, por lo general solo se permite el rango de IP interna de la organización:
allow-query { localhost; };
Como se mencionó, en el caso de tener un servidor esclavo, este realiza una transferencia de zona
desde el servidor maestro, por lo tanto solo se debe permitir la transferencia desde esa IP. Nótese
que es posible agregar esta opción en la sección global o en su defecto, denegarla en forma global
y permitirla de forma local para cada zona:
allow-transfer { <ip servidor>; };
Si se está configurando un servidor autoritativo, se debe desactivar la recursión, en el caso que se

desee configurar un servidor recursivo, se debe habilitar esta opción y se recomienda agregar una
regla indicando las IP desde las cuales se puede recibir consultas recursivas, destacar que solo se
debe permitir desde las IPs de la organización:
recursion yes;
allow-recursion { 192.168.56.0/24; localhost; };
Para crear una nueva zona para el servidor DNS, se implementa una nueva sección al final del
archivo. Se debe crear una de estas entradas para cada una de las zonas que se desea. En este
17
ejemplo se creará una entrada para la zona a.com” que se utilizó en semanas anteriores. Recordar
que Named está siendo ejecutado con chroot, por lo que se creará cada archivo de zona en
/var/named/chroot/var/named/ para Named, estos se encuentran en /var/named.
zone “a.com" IN {
type master;
file "/var/named/a.com.zone";
};
Una vez que se ha declarado la zona se puede proceder a especificar sus detalles.
2.1. ARCHIVOS DE ZONA

Un archivo de zona típicamente puede tener esta forma
# vi /var/named/chroot/var/named/a.com.zone
a.com. IN SOA ns1.a.com. user1.a.com. (

2014100901 ; serial, todays date+todays
28800 ; refresh, seconds
7200 ; retry, seconds
360000 ; expire, seconds
86400 ) ; minimum, seconds
ns1.a.com. IN A 192.168.56.101
ns2.a.com. IN A <IP servidor Esclavo>
a.com. IN NS ns1.a.com.
a.com. IN A 192.168.56.101
mail.a.com. IN A 192.168.56.101
IN MX 10 mail.a.com.
www IN CNAME a.com.

imap IN CNAME mail.a.com.
smtp IN CNAME mail.a.com.
a.com. IN TXT "v=spf1 a mx ~all"

a.com. IN SPF "v=spf1 a mx ~all"
18
A continuación se detallan cada uno de los registros más comunes:
Registros SOA: Start Of Authority en inglés, es un registro obligatorio en los archivos de zona, en el
ejemplo anterior corresponde a:

2014100901 ; serial
28800 ; refresh, segundos
7200 ; retry, segundos
360000 ; expire, segundos
86400 ) ; minimum, segundos
Las secciones se detallan a continuación:
a.com.: esta es la raíz de la zona y especifica que se trata del dominio a.com. Muchas veces es
reemplazado por “@” que es una variable que refleja el dominio. Notar que los puntos finales en
el dominio“a.com.” son relevates para indicar el fin del dominio.
IN SOA: la porción “IN” la verá en muchos registros y significa “Internet”. La sección “SOA”
significa que este es un registro Start of Authority.
Ns1.a.com: define el servidor primario de nombres para este dominio, estos pueden ser maestros
o esclavos.
User1.a.com: define el email del administrador del dominio, el punto es reemplazado por “@”.
2014100901: este es número serial del archivo de zona, cada vez que se edite el archivo, se debe
incrementar este número para que los cambios se propaguen correctamente, los esclavos
verificarán este número contra el que ellos manejan, si el del maestro es mayor los esclavos
descargarán el nuevo archivo, si es menor, los esclavos continuarán sirviendo la información que
ya tienen. Una regla fácil de recordar es utilizar el serial con el formato aaaammddxx donde xx
corresponde a las veces que se ha editado el archivo el mismo día, de esta forma el serial siempre
se irá incrementando.
28800: la cantidad de segundos que ese esclavo esperará antes de consultar al maestro si tiene un
nuevo archivo.
7200: a cantidad de segundos que el esclavo esperará antes de consultar al maestro en caso que
no pueda contactarlo.
360000: si un esclavo no puede contactar al maestro en este intervalo de tiempo, dejará de dar
respuestas autoritativas al dominio.
19
86400: esta es la cantidad de tiempo que el servidor almacenará un error de nombres en caso de
no poder encontrar el nombre en el archivo.
Registros A y AAAA
Estos registros hacen la asociación entre un nombre y una dirección IP. El registro “A” se utiliza
para asociar una IPv4 mientras que el registro AAAA se utiliza para asociar IPv6.
El formato general de estos registros es:
host IN A IPv4_address
host IN AAAA IPv6_address
Como en el ejemplo se ha declarado que el servidor primario de nombres es ns1.a.com, se debe

asociar este nombre a una IP ya que ns1.a.com está al interior del dominio que se está definiendo.
ns1.a.com. IN A 192.168.56.101
Obsérvese, que en el caso del ejemplo se ha dado el FQDN del host (no se debe olvidar el punto
final), pero perfectamente se puede listar solo el nombre del host.
ns1 IN A 192.168.56.101
También es buena práctica definir dónde se debe resolver el dominio base.
Es posible utilizar “@” para reemplazar el nombre del dominio.
@ IN NS ns1.a.com.
Finalmente, se puede mapear todo lo que no esté asociado explícitamente a este dominio a algún
servidor mediante una línea del tipo:
* IN A <IP del servidor>
20
Registros CNAME: los registros CNAME simplemente definen un alias para alguno de los registros
previamente definidos mediante un registro A o AAAA.
www IN CNAME a.com.
Registros MX: los registros MX se utilizan para definir los servidores de email del dominio, a
diferencia de los registros normales los registros MX no mapean a ningún host pues aplican para
todo el dominio, por este motivo, tienen el siguiente formato:
Notar, además, que hay un número en el registro, este indica la prioridad del servidor de correos
en caso de existir más de uno (a menor número, mayor prioridad).
Registros NS: los registros NS definen cuales servidores de nombres se deben utilizar para el
dominio. Puede parecer redundante referenciar los servidores de nombres en el archivo de zona
del DNS, pero se debe recordar que el sistema de DNS tiene varios niveles de cache, por lo que se
deben especificar los servidores para que estos se repliquen por todos los servidores.
Tienen el siguiente formato:
Se recomienda tener dos servidores de DNS en caso que alguno presente problemas.
2.2. FINALIZACIÓN DEL EJEMPLO

Una vez aplicados los cambios a los archivos:
21
zone “a.com" {
type master;
file "/var/named/a.com.zone";
};
# vi /var/named/chroot/var/named/a.com.zone

2014100901 ; serial, todays date+todays
28800 ; refresh, seconds
7200 ; retry, seconds
360000 ; expire, seconds
86400 ) ; minimum, seconds
ns1.a.com. IN A 192.168.56.101
ns2.a.com. IN A <IP servidor Esclavo>
a.com. IN A 192.168.56.101
mail.a.com. IN A 192.168.56.101
www IN CNAME a.com.

imap IN CNAME mail.a.com.
smtp IN CNAME mail.a.com.
a.com. IN TXT "v=spf1 a mx ~all"

a.com. IN SPF "v=spf1 a mx ~all"
Es posible validar si la configuración de los archivos es correcta utilizando las herramientas que
incorpora named para verificar la integridad de los archivos.
[root@localhost named]# named-checkconf /etc/named.conf
[root@localhost named]# named-checkzone a.com

/var/named/chroot/var/named/a.com.zone
/var/named/chroot/var/named/a.com.zone:1: no TTL specified;

using SOA MINTTL instead
zone a.com/IN: loaded serial 2014100901
OK
En caso de que la herramienta arroje algún error, este se lo notificará y se debe, corregir.
22
[root@localhost ~]# named-checkconf /etc/named.conf
/etc/named.conf:44: missing ';' before 'logging'
[root@localhost ~]#
Al igual que en todos los servicios, una vez realizados los cambios, se debe reiniciar el servidor
para asegurar que tome los últimos cambios.
root@localhost named]# systemctl restart named-chroot.service
Finalmente, utilizando la herramienta dig, se puede verificar la respuesta que entrega sobre el
dominio a.com que fue recién configurado:
[root@localhost named]# dig @192.168.56.101 a.com; <<>> DiG 9.9.4-

P2-RedHat-9.9.4-15.P2.fc20 <<>> @192.168.56.101 a.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39663
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2,
ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;a.com. IN A
;; ANSWER SECTION:
a.com. 86400 IN A 192.168.56.101
;; AUTHORITY SECTION:
a.com. 86400 IN NS ns1.a.com.
a.com. 86400 IN NS ns2.a.com.
;; ADDITIONAL SECTION:
ns1.a.com. 86400 IN A 192.168.56.101
ns2.a.com. 86400 IN A 192.168.56.101
;; Query time: 2 msec

;; SERVER: 192.168.56.101#53(192.168.56.101)
;; WHEN: mar nov 11 00:55:25 CET 2014
;; MSG SIZE rcvd: 118
[root@localhost named]#
23
Ya es posible agregar al servidor DNS al resolvedor de la máquina virtual.
# vi /etc/resolv.conf
nameserver 192.168.56.101
Y eliminar del archivo hosts las entradas temporales ingresadas durante semanas anteriores.
# vi /etc/hosts
#127.0.0.1 a.com www.a.com
#127.0.0.1 b.com www.b.com
#127.0.0.1 c.com www.c.com
En estos momentos al abrir un navegador local en la máquina virtual y navegar hacia www.a.com
se debe visualizar la página sin problemas ya que el servidor DNS está entregando los registros de
forma correcta.
24
COMENTARIO FINAL
DNS es uno de los servicios más utilizados en Internet, en todo momento se realizan millones de
consultas al sistema DNS para poder resolver los distintos nombres a direcciones IP que manejan
los computadores.
La robustez de este sistema está en su arquitectura distribuida, su jerarquía y las posibilidades de

tener respaldos y servidores dedicados a distintos roles.
Se ha estudiado la forma de configurar un servidor DNS y las posibilidades que ofrece un servidor
DNS, el que opera como una gran máquina almacenadora de “nombres” que hace referencia a las
miles de direcciones IP disponibles en Internet, imposibles de retener en la memoria de cada
individuo.
25
REFERENCIAS
Liu, C. y Albitz, P. (2006). DNS and BIND. 5a edición. EE. UU.: O’Reilly.
PARA REFERENCIAR ESTE DOCUMENTO, CONSIDERE:
IACC (2014). DNS. Administración de Servicios. Semana 8.
26
27

Contenido Semana8 VF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Contenido Semana8 VF

Cargado por

Copyright:

Formatos disponibles

Administración de Servicios

Sistema de dominio de nombres: Domain Name System en inglés o simplemente DNS, es el

Nombre de dominio completamente calificado: Fully Qualified Domain Name en inglés o

1.1. ¿CÓMO FUNCIONAN LOS DNS?

Los servidores recursivos mantienen su propia caché de direcciones, si no la encuentra en lacaché,

1.2. JERARQUÍA DE SERVIDORES

Domain-level name servers: Estos servidores se encargan de responder consultas sobre su

1.3. ROLES DE SERVIDORES DNS

Servidores de redirección: Forwarding DNS Servers en inglés. Se utilizan principalmente para

1.4. PRIMARIO VS. ESCLAVO

Es posible que un servidor sea maestro de un dominio y esclavo de otro.

yum install bind-chroot

La salida del comando se detalla a continuación.

Tamaño total: 3.4 M

Se puede iniciar el servicio y comprobar su estatus:

[root@localhost ~]# systemctl start named-chroot.service

nov 10 20:29:37 localhost.localdomain named[2465]: error (network

[root@localhost ~]# more /etc/named.conf

Si se está configurando un servidor autoritativo, se debe desactivar la recursión, en el caso que se

2.1. ARCHIVOS DE ZONA

a.com. IN SOA ns1.a.com. user1.a.com. (

www IN CNAME a.com.

a.com. IN TXT "v=spf1 a mx ~all"

a.com. IN SOA ns1.a.com. user1.a.com. (

Las secciones se detallan a continuación:

El formato general de estos registros es:

Como en el ejemplo se ha declarado que el servidor primario de nombres es ns1.a.com, se debe

También es buena práctica definir dónde se debe resolver el dominio base.

Es posible utilizar “@” para reemplazar el nombre del dominio.

* IN A <IP del servidor>

Tienen el siguiente formato:

2.2. FINALIZACIÓN DEL EJEMPLO

a.com. IN SOA ns1.a.com. user1.a.com. (

www IN CNAME a.com.

a.com. IN TXT "v=spf1 a mx ~all"

[root@localhost named]# named-checkconf /etc/named.conf

[root@localhost named]# named-checkzone a.com

/var/named/chroot/var/named/a.com.zone:1: no TTL specified;

zone a.com/IN: loaded serial 2014100901

root@localhost named]# systemctl restart named-chroot.service

[root@localhost named]# dig @192.168.56.101 a.com; <<>> DiG 9.9.4-

;; Query time: 2 msec

La robustez de este sistema está en su arquitectura distribuida, su jerarquía y las posibilidades de

PARA REFERENCIAR ESTE DOCUMENTO, CONSIDERE:

IACC (2014). DNS. Administración de Servicios. Semana 8.

También podría gustarte