Source: https://www.scribd.com/document/66333357/Apuntes-Vii-DNS
Timestamp: 2018-03-21 20:59:48+00:00

Document:
Uploaded by Humanistas del Sur
El Domain Name System (DNS) o Sistema de Nombres de Dominio permite a los
usuarios de una red TCP/IP utilizar nombres jerárquicos y descriptivos para
localizar fácilmente ordenadores (hosts) y otros recursos en dicha red, evitando
de esta manera tener que recordar la dirección IP de cada ordenador al que se
desea acceder. En esencia, DNS es una base de datos distribuida que contiene
asociaciones de nombres simbólicos (de hosts) a direcciones IP. El hecho de
que sea distribuida permite delegar el control sobre diferentes segmentos de la
base de datos a distintas organizaciones, pero siempre de forma que los datos
de cada segmento están disponibles en toda la red, a través de un esquema
Los programas denominados servidores de nombres (name servers) constituyen
la parte servidora del esquema cliente-servidor. Los servidores de nombres
contienen información sobre algunos segmentos de la base de datos y los ponen
a disposición de los clientes, llamados solucionadores o resolvers.
La base de datos distribuida de DNS está indexada por nombres de dominio.
Cada nombre de dominio es esencialmente una trayectoria en un árbol invertido
denominado espacio de nombres de dominio. La estructura jerárquica del árbol
es similar a la estructura del sistema de ficheros UNIX. El árbol tiene una única
raíz en el nivel superior llamada raíz (root). Cada nodo del árbol puede
ramificarse en cualquier número de nodos de nivel inferior. La profundidad del
árbol está limitada a 127 niveles.
Cada nodo en el árbol se identifica mediante una etiqueta no nula que puede
contener hasta 63 caracteres, excepto el nodo raíz, identificado mediante una
etiqueta nula. El nombre de dominio completo de cualquier nodo está formado
por la secuencia de etiquetas que forman la trayectoria desde dicho nodo hasta
la raíz, separando cada etiqueta de la siguiente mediante un punto. De esta
forma, el nombre del nodo especifica de forma unívoca su localización en la
jerarquía. A este nombre de dominio completo o absoluto se le conoce como
nombre de dominio completamente cualificado o Fully Qualified Domain Name
(FQDN). Al ser nula la etiqueta que identifica el nodo raíz, el FQDN de cualquier
nodo del árbol siempre acaba con un punto. La única restricción que se impone
en el árbol de nombres es que los nodos hijos del mismo padre tengan etiquetas
En el esquema jerárquico de nombres DNS, se denomina dominio a cualquier
subárbol del espacio de nombres de dominio. De esta forma, cada dominio
puede contener, a su vez, otros dominios. Generalmente, los hosts están
representados por las hojas del árbol, aunque es posible nombrar a un host con
una etiqueta correspondiente a un nodo intermedio del árbol (en este caso,
tendríamos un dominio y un nodo que se llaman igual).
La información sobre los nombres de dominio DNS se guarda mediante los
denominados registros de recursos en los servidores DNS de la red.
Concretamente, cada servidor DNS contiene los registros de recursos
necesarios para responder a las consultas sobre la parte del espacio de nombres
en la que tiene autoridad.
El Espacio de Nombres de Dominio en Internet
El estándar DNS no impone muchas reglas sobre las etiquetas de los nombres
de dominio, ni tampoco asocia un significado determinado a las etiquetas de un
determinado nivel del espacio de nombres. Cuando manejamos una parte de
este espacio, podemos decidir el significado y la sintaxis de nuestros nombres de
dominio. Sin embargo, en el espacio de nombres Internet existente, se ha
impuesto una estructura de nombres bien definida, especialmente en los
Los dominios originales de primer nivel dividían originalmente el espacio de
nombres de Internet en siete dominios: com, edu, gov, mil, net, org, e int.
Posteriormente, para acomodar el crecimiento y la internacionalización de
Internet, se reservaron nuevos dominios de primer nivel que hacían referencia a
países individuales.
Actualmente, los dominios originales se denominan dominios de primer nivel
genéricos y han surgido nuevos nombres que se ajustan a los tiempos que
Es importante resaltar que el objetivo principal del diseño del sistema de
nombres de dominio fue su administración descentralizada. Este objetivo se
consigue a través de la delegación. La delegación de dominios funciona de
forma parecida a la delegación de tareas en una organización. Un responsable
de proyecto divide el proyecto en pequeñas tareas y asigna (delega) la
responsabilidad de las mismas a diferentes empleados.
De la misma forma, una organización que administra un dominio puede dividirla
en subdominios. Cada subdominio puede ser delegado a diferentes
organizaciones, lo cual implica que esa organización será responsable de
mantener los datos (registros de recursos) de ese subdominio. Esa organización
puede libremente cambiar los datos e incluso volver a dividir el dominio delegado
en subdominios y delegarlos. El dominio padre solamente contiene enlaces a los
responsables del subdominio delegado, de forma que pueda hacer referencia a
ellos cuando se le planteen consultas sobre nombres en dicho subdominio
Realmente, la subdivisión de un dominio en subdominios y la delegación de
dichos subdominios son cosas distintas. En primer lugar, un dominio que tenga
capacidad de autogestión (autoridad), siempre puede decidir subdividirse en
diferentes subdominios, manteniendo él en principio la autoridad sobre todos
ellos. Posteriormente, la organización que gestiona el dominio puede decidir
además delegar la autoridad de algunos (o todos) sus subdominios en otras
organizaciones. La delegación es una acción que siempre decide el dominio
padre, y éste puede revocarla cuando desee, volviendo a retomar la autoridad
sobre el subdominio que había delegado.
Como se ha dicho anteriormente, los programas que almacenan información
sobre el espacio de nombres de dominio se denominan servidores de nombres.
En virtud de la delegación mencionada anteriormente, cada servidor de nombres
posee generalmente información completa sobre una parte contigua del espacio
de nombres (generalmente un dominio, potencialmente dividido en subdominios).
Dicha parte del espacio se denomina zona, y se dice que el servidor de nombres
tiene autoridad sobre ella. En realidad, un mismo servidor de nombres puede
tener autoridad sobre múltiples zonas, y obtiene la información que describe la
zona (los registros de recursos) o bien de un fichero local o bien de otro servidor
Entender la diferencia entre una zona y un dominio es importante. Todos los
dominios de primer nivel, y la mayoría de dominios de segundo nivel, se dividen
en unidades más pequeñas y manejables gracias a la delegación. Estas
unidades se denominan zonas y contienen una serie de registros almacenados
en un servidor. Sin embargo, las zonas no son dominios. Un dominio es un
subárbol del espacio de nombres, mientras que una zona es una parte del
espacio de nombres DNS que se almacena generalmente en un fichero y que
puede contener informació sobre múltiples dominios.
DNS define dos tipos de servidores de nombres que mantienen informacion
sobre el espacio de nombres: primarios (maestros) y secundarios (esclavos). Un
servidor de nombres primario para una zona lee los datos de la zona desde un
fichero que él mantiene. Un servidor de nombres secundario para una zona
obtiene los datos de la zona desde otro servidor de nombres que es autoritario
para la zona, llamado servidor maestro. Normalmente el servidor maestro es el
servidor primario de la zona, pero esto no es un requisito ya que un servidor
secundario puede cargar los datos desde otro secundario.
Cuando un servidor de nombres secundario se inicia, éste se pone en contacto
con su servidor maestro y, si es necesario, inicia una transferencia de zona, es
decir, una actualización de su información sobre la zona (ver “Transferencias de
zona”). Además, periódicamente el servidor secundario contacta con el servidor
maestro para ver si los datos de zona han cambiado. Tanto el servidor primario
como el secundario poseen autoridad sobre la zona. Definir servidores
secundarios proporciona tolerancia a errores y reduce la carga en el servidor
primario de la zona.
Los clientes DNS utilizan bibliotecas llamadas solucionadores (resolvers) que
efectúan las consultas DNS a los servidores en nombre del cliente.
Los servidores de nombres son los expertos en obtener información del espacio
de nombres de dominio. Es decir, no solamente responden los datos referentes a
las zonas sobre los que tienen autoridad, sino que pueden también buscar
información a través del espacio de nombres de dominio para encontrar datos
sobre los que no son autoritarios. A este proceso se le denomina resolución de
nombres. Por ese motivo, existen servidores de nombres que no mantienen
información sobre ninguna zona, y únicamente sirven para responder consultas
de los clientes (resolvers) sobre cualquier dominio. Este tipo de servidores DNS
se denomina cache only.
Ya que el espacio de nombres está estructurado como un árbol invertido, un
servidor de nombres necesita únicamente los nombres de dominio y las
direcciones de los servidores de nombres raíz para encontrar cualquier punto en
el árbol. Los servidores raíz conocen dónde se encuentran los servidores de
nombres con autoridad para los dominios de primer nivel. De hecho, la mayoría
de servidores raíz son autoritarios para los dominios de primer nivel genéricos.
Cuando se solicita una consulta a cualquier nombre de dominio, los servidores
raíz pueden al menos proporcionar los nombres y direcciones de los servidores
de nombres autoritarios para el dominio de primer nivel al que pertenece el
nombre de dominio buscado. Y los servidores de nombres de primer nivel
pueden proporcionar la lista de servidores de nombres autoritarios para el
dominio de segundo nivel al que pertenece el nombre de dominio buscado. De
esta forma, cada servidor de nombres consultado va proporcionando la
información más próxima a la respuesta buscada, o proporciona la propia
Como conclusión hay que resaltar la importancia que tienen los servidores de
nombres raíz en el proceso de resolución. Por esta razón, el sistema de nombres
de dominio proporciona mecanismos de caché para ayudar a reducir la carga
que supondría el proceso de resolución sobre los servidores raíz. Si todos los
servidores raíz de Internet fallaran por un largo período de tiempo, toda la
resolución en Internet fallaría. Para protegerse, Internet posee 13 servidores de
nombres raíz repartidos por diferentes partes de la Red.
Los estándares de DNS no especifican la estructura de datos interna en que deben
almacenarse los registros de recursos (registros de la base de datos DNS), y por tanto
existen varias implementaciones que son diferentes en este sentido. Por regla general,
los servidores guardan la información sobre las zonas en ficheros en texto plano sin
formato. Los nombres de los archivos son arbitrarios y se especifican en la configuración
del servidor DNS.
Por ejemplo, en la implementación habitual de DNS en el mundo UNIX, BIND (Berkeley
Intenet Name Domain), se utiliza los nombres de archivo siguientes para almacenar los
registros de cada zona:
Db.dominio: zona de resolución directa.
Db.direccion: zona de resolución inversa.
Db.cache: sugerencias de servidores raíz.
Db.127.0.0.1: resolución inversa de bucle cerrado.
Por el contrario, la configuración predeterminada del servidor DNS de Microsoft Windows
2000 no utiliza los mismos nombres de archivo que BIND, sino que usa la nomenclatura
nombre_zona.dns. Por otra parte, en Windows 2000, la base de datos DNS puede
integrarse con la base de datos de Active Directory, en cuyo caso dicha información
participa de los mismos mecanismos de almacenamiento y replicación que el resto de
información contenida en el Directorio Activo.
Registros de Recursos (RR)
Para resolver nombres, los servidores consultan sus zonas. Las zonas contienen
registros de recursos que constituyen la información de recursos asociada al dominio
DNS. Por ejemplo, ciertos registros de recursos asignan nombres descriptivos a
El formato de cada registro de recursos es el siguiente:
Propietario TTL Clase Tipo RDATA
Propietario: nombre de host o del dominio DNS al que pertenece este recurso.
Puede contener un nombre de host/dominio (completamente cualificado o no), el
símbolo "@" (que representa el nombre de la zona que se está describiendo) o una
cadena vacía (en cuyo caso equivale al propietario del registro de recursos anterior).
TTL: (Time To Live) Tiempo de vida, generalmente expresado en segundos, que un
servidor DNS o un resolver debe guardar en caché esta entrada antes de
descartarla. Este campo es opcional. También se puede expresar mediante letras
indicando días (d), horas (h), minutos (m) y segundos (s). Por ejemplo: "2h30m".
Clase: define la familia de protocolos en uso. Suele ser siempre "IN", que representa
RDATA: los datos del registro de recursos.
A continuación se describen los principales tipos de registros de recursos: SOA, NS, A,
PTR, CNAME, MX y SRV.
Registro de Recurso SOA
Cada zona contiene un registro de recursos denominado Inicio de Autoridad o SOA
(Start Of Authority) al comienzo de la zona. Los registros SOA incluyen los siguientes
campos (sólo se incluyen los que poseen un significado específico para el tipo de
registro):
Propietario: nombre de dominio de la zona.
Tipo: "SOA".
Persona responsable: contiene la dirección de correo electrónico del responsable
de la zona. En esta dirección de correo, se utiliza un punto en el lugar del símbolo
"@".
Número de serie: muestra el número de versión de la zona, es decir, un número que
sirve de referencia a los servidores secundarios de la zona para saber cuándo deben
proceder a una actualización de su base de datos de la zona (o transferencia de
zona). Cuando el número de serie del servidor secundario sea menor que el número
del maestro, esto significa que el maestro ha cambiado la zona, y por tanto el
secundario debe solicitar al maestro una transferencia de zona. Por tanto, este
número debe ser incrementado (manualmente) por el administrador de la zona cada
vez que realiza un cambio en algún registro de la zona (en el servidor maestro).
Actualización: muestra cada cuánto tiempo un servidor secundario debe ponerse en
contacto con el maestro para comprobar si ha habido cambios en la zona.
Reintentos: define el tiempo que el servidor secundario, después de enviar una
solicitud de transferencia de zona, espera para obtener una respuesta del servidor
maestro antes de volverlo a intentar.
Caducidad: define el tiempo que el servidor secundario de la zona, después de la
transferencia de zona anterior, responderá a las consultas de la zona antes de
descartar la suya propia como no válida.
TTL mínimo: este campo especifica el tiempo de validez (o de vida) de las
respuestas "negativas" que realiza el servidor. Una respuesta negativa significa que
el servidor contesta que un registro no existe en la zona.
Hasta la versión 8.2 de BIND, este campo establecía el tiempo de vida por
defecto de todos los registros de la zona que no tuvieran un campo TTL
específico. A partir de esta versión, esto último se consigue con una directiva que
debe situarse al principio del fichero de la zona. Esta directiva se especifica así:
$TTL tiempo
Por ejemplo, un tiempo de vida por defecto de 30 minutos se establecería así:
$TTL 30m
Un ejemplo de registro SOA sería el siguiente:
admon.com. IN pc0100.admon.com hostmaster.admon.com.
1 ; número de serie
3600 ; actualización 1 hora
600 ; reintentar 10 minutos
86400 ; caducar 1 día
60 ; TTL 1 minuto
Registro de Recurso NS
El registro de recursos NS (Name Server) indica los servidores de nombres autorizados
para la zona. Cada zona debe contener registros indicando tanto los servidores
principales como los secundarios. Por tanto, cada zona debe contener, como mínimo, un
registro NS.
Por otra parte, estos registros también se utilizan para indicar quiénes son los servidores
de nombres con autoridad en subdominios delegados, por lo que la zona contendrá al
menos un registro NS por cada subdominio que haya delegado.
Ejemplos de registros NS serían los siguientes:
admon.com. IN NS pc0100.admon.com.
valencia.admon.com. IN NS pc0102.valencia.admon.com.
Registro de Recurso A
El tipo de registro de recursos A (Address) asigna un nombre de dominio completamente
cualificado (FQDN) a una dirección IP, para que los clientes puedan solicitar la dirección
IP de un nombre de host dado.
Un ejemplo de registro A que asignaría la dirección IP 158.42.178.1 al nombre de
dominio pc0101.valencia.admon.com., sería el siguiente:
pc0101.valencia.admon.com. IN A 158.42.178.1
Registro de Recurso PTR
El registro de recursos PTR (PoinTeR) o puntero, realiza la acción contraria al registro de
tipo A, es decir, asigna un nombre de dominio completamente cualificado a una dirección
IP. Este tipo de recursos se utilizan en la denominada resolución inversa, descrita en
“Servidores de nombres y zonas”.
Un ejemplo de registro PTR que asignaría el nombre pc0101.valencia.admon.com. a
la dirección IP 158.42.178.1 sería el siguiente:
1.178.42.158.in-addr.arpa. IN PTR pc0101.admon.valencia.com.
Registro de Recurso CNAME
El registro de nombre canónico (CNAME, Canonical NAME) crea un alias (un sinónimo)
para el nombre de dominio especificado.
Un ejemplo de registro CNAME que asignaría el alias controlador al nombre de
dominio pc0102.valencia.admon.com, sería el siguiente:
controlador.valencia.admon.com.
IN CNAME pc0101.valencia.admon.com.
Registro de Recurso MX
El registro de recurso de intercambio de correo (MX, Mail eXchange) especifica un
servidor de intercambio de correo para un nombre de dominio. Puesto que un mismo
dominio puede contener diferentes servidores de correo, el registro MX puede indicar un
valor numérico que permite especificar el orden en que los clientes deben intentar
contactar con dichos servidores de correo.
Un ejemplo de registro de recurso MX que define al servidor pc0100 como el servidor de
correo del dominio admon.com, sería el siguiente:
admon.com. IN MX 0 pc0100.admon.com.
Registro de Recurso SRV
Con registros MX se puede especificar varios servidores de correo en un dominio DNS.
De esta forma, cuando un proveedor de servicio de envío de correo necesite enviar
correo electrónico a un host en el dominio, podrá encontrar la ubicación de un servidor
de intercambio de correo. Sin embargo, esta no es la forma de resolver los servidores
que proporcionan otros servicios de red como WWW o FTP.
Los registros de recurso de servicio (SRV, SeRVice) permiten especificar de forma
genérica la ubicación de los servidores para un servicio, protocolo y dominio DNS
El formato de un registro SRV es el siguiente:
servicio.protocolo.nombre TTL clase SRV
prioridad peso puerto destino
El campo servicio especifica el nombre de servicio: http, telnet, etc.
El campo protocolo especifica el protocolo utilizado: TCP o UDP.
nombre define el nombre de dominio al que hace referencia el registro de recurso
Los campos TTL y clase ha sido definidos anteriormente.
prioridad especifica el orden en que los clientes se pondrán en contacto con los
servidores: los clientes intentarán ponerse en contacto primero con el host que tenga
el valor de prioridad más bajo, luego con el siguiente y así sucesivamente.
peso: es un mecanismo de equilibrio de carga.
puerto: muestra el puerto del servicio en el host.
destino: muestra el nombre de dominio completo para la máquina compatible con
Un ejemplo de registros SRV para los servidores Web del dominio admon.com., sería:
http.tcp.admon.com. IN SRV 0 0 80 www1.admon.com.
http.tcp.admon.com. IN SRV 10 0 80 www2.admon.com.
Definición de la delegación
Para que una zona especifique que uno de sus subdominios está delegado en una zona
diferente, es necesario agregar un registro de delegación y, generalmente, el
denominado "registro de pegado" (glue record). El registro de delegación es un registro
NS en la zona principal (padre) que define el servidor de nombres autorizado para la
zona delegada. El registro de pegado es un registro tipo A para el servidor de nombres
autorizado para la zona delegada, y es necesario cuando el servidor de nombres
autorizado para la zona delegada también es un miembro de ese dominio (delegado).
Por ejemplo, si la zona admon.com deseara delegar la autoridad a su subdominio
valencia.admon.com, se deberían agregar los siguientes registros al archivo de
configuración correspondiente de la zona admon.com:
pc0102.valencia.admon.com. IN A 158.42.178.2
Aunque distintas implementaciones de DNS difieren en cómo configurar las zonas,
generalmente existe un fichero que indica sobre qué zonas tiene autoridad el servidor,
indicando para cada una el fichero que contiene la información de dicha zona (si el
servidor es primario para la zona), o la dirección del servidor maestro a quien preguntar
por ella (si es secundario).
En general, existen tres tipos distintos de zonas: zonas de búsqueda directa, zonas de
búsqueda inversa y zonas de "sugerencia raíz". Un servidor DNS puede tener autoridad
sobre varias zonas directas e inversas, y necesita poseer información sobre las
"sugerencias raíz" si desea responder a sus clientes sobre registros de zonas sobre las
que no posee autoridad. A continuacion se describe cada tipo brevemente.
Las zonas de búsqueda directa contienen la información necesaria para resolver
nombres en el dominio DNS. Deben incluir, al menos, registros SOA y NS, y pueden
incluir cualquier otro tipo de registros de recurso, excepto el registro de recursos PTR.
Las zonas de búsqueda inversa contienen información necesaria para realizar las
búsquedas inversas. La mayor parte de las consultas proporcionan un nombre y solicitan
la dirección IP que corresponde a ese nombre. Este tipo de consulta es el descrito en la
zona de resolución directa.
Pero existen ocasiones en que un cliente ya tiene la dirección IP de un equipo y desea
determinar el nombre DNS de ese equipo. Esto es importante para los programas que
implementan la seguridad basándose en el FQDN que se conecta y también se utiliza
para la solución de problemas de red TCP/IP.
Si el único medio de resolver una búsqueda inversa es realizar una búsqueda detallada
de todos los dominios en el espacio de nombres DNS, la búsqueda de consulta inversa
sería demasiado exhaustiva como para realizarla de forma práctica.
Para solucionar este problema se creó un dominio DNS especial para realizar
búsquedas "inversas", denominado in-addr.arpa.. Este dominio utiliza un orden
inverso de números en la notación decimal de las direcciones IP. Con esta disposición
se puede delegar la autoridad de miembros inferiores del dominio in-addr.arpa. a las
distintas organizaciones, a medida que se les asigna identificadores de red de clase A, B
Sugerencias de los servidores del Dominio Raíz
El archivo de "sugerencias raíz" (root hint), denominado también archivo de sugerencias
de caché, contiene la información de host necesaria para resolver nombres fuera de los
dominios en los que el servidor posee autoridad. En concreto, este archivo contiene los
nombres y las direcciones IP de los servidores DNS del dominio punto (.) o raíz.
En aquellas zonas en las que existen diferentes servidores de nombres con autoridad
(uno principal o maestro y uno o varios secundarios o esclavos), cada vez que se
realizan cambios en la zona del servidor maestro, estos cambios deben replicarse a
todos los servidores secundarios de esa zona. Esta acción se lleva a cabo mediante un
mecanismo denominado transferencia de zona. Existen dos tipos de transferencia de
zonas: completa e incremental.
Transferencia completa de zona
En una transferencia completa de zona, el servidor maestro para una zona transmite
toda la base de datos de zona al servidor secundario para esa zona.
Los servidores secundarios siguen los siguientes pasos a la hora de realizar una
transferencia de zona:
El servidor secundario para la zona espera el tiempo especificado en el campo
Actualizar del registro SOA y luego le pregunta al servidor maestro por su registro
El servidor maestro responde con su registro SOA.
El servidor secundario para la zona compara el número de serie devuelto con su
propio número y si este es mayor que el suyo, solicita una transferencia de zona
El servidor maestro envía la base de datos de la zona completa al servidor
Si el servidor maestro no responde, el servidor secundario lo seguirá intentando después
del intervalo especificado en el campo Reintentos del registro SOA. Si todavía no hay
respuesta después del intervalo que se especifica en el campo Caduca desde la última
transferencia de zona, este descarta su zona.
Transferencia incremental de zona
Las transferencias completas de zona pueden consumir gran ancho de banda de la red.
Para poder solucionar este problema se define la transferencia incremental de zona, en
la cual sólo debe transferirse la parte modificada de una zona.
La transferencia incremental de zona funciona de forma muy similar a la transferencia
completa. En este caso, el servidor secundario para la zona comprueba el número de
serie del registro SOA del maestro con el suyo, para determinar si debe iniciar una
transferencia de zona, la cual en este caso sería incremental (sólo de los cambios
Notificación DNS
Con este proceso se pretende que el servidor maestro para la zona notifique los cambios
a ciertos servidores secundarios y de esta manera los secundarios podrán comprobar si
necesitan iniciar una transferencia de zona. De esta forma se mejora la coherencia de
los datos mantenida por todos los servidores secundarios.
Originalmente, DNS se diseñó para que solamente admitiera cambios estáticos. De esta
forma, sólo el administrador del sistema DNS podía agregar, quitar o modificar los
registros de recursos, realizando cambios manuales sobre los ficheros de configuración
El sistema de actualizaciones dinámicas, permite que el servidor principal para la zona
pueda configurarse de forma que acepte actualizaciones de recursos enviadas desde
otros equipos (habitualmente, sus clientes DNS). Este es el sistema preferido en el caso
de Windows 2000.
Por ejemplo, el servidor maestro puede admitir (e incluir en su configuración)
actualizaciones de registros A y PTR de las estaciones de trabajo de su dominio, que le
envían esa información cuando arrancan. También sería posible recibir estas
actualizaciones de un servidor DHCP, una vez ha proporcionado la configuración IP a un
de forma que pueda hacer referencia a ellos cuando se le planteen consultas sobre nombres en dicho subdominio delegado. siempre puede decidir subdividirse en diferentes subdominios. Posteriormente. una organización que administra un dominio puede dividirla en subdominios. Posteriormente. org. En primer lugar. Realmente. Este objetivo se consigue a través de la delegación. Concretamente. la subdivisión de un dominio en subdominios y la delegación de dichos subdominios son cosas distintas. net. podemos decidir el significado y la sintaxis de nuestros nombres de dominio. Esa organización puede libremente cambiar los datos e incluso volver a dividir el dominio delegado en subdominios y delegarlos. se ha impuesto una estructura de nombres bien definida. para acomodar el crecimiento y la internacionalización de Internet. un dominio que tenga capacidad de autogestión (autoridad). Es importante resaltar que el objetivo principal del diseño del sistema de nombres de dominio fue su administración descentralizada. La delegación de dominios funciona de forma parecida a la delegación de tareas en una organización. El dominio padre solamente contiene enlaces a los responsables del subdominio delegado. la organización que gestiona el dominio puede decidir además delegar la autoridad de algunos (o todos) sus subdominios en otras 2 .La información sobre los nombres de dominio DNS se guarda mediante los denominados registros de recursos en los servidores DNS de la red. mil. especialmente en los dominios de primer nivel. De la misma forma. gov. ni tampoco asocia un significado determinado a las etiquetas de un determinado nivel del espacio de nombres. El estándar DNS no impone muchas reglas sobre las etiquetas de los nombres de dominio. Los dominios originales de primer nivel dividían originalmente el espacio de nombres de Internet en siete dominios: com. en el espacio de nombres Internet existente. se reservaron nuevos dominios de primer nivel que hacían referencia a países individuales. Cada subdominio puede ser delegado a diferentes organizaciones. edu. Un responsable de proyecto divide el proyecto en pequeñas tareas y asigna (delega) la responsabilidad de las mismas a diferentes empleados. Actualmente. cada servidor DNS contiene los registros de recursos necesarios para responder a las consultas sobre la parte del espacio de nombres en la que tiene autoridad. lo cual implica que esa organización será responsable de mantener los datos (registros de recursos) de ese subdominio. manteniendo él en principio la autoridad sobre todos ellos. Sin embargo. Cuando manejamos una parte de este espacio. e int. los dominios originales se denominan dominios de primer nivel genéricos y han surgido nuevos nombres que se ajustan a los tiempos que corren.
cada servidor de nombres posee generalmente información completa sobre una parte contigua del espacio de nombres (generalmente un dominio. Entender la diferencia entre una zona y un dominio es importante. Cuando un servidor de nombres secundario se inicia. En virtud de la delegación mencionada anteriormente. mientras que una zona es una parte del espacio de nombres DNS que se almacena generalmente en un fichero y que puede contener informació sobre múltiples dominios. llamado servidor maestro. Definir servidores secundarios proporciona tolerancia a errores y reduce la carga en el servidor primario de la zona. y la mayoría de dominios de segundo nivel. Un servidor de nombres secundario para una zona obtiene los datos de la zona desde otro servidor de nombres que es autoritario para la zona. no solamente responden los datos referentes a 3 . Todos los dominios de primer nivel. Un dominio es un subárbol del espacio de nombres. éste se pone en contacto con su servidor maestro y. un mismo servidor de nombres puede tener autoridad sobre múltiples zonas. y éste puede revocarla cuando desee. Los servidores de nombres son los expertos en obtener información del espacio de nombres de dominio. La delegación es una acción que siempre decide el dominio padre. Como se ha dicho anteriormente. Normalmente el servidor maestro es el servidor primario de la zona. En realidad. Un servidor de nombres primario para una zona lee los datos de la zona desde un fichero que él mantiene. los programas que almacenan información sobre el espacio de nombres de dominio se denominan servidores de nombres. Tanto el servidor primario como el secundario poseen autoridad sobre la zona. inicia una transferencia de zona.organizaciones. Sin embargo. periódicamente el servidor secundario contacta con el servidor maestro para ver si los datos de zona han cambiado. DNS define dos tipos de servidores de nombres que mantienen informacion sobre el espacio de nombres: primarios (maestros) y secundarios (esclavos). Estas unidades se denominan zonas y contienen una serie de registros almacenados en un servidor. Dicha parte del espacio se denomina zona. potencialmente dividido en subdominios). y se dice que el servidor de nombres tiene autoridad sobre ella. Además. Es decir. las zonas no son dominios. si es necesario. se dividen en unidades más pequeñas y manejables gracias a la delegación. volviendo a retomar la autoridad sobre el subdominio que había delegado. una actualización de su información sobre la zona (ver “Transferencias de zona”). pero esto no es un requisito ya que un servidor secundario puede cargar los datos desde otro secundario. Los clientes DNS utilizan bibliotecas llamadas solucionadores (resolvers) que efectúan las consultas DNS a los servidores en nombre del cliente. es decir. y obtiene la información que describe la zona (los registros de recursos) o bien de un fichero local o bien de otro servidor de nombres.
Cuando se solicita una consulta a cualquier nombre de dominio. y por tanto existen varias implementaciones que son diferentes en este sentido. Db. sino que pueden también buscar información a través del espacio de nombres de dominio para encontrar datos sobre los que no son autoritarios. Como conclusión hay que resaltar la importancia que tienen los servidores de nombres raíz en el proceso de resolución. en la implementación habitual de DNS en el mundo UNIX. los servidores raíz pueden al menos proporcionar los nombres y direcciones de los servidores de nombres autoritarios para el dominio de primer nivel al que pertenece el nombre de dominio buscado. o proporciona la propia respuesta. Por ese motivo. existen servidores de nombres que no mantienen información sobre ninguna zona. Este tipo de servidores DNS se denomina cache only. Internet posee 13 servidores de nombres raíz repartidos por diferentes partes de la Red. 4 . Los nombres de los archivos son arbitrarios y se especifican en la configuración del servidor DNS.las zonas sobre los que tienen autoridad. Por esta razón. y únicamente sirven para responder consultas de los clientes (resolvers) sobre cualquier dominio. BIND (Berkeley Intenet Name Domain).direccion: zona de resolución inversa. los servidores guardan la información sobre las zonas en ficheros en texto plano sin formato. Por regla general. el sistema de nombres de dominio proporciona mecanismos de caché para ayudar a reducir la carga que supondría el proceso de resolución sobre los servidores raíz. Ya que el espacio de nombres está estructurado como un árbol invertido. Los estándares de DNS no especifican la estructura de datos interna en que deben almacenarse los registros de recursos (registros de la base de datos DNS). la mayoría de servidores raíz son autoritarios para los dominios de primer nivel genéricos. De hecho. un servidor de nombres necesita únicamente los nombres de dominio y las direcciones de los servidores de nombres raíz para encontrar cualquier punto en el árbol. Los servidores raíz conocen dónde se encuentran los servidores de nombres con autoridad para los dominios de primer nivel. A este proceso se le denomina resolución de nombres.dominio: zona de resolución directa. toda la resolución en Internet fallaría. Por ejemplo. Si todos los servidores raíz de Internet fallaran por un largo período de tiempo. Para protegerse. cada servidor de nombres consultado va proporcionando la información más próxima a la respuesta buscada. De esta forma. Y los servidores de nombres de primer nivel pueden proporcionar la lista de servidores de nombres autoritarios para el dominio de segundo nivel al que pertenece el nombre de dominio buscado. se utiliza los nombres de archivo siguientes para almacenar los registros de cada zona: Db.
Los registros SOA incluyen los siguientes 5 . RDATA: los datos del registro de recursos.Db. Este campo es opcional. minutos (m) y segundos (s). Puede contener un nombre de host/dominio (completamente cualificado o no). Clase: define la familia de protocolos en uso.cache: sugerencias de servidores raíz. Por ejemplo: "2h30m".0. Db. que un servidor DNS o un resolver debe guardar en caché esta entrada antes de descartarla. Suele ser siempre "IN". Registro de Recurso SOA Cada zona contiene un registro de recursos denominado Inicio de Autoridad o SOA (Start Of Authority) al comienzo de la zona. Tipo: identifica el tipo de registro. la base de datos DNS puede integrarse con la base de datos de Active Directory. sino que usa la nomenclatura nombre_zona. CNAME. También se puede expresar mediante letras indicando días (d).1: resolución inversa de bucle cerrado. Para resolver nombres. horas (h). El formato de cada registro de recursos es el siguiente: Propietario TTL Clase Tipo RDATA donde: Propietario: nombre de host o del dominio DNS al que pertenece este recurso. Las zonas contienen registros de recursos que constituyen la información de recursos asociada al dominio DNS. MX y SRV. A continuación se describen los principales tipos de registros de recursos: SOA. los servidores consultan sus zonas. TTL: (Time To Live) Tiempo de vida. Por otra parte. ciertos registros de recursos asignan nombres descriptivos a direcciones IP. en cuyo caso dicha información participa de los mismos mecanismos de almacenamiento y replicación que el resto de información contenida en el Directorio Activo.127. NS. la configuración predeterminada del servidor DNS de Microsoft Windows 2000 no utiliza los mismos nombres de archivo que BIND. en Windows 2000. generalmente expresado en segundos. que representa Internet. A. Por ejemplo.dns.0. PTR. Por el contrario. el símbolo "@" (que representa el nombre de la zona que se está describiendo) o una cadena vacía (en cuyo caso equivale al propietario del registro de recursos anterior).
esto último se consigue con una directiva que debe situarse al principio del fichero de la zona. un tiempo de vida por defecto de 30 minutos se establecería así: $TTL 30m Un ejemplo de registro SOA sería el siguiente: 6 . Actualización: muestra cada cuánto tiempo un servidor secundario debe ponerse en contacto con el maestro para comprobar si ha habido cambios en la zona. Cuando el número de serie del servidor secundario sea menor que el número del maestro. Una respuesta negativa significa que el servidor contesta que un registro no existe en la zona. Hasta la versión 8.2 de BIND. Caducidad: define el tiempo que el servidor secundario de la zona. Esta directiva se especifica así: $TTL tiempo Por ejemplo. esto significa que el maestro ha cambiado la zona. A partir de esta versión. después de la transferencia de zona anterior. se utiliza un punto en el lugar del símbolo "@". Reintentos: define el tiempo que el servidor secundario. es decir. TTL mínimo: este campo especifica el tiempo de validez (o de vida) de las respuestas "negativas" que realiza el servidor. En esta dirección de correo. después de enviar una solicitud de transferencia de zona. Tipo: "SOA". Persona responsable: contiene la dirección de correo electrónico del responsable de la zona. este campo establecía el tiempo de vida por defecto de todos los registros de la zona que no tuvieran un campo TTL específico.campos (sólo se incluyen los que poseen un significado específico para el tipo de registro): Propietario: nombre de dominio de la zona. un número que sirve de referencia a los servidores secundarios de la zona para saber cuándo deben proceder a una actualización de su base de datos de la zona (o transferencia de zona). responderá a las consultas de la zona antes de descartar la suya propia como no válida. Número de serie: muestra el número de versión de la zona. este número debe ser incrementado (manualmente) por el administrador de la zona cada vez que realiza un cambio en algún registro de la zona (en el servidor maestro). espera para obtener una respuesta del servidor maestro antes de volverlo a intentar. Por tanto. y por tanto el secundario debe solicitar al maestro una transferencia de zona.
admon.valencia.com.42. Un ejemplo de registro A que asignaría la dirección IP 158. Cada zona debe contener registros indicando tanto los servidores principales como los secundarios. IN pc0100. como mínimo. un registro NS. estos registros también se utilizan para indicar quiénes son los servidores de nombres con autoridad en subdominios delegados. número de serie . Ejemplos de registros NS serían los siguientes: admon. reintentar 10 minutos . valencia. cada zona debe contener.com.com ( 1 3600 600 86400 60 ) hostmaster. IN Registro de Recurso A El tipo de registro de recursos A (Address) asigna un nombre de dominio completamente cualificado (FQDN) a una dirección IP.valencia..admon.com. TTL 1 minuto Registro de Recurso NS El registro de recursos NS (Name Server) indica los servidores de nombres autorizados para la zona.admon.admon. .com. Por tanto. IN NS NS pc0100.1 al nombre de dominio pc0101. actualización 1 hora .admon. para que los clientes puedan solicitar la dirección IP de un nombre de host dado.admon. caducar 1 día . por lo que la zona contendrá al menos un registro NS por cada subdominio que haya delegado. pc0102.com. Por otra parte.admon.com. sería el siguiente: 7 .178.com.
valencia.admon.valencia. Canonical NAME) crea un alias (un sinónimo) para el nombre de dominio especificado. asigna un nombre de dominio completamente cualificado a una dirección IP.178.com. Este tipo de recursos se utilizan en la denominada resolución inversa. Un ejemplo de registro PTR que asignaría el nombre pc0101.178.com.42.1 sería el siguiente: 1.admon. Mail eXchange) especifica un servidor de intercambio de correo para un nombre de dominio. el registro MX puede indicar un valor numérico que permite especificar el orden en que los clientes deben intentar contactar con dichos servidores de correo.admon. sería el siguiente: controlador.com.com.158.admon. Puesto que un mismo dominio puede contener diferentes servidores de correo.in-addr.valencia. Un ejemplo de registro CNAME que asignaría el alias controlador al nombre de dominio pc0102. 8 .valencia. sería el siguiente: admon.admon. IN PTR pc0101.com. descrita en “Servidores de nombres y zonas”. IN A 158. a la dirección IP 158.42. Registro de Recurso CNAME El registro de nombre canónico (CNAME.valencia.com.1 Registro de Recurso PTR El registro de recursos PTR (PoinTeR) o puntero.178. realiza la acción contraria al registro de tipo A.42.pc0101.valencia.admon.com.com. es decir. IN MX 0 pc0100. Un ejemplo de registro de recurso MX que define al servidor pc0100 como el servidor de correo del dominio admon. Registro de Recurso MX El registro de recurso de intercambio de correo (MX.admon. IN CNAME pc0101.com.arpa.
IN IN SRV SRV 0 10 0 0 80 80 www1. De esta forma. puerto: muestra el puerto del servicio en el host. El campo protocolo especifica el protocolo utilizado: TCP o UDP. cuando un proveedor de servicio de envío de correo necesite enviar correo electrónico a un host en el dominio.admon. prioridad especifica el orden en que los clientes se pondrán en contacto con los servidores: los clientes intentarán ponerse en contacto primero con el host que tenga el valor de prioridad más bajo.com.tcp.admon. El formato de un registro SRV es el siguiente: servicio. 9 . protocolo y dominio DNS determinados. destino: muestra el nombre de dominio completo para la máquina compatible con ese servicio.admon. luego con el siguiente y así sucesivamente. nombre define el nombre de dominio al que hace referencia el registro de recurso Los campos TTL y clase ha sido definidos anteriormente.com. etc.com.nombre TTL clase SRV peso puerto destino prioridad donde: El campo servicio especifica el nombre de servicio: http.protocolo.Registro de Recurso SRV Con registros MX se puede especificar varios servidores de correo en un dominio DNS. sería: http. telnet. Sin embargo.com.com. www2. SeRVice) permiten especificar de forma genérica la ubicación de los servidores para un servicio. Los registros de recurso de servicio (SRV. Un ejemplo de registros SRV para los servidores Web del dominio admon. podrá encontrar la ubicación de un servidor de intercambio de correo. SRV. http.. esta no es la forma de resolver los servidores que proporcionan otros servicios de red como WWW o FTP. peso: es un mecanismo de equilibrio de carga.tcp.admon.
IN NS A pc0102.42. y es necesario cuando el servidor de nombres autorizado para la zona delegada también es un miembro de ese dominio (delegado). y necesita poseer información sobre las "sugerencias raíz" si desea responder a sus clientes sobre registros de zonas sobre las que no posee autoridad. Esto es importante para los programas que 10 . al menos. La mayor parte de las consultas proporcionan un nombre y solicitan la dirección IP que corresponde a ese nombre.com: valencia. A continuacion se describe cada tipo brevemente.admon. generalmente existe un fichero que indica sobre qué zonas tiene autoridad el servidor. Por ejemplo.valencia. Deben incluir.valencia. 158. indicando para cada una el fichero que contiene la información de dicha zona (si el servidor es primario para la zona).com. Zona de búsqueda directa Las zonas de búsqueda directa contienen la información necesaria para resolver nombres en el dominio DNS. excepto el registro de recursos PTR. IN ! Aunque distintas implementaciones de DNS difieren en cómo configurar las zonas.Para que una zona especifique que uno de sus subdominios está delegado en una zona diferente. Pero existen ocasiones en que un cliente ya tiene la dirección IP de un equipo y desea determinar el nombre DNS de ese equipo. es necesario agregar un registro de delegación y. existen tres tipos distintos de zonas: zonas de búsqueda directa. el denominado "registro de pegado" (glue record). registros SOA y NS. El registro de pegado es un registro tipo A para el servidor de nombres autorizado para la zona delegada.178.2 pc0102. o la dirección del servidor maestro a quien preguntar por ella (si es secundario).com. y pueden incluir cualquier otro tipo de registros de recurso.com.com. zonas de búsqueda inversa y zonas de "sugerencia raíz". Zona de búsqueda inversa Las zonas de búsqueda inversa contienen información necesaria para realizar las búsquedas inversas. si la zona admon.admon. se deberían agregar los siguientes registros al archivo de configuración correspondiente de la zona admon. Este tipo de consulta es el descrito en la zona de resolución directa.admon. El registro de delegación es un registro NS en la zona principal (padre) que define el servidor de nombres autorizado para la zona delegada. Un servidor DNS puede tener autoridad sobre varias zonas directas e inversas.admon.com deseara delegar la autoridad a su subdominio valencia. En general. generalmente.
el servidor maestro para una zona transmite toda la base de datos de zona al servidor secundario para esa zona.arpa. Para solucionar este problema se creó un dominio DNS especial para realizar búsquedas "inversas". a las distintas organizaciones. Esta acción se lleva a cabo mediante un mecanismo denominado transferencia de zona. Transferencia completa de zona En una transferencia completa de zona.. contiene la información de host necesaria para resolver nombres fuera de los dominios en los que el servidor posee autoridad. Existen dos tipos de transferencia de zonas: completa e incremental. B o C. 11 .arpa. El servidor secundario para la zona compara el número de serie devuelto con su propio número y si este es mayor que el suyo. Los servidores secundarios siguen los siguientes pasos a la hora de realizar una transferencia de zona: El servidor secundario para la zona espera el tiempo especificado en el campo Actualizar del registro SOA y luego le pregunta al servidor maestro por su registro SOA. denominado también archivo de sugerencias de caché. El servidor maestro envía la base de datos de la zona completa al servidor secundario.) o raíz. solicita una transferencia de zona completa. denominado in-addr. En concreto. Sugerencias de los servidores del Dominio Raíz El archivo de "sugerencias raíz" (root hint).implementan la seguridad basándose en el FQDN que se conecta y también se utiliza para la solución de problemas de red TCP/IP. a medida que se les asigna identificadores de red de clase A. ! En aquellas zonas en las que existen diferentes servidores de nombres con autoridad (uno principal o maestro y uno o varios secundarios o esclavos). este archivo contiene los nombres y las direcciones IP de los servidores DNS del dominio punto (. Si el único medio de resolver una búsqueda inversa es realizar una búsqueda detallada de todos los dominios en el espacio de nombres DNS. la búsqueda de consulta inversa sería demasiado exhaustiva como para realizarla de forma práctica. Este dominio utiliza un orden inverso de números en la notación decimal de las direcciones IP. Con esta disposición se puede delegar la autoridad de miembros inferiores del dominio in-addr. El servidor maestro responde con su registro SOA. estos cambios deben replicarse a todos los servidores secundarios de esa zona. cada vez que se realizan cambios en la zona del servidor maestro.
En este caso. en la cual sólo debe transferirse la parte modificada de una zona. También sería posible recibir estas actualizaciones de un servidor DHCP. quitar o modificar los registros de recursos. el servidor secundario lo seguirá intentando después del intervalo especificado en el campo Reintentos del registro SOA. Notificación DNS Con este proceso se pretende que el servidor maestro para la zona notifique los cambios a ciertos servidores secundarios y de esta manera los secundarios podrán comprobar si necesitan iniciar una transferencia de zona. Para poder solucionar este problema se define la transferencia incremental de zona. De esta forma. Transferencia incremental de zona Las transferencias completas de zona pueden consumir gran ancho de banda de la red. que le envían esa información cuando arrancan.Si el servidor maestro no responde. realizando cambios manuales sobre los ficheros de configuración correspondientes. De esta forma se mejora la coherencia de los datos mantenida por todos los servidores secundarios. este descarta su zona. sus clientes DNS). DNS se diseñó para que solamente admitiera cambios estáticos. una vez ha proporcionado la configuración IP a un cliente. La transferencia incremental de zona funciona de forma muy similar a la transferencia completa. El sistema de actualizaciones dinámicas. 12 . para determinar si debe iniciar una transferencia de zona. " # Originalmente. Este es el sistema preferido en el caso de Windows 2000. permite que el servidor principal para la zona pueda configurarse de forma que acepte actualizaciones de recursos enviadas desde otros equipos (habitualmente. Por ejemplo. el servidor maestro puede admitir (e incluir en su configuración) actualizaciones de registros A y PTR de las estaciones de trabajo de su dominio. sólo el administrador del sistema DNS podía agregar. el servidor secundario para la zona comprueba el número de serie del registro SOA del maestro con el suyo. Si todavía no hay respuesta después del intervalo que se especifica en el campo Caduca desde la última transferencia de zona. la cual en este caso sería incremental (sólo de los cambios realizados).
Documents Similar To Apuntes- Vii DNS
Siete portadas de periódicos recogen la movilización protesta de la red española Grubby Info Regarding Programa Gestión stock Gratis Divulged.20130218.042007
LC4_Seguridad de Redes II
Propiedad Intelectual Nombres de Dominio
60054628 Manual Zentyal
10. Internet Generalidades
Configuración de Un Servidor DNS
FixComandosWS8
Implementación de Cuentas de Usuario, Grupo y Equipo.odt
Instalar y Configurar Servidor DNS en Windows Server 2003
Autodiagnostico-admon-v1
Ethernet22010
nombrededominio-090711041455-phpapp01
Serie P660H HW W-T Guia de Usuario

References: resolución 
 resolución 

resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución