Curso de Sistema de Nombres de

Dominios, DNS
Ambiente GNU/Linux (20 horas)

Teoría, Guía de prácticas y ejercicios

Página 1 de 24
 Creative Commons
Reconocimiento-No comercial-Compartir bajo la
misma licencia 3.0
Usted es libre de:

• copiar, distribuir y reproducir públicamente la obra

• hacer obras derivadas

Bajo las siguientes condiciones: 

• Reconocimiento. Debe reconocer los créditos de la obra de la

manera especificada por el autor o el licenciante (pero no de una manera
que sugiera que tiene su apoyo o apoyan el uso que hace de su obra).

• No comercial. No puede utilizar esta obra para fines comerciales.

• Compartir bajo la misma licencia. 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
• Nada en esta licencia menoscaba o restringe los derechos morales del
autor.

Los derechos derivados de usos legítimos u otras limitaciones

reconocidas por ley no se ven afectados por lo anterior.
Esto es un resumen fácilmente legible del texto legal de versión original en
Idioma Inglés (la licencia completa)
http://creativecommons.org/licenses/by-nc-sa/3.0/ec/legalcode

Página 2 de 24
Índice de contenido
Objetivos del curso..................................................................................................4
Prerequisitos...........................................................................................................4
Teoría de los servidores DNS .................................................................................5
Funcionamiento y proceso de resolución de nombres............................................8
Clientes DNS...........................................................................................................8
Tipos de servidores DNS.......................................................................................10
Tipos de consultas.................................................................................................10
Zonas de autoridad................................................................................................11
¿Que es BIND?......................................................................................................12
Instalación de bind9..............................................................................................15
Archivos y directorios involucrados..................................................................16
Servidor cache...................................................................................................17
DNS maestro.........................................................................................................19
DNS esclavo..........................................................................................................22
Configuración de un subdominio...........................................................................23
Caso práctico de configuración de un servicio DNS.............................................24

Página 3 de 24
Objetivos del curso
El curso tiene como objetivo brindar a los participantes las destrezas,
conocimiento y la confianza para preparar un servicio de DNS en GNU/Linux en
una organización.

● Instalar BIND

● Configurar un cliente DNS.

● Configurar un servidor DNS en GNU/Linux

● Crear archivos de zonas primarias para resolución de nombres y resolución

reversa.

● Interrogar al DNS usando nslookup, dig o host.

● Configurar la seguridad de un DNS.

● Resolver problemas en DNS.

Prerequisitos

Conocimiento de protocolos de redes TCP/IP y conocimientos básicos de

servidores GNU/Linux.

Página 4 de 24
Teoría de los servidores DNS

El DNS ( Domain Name System) es un sistema de nombres que permite

traducir de nombre de dominio a dirección IP y vice-versa. Aunque Internet sólo
funciona en base a direcciones IP, el DNS permite que los humanos usemos
nombres de dominio que son bastante más simples de recordar.

El sistema de nombres de dominios en Internet es un sistema distribuido,

jerárquico, replicado y tolerante a fallas. Aunque parece muy difícil lograr todos
esos objetivos, la solución no es tan compleja en realidad. El punto central se
basa en un árbol que define la jerarquía entre los dominios y los sub-dominios.
En un nombre de dominio, la jerarquía se lee de derecha a izquierda. Por
ejemplo, en lab.dominio.com, el dominio más alto es com. Para que exista una
raíz del árbol, se puede ver como si existiera un punto al final del nombre:
lab.dominio,com., y todos los dominios están bajo esa raíz (también llamada
``punto"). Un termino que veremos comúnmente sera FQDN (Nombre de
dominio completo cualificado, lo que se refiere a un nombre como
www.misitio.com.

Cada componente del dominio (y también la raíz) tiene un servidor

primario y varios servidores secundarios. Todos estos servidores tienen la misma
autoridad para responder por ese dominio, pero el primario es el único con
derecho para hacer modificaciones en él. Por ello, el primario tiene la copia
maestra de los archivos y los secundarios copian la información desde él.

La raíz del sistema de dominios es servida por algunos servidores ''bien

conocidos o autorizados''. Todo servidor de nombres debe ser configurados con
la lista de los servidores raíz bien conocidos (en general lo vienen de fábrica).
Estos servidores dicen cuales dominios de primer nivel existen y cuales son sus
servidores de nombres. Recursivamente, los servidores de esos dominios dicen

Página 5 de 24
qué sub-dominios existen y cuales son sus servidores.

Existen 13 servidores raíz en toda Internet distribuidos en diferentes partes de la

red. Estos servidores reciben miles de consultas por segundo, y a pesar de esta
carga la resolución de nombres trabaja con bastante eficiencia.

Inicial Nombre viejo Empresa Lugar

A ns.internic.net VeriSign Dulles, Virginia, EEUU

B ns1.isi.edu USC­ISI Marina Del Rey, California, EEUU
C c.psi.net Cogent Communications distribuido (anycast)
D terp.umd.edu University of Maryland College Park, Maryland, EEUU
E ns.nasa.gov NASA Mountain View, California, EEUU
F ns.isc.org ISC distribuido (anycast)
G ns.nic.ddn.mil U.S. DoD NIC Columbus, Ohio, EEUU
H aos.arl.army.mil U.S. Army Research Lab Aberdeen Proving Ground, Maryland, EEUU

Página 6 de 24
 I nic.nordu.net Autonómica distribuido (anycast)
J VeriSign distribuido (anycast)
K RIPE NCC distribuido (anycast)
L ICANN Los Angeles, California, EEUU
M WIDE Project distribuido (anycast)

DNS permite la resolución en ambas direcciones. La conversión hacia

adelante convierte los nombres en direcciones IP, y la resolución inversa
convierte direcciones IP en nombres.

Existen muy pocos dominios a alto nivel, pero en cada nivel se despliegan
muchos mas. Siguiendo esta lógica, las direcciones IP deben tener también un
dominio a alto nivel. Este dominio se llama in-addr.arpa.

A diferencia del FQDN, las direcciones IP se resuelven de izquierda a

derecha una vez que están bajo el dominio in-addr.arpa. Cada octeto de una
dirección IP reduce mas los posibles nombres de maquinas. Devuelven nombres
FQDN (Fully Qualified Domain Name) para las búsquedas hechas para
direcciones IP. Los grandes ISP, y en algunos casos algunas empresas, son
quienes se hacen cargo de las Zonas de Resolución Inversa.
Veamos la siguiente imagen de ejemplo de una resolución inversa:

Página 7 de 24
Funcionamiento y proceso de resolución de nombres.

Cuando una aplicación (cliente) necesita resolver un FQDN envía un

requerimiento al servidor de nombres configurado en el sistema (normalmente,
el provisto por el ISP). A partir de entonces se desencadena el proceso de
resolución del nombre:

1. El servidor de nombres inicial consulta a uno de los servidores raíz (cuya

dirección IP debe conocer previamente).

2. Este devuelve el nombre del servidor a quien se le ha delegado la sub-zona.

3. El servidor inicial interroga al nuevo servidor.

4. El proceso se repite nuevamente a partir del punto 2 si es que se trata de

una sub-zona delegada.

5. Al obtener el nombre del servidor con autoridad sobre la zona en cuestión,

el servidor inicial lo interroga.

6. El servidor resuelve el nombre correspondiente, si este existe.

7. El servidor inicial informa al cliente el nombre resuelto.

Clientes DNS

Los Clientes DNS son programas que se ejecutan en la computadora del

usuario y que genera peticiones DNS de resolución de nombres a un servidor
DNS (Por ejemplo: ¿Qué dirección IP corresponde a nombre.dominio?).

La configuración de equipos cliente DNS suele implicar la ejecución de las

siguientes tareas administrativas:

Página 8 de 24
 • Configurar en el PC cliente los nombres para cada PC en la red.

• Configurar un sufijo DNS principal para el PC. El sufijo DNS principal del
equipo es el nombre del dominio el cual este es miembro.

• Identificar los servidores DNS para los clientes y así realizar la consulta de
resolución de nombres de forma rápida. Puede configurar los servidores
DNS preferidos y alternativos. Los servidores DNS alternativos o suplentes
se consultan cuando el preferido no contesta.

El orden en el cual se coloquen los servidores DNS es predominante para

la rapidez de las consultas. Supongamos que tenemos el siguiente orden en el
archivo de configuración:

nameserver 200.44.32.12
nameserver 150.187.110.2

El primero que el cliente consulta seria al servidor 200.44.32.12; si este no

contesta, automáticamente se realiza la consulta al siguiente que vendría siendo
el servidor 150.187.110.2. Puede configurar tantos servidores DNS como
prefiera.

Página 9 de 24
Tipos de servidores DNS.

Primarios (Autorizados): Son los que se consideran autorizados para un

dominio en particular, es en el cual residen los archivos de configuración del
dominio. Cuando se produzca una actualización de las tablas de dominio DNS se
harán en este servidor

Secundarios (No autorizados completamente): Trabajan como respaldo y

como distribuidores de carga de los servidores primarios, estos solo mantienen
copias de la información ayudando a disminuir el trabajo de los servidores
primarios.

Cache (No autorizados): No contienen archivos de configuración de ningún

dominio. Cuando una maquina cliente realiza una petición a un servidor cache
para que resuelva un nombre, este servidor comprueba su cache local. Si no la
encuentra, la buscara en un servidor primario y le preguntara, luego la respuesta
del primario pasa a cache. Todos los DNS actúan como cache de otros dominios
sin importar si son primarios o secundarios.

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

Página 10 de 24
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 archivo en el Servidor DNS. Este archivo 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 Registro de nombre canónico que hace que un nombre sea
(Canonical alias de otro. Los dominios con alias obtiene los sub-
Name) dominios y registros DNS del dominio original.
MX (Mail Registro de servidor de correo que sirve para definir una
Exchanger) 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 Registro de servidor de nombres que sirve para definir una
Server) lista de servidores de nombres con autoridad para un
dominio.
SOA (Start of Registro de inicio de autoridad que especifica el Servidor
Authority) DNS Maestro (o Primario) que proporcionará la información

Página 11 de 24
 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.

¿Que es BIND?

BIND (Berkeley Internet Name Domain, anteriormente: Berkeley Internet

Name Daemon) es el servidor de DNS más comúnmente usado en Internet,
especialmente en sistemas Unix, en los cuales es un standard de facto. Es
patrocinado por la Internet Systems Consortium. BIND fue creado originalmente
por cuatro estudiantes de grado en la University of California, Berkeley y
liberado por primera vez en el 4.3BSD. Paul Vixie comenzó a mantenerlo en 1988
mientras trabajaba para la DEC.

Una nueva versión de BIND (BIND 9) fue escrita desde cero en parte para
superar las dificultades arquitectónicas presentes anteriormente para auditar el
código en las primeras versiones de BIND, y también para incorporar DNSSEC
(DNS Security Extensions). BIND 9 incluye entre otras características

Página 12 de 24
importantes: TSIG, notificación DNS, nsupdate, IPv6, rndc flush, vistas,
procesamiento en paralelo, y una arquitectura mejorada en cuanto a
portabilidad. Es comúnmente usado en sistemas Linux.

BIND trabaja en la capa de aplicación. Si el segmento a enviar es menor

que 512 Bytes utiliza el protocolo UDP, de lo contrario utiliza el protocolo TCP. El
número de puerto que utiliza el protocolo DNS para comunicarse con la capa de
aplicación es el número 53.
Todos los mensajes generados por el protocolo DNS utilizan un único formato de
cabecera:

0123456789012345

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| ID |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

|QR| Opcode |AA|TC|RD|RA| Z | RCODE |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| QDCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| ANCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| NSCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| ARCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Cabecera del protocolo DNS

Página 13 de 24
• ID: Es un identificador de 16 bits asignado por el programa. Este
identificador se copia en la respuesta correspondiente del servidor de
nombres y se puede usar para diferenciar respuestas cuando concurren
múltiples consultas.

• QR: Flag que indica consulta(0) o respuesta(1).

• Op code: Campo de 4-bit que especifica el tipo de consulta:

0 consulta estándar(QUERY).

1 consulta inversa(IQUERY).

2 solicitud del estado del servidor(STATUS).

• Se reservan los otros valores para su uso en el futuro.

• AA: Flag de respuesta autoritativa. Si está activo es una respuesta,

especifica que el servidor de nombres que responde tiene autoridad para el
nombre de dominio enviado en la consulta.

• TC: Flag de truncado. Activo si el mensaje es más largo de lo que permite

la línea de transmisión.

• RD: Flag de recursividad. Este bit se copia en la respuesta e indica al

servidor de nombres una resolución recursiva.

• RA: Flag de recursividad disponible. Indica si el servidor de nombres

soporta resolución recursiva.

• Z: 3 bits reservados para uso futuro. Deben ser cero.

• Rcode: Código de respuesta de 4 bits. Los posibles valores son:

0. Ningún error.

1. Error de formato. El servidor fue incapaz de interpretar el

mensaje.

Página 14 de 24
 2. Fallo en el servidor. El mensaje no fue procesado debido a un
problema con el servidor.

3. Error en nombre. El nombre de dominio de la consulta no existe.

Sólo válido si el bit AA está activo en la respuesta.

4. No implementado. El tipo solicitado de consulta no está

implementado en el servidor de nombres.

5. Rechazado. El servidor rechaza responder por razones políticas.

Los demás valores se reservan para su usuario en el futuro.

• Qdcount: Un entero sin signo de 16 bits que especifica el número de

entradas en la sección "question".

• Ancount: Un entero sin signo de 16 bits que especifica el número de RRs

en la sección "answer".

• NScount. Un entero sin signo de 16 bits que especifica el número de RRs

en la sección "authority".

• ARcount. Un entero sin signo de 16 bits que especifica el número de RRs

en la sección "additional records".

Instalación de bind9.

La instalación de un servidor DNS es sencilla es esta a cargo del paquete

bind en su version9. Colocamos en consola:
#apt-get install bind9 dnsutils
Luego de desempaquetar y configurar la aplicación, nos dirigimos al
directorio para visualizar los archivos de configuración involucrados:

# cd /etc/bind
# ls
db.0 db.255 db.local named.conf named.conf.options zones.rfc1918 db.127

Página 15 de 24
db.empty db.root named.conf.local rndc.key

Archivos y directorios involucrados.

• Directorios.

/etc/bind: Archivos de configuración, archivos de números IP y nombres de

máquinas de la zona local atendida por esta máquina.

/var/cache/bind: Directorio de trabajo donde bind guarda la información sobre

números IP y nombres de máquinas que va recogiendo en sus actividades de
búsqueda consultando otras máquinas DNS de la red.

• Archivos existentes.

db.local: Datos de resolución directa para interfaz local "loopback".

db.127: Datos de resolución inversa para interfaz local "loopback".

db.0: Inverso para zona de difusión, según lo requerido por las normas.

db.255: Inverso para zona de difusión, según lo requerido por las normas.

db.root: Información de servidores de nombres raíz de Internet, autoridades

máximas en servicio de nombres; estos servidores son la referencia esencial para
iniciar la actividad del servidor DNS local en búsqueda de nombres por Internet.
El DNS local puede preguntar a estos servidores las direcciones desconocidas, o
a otros servidores DNS más cercanos si se le indican. Ver documento “dnsraiz”.

Página 16 de 24
named.conf: Archivo de configuración para el servidor DNS local. Aquí figuran
todos los nombres de archivos locales consultados, direcciones de servidores
DNS próximos y ajustes de operación para el DNS.

named.conf.options: Opciones genéricas.

named.conf.local: Especificación particular de este servidor DNS.

rndc.key: Para generar una llave y comunicarse con el servidor de nombres en

comunicaciones TCP autenticadas.

zones.rfc1918: Direcciones IP invalidas especificadas en el RFC1918 para

diseñar redes privadas o intranets y recomendadas cuando se experimenta con
redes. Estas son: 10. - 172.16 – 172.31 y 192.168

db.empty: Archivo vacío de ejemplo.

Servidor cache.

Por defecto al instalar bind, actuara como un servidor cache. Recordemos

que la función de un servidor cache es consultar a otros servidores DNS y las
respuestas de esas consultas realizadas por los clientes, son almacenadas en el
cache del servidor local. Veremos a continuación los pasos para configurar los
clientes y el servidor para realizar las pruebas del funcionamiento del servidor
DNS cache.

Primero vamos a configurar los clientes. Editaremos el archivo resolv.conf

de la siguiente forma:

Página 17 de 24
#nano /etc/resolv.conf
search pruebadns.org cantv.net
nameserver (DNS LOCAL)
nameserver (Direccion IP DNS1)
nameserver (Direccion IP DNS2)

En el servidor editaremos el archivo named.conf.options y localizaremos la

linea que tiene comentados los forwarders. Aquí asignaremos los DNS externos
los cuales podrán consultar:
forwarders {
200.44.32.12;
};

Nota: En este caso se coloco en forwarders la dirección IP del servidor

DNS de CANTV, lógicamente esto puede variar segun su ISP.
Luego de haber editado los archivos correspondientes en el cliente y en el
servidor, reiniciaremos los servicios

En el cliente: /etc/init.d/networking restart

En el servidor: /etc/init.d/bind9 restart

Para realizar las pruebas de funcionamiento utilizaremos el comando “dig”:

# dig www.yahoo.com
Buscaremos una linea casi al final de la respuesta de la consulta realizada:

;; Query time: 97 msec

;; SERVER: 190.75.126.72#53(190.75.126.72)
;; WHEN: Sat May 19 17:06:08 2007
;; MSG SIZE rcvd: 403

Página 18 de 24
 Vemos que la consulta ha tardado 97 milisegundos. Ahora, si realizamos la
consulta nuevamente tendremos un cambio:

;; Query time: 9 msec

;; SERVER: 190.75.126.72#53(190.75.126.72)
;; WHEN: Sat May 19 17:09:26 2007
;; MSG SIZE rcvd: 403

La consulta ahora ha tardado tan solo 9 milisegundos. ¿Porque? La

respuesta es sencilla. Anteriormente hemos consultado www.yahoo.com, y al
realizar la segunda vez esta consulta, no se realizo a DNS externos sino a
nuestro servidor DNS local, el cual tenia almacenado en cache esta información,
optimizando las consultas a nombres de maquinas externas a nuestra red local.

Probar accediendo a páginas web más de una vez. Comparar los tiempos.

Nota: No olvidemos revisar constantemente los registros syslog y

daemon.log en el directorio “/var/log/”, si queremos obtener mayor información
de lo que ocurre en nuestro servidor.

DNS maestro.

Ahora vamos a configurar un dominio simple. Para ello solo debemos crear
dos archivos nuevos. Una zona directa y una zona inversa para la resolución de
nombres a IP y viceversa. Antes agregaremos información sobre nuestro dominio
al archivo named.conf:

# cd /etc/bind
#ls
db.0 db.255 db.local named.conf.local zones.rfc1918

Página 19 de 24
db.0.0.10 db.dominio db.root named.conf.options
db.127 db.empty named.conf rndc.key

#nano named.conf
Al final del archivo agregaremos los siguiente:

#Resolución Directa.
zone "dominio.com" {
type master;
notify no;
file "/etc/bind/db.dominio";
};

// Resolución Inversa.
zone "168.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.168.168.192";
};

Ahora debemos crear los archivos para la resolución directa e inversa, para
ello utilizaremos el archivo db.empty:

# cd /etc/bind
# cat db.empty > db.dominio

En el cual agregaremos los siguientes parámetros:

$TTL 86400
@ IN SOA dominio.com. root.dominio.com. (
1 ; Serial

Página 20 de 24
 604800 ; Refresco
86400 ; Reintento
2419200 ; Expira
86400 ) ; Negative Cache TTL
;
@ IN NS server.dominio.com.
IN MX 10 mail.dominio.com

debian IN A 192.168.168.112 ;Cliente

web IN A 192.168.168.34 ;Servidor web
www IN CNAME web
dns IN A 192.168.168.2 ;Servidor DNS
mail IN A 192.168.168.44 ;Servidor Correo
gw IN A 192.168.168.1
TXT “Enrutador red local”

Para el archivo de resolución inversa utilizaremos de nuevo el archivo

db.empty:

# cd /etc/bind
# cat db.empty > db.168.168.192

En el cual agregaremos los siguientes parámetros:

$TTL 86400
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresco
86400 ; Reintento
2419200 ; Expira
86400 ) ; Negative Cache TTL
;
@ IN NS server.dominio.com.

Página 21 de 24
112 IN PTR debian.dominio.com.
2 IN PTR dns.dominio.com.
34 IN PTR www.dominio.com.
44 IN PTR mail.dominio.com

Para realizar las pruebas de funcionamiento, chequearemos los registros:

# named
# tail -f /var/log/syslog

También podemos probar haciendo ping a las maquinas pero utilizando

nombres, lo cual nos mostrara la ip de la maquina:

$ping maquina1

Además las herramientas dig y host:

#dig -x (ip-del-servidor)
#host (nombre-maquina)

DNS esclavo.

Ya con las configuraciones correctas en nuestras zonas, en el servidor

primario, necesitamos al menos un servidor esclavo en la red local. Se debería
agregar en el servidor esclavo lo siguiente:

En el archivo named.conf (del Servidor esclavo)

zone “dominio.com” {

Página 22 de 24
 type slave;
file “/etc/bind/db.dominio;
masters { 192.168.168.2; };
};

En el archivo db.dominio (del servidor esclavo)

$TTL 86400
@ IN SOA ns.dominio.com. root.dominio.com. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL

Configuración de un subdominio.

Supongamos queremos agregar un subdominio y queremos que la

resolución la realice un determinado servidor

En el archivo named.conf

zone “redes.dominio.com” {
type slave;
file “/etc/bind/db.redes;
masters { 192.168.168.56; };
};

En el archivo db.dominio

$TTL 86400

Página 23 de 24
@ IN SOA ns.dominio.com. root.dominio.com. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL

Caso práctico de configuración de un servicio DNS.

Para desarrollar en el curso: Ejecutar todo los pasos para configurar y verificar,
con las herramientas de búsqueda y consulta, el servicio de DNS en un ambiente
como se describe a continuación:

Nótese que para configurar, iniciar y verificar este servicio de DNS no se

pueden utilizar valores hipotéticos.

Servidor: valiente01

dominio: telecomvcg.net

Servidor de nombre principal (SOA) FQDN:

Correo administrador:

Servidor de correo (MX), con registro A, nunca CNAME:

ISP: Cantv.net

Servidor DNS 1: 200.44.32.12

Servidor DNS 2: 200.11.248.12

Red privada: 192.168.1.0/24

Página 24 de 24