Sri - Tema 3 DNS Rev 1.4

Tema 3.
Servicio de nombres de dominio (DNS)
Tema 3. Servicio de Nombres de Dominio. DNS

1. Caractersticas.......................................................................................3
2. Componentes.........................................................................................3
3. Espacio de nombres de dominio............................................................4
3.1. Nombres de dominio relativos y absolutos........................................................4
3.2. Administracin de nombres de dominio............................................................4
3.3. Delegacin de dominios.....................................................................................5
3.4. Registros de dominio.........................................................................................5
4. Servidores de nombres..........................................................................6
4.1. Tipos de servidores de nombres.........................................................................7
5. Clientes DNS (resolvedores).................................................................8

6. Mecanismo de resolucin......................................................................9
6.1. Respuestas en cach.........................................................................................10
7. Correspondencias inversas..................................................................10
8. Registros de recursos...........................................................................11
8.1. Tipos de registros.............................................................................................12
8.2. Registros pegamento (Glue Record)................................................................13
9. Transferencias de zona........................................................................13
10. DNS dinmico (DDNS, Dynamic DNS)...........................................14
11. Seguridad DNS..................................................................................15
12. Servidores DNS en Linux.................................................................15
13. Servidores DNS en Windows............................................................21
14. Configuracin de clientes..................................................................22
14.1. Clientes Linux................................................................................................22
14.2. Clientes Windows..........................................................................................23
15. Herramientas de consulta..................................................................23
IES Zaidn Vergeles de Granada. Departamento de Informtica.
Tema 3. Servicio de nombres de dominio (DNS)
Tema 3. Servicio de nombres de dominio. DNS.

El servicio de resolucin de nombres usado en las redes TCP/IP es el servicio DNS Domain Name
System o Sistema de Nombres de Dominio. Este servicio permite identificar de una forma ms sencilla a
un equipo mediante un nombre, en lugar de usar la identificacin numrica de la direccin IP.
1. Caractersticas.
En las redes TCP/IP, como es Internet, no es fcil recordar las direcciones IP de los equipos, ya que a
las personas nos es ms cmodo usar y recordar nombres que secuencias de nmeros.
Para facilitar el uso de los servicios, recursos y equipos de una red se cre un sistema de nombres que
mediante un servicio de resolucin de nombres permite asociar nombres con direcciones numricas. De
forma simplificada podemos decir que un servicio de nombres almacena direcciones y sus nombres
correspondientes.
La operacin que hay que realizar para conocer la direccin IP de un equipo a travs de su nombre se
denomina resolucin de nombre.
Los sistemas de nombres se clasifican en planos y jerrquicos. En los sistemas de nombre planos, los
nombres se usan sin ninguna estructura u organizacin que permita clasificarlos de alguna manera. Por
ejemplo, los nmeros de matrcula de los alumnos de un centro y su correspondencia con los nombres de
dichos alumnos. (Los nombres NetBIOS que usa Windows son un espacio de nombres plano). El mayor
inconveniente es que los nombres deben ser nicos, sin repeticin.
Los sistemas de nombres jerrquicos usan nombres que se agrupan o clasifican bajo algn criterio.
Esta cualidad permite una gestin ms simple, que los nombres se puedan repetir y con la posibilidad de
de realizar una gestin de forma distribuida. Ejemplo de ello son los nombres en un sistema de archivos y
tambin como veremos, el servicio de resolucin de nombres DNS.
El servicio DNS es un servicio de registro y consulta de informacin, la cual se almacena en una base
de datos distribuida en numerosos equipos. Estos equipos que almacenan una parte de dicha informacin
de denominan servidores de nombres.
La informacin a la hora de distribuirla entre los diversos servidores de nombres se organiza mediante
un esquema de nombres jerrquico. Este esquema jerrquico es lo que se denomina espacio de nombres
de dominio. As cada servidor de nombre gestiona slo una parte del espacio de nombres de dominio.
Dicha parte se denomina dominio y es un subrbol del espacio de nombres de dominio.
Los clientes DNS se dedican a preguntar a los servidores de nombres, los cuales responden usando
para la comunicacin entre ellos el protocolo DNS.
El servicio DNS no slo permite asociar un nombre de dominio con una direccin IP, adems se
permite almacenar otras informaciones, como por ejemplo qu equipos ofrecen un determinado servicio,
o qu equipos son fuentes de malware o de spam.
2. Componentes.
El servicio DNS se basa en el modelo cliente-servidor y est formado por los componentes siguientes:
Espacio de nombres de dominio. Lo forma la totalidad del conjunto de nombres que permite
identificar equipos o servicios de red, estructurados de forma jerrquica.
Base de datos DNS. Es una base de datos distribuida que contiene la informacin del espacio de
nombres del dominio. La base de datos se organiza en zonas, en las cuales los datos se registran
mediante los llamados registros de recursos (RR).
Servidores de nombres. Tambin llamados servidores DNS. Guardan parte de la base de datos
DNS en las llamadas zonas y son capaces de responder a las preguntas relativas a la informacin
que almacena en sus zonas. Normalmente un servidor de nombres guarda informacin de una sola
zona; la informacin correspondiente a esa parte del espacio de nombres o dominio, pero tambin
puede registrar la informacin de varios dominios que el servidor almacenar en varias zonas.
Clientes DNS o resolvedores. Son los encargados de realizar las preguntas a los servidores de
nombres y ofrecer las respuestas a los clientes o aplicaciones que las solicitan.

Protocolo DNS. Conjunto de reglas y normas que usan los servidores y clientes DNS para dialogar.
3. Espacio de nombres de dominio.

Como hemos comentado, el espacio de nombres de dominio lo forma el conjunto de nombres que
permite identificar equipos o servicios de red, estructurados de forma jerrquica.
Estos nombres se denominan nombres de dominio y estn formados por una serie de caracteres
separados por puntos. Por ejemplo: google.es., info., servidor.aula.izv.
El espacio de nombres de dominio se puede representar mediante una estructura jerrquica
arborescente, donde cada nodo del rbol se separa de otro mediante un punto.
Los nombres de dominio no pueden superar los
255 caracteres distribuidos en como mximo 127
niveles, los cuales pueden contener como mximo
63 caracteres.
Los nombres de dominio siempre terminan con
un punto, ya que el rbol de nombres de dominio
empieza en el dominio . o dominio raz. Los
dominios que cuelgan del dominio raz se
denominan dominios de primer nivel o dominios de
nivel superior (TLD, Top Level Domains). Los que
cuelgan de los dominios de primer nivel se
denominan
dominios
de
segundo
nivel.
Normalmente a los dominios de tercer nivel e
inferiores se les suelen denominar subdominios,
aunque slo es cuestin de nomenclatura.
3.1. Nombres de dominio relativos y absolutos.

Cuando se hace referencia a un dominio, podemos usar su nombre relativo o absoluto.
Si usamos nombres relativos debemos conocer cual es el dominio superior para saber a qu nombre
nos estamos refiriendo exactamente. Si uso como nombre puesto7 a no ser que el dominio de contexto sea
por ejemplo aula.izv. no sabr exactamente a qu equipo estoy haciendo referencia.
Los nombres absolutos estn formados por todos los nombres de nodos separados por puntos desde el
nodo correspondiente hasta el nodo raz inclusive. Por ejemplo: puesto7.aula.izv.
Los nombres absolutos se denominan nombres de dominio perfectamente cualificados (FQDN, Fully
Qualified Domain Names).
Los nombres de dominio no slo sirven para hacer referencia a un equipo en el espacio de nombres de
dominio. Tambin sirven para hacer referencia a un subrbol del espacio de nombres del dominio, es
decir para hacer referencia a un nodo, y a todos los nodos que cuelgan de ste.
Por ejemplo, el dominio es. hace referencia a todos los nodos (subdominios y equipos) que cuelgan
del dominio de primer nivel es. El dominio aula.izv. hace referencia a todos los nodos que cuelgan del
domino de segundo nivel aula.izv.
Por lo tanto un dominio permite hacer referencia a un conjunto de equipos y subdominios que se
agrupan segn un criterio. Uno de los criterios ms usados, y que suele causar confusin, es el de los
equipos que pertenecen a una misma red. Por ejemplo, en nuestro caso el dominio aula.izv. agrupa a
todos los equipos del aula, los cuales estn en la misma red (192.168.210.0/24), pero esto no quiere decir
que todos los equipos que pertenezcan a una misma red deben pertenecer al mismo dominio. De hecho se
pueden usar otros criterios de agrupacin: equipos de una misma empresa (aunque los equipos estn en
redes distintas), equipos que prestan servicios, equipos que estn en una misma ubicacin fsica, etc.
3.2. Administracin de nombres de dominio.

En Internet, la administracin y la organizacin del espacio de nombres de dominio se realiza a travs
de diversas empresas y organizaciones coordinadas por la ICANN (Internet Corporation for Assigned
Names and Numbers http://www.icann.org/).
El ICANN tiene la misin de que Internet sea funcional y entre otras cosas, de administrar el dominio
raz y de mantener un registro de los dominios de nivel superior (TLD).
Por otra parte, InterNIC, (http://www.internic.net/) organizacin asociada al ICANN, es la encargada
de registrar los dominios de primer nivel (TLD).
Los dominios de primer nivel (TLD) se clasifican por parte de la ICANN en:
Genricos. Usan un nombre relacionado con el propsito o el tipo de organizacin que lo va a

utilizar. stos a su vez se clasifican en:
o
Patrocinados. Existe una organizacin que lo patrocina. Ejemplos: info, asia, edu, etc.
No patrocinados. Operan con unas reglas comunes establecidas por el ICANN. Por
ejemplo:com, net, org, etc.
Geogrficos. Usan dos letras en funcin del pas. La gestin de estos dominios es delegada por el
ICANN a organizaciones propias de cada uno de los pases denominadas operadoras de registro.
Ejemplo de dominios geogrficos son: es, uk, fr. En Espaa, Red.es (http://www.red.es) es
la organizacin delegada por el ICANN para la gestin del dominio es, y del registro de
dominios de segundo nivel dentro de es.
arpa. El dominio arpa lo gestiona directamente la ICANN y sirve a travs de los subdominios
in-addr.arpa y ip6.arpa para poder efectuar la resolucin inversa de direcciones.
Reservados. Son dominios de primer nivel reservados slo para pruebas y documentacin. Por
ejemplo: test, example y localhost.
3.3. Delegacin de dominios.

Comentamos que el servicio DNS se basa en la administracin distribuida de la informacin del
espacio de nombres de dominio entre mltiples servidores de nombres. Esto se consigue mediante la
delegacin.
La delegacin permite que una organizacin que administra un dominio, ceda la administracin de sus
subdomnios (de uno, de varios, o de todos) a otras organizaciones. La ICANN, administradora del
dominio raz, delega en otras organizaciones los dominios de primer nivel. En Espaa Red.es administra
el dominio de primer nivel es, el cual delega a otras organizaciones los dominios de segundo nivel.
Por ejemplo, el dominio ugr.es. es delegado por Red.es a la Universidad de Granada, la cual puede a
su vez delegar o no sus subdominios a otras organizaciones. As el subdominio etsiit.ugr.es. es
delegado por la Universidad de Granada a la ETS de Informtica y Telecomunicaciones.
El hecho de que un dominio se divida en subdominios no implica que tenga que ser delegado. Por
ejemplo la UGR puede crear el subdominio derecho.ugr.es. pero no delegar su administracin.
3.4. Registros de dominio.

El registro de un dominio consiste en reservarle un nombre durante un tiempo, para poder crear
subdominios y asociar al dominio y a sus subdominios direcciones IP.
El registro de nombres de segundo nivel lo realizan empresas u organizaciones acreditadas
denominadas agentes registradores las cuales asesoran a los clientes que quieren registrar un dominio.
Adems tramitan las solicitudes operando como intermediarios entre los clientes y las operadoras de
registro de primer nivel.
En Espaa, Red.es es la operadora de registro de primer nivel para el dominio es, y aunque puede
registrar directamente dominios de segundo nivel a los clientes, stos utilizan normalmente los servicios
de los agentes registradores debido a que suelen ofrecer otros servicios complementarios (alojamiento
web, servidores de correo, etc,) y a precios ms competitivos.
En los sitios web pertenecientes a ICANN e InterNIC podemos obtener la lista de empresas
registradoras acreditadas que ofrecen servicios de registro de dominios genricos; y en Red.es las
acreditadas para el dominio es.
4. Servidores de nombres.
Los servidores de nombres o servidores DNS almacenan una parte de la base de datos DNS guardando
informacin sobre nombres de dominio y respondiendo a los clientes DNS u otros servidores DNS. Los
servidores escuchan las peticiones por defecto en los puertos 53/TCP y 53/UDP.
La parte de informacin del espacio de nombres de dominio que mantienen los servidores de nombres
se denomina zona. Cuando un servidor de nombres contiene informacin de una zona se dice que es
autorizado para esa zona. La informacin de una zona se almacena en archivos de texto o en bases de
datos, dependiendo del tipo de servidor.
Los ficheros de zona almacenan bsicamente sus datos mediante registros de recursos. Dependiendo
del tipo de informacin que se asocie con un nombre de dominio se utiliza un tipo de registro de recurso.
Por ejemplo un servidor DNS para los equipos del aula almacenara la informacin de la zona
aula.izv y en el se definiran los nombres que cuelgan de aula.izv como por ejemplo
puesto1.aula.izv, puesto2.aula.izv, etc.
Aunque posteriormente lo examinaremos con ms detalle, el servidor BIND (Berkeley Internet Name
Domain), el servidor DNS ms comnmente usado en Internet y estndar de facto, registra los datos en
formato texto. Los registros de recursos ms usuales son:
NS. Indica los servidores de nombres de dominio DNS que tienen autoridad para una zona.
A. Asocia un nombre de dominio su direccin IP.
CNAME. Asigna otro nombre o alias a un nombre de dominio.
Por ejemplo, un archivo de zona de resolucin directa con delegacin para el dominio aula.izv, podra
ser:
...
aula.izv.
IN
NS
puesto1.aula.izv.
puesto1.aula.izv.
IN
192.168.210.1
puesto2.aula.izv.
IN
192.168.210.2
puesto3.aula.izv.
IN
192.168.210.3
www.aula.izv
IN
CNAME
puesto2.aula.izv.
;subdominio sri.aula.izv. delegado

sri.aula.izv.
IN
puesto10.sri.aula.izv. IN
;subdominio bd.aula.izv.
NS
puesto10.sri.aula.izv.
192.168.210.10
no delegado
puesto15.bd.aula.izv. IN
192.168.210.15
192.168.219.16
192.168.219.17
...
El archivo de zona del dominio aula.izv. indica que se almacena en un servidor DNS que est en el
equipo con direccin IP 192.168.210.1 y cuyo nombre es puesto1.aula.izv. A continuacin los registros
tipo A asocian un nombre de dominio con una direccin IP, y con CNAME indicamos otro nombre de
dominio (un alias) para puesto2.aula.izv.
Tambin podemos comprobar cmo se ha delegado el subdominio sri.aula.izv. en otro servidor DNS
con direccin IP 192.168.210.10 y cuyo nombre es puesto10.sri.aula.izv. Este servidor ser autorizado
para el dominio sri.aula.izv. y almacenar el archivo de zona del dominio.
El archivo de zona del dominio delegado sri.aula.izv. podra ser:
...
sri.aula.izv.
NS
IN
192.168.210.10
192.168.210.11
192.168.210.12
...
Por otro lado, el subdominio bd.aula.izv. no se ha delegado.
Es comn el error de considerar los trminos zona y dominio como sinnimos. Un dominio es un
subrbol del espacio de nombres del dominio. Los datos asociados a los nombres de un dominio puede
estar almacenados en una o varias zonas, las cuales pueden estar distribuidas en uno o varios servidores
DNS.
En nuestro ejemplo anterior podemos comprobar como los nombres de dominio aula.izv. se distribuye
en dos archivos de zona, el fichero de la zona aula.izv y el fichero de la zona sri.aula.izv.
Adems, un servidor de nombres puede tener autoridad sobre varias zonas. Por ejemplo, un mismo
servidor puede ser autorizado para las zonas aula.izv y aula209.izv.
4.1. Tipos de servidores de nombres.

Un servidor autorizado para una zona puede dejar de funcionar, o bien estar colapsado por la carga de
trabajo. Para evitar estos problemas y mejorar el servicio de resolucin de nombres, DNS permite
almacenar una misma zona en varios servidores DNS. Podemos imaginarnos que el servicio de bsquedas
de Google no ira tan rpido si hubiera un nico servidor autorizado para google.com.
Veremos que estas situaciones se resuelven mediante zonas maestras y zonas esclavas.
Segn la funcin que realizan los servidores de nombres se pueden clasificar en:
Servidor maestro (master). Define una o varias zonas para las que es autorizado. El administrador es
el responsable de los archivos de zona, aadiendo, modificando o borrando nombres de dominio.
Si un cliente DNS le pregunta por un nombre de dominio para el que est autorizado, consultar en
los archivos de su zona y le responder. Si no est autorizado, buscar la informacin en otros
servidores DNS o responder que no sabe la respuesta.
Servidor esclavo (slave). Define una o varias zonas para las que es autorizado, pero obtiene los
archivos de zona de otro servidor autorizado para la zona (maestro o esclavo), realizando lo que se
denomina transferencia de zona. Los archivos de zona del servidor esclavo no se pueden editar, por
lo que las modificaciones deben realizarse en el servidor que realiza la transferencia.
Un servidor DNS puede ser maestro para una o varias zonas y a la vez esclavo de otras. Adems
pueden existir varios servidores esclavos para una misma zona.
Con los servidores esclavos se puede repartir la carga de trabajo entre varios servidores y disminuir
los fallos que se puedan producir en el servicio.
Servidor cach. Si un servidor DNS recibe una pregunta sobre un nombre de dominio para la que no
est autorizado, podr preguntar, si est configurado as, a otros servidores DNS. Si el servidor acta
como cach, las respuestas obtenidas de los otros servidores las podr almacenar durante un tiempo
(TTL, Time To Live). De esta forma, cuando un cliente u otro servidor DNS le formule una pregunta,
consultar primero en su memoria cach, por si ya tuviera la respuesta.
Los servidores llamados solo cach, son los que no tienen autoridad sobre ningn dominio y realizan
preguntas a otros servidores para resolver las peticiones, guardando las respuestas en su memoria
cach. En redes extensas y con muchos equipos es adecuado tener un servidor DNS que acte de esta
forma ya que se logra disminuir significativamente el trfico en la red.
Servidor reenviador (forwarding). Cuando un servidor DNS no tiene respuesta a una peticin de
resolucin, puede realizar la pregunta a otros servidores en un orden que luego explicaremos o bien
puede trasladar directamente la pregunta a otros servidores DNS (forwarders), para que sean estos
los que se encarguen de resolverla.
Por lo tanto, un servidor configurado como reenviador traslada las preguntas que no puede resolver a
otros servidores DNS a los que se les trasladan dichas consultas. Con esto se consigue disminuir el
trfico de peticiones DNS generado por los equipos de una red a Internet (se encargan de resolver los
forwarders) y se comparte la cach de los servidores DNS a los que se le reenvan las consultas.
Lgicamente las consultas que se reenvan son slo aquellas para las que el servidor no est
autorizado ni estn previamente cacheadas.
Servidor slo autorizado. Son los servidores que son autorizados para una zona pero que no
responden a peticiones que no sean para su zona. Esto implica que no preguntan a otros servidores
(no hacen preguntas recursivas), no hacen de reenviador, ni tampoco actan como cach.
En Internet existen una serie de servidores DNS denominados servidores raz (root servers)
autorizados para el dominio raz . Estos servidores contienen el archivo de la zona . en donde se
delega a otros servidores DNS autorizados los dominios de primer nivel.
El ICANN es responsable de estos servidores raz, en concreto 13, de los cuales existen copias
repartidas mundialmente. Cada uno de ellos, y sus copias, se identifica con una misma direccin IP, de
forma que cuando un cliente u otro servidor DNS les realiza una pregunta, responde la copia ms cercana.
Como luego veremos, estos servidores raz deben ser conocidos por todos los servidores DNS para
poder responder a preguntas sobre nombres de dominio para los que no estn autorizados.
En la web http://root-servers.org/ podemos ver cuales son los servidores raz, sus nombres,
ubicaciones y las empresas que los administran y en http://www.iana.org/domains/root/db los servidores
de nombres y las empresas u organizaciones responsables de los dominios de primer nivel.
5. Clientes DNS (resolvedores).

Antes de que existieran servidores DNS que resolvieran los dominios, se usaba un archivo de texto
(denominado hosts) donde se guardan las correspondencias entre nombres de dominio y direcciones IP.
Este mecanismo se dej de utilizar cuando Internet empez a crecer en nombres de dominio, pasndose a
usar servidores DNS.
Muchos sistemas operativos estn configurados para usar este mtodo antes de usar el servicio DNS.
Si mediante la tabla de hosts no se puede resolver, se usa el servicio DNS. En una red local con pocos
equipos y que mantengan direcciones fijas puede ser efectivo mantener la tabal de hosts, en otro caso,
mantener actualizado y sincronizado el archivo hosts en todos los equipos es muy complicado y genera
errores. En la actualidad tambin se usa para bloquear contenidos de Internet como la publicidad web.
El formato del archivo hosts es el siguiente:
Se debe introducir la direccin IP a la que resolver, uno o ms espacios o tabulaciones y el
dominio a resolver.
Se pueden introducir ms de un dominio a resolver en la misma lnea separados por uno o ms
espacios o tabulaciones.
Cada correspondencia de direccin IP y dominio debe ir en una lnea distinta.
Las lneas que comienzan por # se consideran comentarios y no se computan.
Un ejemplo vlido de archivo hosts podra ser este:
#Definicin de localhost
127.0.0.1
localhost
#Correspondencia para equipos de la red local
192.168.210.1
pc1.aula.izv
192.168.210.222 ns1.aula.izv
#Correspondencia para una pgina web
209.85.229.104
www.google.es
#Dominios de Internet bloqueados mediante una IP invlida (como por ejemplo una mscara
de subred)
255.255.255.0
www.fantomas.com www.patapalo.com
La nica entrada obligatoria y que aparece siempre por defecto es la del dispositivo de red loopback.
Las direcciones del rango 127.0.0.0/8 son direcciones de loopback, de la cual la que se utiliza de forma
mayoritaria es la 127.0.0.1 por ser la primera de dicho rango. A pesar de que solo se usa la direccin
nica 127.0.0.1, se reservan las direcciones 127.0.0.0 a 127.255.255.255. Cualquier direccin dentro de
este bloque producir un loopback dentro del equipo local.
Esta direccin especial se suele utilizar cuando una transmisin de datos tiene como destino el propio
equipo de forma que stos la utilizan para dirigir el trfico hacia ellos mismos. Tambin es posible hacer
ping a la direccin de loopback para probar la configuracin de TCP/IP en el host local.
En algunas distribuciones Linux de Debian o basadas en sta, se aade otra entrada asociada al
loopback, en concreto 127.0.1.1. Esto realmente es un apao para resolver un bug del escritorio gnome.
Se puede sustituir esta direccin por la que tenga el equipo, siempre que dicha direccin se mantenga y
no cambie de forma dinmica.
Un resolvedor (resolver) es cualquier software que realiza preguntas a un servidor DNS y entiende las
respuestas recibidas. Los sistemas operativos incluyen un conjunto de libreras que realizan estas
operaciones y que son invocadas por las aplicaciones cuando usan un nombre de dominio.
Normalmente, se puede configurar si el resolvedor deber buscar primero en el archivo de hosts antes
de hacer la resolucin del nombre mediante el servicio DNS.
En general los pasos que realiza el resolver cuando una aplicacin quiere resolver un nombre son:
1.
Consulta la memoria cach de resolucin de nombres, si est configurada.
2.
Si la respuesta no es positiva, realiza la bsqueda en el archivo hosts del equipo.
3.
Si el nombre de dominio tampoco existe en el archivo hosts, se realizar una consulta recursiva al
servidor DNS que se tenga configurado y ste suministrar la respuesta a la aplicacin.
6. Mecanismo de resolucin.
Las consultas a un servidor DNS pueden ser recursivas o bien iterativas (tambin llamadas no
recursivas). Como veremos a continuacin, a la hora de resolver un nombre el resolver realiza una
consulta recursiva, la cual podr generar o no en una serie de consultas iterativas.
Una consulta recursiva es aquella en la que el servidor siempre debe dar una respuesta completa. Esta
respuesta podr ser: positiva indicndose si es autorizada o no, negativa (si no se pudo resolver) o de error
(por ejemplo por fallo en la red).
Una consulta iterativa es aquella en la que el servidor DNS puede proporcionar una respuesta parcial.
En este caso, a parte de las respuestas positivas, negativas o de error, puede dar una respuesta incompleta
que indique una referencia a otros servidores a los que se les puede preguntar para resolver la pregunta.
Una consulta recursiva la inicia un cliente DNS a travs del resolvedor o bien un servidor DNS que la
traslada a otro servidor DNS actuando como reenviador. El proceso de resolucin cuando un servidor
recibe una consulta recursiva es el siguiente:
1.
Si el servidor es autorizado para alguna zona, comprueba sus archivos de zona, y si encuentra la
respuesta, responde indicando que la respuesta es autoritativa.
2.
Si no encuentra la respuesta, o no es autorizado y acta como cach, consulta su cach de

respuesta anteriores, y si la encuentra responde que la respuesta es no autoritativa.
3.
Si en el paso anterior no se encontr respuesta positiva, y tiene configurados reenviadores,

entonces reenva la consulta recursiva a otro servidor DNS y la respuesta que reciba de ese otro
servidor DNS la traslada al cliente o al servidor que le pregunt.
4.
Si no tiene configurados reenviadores entonces:

a.
Inicia una serie de consultas iterativas a otros servidores DNS empezando la primera de
ellas por un servidor raz.
b.
Los servidores consultados devuelven referencias a otros servidores DNS que se usan
para realizarles la pregunta. Este proceso de preguntas iterativas a distintos servidores
finaliza cuando un servidor autorizado proporciona una respuesta positiva o negativa.
10 Tema 3. Servicio de nombres de dominio (DNS)

La figura muestra los pasos cuando un cliente realiza una pregunta recursiva por el dominio
farpoint.companyA.com a un servidor que tiene activada la recursividad (tiene que dar una respuesta
completa). Como el servidor DNS no est autorizado para la zona companyA.com, no tendr en sus
archivos de zona el nombre de dominio por el que se le ha preguntado.
Como debe dar una respuesta, empezar una serie de consultas iterativas empezando por uno de los
servidores raz. El servidor raz responde con una referencia al servidor autorizado para el dominio
com. El servidor DNS enva una consulta iterativa al servidor autorizado del dominio com, y ste le
responde con una referencia al servidor autorizado para el dominio companyA.com. Posteriormente el
servidor DNS enva una consulta iterativa al servidor autorizado del dominio companyA.com.
El servidor autorizado del dominio companyA.com consulta en sus ficheros de zona y como existe
el nombre de dominio farpoint.companyA.com responde con la informacin asociada a l, en este caso
con la direccin IP. (Si no existiera el nombre de dominio en los archivos de zona respondera de forma
negativa).
El servidor que recibi la respuesta recursiva entrega al resolver la informacin por la que pregunt y
la guarda en su cach disponible para futuras consultas.
Por lo tanto, las consultas iterativas son iniciadas por un servidor DNS a otro servidor DNS, cuando
en una consulta recursiva no ha encontrado la respuesta en sus archivos de zona o en la cach.
En este proceso de resolucin es muy importante la cach. Por ejemplo si el resolvedor pregunta
primero por el dominio www.granada.es y luego por www.alomartes.es no tendr que preguntar de nuevo
a un servidor raz, ya que tendr almacenada en la cach las direcciones de los servidores DNS
autorizados para el dominio es.
Como hemos podido comprobar, las consultas recursivas son costosas para los servidores DNS ya que
deben dar siempre una respuesta; de hecho los servidores DNS raz y los de primer nivel no responden a
consultas recursivas.
6.1. Respuestas en cach.

Las respuestas almacenadas en cache pueden ser positivas o negativas. Es decir se puede almacenar
los registros de recursos de nombres de dominio resueltos, y la informacin de que no existe un registro
de recursos para el nombre de dominio consultado. En este ltimo caso se impide la repeticin de
preguntas para nombres que no existen.
Los archivos de zona almacenan los tiempos mximos que guardan las respuestas en cach (TTL), de
forma que habr TTL para las respuestas positivas y TTL para las negativas. Se recomienda que el TTL
para las respuestas positivas sean mayor de un da, incluso semanas, y que el TTL para las respuestas
negativas sean menores de 3 horas.
El administrador es el que tiene que valorar estos tiempos en funcin de la frecuencia con la que
cambian los registros de recursos. Si el TTL para las preguntas positivas es pequeo, la informacin del
dominio ser ms congruente a costa de aumentar el trabajo de los servidores y la carga de la red.
7. Correspondencias inversas.
Las resoluciones de nombre de dominio que hemos comentado hasta ahora se denominan de
resolucin directa. Las resoluciones inversas consisten en preguntar por una direccin IP para obtener el
nombre o nombres de dominio como respuesta.
Uno de los principales motivos por el que se realiza una resolucin inversa est ligado a la seguridad.
Si al realizar una resolucin directa para un nombre de dominio obtenemos una direccin IP, la cual se
usa para realizar una resolucin inversa, se debera obtener el nombre de dominio por el que
preguntamos. Si no es as, posiblemente un intruso est resolviendo nombres a direcciones IP no vlidas
con fines maliciosos. Los servidores DNS pueden configurarse para que acten de esta forma para
asegurarse de las respuestas recibidas.
Tambin se suelen usar para detectar errores en la configuracin de los servidores y equipos, spam en
los servidores de correo, o seguir la traza de un ataque.
11
En la resolucin inversa, las direcciones IP se

tratan como nombres donde cada byte de la IP es un
dominio que cuelga del dominio in-addr.arpa. As
cuando realizamos una pregunta inversa del tipo cul
es el nombre de dominio para la IP 192.168.210.1?, lo
que realmente estamos preguntando es por el nombre
de dominio de 1.210.168.192.in-addr.arpa. Como
vemos, la estructura jerrquica de la direccin IP
tratada como nombre de dominio es de izquierda a
derecha comenzando por el dominio in-addr.arpa.
Para la resolucin inversa los servidores de
nombres deben almacenar zonas de resolucin inversa
que podrn ser maestras o esclavas.
Las zonas directas e inversas son independientes,
y el administrador debe mantener la informacin de
ambas sin discrepancias. Si se administra una zona
directa no es obligatorio administrar la zona inversa
correspondiente. De hecho si administramos un
dominio asociado a una IP pblica contratada a un
ISP ste no incluir nuestro dominio en su zona
inversa salvo que se lo pidamos expresamente.
El proceso de resolucin inversa es anlogo al directo. Por ejemplo una consulta recursiva de la IP
a un servidor DNS, empezara en buscar en la cach, y si no tiene la respuesta comenzara
una serie de consultas iterativas a los servidores DNS raz, a los servidores autorizados para el dominio
191.in-addr.arpa, a los autorizados para el dominio 27.191.in-ddr.arpa y as sucesivamente.
191.27.203.8
Los archivos de zona de resolucin inversa usan registros de recursos de tipo NS y PTR. Por ejemplo
para el siguiente archivo de zona de resolucin directa:
aula.izv.
IN
NS
puesto1.aula.izv.
puesto1.aula.izv.
IN
192.168.210.1
puesto2.aula.izv.
IN
192.168.210.2
puesto3.aula.izv.
IN
192.168.210.3
www.aula.izv.
IN
CNAME
puesto2.aula.izv.
el siguiente archivo de zona de resolucin inversa 210.168.192.in-addr.arpa. nos permitira resolver

las consultas inversas sobre direcciones IP de la red 192.168.210.0/24.
210.168.192.in-addr.arpa.
IN
NS
puesto1.aula.izv.
1.210.168.192.in-addr.arpa.
IN
PTR
puesto1.aula.izv.
2.210.168.192.in-addr.arpa.
IN
PTR
puesto2.aula.izv.
3.210.168.192.in-addr.arpa.
IN
PTR
puesto3.aula.izv.
8. Registros de recursos.
Los archivos de zona almacenan la informacin sobre nombres de dominio mediante registros de
recursos (RR, Resource Records). Estos RR son los que se envan entre los clientes y servidores DNS en
las preguntas y respuestas.
Los RR se representan en los archivos de zona en formato texto, y de forma binaria en los mensajes
que se envan mediante el protocolo DNS. El formato en modo texto es:
Nombre de Dominio
[TTL]
Clase
Tipo
Dato
3600
IN
192.168.210.1
Por ejemplo:
puesto1.aula.izv.
Lo primero es el nombre de dominio que se asocia al recurso, opcionalmente aparece el tiempo de

vida medio (TTL) que indica en segundos el tiempo que puede estar el registro en cach antes de ser
descartado. (Veremos que se puede especificar un tiempo global para todos los registros de la zona).

La clase define el tipo de protocolo usado. Aunque se pueden usar otras arquitecturas la habitual es
Internet (IN). A continuacin el tipo indica el tipo de dato asociado al nombre de dominio y por ltimo se
especifica el dato asociado al nombre de dominio.
8.1. Tipos de registros.

Comentaremos slo los tipos de registros de recursos ms usados, ya que el protocolo define alrededor
de 30 tipos diferentes. En el sitio web del IANA se pueden consultar todos ellos.
Registro SOA (Star of Authority). Es el primer registro de una zona y permite definir el tipo de
servidor y las opciones generales de la zona.
El registro tipo SOA comienza con el nombre del dominio de la zona, opcionalmente un TTL (lo
normal es establecerlo de forma global para toda la zona) y continua con la clase IN, el tipo SOA y
finaliza con los datos asociados. Estos datos asociados son:
-
FQDN del servidor de nombres maestro para el dominio
Contacto. Direccin de correo del responsable del dominio. (La arroba se sustituye por .)
Nmero de serie (serial). Indica la versin del archivo de zona que se ir incrementando cada vez
que el archivo se modifique. De esta forma los servidores secundarios conocen si el archivo de
zona ha cambiado y deben actualizarse mediante una transferencia de zona.
Actualizacin (refresh). Indica cada cuanto tiempo deben contactar los servidores secundarios
con el servidor maestro para comprobar si ha habido cambios en la zona. Dependiendo de la
frecuencia de actualizacin de la zona primaria se usar ms o menos tiempo. Se recomiendan
valores entre 12 y 24 horas.
Reintentos (retry). Indica cada cuanto tiempo deben reintentar los servidores secundarios
contactar con el servidor maestro si ste no responde a una actualizacin.
Caducidad (expire). Tiempo durante el cual un servidor secundario puede estar sin contactar con
el primario para comprobar la zona. Si se supera este tiempo, el secundario descarta los datos
que tena sobre la zona y se declara no autorizado para la zona.
TTL negativo. Es el tiempo mnimo en que se almacena las respuestas negativas sobre la zona.
Por ejemplo, nuestro dominio aula.izv podra tener el siguiente registro SOA
aula.izv. IN SOA puesto1.aula.izv. carlos.aula.izv. (
2012102301
; n de versin del archivo de zona
604800
; tiempo de refresco
86400
; tiempo de reintento
2419200
; tiempo de expiracin
38400 )
; TTL negativo
Registro NS (Name Server). Permite indicar los servidores de nombres autorizados para una zona.
(Cada zona debe contener al menos un registro NS, por ejemplo un maestro, y puede tener uno o ms
esclavos). Este registro tambin permite indicar los nombres de los servidores con autoridad en los
subdominios que hayan sido delegados. (Ver ejemplo de la pgina 6).
Registro A. (Address). Establece una correspondencia entre un nombre de dominio FDQN y una
direccin IP (IPv4).
Registro AAAA. (Address). Establece una correspondencia entre un nombre de dominio FDQN y
una direccin IP (IPv6).
Registro CNAME (Canonical Name). Indican un alias o sobrenombre para los nombres de dominio
especificados en registros A y AAAA. Un alias puede apuntar a otro dominio, pero no se pueden
usar en la parte derecha de registros MX y NS. Estos dos tipos de registros necesitan usar en su parte
derecha nombres que aparezcan en registros de tipo A o AAAA.
Registro MX (Mail Exchange). Define los equipos encargados de correo en el dominio para que los
agentes de transporte de correo sepan a que equipo deben entregar el correo. Se pueden definir varios
servidores de correo donde en el registro de recursos de cada uno se indican mediante un nmero el
orden de preferencia de cada uno de ellos; a nmero menor le corresponde mayor preferencia.
13
Registro SRV (Services Record). Permite definir equipos que actan como servidores de algn
servicio particular en el dominio. Por ejemplo servidores LDAP, servidores de mensajera, etc.
Registro PTR (Pointer Record). Establecen correspondencias entre direcciones IP y nombres de

dominio en las zonas de resolucin inversas. Si se usan direcciones tipo IPv4 y IPv6 deben aparecer
en zonas separadas.
Registro TXT (Texto). Permite registrar cualquier texto que tenga relacin con un equipo.
8.2. Registros pegamento (Glue Record).

Sabemos que un servidor de nombres se puede configurar para delegar o no algunos de sus dominios
en otros servidores de nombres.
En el caso de que el servidor de nombres autorizado para el subdominio delegado se encuentre en el
mismo dominio es necesario aadir:
1.
Un registro NS en el dominio que delega, para indicar cul es el servidor de nombres para la
zona delegada.
2.
Un registro A que indique la IP del servidor de nombres del subdominio delegado. Este tipo de
registro se denomina glue record porque que de alguna forma relaciona o pega la zona hija con
la zona padre.
Por lo tanto, los servidores de un dominio deben conocer la direccin IP de los servidores de nombres
de los subdominios para que los clientes puedan dirigirse a ellos en las consultas. (Ver ejemplo pag. 6).
En el cado de que el servidor de nombres autorizado para el subdominio delegado no se encuentra en
el mismo dominio, slo es necesario aadir el registro NS que indique el servidor de nombres de la zona
delegada. En este caso no necesita un registro tipo A, por que los clientes podrn resolver el nombre de
dominio de la zona delegada normalmente.
Finalizamos con un ejemplo de zona de resolucin directa para el dominio aula.izv.
aula.izv. IN SOA puesto1.aula.izv. carlos.aula.izv. (
2012041401
604800
86400
2419200
38400 )
; TTL negativo
aula.izv.
IN
NS
puesto1.aula.izv.
puesto1.aula.izv.
IN
192.168.210.1
puesto2.aula.izv.
IN
192.168.210.2
puesto3.aula.izv.
IN
192.168.210.3
www.aula.izv. IN
CNAME
ftp.aula.izv.
IN
CNAME
aula.izv.
IN
MX
smtp.aula.izv.IN
CNAME
_ldap._tcp.aula.izv.
SRV
puesto2.aula.izv.
puesto2.aula.izv.
10
puesto3.aula.izv.
puesto3.aula.izv.
0 0 389 puesto3.aula.izv.
;subdominio sri.aula.izv.
delegado en un subdominio propio
sri.aula.izv.
IN
NS
192.168.210.10
;subdominio bd.aula.izv.
delegado en un subdominio ajeno
bd.aula.izv.
NS
IN
; (Glue Record)
ns1.informatica.izv.
9. Transferencias de zona.
Los servidores en los que se declaran zonas esclavas, deben obtener los archivos de zonas, es decir los
registros de recursos, de otros servidores (maestros o esclavos) autorizados para dichas zonas.
Este proceso se denomina transferencia de zona y hay que configurar los servidores para que las
realicen. Los servidores maestros usan el puerto 53/TCP para realizar el intercambio de zona la cual
puede ser de dos tipos: completa e incremental.

En las transferencias de zonas completas, el servidor maestro enva al esclavo todos los datos de la
zona sustituyendo a los datos anteriores. En las transferencias de tipo incremental, el maestro slo enva
los datos que han cambiado desde la ltima transferencia de zona.
Las transferencias de zona puede comenzar por una pregunta del servidor esclavo al maestro para
comprobar si hay algn cambio en la zona. La primera vez que se inicia el servidor esclavo realiza esta
pregunta, y luego la repite cada cierto tiempo (especificado en el campo refresh del registro SOA).
Por otro lado el servidor maestro puede ser el encargado de notificar a los servidores esclavos de las
modificaciones producidas en sus zonas. De esta manera, si se produce una modificacin en la zona del
maestro, el esclavo queda enterado de forma inmediata y puede comenzar el proceso de transferencia.
En el proceso de transferencia, el servidor maestro enva su registro SOA al esclavo, de forma que
ste obtiene su nmero de serie y lo compara con el que tiene almacenado en su zona. Si el nmero de
serie que obtiene es superior al suyo, entiende que sus datos no estn actualizados y se realiza la
transferencia.
El que la transferencia sea de tipo completa o incremental depende del tipo de peticin que enve el
servidor maestro al esclavo empleando mensajes de tipo AXFR o IXFR respectivamente.
10. DNS dinmico (DDNS, Dynamic DNS)

Hasta ahora hemos comentado que es responsabilidad del administrador mantener actualizada la zona
de los servidores de nombres. Esta tarea puede ser muy costosa si la organizacin dispone de varios
dominios o mltiples servidores DNS. Si adems si se usan servidores DHCP para asignar direcciones a
los equipos, el mantenimiento manual de las zonas no es una opcin. Adems cada vez que se realizara
una modificacin, se tendra que parar y reiniciar el servicio DNS.
Para aliviar esta situacin, el RFC 2162 define los procesos para que de forma automtica, los
registros de recursos de una zona se puedan actualizar de forma externa, sin que el administrador tenga
que editar manualmente los archivos de zona y sin necesidad de reiniciar el servicio DNS.
Normalmente las actualizaciones dinmicas de los registros de una zona las pueden realizar los
propios equipos clientes o bien servidores DHCP.
En el primer caso hay que configurar los clientes de cada equipo y el servidor DNS para que permita
las actualizaciones por parte de los equipos. Si las realizan los servidores DHCP, se deber configurar el
servidor DHCP de forma apropiada: si se permite el cambio de los nombre de dominio, podrn ser los
clientes DHCP los que se configuren para que enven su nombre al servidor DHCP o bien sea el propio
servidor DHCP el que le asigne el nombre al equipo; tambin hay que configurar el servidor DNS para
que permita las actualizaciones por parte del servidor DHCP.
Para controlar quin puede realizar estas actualizaciones, se suelen usar ACL (listas de control de
acceso) para determinar desde que IPs se pueden realizar las actualizaciones, acompaado de algn
protocolo de autentificacin simple como es TSIG (Transaction SIGnature) o TKEY (Transaction Key)
para aumentar la seguridad.
Otro problema para los usuarios que usan el servicio DNS para acceso a Internet, es cuando quieren
acceder a un servicio (servidor web, ftp, corro, etc.) en un dominio que no tiene una IP fija en Internet.
Actualmente, la mayora de los ISP proporcionan direcciones IP pblicas por DHCP al router que nos
conecta a la red. Esto implica que la IP cambiar cada cierto tiempo y por lo tanto no podemos asignarle
un nombre de dominio estable a esta direccin IP.
Los llamados DNS dinmicos que ofrecen algunos sitios web en Internet permiten registrar un nombre
de dominio actualizndolo con la direccin IP que realmente se tenga en el momento. Lo ms habitual es
que sea el propio router el que tenga la posibilidad de actualizar el servidor DNS cuando cambie su
direccin IP, aunque tambin podra ser un programa instalado en algn equipo de la red.
Varias web, como DynDNS o No-ip ofrecen estos servicios de forma gratuita sobre un dominio de
segundo nivel de su propiedad. Por ejemplo podramos configurar un servidor web con IP dinmica con
el nombre de dominio micasa.dynds.org.
15
11. Seguridad DNS.

El servicio DNS es fundamental para el funcionamiento de una red e imprescindible en Internet, por
ello suele ser un objetivo para los atacantes. El hecho de que el protocolo DNS se dise inicialmente sin
tener en cuenta la seguridad (al igual que otros servicios de red) y que el servicio al ser distribuido
depende de muchos equipos, implica dificultades para su administracin.
Las principales amenazas para un servicio DNS son:
Ataques al servidor DNS usando exploits aprovechando agujeros en la seguridad.
Modificaciones de los archivos de zonas aprovechando una mala configuracin de los permisos
de usuarios que puedan acceder al equipo servidor de forma remota.
Ataques DoS (Denail of Service) mediante inundacin de mltiples peticiones UDP.
Suplantacin del servidor DNS, enviando RR incorrectos y envenenamiento de cach de clientes.
Envenenamiento de la cach de un servidor DNS al preguntar a otro DNS suplantado.
Suplantaciones del servidor maestro en las transferencias de zona.
Suplantaciones de los orgenes externos que envan actualizaciones a los DNS dinmicos.
Los mecanismos de seguridad que se pueden establecer son:

1.
En los servidores DNS. Actualizacin a las ltimas versiones software, instalacin de parches
de seguridad, enjaular el servidor en un entorno seguro, configuracin de los privilegios de
acceso a los archivos de zona, distribuir los servidores DNS en distintas redes y ubicaciones.
2.
En las transferencias de zona y actualizaciones dinmicas.
- Establecer ACL (listas de control de acceso por IP o nombres de dominios) con los
servidores desde los que se permiten las transferencias de zona y las actualizaciones
dinmicas.
- Utilizar cortafuegos para controlar las transferencias y actualizaciones de zona.
- Mecanismos de autentificacin de servidores y equipos mediante generacin de claves del
tipo TSIG o TKEY.
3.
En las consultas DNS.
- Configurar los servidores para minimizar las consultas iterativas.
- Limitar por direccin IP los equipos que pueden preguntar a un servidor.
- Implantacin de DNSSEC (DNS Security) basado en algoritmos de cifrado asimtricos
para garantizar la autenticidad e integridad en las consultas y respuestas DNS.
12. Servidores DNS en Linux.

El servidor DNS ms extendido en sistemas operativos basados en UNIX, y de facto un estndar, se
llama bind (Berkeley Internet Name Domain), y actualmente lo desarrolla la organizacin ISC (Internet
Systems Consortium).
Antes de realizar la instalacin, necesitamos siempre poder resolver el nombre de nuestro servidor
independientemente de que tengamos un servidor DNS. Al inicio del sistema, puede suceder que sea
necesario resolver el nombre del equipo, pero todava no est operativa la red, el servicio DNS, o que no
podamos acceder al servidor DNS. Para ello, se comprueba que el nombre del servidor est correctamente
establecido en los ficheros /etc/hostname y /etc/hosts.
Por ejemplo el contenido de un fichero /etc/hostname:
ubup
Y el contenido del fichero /etc/hosts:

127.0.0.1
127.0.1.1
localhost
ubup.aula.izv ubup
# The following lines are desirable for IPv6 capable hosts

::1
ip6localhost ip6loopback
fe00::0 ip6localnet
ff00::0 ip6mcastprefix
ff02::1 ip6allnodes
ff02::2 ip6allrouters

ff02::3 ip6allhosts
Tambin, como suele suceder en la mayora de los servicios, el servidor deber tener una IP fija.
El servidor bind se instala mediante el paquete bind9, sus archivos de configuracin se ubican en el
directorio /etc/bind, el demonio del proceso servidor se denomina named, y el script que permite
arrancar, parar y reiniciar el servicio es /etc/init.d/bind9 {start|stop|reload|restart|force-reload|status}.
Terminada la instalacin debemos comprobar que named est en ejecucin, y que el servicio est a la
escucha en los puertos 53 TCP y UDP. Para ello ejecutamos:
$ ps ef | grep named
$ netstat ltun
Cuando se instala bind, se generan unos archivos con una configuracin bsica con unas zonas ya
preconfiguradas:
El archivo /etc/bind/named.conf es el archivo de configuracin principal y mediante la directiva
include, incluye la configuracin de los tres archivos siguientes:
o
o
o
/etc/bind/named.conf.options. Contiene las opciones de configuracin generales del servidor y

define su comportamiento de forma global.
/etc/bind/named.conf.local. Es el archivo de configuracin de zonas y donde se declaran las
zonas de resolucin tanto directas como inversas.
/etc/bind/named.conf.default-zones. Contiene la definicin de las zonas creadas por defecto. Los
archivos de zonas creados por defecto, y referenciados desde /etc/bind/named.conf.default-zones
son:
/etc/bind/db.root Servidores raz.
/etc/bind/db.local Resolucin directa del bucle local.
/etc/bind/db.127 Resolucin inversa del bucle local.
/etc/bind/db.0 Resolucin inversa broadcast.
/etc/bind/db.255 Resolucin inversa broadcast.
Siempre que se cambie la configuracin del servidor hay que reiniciar el servicio para que tengan
efecto los cambios. Es muy conveniente examinar el archivo de logs (/var/log/syslog) del sistema para
comprobar que no se hayan producido fallos en el arranque del servidor.
El contenido del archivo de configuracin /etc/bind/named.conf.options que se genera por defecto es
muy simple. Le vamos a aadir algunas opciones ms cuyo significado aparecen como comentarios.
options {
// Directorio de trabajo por defecto
directory "/var/cache/bind";
// Para aceptar slo peticiones de resolucin de ciertos equipos.
allow-query { 127.0.0.1; 192.168.210.0/24;};
// Por defecto se permiten consultas recursivas (
consultas
recursion yes;) pero podemos limitar dichas
// recursivas solo a los equipos que indiquemos

allow-recursion {127.0.0.1; 192.168.210.0/24;};
// En principio no se permite enviar notificaciones de actualizacin de zonas a otros servidores
notify no;
// Servidores DNS a los que hacer peticiones de informacin de otras zonas (normalmente a los
servidores
// pblicos de los ISP)
// forwarders {80.58.61.250;};
// No se responder autoritativamente a peticiones de dominio inexistentes
auth-nxdomain no;
# conform to RFC1035
// Direcciones y puertos en los que realizar la escucha de peticiones de resolucin.

// (Por si hay varias interfaces de red)
listen-on port 53 { 127.0.0.1; 192.168.210.211;};
// tambin escucha en Ipv6 (adems por cualquier interfaz)
listen-on-v6 { any; };
17
};
Existen muchas ms opciones disponibles, algunas de stas irn apareciendo posteriormente.

- Configuracin del servidor DNS como solo cach.
Por defecto, el servidor bind est configurado como solo cach (no es autorizado para ninguna zona) y
es capaz de responder a consultas recursivas (recursin yes).
Podemos probarlo configurando un cliente con dicho servidor DNS y preguntar por cualquier nombre
de dominio en Internet. Adems las consultas repetidas se aceleran al estar resueltas en la cach.
- Configuracin del servidor DNS como reenviador (forwarding).
Para configurar un servidor que reenve las consultas a otros servidores (forwading) se edita el archivo
named.conf.options y mediante el atributo forwarders se indican las direcciones IP separadas por punto y
coma de los DNS que actuarn como reenviadores (forwarders).
Recordemos que las consultas que se reenvan son slo aquellas para las que el servidor no est
autorizado y sus respuestas no estn en cach.
Si el servidor est configurado como reenviador, podemos usar la opcin forward la cual tiene como
valor por defecto first. En este caso el servidor consultar a los servidores forwarders en primer lugar, y si
no obtiene respuesta, entonces intentar buscarla por s mismo. Si se usa el valor only entonces el servidor
slo consultar los reenviadores.
- Configuracin del servidor DNS como maestro para una zona de resolucin directa y una zona de
resolucin inversa.
Para configurar el servidor DNS como maestro para una zona de resolucin directa y una zona de
resolucin inversa se debe editar el archivo named.conf.local. Aqu se indican entre otras opciones el
nombre de la zona, el tipo de zona y el archivo donde se almacenarn los registros de recursos de la zona.
Por ejemplo, si queremos que el servidor tenga autoridad para el dominio aula.izv y para la zona de
resolucin inversa de la red 192.168.210.0/24 editaramos el archivo named.conf.local y le aadimos las
zonas directa e inversa:
zone "aula.izv" {
type master;
file "/etc/bind/db.aula.izv";
};
zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192.168.210";
};
A continuacin deberamos crear los archivos con los registros de recursos de ambas zonas. Los
archivos a crear son los que hemos indicado anteriormente en el parmetro file. Si no hubiramos
especificado la ruta absoluta, se toma el directorio de trabajo por defecto (/var/cache/bind).
Crear los archivos con los registros de recursos editndolos directamente suele causar problemas, ya
que la sintaxis es algo complicada. Lo ms cmodo es usar alguna herramienta grfica que nos ayude en
esta tarea como es webmin. Adems podemos indicarle que a medida que vayamos registrando
registros de recursos de la zona directa, cree de forma automtica los correspondientes PTR de la zona
inversa.
Ejemplo de archivo de zona de resolucin directa
$ttl 38400 ;
aula.izv. IN SOA ubup.aula.izv. carlos.aula.izv. (
aula.izv.
ubup.aula.izv.
2012041401
604800
86400
2419200
38400 )
; TTL negativo
IN
NS
ubup.aula.izv.
IN
; servidor maestro autorizado
192.168.210.211
; correspondencia FDQN a IP

winp.aula.izv. IN
192.168.210.212
profe.aula.izv.
IN
smtp.aula.izv.IN
CNAME profe.aula.izv.
www.aula.izv. IN
CNAME profe.aula.izv.
aula.izv.
MX 10 profe.aula.izv.
IN
192.168.210.210
; alias para nombres de dominio
; quien entrega el correo al dominio
--------------------------------------------------------------------------------------------------------------------------------
Ejemplo de archivo de zona de resolucin inversa

$ttl 38400 ;
210.168.192.in-addr.arpa. IN
SOA
ubup.aula.izv. carlos.aula.izv. (
1316802825
10800
3600
604800
38400 )
210.168.192.in-addr.arpa.
IN
NS
ubup.aula.izv.
211.210.168.192.in-addr.arpa. IN
PTR
ubup.aula.izv.
212.210.168.192.in-addr.arpa. IN
PTR
winp.aula.izv.
210.210.168.192.in-addr.arpa. IN
PTR
profe.aula.izv.
En los archivos de zona puede usarse expresiones del tipo $TTL 86400. Esto permite especificar un
valor de TTL por defecto para todos los registros de recursos. Se puede usar el carcter @ como
sustituto del nombre de la zona definido en named.conf.local para no tener que repetirlo en el archivo.
Despus de reiniciar el servicio y comprobar que no hay errores, deberamos configurar los clientes
para que usen como servidor DNS la mquina en donde hemos instalado y configurado el servidor.
- Configuracin del servidor DNS como esclavo para una zona de resolucin directa y una zona de
resolucin inversa.
En el servidor que se configure como esclavo debe crearse una zona secundaria, luego debemos editar
su archivo /etc/named.conf.local y aadirle dicha zona indicando: el tipo de servidor (slave), cual es el
servidor maestro del que recibir la transferencia (masters) y el archivo donde se almacenarn los
registros de recursos que se reciban (files).
Por ejemplo si el equipo donde se va a configurar como servidor esclavo fuera profe.aula.izv con IP
escribiramos en el archivo /etc/named.conf.local de este servidor esclavo:
192.168.210.210,
zone "aula.izv" {
// tipo de servidor
type slave;
// IP del servidor maestro
masters { 192.168.210.211; };
};
En el archivo /etc/named.conf.local del servidor maestro deberemos permitir que se realicen

transferencias de zona hacia el servidor esclavo (allow-transfer), y adems vamos a configurarlo para que
notifique a los esclavos los cambios que se produzcan en el servidor (notify).
zone "aula.izv" {
type master;
// servidor permitido al que transferir la zona
allow-transfer { 192.168.210.210; };
// notificar a los servidores esclavos de los cambios
notify yes;
};
Por ltimo, en el archivo de zona del servidor maestro, deberemos indicar que existe otro servidor
DNS para la zona, aadiendo para ello un nuevo registro NS:
...
aula.izv.
IN
NS
profe.aula.izv.
; nombre de dominio del servidor esclavo
...
19
- Configuracin del servidor DNS para actualizaciones dinmicas (Dynamic DNS).

Si usamos el servidor DHCP del ISC, podemos configurar el servicio DNS bind para que admita
actualizaciones dinmicas de forma fcil. Supondremos que ambos servidores corren en el mismo equipo
(ubup.aula.izv).
En muchas instalaciones es frecuente que en el servidor DNS se creen de forma manual los registros
de recursos correspondientes a los equipos que van a ofrecer un servicio (servidor web, ftp, correo, etc.);
y se configuren los servicios DNS y DHCP para que los registros de recursos de los equipos clientes se
generen o actualicen de forma automtica.
A continuacin detallaremos los pasos necesarios a realizar.
1) En primer lugar est el tema de la seguridad. Normalmente, aparte de indicar qu equipos podrn
actualizar los archivos de zona del servidor DNS, se usa un protocolo de autentificacin consistente en
firmar las actualizaciones mediante claves TSIG de forma que slo estarn permitidas las actualizaciones
que presenten la clave autorizada.
Las claves TSIG se generan a partir de datos aleatorios que se encriptan mediante el algoritmo base64. Este sistema usa claves simtricas: en nuestro caso, la clave del servidor DNS y la de servidor DHCP
que le enviar los datos de las actualizaciones debern ser las mismas. Para generar la clave se usa el
comando dnssec-keygen de la forma:
dnssec-keygen -a HMAC-MD5 -b 128 -n HOST ddnsclave
En este caso, el comando genera una clave de 128 bits empleando el algoritmo HMAC-MD5 (base-64)
de tipo HOST crendose dos archivos: Kddnsclave.+157+59571.key y Kddnsclave.
+157+59571.private; el primero contiene la clave privada y el segundo la pblica. Los nmeros 157 en el
nombre del archivo indican el tipo de algoritmo usado, y los 5 dgitos posteriores indican un identificador
aleatorio.
y
Estos dos archivos debern colocarse en el directorio donde el servidor DNS almacene los archivos de
zona; en nuestro caso en /etc/bind.
2) El segundo paso sera configurar el servidor DNS para que acepte actualizaciones firmadas con esta
clave. Para ello editamos el archivo /etc/bind/named.conf.local y le aadimos una entrada key con la
definicin de la clave.
Adems deberemos configurar las zonas que recibirn las actualizaciones con dicha clave usando la
opcin allow-update; o bien podemos afinar un poco ms y especificar ciertas reglas mediante el uso de
update-policy.
El archivo quedara de la forma:
key ddnsclave {
algorithm hmac-md5;
// la clave secreta se obtiene del archivo Kddnsclave.+157+59571.key
secret "4vi9ZnoZlJ/axrD3ODwEbw==";
};
zone "aula.izv" {
type master;
file "/var/lib/bind/aula.izv.hosts";
// permitimos que la clave "ddnsclave" se pueda usar para actualizar la zona

allow-update { key ddnsclave; };
// O bien indicamos reglas para la actualizacin
// update-policy {grant ddnsclave wildcard *. aula.izv. A TXT; };
};
zone "210.168.192.in-addr.arpa" {
type master;
file "/var/lib/bind/192.168.210.rev";
// permitimos que la clave "ddnsclave" se pueda usar para actualizar la zona

allow-update { key ddnsclave; };
};
// O bien indicamos reglas para la actualizacin

// update-policy {grant ddnsclave wildcard *.210.168.192.in-addr-arpa. PTR; };

3) Ahora vamos a configurar el servidor DHCP para que actualice las zonas del servidor DNS cada vez
otorgue una concesin. Usaremos la configuracin de ejemplo para el servidor DHCP del tema anterior y
le aadiremos varias entradas. Para ello editamos el archivo de configuracin /etc/dhcp3/dhcpd.conf
# Configuracin global
option domain-name-servers 192.168.210.211, 8.8.8.8; # DNS para los clientes
option domain-name "aula.izv.";
# Nombre de dominio para los clientes
option subnet-mask 255.255.255.0;
# Mscara por defecto para los clientes
default-lease-time 600;
# Tiempo en segundos de la concesin
max-lease-time 7200;
# Mximo tiempo en segundos que durar la
concesin
# Activamos las actualizaciones DNS dinmicas
ddns-updates on;
# Indica el modo de actualizacin
ddns-update-style interim;
#los clientes no podrn realizar directamente las actualizaciones
ignore client-updates;
# indicamos la clave secreta (la misma que indicamos en el servidor DNS)
key ddnsclave {
algorithm hmac-md5;
secret "4vi9ZnoZlJ/axrD3ODwEbw==";
}
# Establecemos las zonas a actualizar indicando dnde se halla el servidor DNS y la clave a usar
zone aula.izv. { primary 127.0.0.1; key ddnsclave; }
zone 210.168.192.in-addr.arpa. { primary 127.0.0.1; key ddnsclave;}
# Especificacin de un rango
subnet 192.168.210.0 netmask 255.255.255.0 {
range 192.168.210.60 192.168.210.80;
# Rango de IP desde la 60 a la 80 inclusive
option broadcast-address 192.168.210.255;
# Direccin de difusin para el rango
option routers 192.168.210.254;
# Puerta de enlace
option domain-name-servers 192.168.210.211;
# servidores DNS
default-lease-time 3600;
# Tiempo en segundos que durar la concesin
# nombres de dominio cuyas zonas DHCP actualizar.
ddns-domainname "aula.izv.";
ddns-rev-domainname ".in-addr.arpa.";
# Configuracion particular para un equipo

host puesto7 {
hardware ethernet 00:0c:29:1e:88:1d;
fixed-address 192.168.1.66;
option host-name "ubu7";
}
4) Terminada la configuracin de los servidores DNS y DHCP, reiniciamos ambos servicios

comprobando que no hay errores en los logs (/var/log/syslog). A partir de ahora, ya no podremos
modificar los archivos de zona manualmente para despus reiniciar el servicio DNS. Una vez configurado
el DNS dinmico, bind se hace cargo de la actualizacin de los archivos de zona.
A partir de ahora, para modificar los archivos de zona tendremos que usar el comando nsupdate o bien
aprovechar que cuando se para bind, ste sobrescribe los archivos de zona con los datos actuales y con
todas las actualizaciones. Por lo tanto si queremos modificar el archivo de la zona, pararemos bind,
borramos los archivos journal (archivos con las actualizaciones), editamos manualmente los archivos de
zona e iniciamos bind.
Los archivo journal (o de diario), son archivos binarios y no se pueden editar. Los nombres de dichos
archivos coinciden con los nombre de archivo de la definicin de las zonas aadindoles la extensin .jnl
5) Por ltimo queda comprobar la configuracin iniciando algn cliente configurado para obtener su
configuracin de red mediante DHCP. Dicho cliente no puede estar registrado previamente de forma
manual en los archivos de zona.
Los clientes Windows de forma general envan al servidor DHCP el nombre de equipo, lo que
permitir que DHCP enve dicho nombre de dominio para actualizar las zonas del servidor DNS. En los
clientes Linux debemos asegurarnos que tambin lo hacen. Para ello deberemos editar el archivo de
configuracin del cliente /etc/dhcpd3/dhclient.conf y comprobar que est activa la opcin
21
send host-name "<hostname>";
Una vez iniciado el cliente, deberemos observar el archivo /var/log/syslog del equipo servidor para
comprobar que la concesin ha sido correcta y que los registros de zona del servidor DNS han quedado
actualizados.
13. Servidores DNS en Windows.

La instalacin del servicio DNS se puede realizar desde el botn "Inicio" - > "Panel de Control" - >
"Agregar o quitar programas" -> "Agregar o quitar componentes de Windows". Como resultado de la
accin anterior, pasa a ser mostrada la ventana del "Asistente para componentes de Windows", en la que
nos situaremos sobre el apartado "Servicios de red", y tras ello pulsaremos sobre el botn "Detalles".
En la nueva ventana mostrada, activaremos la casilla correspondiente al apartado "Sistema de
nombres de dominio (DNS)", y tras ello pulsaremos sobre el botn "Aceptar", y de vuelta a la ventana
anterior, sobre el botn "Siguiente". En ese instante comienza la instalacin del servicio DNS de
"Windows 2003 Server".
El proceso de instalacin nos solicitar el CD de "Windows 2003 Server". Terminada la instalacin,
en las "Herramientas Administrativas" del "Panel de Control" de dispondremos de una nueva entrada
"DNS", correspondiente al servidor DNS recin instalado.
Otra posibilidad para realizar el proceso de instalacin es desde "Herramientas Administrativas", y
seleccionar Administre su servidor. En la parte superior de la ventana que aparece activar el enlace
Agregar o quitar funcin. Esto lanzar un asistente donde podremos elegir de una lista Servidor DNS.
Si en algn momento se lanza un asistente para crear una zona, cancelaremos esta opcin ya que
crearemos las zonas necesarias posteriormente.
Si ejecutamos desde Herramientas administrativas la consola de administracin del servidor DNS,
aparecer una ventana de administracin dividida en dos partes. En la parte izquierda aparecen los
equipos con servicios DNS a administrar. En principio aparece nuestra mquina, pero podramos
administrar otros servidores (icono DNS, opcin Conectar con el servidor DNS del men contextual).
Para cada servidor se puede gestionar las zonas de resolucin directa e inversa expandiendo el icono
que representa el servidor. En nuestro caso no existe ninguna zona, pero las crearemos luego.
- Configuracin del servidor DNS como solo cach.
Por defecto el servidor DNS est configurado como slo cach (no est autorizado para ninguna zona)
y responde a consultas recursivas. Podemos comprobarlo seleccionado las propiedades del servidor, y en
la ventana que aparece, en la ficha Sugerencias de raz se presenta una lista con los FQDN y
direcciones IP de los 13 servidores DNS raz.
Para ver las bsquedas que estn en cach, se debe activar Avanzadas de la opcin Ver de la
barra de men principal. Si acabamos de instalar el servicio DNS, la carpeta Bsquedas en cach estar
vaca. Si configuramos un cliente indicndole como servidor DNS el que hemos instalado, y preguntamos
por un nombre de dominio, por ejemplo, nslookup www.google.es, podremos comprobar como la
informacin obtenida se queda almacenada en la cach del servidor.
- Configuracin del servidor DNS para que reenve las consultas a reenviadores (forwarding).
En las propiedades del servidor, pestaa Reenviadores podemos configurar las IP de los servidores
DNS a los que se reenviarn las consultas cuando se pregunte por un dominio concreto o por cualquier
dominio (opcin por defecto).
- Configuracin del servidor DNS como maestro para una zona de resolucin directa y una zona de
resolucin inversa.
Lo primero ser configurar, si no lo est ya, el sufijo DNS del equipo. Se establece en propiedades de
Mi PC, pestaa Nombre de equipo, botn Cambiar, botn Ms , en sufijo principal del equipo.
(Por ejemplo aula.izv). Este sufijo se aadir automticamente al nombre del equipo cuando usemos el
nombre del equipo sin indicar un dominio.
La manera ms cmoda de configurar el servidor DNS como maestro para una zona de resolucin
directa y una zona de resolucin inversa, es crear primero ambas zonas pero sin aadir registros a la zona

directa hasta que no est creada la zona inversa. Cuando aadamos los registros a la zona de resolucin
directa, indicaremos que se crean de forma automtica los correspondientes PTR en la zona inversa.
A continuacin vamos a definir una nueva zona de bsqueda directa gestionada por nuestro equipo,
para lo cual pulsamos sobre el icono "+" mostrado junto al icono del equipo, y tras ello nos ubicamos
sobre la carpeta "Zonas de bsqueda directa", pulsando en la misma con el botn derecho del ratn para
elegir la opcin "Zona nueva..." en el desplegable correspondiente.
Como resultado pasa a ejecutarse el asistente de creacin de nueva zona, en cuya primera ventana
debemos seleccionar "Zona principal". A continuacin debemos indicar el nombre que vamos a asignar a
la nueva zona definida y el nombre del archivo de disco donde se almacenar los datos de la zona.
Luego hemos de indicar como se realizarn las actualizaciones de nuestro servidor DNS; en nuestro
caso dejaremos activada la opcin "No admitir actualizaciones dinmicas. Esto obligar a actualizar
manualmente los registros de recursos. Para concluir la definicin de la nueva zona creada, pulsaremos
sobre el botn "Finalizar".
Al pulsar en la zona, deber aparecer una lista con los registros definidos en esta zona. En su creacin
se definen tres registros por defecto: SOA (registro de autoridad) NS (servidor DNS) y A (Address).
Para crear la zona de resolucin inversa, deberemos seguir de forma anloga los pasos anteriores hasta
llegar al punto en que el asistente nos preguntar por el Id. de red (parte de la direccin IP que
corresponde a la red, pero sin utilizar el orden inverso). Seguidamente indicaremos el nombre del archivo
de disco que almacenar los datos de la zona y la opcin No admitir actualizaciones dinmicas. Cuando
pulsemos el botn finalizar, se crear la zona inversa.
Al pulsar en la zona, deber aparecer una lista con los registros definidos en esta zona. En su creacin
se definen dos registros por defecto: SOA (registro de autoridad) y NS (servidor DNS).
Ahora ya podemos aadir registros a las zonas. Para ello hay que seleccionar la zona y pulsar en la
opcin del men principal Accin y elegir de la lista el tipo de registro a aadir.
Para cualquier tipo de registro creado, podemos realizar modificaciones a travs de la opcin
Propiedades de su men contextual.
Siempre que se creen o se realicen modificaciones en el servidor, deberemos reiniciar el servicio. Para
ello, en el men contextual del icono que representa al servidor, se elige la opcin Todas la tareas y
luego Reiniciar.
14. Configuracin de clientes.

14.1. Clientes Linux.
Importante. En Ubuntu, la configuracin de las interfaces de red debe siempre realizarse a travs de
la misma aplicacin. Podemos usar Network Manager, o los comandos ifconfig o ip. Tambin es factible
editar el archivo de configuracin /etc/network/interfaces. No se deben mezclar dichos modos por que se
producen configuraciones inconsistentes.
Por ejemplo, datos tpicos de la interfaces de red en un archivo /etc/network/interfaces seran:
# the loopback network interface
auto lo
iface lo inet loopback
# the primary network interface
auto eth0
iface eth0 inet static
address 192.168.210.212
netmask 255.255.255.0
gateway 192.168.210.254
broadcast 192.168.210.255
Si hacemos algn cambio, siempre deberemos reiniciar el servicio de red:

$ /etc/init.d/networking restart
Es conveniente ejecutar posteriormente el comando ifconfig para verificar la configuracin.
23
La configuracin de los clientes DNS usando los archivos de configuracin se realiza bsicamente
editando los archivos etc/nsswitch.conf y /etc/resolv.conf
etc/nsswitch.conf. En este archivo se define el orden que usa el resolver a la hora de buscar
informacin sobre nombres de dominio. El orden definido es primero files (se consulta en el
archivo /etc/hosts) y luego dns (se consulta a los servidores DNS definidos en /etc/resolv.conf).
etc/resolv.conf. Este archivo contiene una serie de atributos a los que se puede asociar valores. El
atributo nameserver indica los servidores DNS que consultar el resolver. El atributo domain
especifica el dominio por defecto al que pertenece la mquina y el que se aadir a la bsqueda
de nombres no cualificados. El atributo search permite ampliar la lista de dominios que se
aadirn a los nombres de dominio en las bsquedas de nombres no cualificados, los llamados
sufijos. Las opciones domain y search no pueden usarse simultneamente. Por ejemplo:
nameserver 192.168.210.211
nameserver 8.8.8.8
search aula.izv
Si usamos la interfaz grfica, en ajustes de IPv4 de las propiedades TCP/IP del adaptador de red
(Sistema -> Preferencias -> Conexiones de red) podremos editar en cuadros de texto tanto las IP de los
servidores DNS (se escriben uno detrs de otro separados por comas), como el dominio de bsqueda al
que pertenece la mquina.
Es conveniente editar el archivo /etc/hostname y comprobar que contiene el nombre que queremos
para la mquina.
14.2. Clientes Windows.

En los clientes Windows XP la configuracin de red se establece a travs de las propiedades del
protocolo TCP/IP que podemos activar mediante las propiedades de la Conexin de rea local. En
Usar las siguientes direcciones de servidores DNS es posible definir dos servidores DNS. El segundo
servidor DNS que sealemos, ser un servidor alternativo en el caso de que el primero de ellos no est
disponible.
Tambin en Opciones avanzadas, en la pestaa DNS se pueden aadir ms servidores DNS
alternativos, y sufijos para los nombres DNS no cualificados. Por defecto el nico prefijo que se aade a
los nombres no cualificados es el llamado sufijo principal que se configura en las propiedades del nombre
del equipo (Equipo o MiPc -> Propiedades -> Configuracin avanzada del sistema - > Pestaa Nombre de
equipo -> botn Cambiar -> Botn Ms -> sufijo DNS principal del equipo). Si se desea aadir ms
sufijos al nombre del equipo, habr que habilitar el botn de opcin Anexar estos sufijos (en este orden)
e introducir la lista de sufijos.
15. Herramientas de consulta.

Los comandos nslookup, dig y host permiten realizar consultas a servidores DNS. Estos comandos
permiten comprobar el funcionamiento del servicio y de los servidores DNS. El comando nslookup es
ms antiguo y ofrece menos informacin que dig, pero est disponible en equipos Linux y Windows.
nslookup. De forma general obtiene registros de recursos tipo A o PTR, pero dispone de opciones
para obtener otros tipos de informaciones. Puede funcionar en lnea de comandos o de forma
interactiva. El comando acta de una forma predeterminada segn se haya establecido mediante
unos parmetros, los cuales podemos cambiarlos. Esta lista de parmetros se pueden obtener
invocando el comando seguido del argumento all.
Ejemplos de uso en lnea de comandos:
# obtiene la direccin de un nombre de dominio (pregunta al servidor DNS configurado en el
equipo)
nslookup www.mec.es
# obtiene la direccin de un nombre de dominio preguntando al servidor DNS especificado
nslookup www.mec.es a.nic.es
# obtiene el nombre de dominio correspondiente a la IP
nslookup 150.214.20.1
# obtiene todos los tipos de registros de un dominio

nslookup -type=ANY mec.es
# obtiene el registro SOA del dominio
nslookup -type=SOA example.com
Cuando se usa de forma interactiva (sin argumentos) aparece un indicador de rdenes (>) donde se
puede ir escribiendo comandos. Se sale con exit o bien Ctrl+C (Windows) o Crtl+D (Linux). Las
posibles rdenes que se pueden ejecutar dependen del sistema operativo, algunas son comunes a
Windows y a Linux, y otras slo funcionan en uno de ellos.
Con unos ejemplos veremos las posibilidades:
# configura el servidor a quien se le preguntar y se le pregunta por los servidores autorizados para
ugr.es
nslookup
> server 8.8.8.8
> set type=NS
> ugr.es
# configura el servidor a quien se le preguntar y se pregunta por el nombre de dominio
correspondiente a la IP
nslookup
> server a.nic.es
> set type=PTR
> 150.214.20.1
dig. La herramienta dig ofrece ms opciones y suministra ms informacin en sus respuestas que
nslookup. Organiza la informacin en secciones que se corresponden con los campos principales de
los mensajes DNS. Los registros de recursos los muestra con un formato similar a como se escriben
en los archivos de zona.
Tradicionalmente dig slo ha estado disponible en sistemas Unix/Linux, pero actualmente existen
versiones para Windows; incluso como aplicacin con interfaz grfica, como es el caso de Ezdig,
aplicacin freeware de la empresa Eztk (http://www.eztk.com/).
El formato (simplificado) es el siguiente:
dig [@dns] domain [question-type]
donde dns especifica el servidor de dominio al que se le realizar la consulta; domain indica el
nombre de dominio a preguntar, y question-type expresa el tipo de recurso consultado. Ejemplo:
#obtiene por defecto la IP correspondiente al nombre del dominio (registro tipo A)
dig www.mec.es
#obtiene la direccin IP correspondiente al nombre de dominio
dig x 8.8.4.4
# pregunta al servidor 8.8.8.8 por el nombre del dominio mostrando la traza de la consulta
dig @8.8.8.8 www.google.es +trace
#pregunta a 8.8.8.8 por los servidores autorizados para el dominio es
dig @8.8.8.8 es NS
# pregunta a 8.8.8.8 por todos los registros de recursos del dominio mec.es
dig @8.8.8.8 mec.es ANY
host. Es un comando Linux cuyo formato simplificado es:

host [options] name [server]
donde options indica entre otras cosas el tipo de recurso a preguntar, name es el nombre de dominio
por el que se consulta y server es el servidor de dominio consultado. Ejemplo:
#obtiene la IP correspondiente al nombre del dominio (registro tipo A)
host www.mec.es
#obtiene la direccin IP correspondiente al nombre de dominio
host 8.8.4.4
#pregunta a 8.8.8.8 por los servidores autorizados para el dominio
host -t NS es 8.8.8.8
# pregunta a 8.8.8.8 por todos los registros de recursos del dominio con informacin detallada en
secciones
host v t ANY mec.es 8.8.8.8

Sri - Tema 3 DNS Rev 1.4

Cargado por

Copyright:

Formatos disponibles

Sri - Tema 3 DNS Rev 1.4

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

Sri - Tema 3 DNS Rev 1.4

Cargado por

Copyright:

Formatos disponibles

Tema 3.

Servicio de nombres de dominio (DNS)

Tema 3. Servicio de Nombres de Dominio. DNS

5. Clientes DNS (resolvedores).................................................................8

15. Herramientas de consulta..................................................................23

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 3. Servicio de nombres de dominio (DNS)

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 3. Servicio de nombres de dominio (DNS)

Tema 3. Servicio de nombres de dominio. DNS.

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 3. Servicio de nombres de dominio (DNS)

3. Espacio de nombres de dominio.

3.1. Nombres de dominio relativos y absolutos.

3.2. Administracin de nombres de dominio.

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 3. Servicio de nombres de dominio (DNS)

Genricos. Usan un nombre relacionado con el propsito o el tipo de organizacin que lo va a

3.3. Delegacin de dominios.

3.4. Registros de dominio.

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 3. Servicio de nombres de dominio (DNS)

A. Asocia un nombre de dominio su direccin IP.

CNAME. Asigna otro nombre o alias a un nombre de dominio.

;subdominio sri.aula.izv. delegado

Por otro lado, el subdominio bd.aula.izv. no se ha delegado.

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 3. Servicio de nombres de dominio (DNS)

4.1. Tipos de servidores de nombres.

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 3. Servicio de nombres de dominio (DNS)

5. Clientes DNS (resolvedores).

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 3. Servicio de nombres de dominio (DNS)

Consulta la memoria cach de resolucin de nombres, si est configurada.

Si la respuesta no es positiva, realiza la bsqueda en el archivo hosts del equipo.

Si no encuentra la respuesta, o no es autorizado y acta como cach, consulta su cach de

Si en el paso anterior no se encontr respuesta positiva, y tiene configurados reenviadores,

Si no tiene configurados reenviadores entonces:

IES Zaidn Vergeles de Granada. Departamento de Informtica.

10 Tema 3. Servicio de nombres de dominio (DNS)

6.1. Respuestas en cach.

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 3. Servicio de nombres de dominio (DNS)

En la resolucin inversa, las direcciones IP se

el siguiente archivo de zona de resolucin inversa 210.168.192.in-addr.arpa. nos permitira resolver

Lo primero es el nombre de dominio que se asocia al recurso, opcionalmente aparece el tiempo de

IES Zaidn Vergeles de Granada. Departamento de Informtica.

12 Tema 3. Servicio de nombres de dominio (DNS)

8.1. Tipos de registros.

FQDN del servidor de nombres maestro para el dominio

; n de versin del archivo de zona

IES Zaidn Vergeles de Granada. Departamento de Informtica.

Tema 3. Servicio de nombres de dominio (DNS)

Registro PTR (Pointer Record). Establecen correspondencias entre direcciones IP y nombres de

8.2. Registros pegamento (Glue Record).

; n de versin del archivo de zona

delegado en un subdominio propio

delegado en un subdominio ajeno