Introduccin al DNS

El direccionamiento de Internet se basa en las direcciones IP, stas forman el esquema bsico de
direccionamiento de Internet y consisten en direcciones de 32 bits en el caso de IPv4 y 128 bits en el
caso de IPv6. Las direcciones IPv4 se representan con una notacin que consiste en escribir los bytes
que forman la direccin separados por puntos, siguiendo el formato xxx.yyy.zzz.ttt (por
ejemplo 192.168.0.1).

Este direccionamiento est diseado para facilitar el trabajo de los routers pero es poco manejable para las
personas, ya que requiere memorizar secuencias numricas. Para solucionar este problema se asignaron
nombres a los equipos.

Inicialmente la correlacin entre nombres y direcciones IP se realizaba mediante el fichero de hosts que
contena la relacin entre todos los nombres y todas las direcciones IP y se mantena de forma centralizada
para despus distribuirlo a todos los equipos de la red. Cuando la red fue creciendo esta frmula se volvi
impracticable y se opt por mover la estructura de nombres a un sistema de directorio jerrquico basado en
lo que se llama nombres de dominio.

Para el DNS se cre una estructura jerrquica que encajase con las estructuras organizativas de las
instituciones que posean equipos conectados a Internet, lo cual dio lugar a una estructura de nombres
jerrquica en la que los niveles de la jerarqua (dominios) y los nombres estn separados por un ".". Los
nombres como por ejemplo www.example.org estn compuestos de un dominio, example.org, y un nombre
de host, www. El nombre de dominio se compone de dos partes org que es el dominio de primer nivel y, en el
caso de los .org, est gestionado por el Public Interest Registry (PIR) y por exampleque correspondera a la
organizacin, que a su vez podra crear delegaciones en subdominios.
En el DNS, cada dominio es gestionado por la institucin que lo controla, de manera que no existe una base
de datos centralizada que contenga toda la informacin del DNS, sino que existen unos servidores
denominados servidores raz (root servers en ingls) que contienen informacin de los servidores que
contienen los dominios de primer nivel (TLD: Top Level Domain en ingls) y estos a su vez contienen la
informacin de los servidores que contienen los dominios de segundo nivel y as sucesivamente. Los
servidores contienen tambin la informacin de los equipos de host que pertenecen a ese dominio, los
servidores de correo para ese dominio e informacin de los servidores de DNS que tienen informacin
autoritativa sobre ese dominio.

Esta estructura hace que las bsquedas se inicien en los servidores raz, siguiendo la estructura de dominios
hasta llegar al dominio que contiene el nombre de host o la informacin solicitada. Los servidores pueden
hacer bsquedas recursivas, de manera que un cliente puede hacer la peticin a un servidor por defecto que
es el encargado de recorrer el rbol y que enva la respuesta al cliente. Este servidor est autorizado a
guardar la respuesta durante un tiempo especificado por el origen en la respuesta.

Un ejemplo de la estructura de rbol del DNS sera la siguiente:

 En ella se puede ver como los servidores raz apuntan a los TLDs y estos a los dominios de segundo nivel, que
tienen tanto hosts como subdominios.

Dominios de primer Nivel

El DNS es una estructura jerrquica de nombres, en la punta de la pirmide est la zona raz, la cual
est alojada en los servidores raz y est gestionada por la IANA (Internet Assigned Numbers
Authority).
En la zona raz se definen los dominios de primer nivel (TLD: Top Level Domain). Inicialmente mediante el RFC
920 se crearon 6 TLDs cada uno para albergar los dominios de diferentes tipos de instituciones, estos son:
arpa (Address and Routing Parameter Area): usos relacionados con la infraestructura de Internet.
gov: instituciones gubernamentales.
edu: instituciones educativas (generalmente universidades).
com: reservados a empresas para usos comerciales.
mil: instituciones militares.
org: organizaciones (aquellos no incluidos en los puntos anteriores).
Adicionalmente en el RFC 920 se aprob la creacin de TLDs siguiendo los cdigos de pas de dos letras del
estndar ISO-3166 de la ISO.
Posteriormente se aadieron los dominios net para usos relacionados con Internet e int creado para su uso
por instituciones internacionales a peticin de la OTAN que quera un TLD que reflejase su carcter
internacional y est gestionado directamente por la IANA.
 Inicialmente la creacin de los TLD estaba gestionada por la IANA aunque a finales de 1998 se cre
la ICANN (Internet Corporation for Assigned Names and Numbers) que en estos momentos gestiona la
creacin de TLDs, dejando al IANA nicamente la gestin tcnica de la infraestructura. Bajo la direccin de la
ICANN se crearon nuevos TLDs y se reorganiz la estructura de manera que actualmente existen cuatro tipos
de TLD:
Infraestructura:
Esta categora tiene un nico TLD, arpa y como se ha mencionado anteriormente se utiliza
exclusivamente para gestin de infraestructura y est gestionado por el IANA. El principal dominio de
segundo nivel debajo de arpa es in-addr que se utiliza para resolucin inversa de IPV4: obtener el
nombre de dominio correspondiente a una direccin IP.

Genricos (gTLD):
Son aquellos TLDs que estn abiertos a cualquier persona o organizacin, estos
son: biz, com, info, name, net, org y pro.

Patrocinados (sTLD):
Tambin conocidos como genricos patrocinados y con frecuencia incluidos en el grupo de los gTLD (el
ICANN suele considerar gTLD todos aquellos TLDs que no son de pas). Son aquellos TLDs que estn
gestionados por instituciones que controlan el acceso a ellos en base a un perfil determinado u
objetivos definidos y aceptados por el ICANN. Estos dominios
son: aero, asia, cat, coop, edu, gov, int, jobs, mil, mobi, museum, tel y travel.

Cdigo de pas (ccTLD):

Son aquellos TLDs que representan a pases, y, con la excepcin de Gran Bretaa que utiliza uk en vez
de gb, utilizan los cdigos de pas de dos letras definidos en estndar ISO-3166.
La creacin de nuevos ccTLD est regulada por el RFC 1591 el cual cita textualmente:
The IANA is not in the business of deciding what is and what is
not a country.

The selection of the ISO 3166 list as a basis for country code
top-level domain names was made with the knowledge that ISO has a
procedure for determining which entities should be and should not
be on that list.

Lo cual bsicamente significa que la IANA, que es la encargada de gestionar las altas de TLDs en los
servidores raz, utiliza el ISO-3166 como base para decidir la validez de una solicitud de alta y que una
vez un pas desaparece de dicho estndar sta inicia un proceso de transicin que finaliza en la baja
del TLD (como por ejemplo cs inicialmente asignado a Checoslovaquia, posteriormente a Serbia y
Montenegro y actualmente no asignado). En estos momentos estn en proceso de
eliminacin su (Unin Sovitica), tp (Timor Portugus) y yu (Yugoslavia).

Existen algunas restricciones en cuanto qu cadenas de texto pueden constituir un TLD:

El RFC 2606 se reservan varios TLDs para su uso en pruebas y documentacin, estos
son: test, example, invalid y localhost. Adicionalmente se reservan los dominios de segundo
nivel example.com, example.net y example.org.
El ICANN no acepta peticiones de gTLD y sTLD de nicamente una o dos letras, estas ltimas estn
reservadas para ccTLDs y, contrariamente a lo que mucha gente piensa, los dominios fm y tv no tienen
 ninguna relacin con la radio o la televisin sino que corresponden a los Estados Federados de Micronesia y
a Tuvalu respectivamente.
La IANA publica el listado de todos los TLDs disponibles en la zona raz as como informacin sobre las
entidades responsables de la gestin de las zonas:http://www.iana.org/domains/root/db.

En estos momentos el ICANN tiene dos procesos abiertos para la reforma de los TLDs:

Revisin del proceso de creacin de gTLDs denominado New gTLD Program, en el cual se revisa el
procedimiento para la creacin de nuevos gTLDs con el fin de flexibilizar el proceso y abrirlo a ms
organizaciones y entidades.
Internationalized Domain Names (IDN), definido en los RFC 3490, 3491 y 3492 permite la implementacin de
nombres de dominio internacionalizados utilizando UTF-8. En estos momentos la ICANN est trabajando para
la introduccin de IDN TLDs (especialmente IDN ccTLDs aunque tambin genricos).

En este punto ya entendemos la estructura de los dominios de primer nivel (TLD) pero estos dominios no son
los que las instituciones, empresas y personas utilizan para identificar sus dominios sino que forman el primer
nivel de delegacin desde la raz y estn agrupados por grupos de inters, pases o simplemente genricos.
Los usuarios finales (empresas, instituciones o personas individuales) generalmente utilizan dominios de
segundo nivel, excepto en algunos casos especiales de ccTLD que los gestores del dominio crean unos pocos
dominios de segundo nivel para propsitos especficos y comercializan los de tercer nivel, un ejemplo de ello
es uk en que la creacin de dominios de segundo nivel est fuertemente restringido (co.uk, org.uk, gov.uk,
etc...) y se comercializan los dominios de tercer nivel.

Para entender el proceso de creacin de dominios de segundo nivel es necesario introducir varios conceptos
nuevos:

Registry (Registro): es el repositorio autoritativo que contiene toda la informacin referente a un TLD, se
puede obtener una lista de todos los TLDs y los Registries en la web de la IANA. Estos son nicos para cada
TLD.
Registrant: se trata del cliente final, la persona o entidad que desea obtener un dominio de segundo nivel.
Aunque no es habitual, es posible para unRegistrant obtener una delegacin de su zona y gestionar
directamente toda la zona.
Registrar (Agente Registrador): es la entidad que hace de intermediario entre el cliente final (Registrant) y el
Registro, generalmente ofrece la opcin de gestionar la zona delegada correspondiente al dominio de
segundo nivel y otros servicios adicionales (gestin de correo, espacio web, etc...). Actan como
distribuidores de los TLD y generalmente existen mltiples Registradores para cada TLD.

As pues el proceso de obtencin de un dominio de segundo nivel generalmente se realiza a travs de un

agente registrador, el cual se encarga de dar el alta en el registro autoritativo para el TLD elegido y el
dominio puede ser gestionado por el agente registrador o a travs de una delegacin por el usuario final.

Qu es una zona de DNS?

Como hemos visto, el DNS es una base de datos jerrquica y distribuida, la jerarqua se basa en la utilizacin
de nombres de dominio que permiten delegar partes del rbol. En este punto debemos introducir el concepto
de zona que el RFC 1035 define como:
Una base de datos completa para un subarbol podado del espacio de dominios.
Cada zona est bajo una autoridad y puede delegar la gestin de una parte del rbol. El origen del rbol del
DNS contiene la zona raz que contiene las delegaciones para los TLDs. Cada TLD constituira a su vez una
zona del DNS, al igual que los dominios de segundo nivel y as sucesivamente. Cada una de estas zonas
puede estar bajo una autoridad distinta. Por ejemplo:

En este esquema podemos ver varios

niveles de la estructura del DNS, arriba
del todo, en el origen, est la zona raz,
que es gestionada por la ICANN y
contiene las delegaciones a las zonas de
los TLDs, estos contienen las
delegaciones de cada dominio (domain1,
domain2, etc...) los cuales constituyen
zonas independientes y as
sucesivamente con los subdominios.

Las zonas contienen informacin de los

recursos que componen esa zona y se
divide enRegistros de Recursos (RR) y
esta informacin se almacena en ficheros
de zona.

Registros de Recurso
Dentro de una zona se definen los Registros de Recurso (En ingls Resource Records y abreviado RR),
estos estn definidos en los RFC 1035 y 3596, los cuales describen cada uno de los elementos que
conforman la zona. Cada RR contiene la siguiente informacin:
Propietario
El dominio que contiene el RR.
Tipo
Es el tipo de registro que contiene el RR. Los ms comunes son:
A
Almacena una direccin IP, concretamente una direccin IPv4, asociada a un nombre.
AAAA
Almacena una direccin IP, concretamente una direccin IPv6, asociada a un nombre.
CNAME
Canonical Name, contiene un alias a un nombre de dominio, no se permite que un alias apunte a
otro, es decir, slo se permite un nivel de indireccin.
MX
Mail eXchanger, especifica el host donde est la pasarela de correo para un dominio y debe ser
un registro A, no estn permitidos CNAMEs dado que slo se permite un nivel de indireccin, se
pueden especificar varios indicando el nivel de prioridad, la prioridad es mayor cuanto menor es
el nmero. Este registro lo utilizan los servidores para de correo (SMTP) para encontrar la
pasarela de recepcin de correo para un dominio y es un elemento bsico de los sistemas de
correo.
 NS
Name Server, indica un servidor de nombres autoritativo para un dominio, estos servidores
deben ser nombres de host y, al igual que los registros MX, debe ser un registro A. Este registro
es el que permite establecer delegaciones de una parte del rbol hacia otros servidores, estas
delegaciones formarn nuevas zonas bajo una autoridad distinta.
PTR
Puntero de dominio, generalmente se utiliza en conjuncin con el dominio in-add.arpa para la
implementacin de resolucin inversa: convertir direcciones IP en nombres de dominio.
SOA
Start Of Authority, define el inicio de una zona de DNS, contiene informacin sobre ella: el
servidor que la contiene, direccin de correo del administrador, nmero de serie, TTL por
defecto, periodo de validez, etc...
Clase
El protocolo o la familia de protocolos a la que pertenece el registro, aunque existen varias clases la
nica que comnmente se utiliza es IN que referencia a direcciones de Internet, las otras son CH
(Chaos) y HS (Hesiod).
TTL
Time To Live, es el tiempo de vida del RR, determina durante cuanto tiempo un servidor haciendo
resoluciones recursivas puede cachear un RR.
RDATA
La informacin que contiene el RR, esta es dependiente del tipo de RR que est contenida y puede ser
una direccin IP, un nombre de dominio, un nombre de host, etc...

Ejemplos de RR (siguiendo el formato utilizado en los ficheros maestros de zona):

;Propietario TTL Clase Tipo RDATA

www.example.org. 172800 IN A 10.0.1.10
172800 IN A 10.0.1.11

example.org. 172800 IN NS 10.0.1.1

Si, como en el caso anterior, un registro no tiene propietario se asume que el propietario es el mismo que el
registro anterior.

Ficheros de zona (Ficheros

Maestros)
Las zonas se definen en los ficheros de zona, que se alojan en los servidores de DNS. Estos ficheros
deben tener un formato definido y est definido en elRFC 1035 y extendido en RFCs posteriores. Estos
ficheros se denominan Ficheros Maestros (Master Files)
Estos ficheros son ficheros de texto orientados a lnea aunque los contenidos de los parntesis se pueden
extender a varias lneas. Los ficheros de zona permiten la inclusin de comentarios, estos se inician con un ; y
terminan en el final de lnea. Los ficheros maestros contienen directivas y RR.

Se definen tres directivas de zona (Bind permite una cuarta, $GENERATE):

$ORIGIN
Define la base con la que se completan los nombres no cualificados, que son aquellos que no acaban
en un .. Los valores de $ORIGIN deben ser nombres cualificados (es decir que acaben en .) y que por
tanto convierten los nombres no cualificados en nombres cualificados cuando se aaden a ellos. El
valor de $ORIGIN se utiliza en el procesado del fichero para cualificar los nombres no cualificados y
para substituir las ocurrencias de @ por su valor.

El formato de la directiva es:

$ORIGIN example.org.
$INCLUDE
Permite la inclusin de un fichero externo que incluya directivas y registros de recursos. Como regla
general se debe suponer que no se pueden incluir directivas $INCLUDE dentro de ficheros incluidos.

El formato de la directiva es:

$INCLUDE <fichero> [nombre-de-dominio]

El nombre de dominio es opcional y si se indica se utilizar como $ORIGIN en el fichero incluido,

adicionalmente en el fichero incluido se pueden incluir directivas $ORIGIN.

$TTL
Time To Live, es el valor por defecto del campo de TTL en los RR, el cual indica el tiempo mximo que
un servidor de cache puede almacenar los RR. El TTL por defecto se utiliza en aquellos RR que no
tienen definido un TTL explcitamente. Si no se indica el TTL se define en segundos, aunque en la
mayor parte de servidores de DNS es posible indicarlo en otras unidades:
Horas: 1h es una hora o 3600 segundos
Das: 2d son dos das, es decir 172800 segundos
Semanas: 3w son 3 semanas o 1814400 segundos

Excepto en caso en los que se prevea que un dominio va a cambiar se recomienda utilizar valores de
TTL elevados, variando entre un da y varias semanas. En general es costumbre utilizar TTLs de dos
das (valor por defecto si no se indica), lo cual significa que los cambios tardan dos das en propagarse,
es posible tambin reducir ese valor cuando se prev un cambio a fin de reducir el periodo de
transicin.

El formato de la directiva es:

$TTL <tiempo>
$GENERATE
Se trata de una extensin del servidor de DNS Bind que sirve para la generacin se secuencias
repetitivas de RR, generalmente se utiliza para generar registros PTR.

El formato de la directiva es:

$GENERATE <lhs> <tipo> <rhs>

Ejemplo:

$ORIGIN 1.168.192.addr-in.arpa.
$GENERATE 1-127 $ PTR $.host.example.org.

Que genera:
 1.1.168.192.addr-in.arpa. IN PTR 1.host.example.org.
2.1.168.192.addr-in.arpa. IN PTR 2.host.example.org.
3.1.168.192.addr-in.arpa. IN PTR 3.host.example.org.
4.1.168.192.addr-in.arpa. IN PTR 4.host.example.org.
...
127.1.168.192.addr-in.arpa. IN PTR 127.host.example.org.

Los ficheros de zona siempre empiezan con la declaracin de las directivas $ORIGIN y $TTL y a
continuacin siempre va un registro de tipo SOA (Start Of Authority), en este registro se definen los
parmetros globales de la zona y slo debe haber un registro por zona. El formato de un registro SOA
es el siguiente:

;Nombre-zona TTL Clase RR Servidor-DNS Direccin-de-correo

example.org. 172800 IN SOA dns1.example.org. hostmaster.example.org. (
1 ; Nmero de serie
1d ; Refresco
1d ; Reintento
4w ; Caducidad
3h ; TTL mnimo
)
Nombre-zona
Es el nombre de la zona que contiene el fichero, se puede indicar tanto el nombre
cualificado (FQDN, de Fully Qualified Domain Name en ingls, y siempre acaba en un
punto) como una @ que se substituye por el valor $ORIGIN.
TTL
TTL del registro, si no se indica se utilizar el valor por defecto.
Clase
Familia de protocolos, siempre que estemos trabajando con direcciones de Internet IN.
RR
Registro, en este caso SOA.
Servidor-DNS
Servidor de DNS principal de la zona, debera ser el servidor que el administrador actualiza
y el que contiene la informacin autoritativa de la zona. Si el nombre no acaba en . se
completar con el contenido de $ORIGIN para obtener el FQDN.
Direccin-de-correo
Es la direccin de correo del administrador (generalmente el contacto tcnico) de la zona
substituyendo la @ por un .. Es costumbre utilizar la direccin de correo
hostmaster.example.org., que corresponde a hostmaster@example.org. En caso que la
direccin de correo tenga un punto en la parte de nombre de usuario (por ejemplo
host.master@example.org) se debe escapar este punto con
una \ (host\.master.example.org).
Nmero de serie
Es un nmero entero (entero de 32 bits sin signo) que se debe incrementar cada vez que
se modifica la zona. El RFC 1912 recomienda el formato YYYYMMDDnn que corresponde a
ao, mes, da y nmero de versin, de esta manera se consigue un nmero entero que se
incrementa en cada modificacin y adems indica la fecha en la que se realiz la ltima
modificacin.
Refresco
 Periodo de tiempo en segundos (entero de 32 bits) que indica la frecuencia con la que los
servidores secundarios deben actualizar la informacin desde el servidor primario.
Reintento
Periodo de tiempo en segundos (entero de 32 bits) que indica el tiempo que los servidores
secundarios deben esperar para actualizar la informacin desde el servidor primario
cuando un intento falla.
Caducidad
Periodo de tiempo (entero de 32 bits) a partir del cual la zona ya no es autoritativa. Este
valor se utiliza por los servidores secundarios para determinar el fin del periodo de validez
de la zona.
TTL mnimo
TTL mnimo (entero de 32 bits sin signo) que puede asignarse a los RR de la zona. Es
tambin el TTL recomendado por el RFC 2308 para las respuestas negativas (NXDOMAIN).

Dentro de una zona existen otros dos elementos fundamentales, los registros NS y MX:

Registros NS
Indican los servidores de nombres autoritativos para la zona, aunque tambin se utilizan
para realizar delegaciones, uno de ellos es el servidor primario, el servidor que contiene la
informacin original, y los servidores secundarios, que replican la informacin del primario.
El servidor primario adems utiliza estos RR como valores por defecto de a que servidores
se deben enviar notificaciones de cambio cuando la zona cambia.
Registros MX
Indican los gestores de correo para el dominio y son esenciales para el correcto
funcionamiento del protocolo de gestin de correo SMTP (Simple Mail Transfer Protocol).
Tienen la particularidad que el campo RDATA se compone de dos elementos, un entero de
16 bits indicando la prioridad (valores bajos indican una mayor prioridad) y un campo de
texto que contiene un nombre de dominio, este nombre de dominio debe ser un registro A
(o AAAA en caso de IPv6) y nunca debe ser un CNAME.

Este registro lo utiliza el protocolo SMTP para determinar los nombres de los servidores de
correo de manera que cuando un servidor SMTP debe entregar un correo a la direccin
usuario@example.org el servidor SMTP busca el registro MX de mayor prioridad para el
dominio example.org y le entrega el correo. Si este servidor no estuviese disponible
recurrir al servidor indicado por el registro MX de prioridad inmediatamente inferior y as
sucesivamente hasta encontrar un servidor SMTP activo o agotar los registros MX.

Ejemplo:

example.org. 172800 IN MX 10 mx1.example.org.

172800 IN MX 20 mx2.example.org.

En este caso el registro MX de mayor prioridad sera mx1.example.org y el secundario

mx2.example.org.

Ejemplo de fichero maestro de zona:

$ORIGIN example.org. ; Base del nombre de dominio de la zona, debe estar cualificado
(acaba en un punto)
$TTL 172800 ; TTL por defecto de la zona (2 das)
 @ IN SOA ns.example.org. hostmaster.example.org. (
2009101401 ; Nmero de serie (YYYYMMDDnn)
86400 ; Refresco (1d)
86400 ; Reintento (1d)
2419200 ; Caducidad (4w)
7200 ; TTL mnimo (2h)
)

IN NS ns.example.org. ; DNS primario, registro A que debe estar

definido en
; la zona
IN NS ns.example.net. ; DNS secundario, debe ser un registro A y est
definido
; en la zona example.net

IN MX 10 mx.example.org. ; Servidor de correo principal de la zona debe

estar
; definido en la zona y ser un
registro A
IN MX 20 mx.example.net. ; Servidor de correo secundario de la zona y
debe ser un registro
; A y debe estar definido en la
zona example.net

ns IN A 10.0.1.1 ; Definicin de ns.example.org, se utiliza el nombre no

; cualificado
; no acabado en punto (lo
cualifica el servidor aadiendo
; el valor de $ORIGIN)
mx 3600 IN A 10.0.1.2 ; Definicin de mx.example.org, se utiliza el nombre
no
; cualificado
Fuente: http://www.shenron.es/es/node/17