CAPTULO 1 INTRODUCCIN A DNS

CAPTULO 1
Introduccin a DNS
El Internet o cualquier red para el caso-obras de la asignacin de una nica IP local o
globalmente frente a cada punto final (host, servidor, router, interfaz, etc.). Pero sin la
capacidad de asignar un nombre que corresponde a cada recurso, cada vez que queremos
acceder a un recurso disponible en el red, el sitio web para www.example.com ejemplo, sera
necesario conocer su direccin IP fsica, tales como 192.168.34.166. Con cientos de millones
de los ejrcitos y ms de 200 millones de sitios web, se trata de una tarea imposible. Tambin
es bastante difcil, incluso con un puado de los ejrcitos y de los recursos.
Para resolver este problema, el concepto de servidores de nombres fue creado a mediados de
los aos 1970 para permitir ciertos atributos (o propiedades) de un recurso con nombre, en
este caso la direccin IP de www.example.com puede ser mantenido en un lugar conocido,
la idea bsica es que las personas les resulta mucho ms fcil de recordar el nombre de algo,
especialmente cuando ese nombre sea razonablemente descriptivo de la funcin, el
contenido, o propsito en lugar de una direccin numrica. Este captulo presenta los
conceptos bsicos del servidor de nombres y proporciona un poco de historia sobre la
evolucin del sistema de nombres de dominio de una herramienta que se utiliza para la
gestin de unos pocos cientos de hosts para una utilidad global responsable de mantener el
buen funcionamiento de toda la moderna Internet.
Una breve historia de los servidores de nombres
El problema de la conversin de nombres a direcciones fsicas es tan antigua como las redes
de computadoras. Incluso en tiempos desde hace mucho tiempo pasado, las personas
encuentran ms fcil recordar que estaban usando un dispositivo teletipo llamado "tty2" ms
que "el puerto 57 de la MCCU", o cualquiera que sea el mtodo de direccionamiento
entonces en uso. Por otra parte, administradores queran la flexibilidad para volver a
configurar el equipo, dejando a los usuarios una forma consistente de describir el dispositivo
que estaban usando. En el ejemplo anterior, el usuario podra seguir utilizando "tty2" incluso
si el dispositivo haba sido reconfigurado para estar en el puerto 23 de la mtica MCCU.
Configuracin sencilla archivos se utilizan normalmente para realizar la traduccin de
direcciones. Como trabajo en red, en lugar de simples comunicaciones, surgieron en la
dcada de 1970, el problema se agudiz. Red del sistema de IBM Architecture (SNA),
probablemente el abuelo de las redes, contena un mainframe rudimentaria base de datos para
su traduccin nombre cuando public originalmente en 1974. Los sistemas abiertos tan
vilipendiados Interconnect (OSI) Modelo, desarrollado por la Organizacin Internacional de
Normalizacin (ISO- www.iso.org), de los servicios de direccin / Nombre de traducciones
multados en la capa de transporte (Capa 4) cuando inicialmente publicado en 1978. NetBIOS
proporcion el NetBIOS Name Server (NBNS) cuando se defini originalmente en 1984, que
ms tarde morphed en Windows Internet Naming Service de Microsoft (WINS).
La primera ARPANET (la red que se transform en Internet) RFC, la Solicitud curiosamente
llamado Para comentarios que documentan y estandarizan Internet, sobre el concepto de las
fechas de los nombres de dominio desde 1981 (RFC 799), y las especificaciones definitivas
para Nombres de Dominio de Sistema de Internet como nos s que hoy se publicaron en 1987
(RFC 1034 y RFC 1035).

Conceptos bsicos Nombre del Servidor

Cuando un servidor de nombres est presente en una red, cualquier host slo necesita saber
la direccin fsica de un nombre servidor y el nombre del recurso, un sitio web, por ejemplo,
se desea acceder. Usando esta informacin, se puede encontrar la direccin (o cualquier otro
atributo o propiedad almacenado) del recurso interrogando (Comnmente referido como
consulta) el servidor de nombres. Los recursos pueden ser aadidos, movidos, cambiados, o
eliminados en un solo lugar, el servidor de nombres, y la nueva informacin estar de
inmediato a disposicin de todos los acogen el uso de este servidor de nombres. Nuestro
servidor de nombres es simplemente una base de datos especializada que traduce los
nombres de propiedades-tpicamente direcciones IP-y viceversa. Nombre servidores
tanto simplificar la gestin de la red y hacer que las redes sea ms dinmico y sensible a los
cambios.
Soluciones, sin embargo, tambin pueden generar problemas. Si nuestro servidor de nombres
no est disponible, entonces nuestro anfitrin no se puede acceder a cualquier recurso de la
red. Hemos hecho el servidor de nombres de un recurso crtico. As que sera mejor
tener ms de un servidor de nombres en caso de fallo.
La solucin inicial al problema de la disponibilidad del servidor de nombres era introducir
Servidores de nombres primarios y secundarios. Si el servidor de nombres primario no
respondi a una consulta, el anfitrin reintenta utilizando el servidor de nombres secundario.
As de crtico es el servidor de nombres que hoy en da es comn ver las listas de tres, cuatro,
o ms servidores de nombres. Los trminos servidores de nombres Primarios y secundarios,
e incluso terciarios, y servidores de nombres cuaternarios, mientras que sigue siendo
ampliamente utilizado, implica prioridad de acceso, lo que va en contra de disponibilidad.
No slo dicha transaccin causa priorizacin agrupamiento en el servidor de nombres
primarios, degrada el rendimiento general, pero en el caso en que el servidor de
nombres primario era inoperable, cada transaccin tendra que esperar un tiempo de
espera antes de reintentar la secundaria, y as sucesivamente. La mayora software de
Nombre servidor utiliza alguna forma de, tiempo de respuesta medido aleatorio o el acceso
de todos contra todos a la lista de servidor de nombres para tratar de difundir las cargas y
disminuir los tiempos de respuesta.
A medida que nuestra red crece, comenzamos a construir un serio nmero de nombres en
nuestro servidor de nombres. Esto se elevar a tres nuevos problemas:
Organizacin: Encontrar a cualquier entrada en la base de datos de nombres se
hace considerablemente lento, ya que pasamos a travs de muchos millones de
nombres en busca de la que queremos. Necesitamos un mtodo para indizar u
organizar los nombres.
Escalabilidad: Si cada host tiene acceso a nuestros servidores de nombres, la
carga se vuelve muy alta. Necesitamos un mtodo para distribuir la carga entre
varios servidores de nombres.
Gestin: Con muchos registros de nombres en nuestra base de datos, la gestin
se hace un problema cada vez ms difcil, ya que varios administradores intentan
actualizar registros al mismo tiempo. Necesitamos un mtodo para separar
(conocido como delegar) la administracin de estos nombres (generalmente conocido
como recursos) registrados.

CAPTULO 1 INTRODUCCIN A DNS

La necesidad de cumplir estos tres requisitos dio lugar a la creacin y evolucin de Internet
de Sistema de Nombres de Dominio (DNS Domain Name System), discutido en la prxima
seccin.
El Sistema de Nombres de Dominio de Internet
Domain Name System de Internet es una implementacin especfica del servidor de nombres
concepto optimizado para las condiciones que prevalecen en Internet. Desde nuestra breve
historia de los servidores de nombres, vimos que tres requisitos surgieron:
La necesidad de una jerarqua de nombres
La necesidad de difundir las cargas operativas en nuestros servidores de nombres
La necesidad de delegar la administracin de nuestros servidores de nombres
Nota Los RFC estndar que definen la funcionalidad bsica de DNS, RFC 1034 y RFC 1035,
ambos fueron escritos cerca de un cuarto de siglo atrs-1987 y escrito por el Dr. Paul
Mockapetris mientras estaba en el Instituto de Ciencias de la Informacin en la Universidad
del Sur de California. Aunque muchos RFCs posteriores han modificado ciertos
comportamientos DNS, la funcionalidad bsica permanece intacta. Este es de hecho un
logro notable.
Dominios y Delegacin
El sistema de nombres de dominio utiliza un rbol (o jerrquico) de estructura nombre. En la
parte superior del rbol est el nodo raz, seguido por los dominios de nivel superior
(TLD), entonces el segundo nivel de dominios (SLD), y entonces cualquier nmero de niveles
inferiores, cada uno separado por un punto.
Nota La raz del rbol se representa la mayor parte del tiempo como un punto silencioso (.),
Lo que simplemente significa que aunque que debe estar presente, no siempre se requiere y
por lo tanto puede ser omitido (silenciosa) simplemente por conveniencia. En ocasiones si ya
est, sin embargo, cuando este punto es de salida es muy importante.

TLD se dividen en dos tipos bsicos:

Genrico dominios de nivel superior (gTLDs): Por ejemplo, .com, .edu, .net, .org,
.mil, etc.
Cdigos de pas de dominios de nivel (ccTLDs): Por ejemplo, .us, .ca, .tv, .uk, etc.
Cdigo de pas TLDs utilizar una secuencia de dos letras estndar definido por la norma ISO
3166. Figura 1-1 ilustra esta forma de diagrama.

Lo que comnmente se llama un nombre de dominio, por ejemplo example.com, es en

realidad una combinacin de un nombre de SLD y un nombre de dominio de nivel
superior y se escribe de izquierda a derecha con el nivel ms bajo en la jerarqua de la
a la izquierda y el ms alto nivel de la derecha:
sld.tld
El trmino de segundo nivel de dominio es tcnicamente preciso en que define los nodos en
el segundo nivel dentro de la jerarqua de nombres de dominio, sino que es de largo aliento.
Para ser an ms largo aliento, tambin puede haber un tercer nivel de dominios, que son
especialmente relevantes con los ccTLDS, y as sucesivamente. Por convencin, o tal vez la
pereza, el termino dominio, o el nombre de dominio, se utiliza generalmente para describir
una entidad delegada, por ejemplo, example.com, que consiste en el SLD example y el TLD
com. A menos que se requiera precisin, el trmino nombre de dominio se utiliza en todo el
resto de este libro.

Autoridad de dominio (Domain Authority)

Los conceptos de autoridad y delegacin en el ncleo de la jerarqua del sistema de nombres
de dominio y exactamente refleja su organizacin jerrquica. Cada nodo dentro de la
jerarqua de nombres de dominio se asigna a una autoridad- una organizacin o persona
responsable de la gestin y el funcionamiento de ese nodo.
Tal organizacin o persona que se dice que administra el nodo con autoridad. La autoridad
para un nodo en particular, a su vez puede delegar autoridad a los niveles ms bajos de ese
nodo dentro del nombre de la jerarqua dominio. Las reglas y las limitaciones de la autoridad
estn cubiertos por acuerdos que fluyen a travs de diversos nodos en la jerarqua.
La autoridad para el dominio raz corresponde a la Corporacin de Internet para la
Asignacin de Nmeros y Nombres (ICANN-www. icann.org/). Since 1998, la ICANN, una
organizacin sin fines de lucro, ha asumido este la responsabilidad del Departamento de
Comercio de los Estados Unidos. Cuando se estableci la ICANN, una parte de su mandato
era abrir esa parte de la jerarqua de nombres de dominio para el que tiene la responsabilidad
de competencia comercial. Para facilitar esta competencia, cre el concepto de registradores
acreditados, organizaciones a las que ICANN delega responsabilidades limitadas para la
venta y administracin de partes de la jerarqua de nombres de dominio.

CAPTULO 1 INTRODUCCIN A DNS

Los gTLD se administran con autoridad por la ICANN y delegadas a una serie acreditada de
registradores. Los ccTLDs son delegados por la ICANN para los distintos pases para fines
de administracin.
Figura 1.1 tambin muestra cmo cualquier autoridad a su vez puede delegar en los niveles
inferiores de la jerarqua; en otro es decir, podrn delegar nada para el que tiene autoridad.
Cada capa de la jerarqua puede delegar el control de autoridad al nivel siguiente o inferior.
En el caso de los ccTLD, los pases a definir sus propias reglas para la delegacin. Pases
como Estados Unidos (ccTLD .us), Canad (ccTLD .ca), y otros han decidido que van a
administrar tanto en el nivel nacional y delegado de cada estado (EE.UU.) o provincia
(Canad), utilizando una de dos caracteres estado / provincia cdigo (por ejemplo, .ny =
Nueva York, .qc = Quebec, .md = Maryland, y as sucesivamente). Por lo tanto,
example.us es el nombre de dominio de ejemplo, que fue delegado del ccTLDs de la
administracin nacional de EE.UU., y example.md.us es el nombre de dominio de ejemplo
que se delega en el estado de Maryland en los Estados Unidos.
Otros pases, como el Reino Unido y Brasil, entre muchos otros, han optado por
segmentacin funcional en sus modelos de delegacin. Por lo tanto example.co.uk es el
nombre de dominio de ejemplo registrado como una empresa de la autoridad de registro de
Reino Unido, y example.com.br es el nombre de dominio ejemplo registrada como una
empresa de la autoridad de registro de Brasil.
Delegacin dentro de cualquier dominio puede ser casi ilimitado y se decidi por la
autoridad delegada. Para ejemplo, muchos estados de los Estados Unidos y provincias de
Canad ciudades delegado dentro de estado / provincia dominios: el nombre de dominio
example.nb.us sera la ciudad del ejemplo en el estado de Nebraska en los Estados Unidos, y
de hecho podra tener mycompany.example.nb.us, lo que sera el nombre de dominio de
MyCompany en la ciudad del example en el estado de Nebraska en los Estados Unidos.
La lectura de un nombre de dominio de derecha a izquierda har un seguimiento de su
delegacin.
Entonces Qu es www.example.com?
Desde nuestra lectura anterior, podemos ver que www.example.com se construye a partir de
www y example.com. La parte del nombre de dominio example.com se deleg a partir de un
registro de gTLD, que a su vez fue delegado de ICANN.
El propietario del dominio eligi la parte www porque ahora son la autoridad delegada para
el nombre de dominio example.com. Son dueos de todo a la izquierda del nombre de
dominio delegado; en este caso, example.com.
La parte ms a la izquierda, la www en este caso, se llama un nombre de host. Tenga en
cuenta que slo por convencin hacer sitios web utilizan el nombre de host www (World
Wide Web), pero un sitio web pueden ser nombrados fred.example.com-pocos usuarios
pueden pensar de escribir este nombre en el navegador web, pero eso no lo hace que se
invalide el nombre!
Cada ordenador conectado a Internet o a una red interna y si se accede mediante un servidor
de nombres tiene un nombre de host. Aqu hay algunos ejemplos ms:
www.example.com
ftp.example.com

El servicio web de la empresa

El servidor de protocolo de transferencia de archivo de empresa

pc17.example.com
accounting.example.com

Una PC normal
El sistema de contabilidad principal

Un nombre de host debe ser nico dentro del nombre de dominio delegado, pero puede ser
cualquier cosa que el propietario del example.com quiera.
Por ltimo, tenga en cuenta este nombre:
www.us.example.com
Desde nuestra lectura anterior, calculamos el nombre de dominio example.com; www
probablemente indica un sitio web, que sale de la parte de nosotros.
La parte que nos fue asignada por el propietario de example.com (que es autoritario) y se
llama un subdominio. En este caso, la autoridad delegada para example.com ha decidido
que su organizacin es mejor servida por una estructura de subdominio basado en los
pases. Ellos podran delegar la responsabilidad internamente para la filial
estadounidense de la administracin de este subdominio, que a su vez podra crear una
planta- basada en estructura; por ejemplo, www.cleveland.us.example.com podra indicar
el sitio web de la planta de Cleveland en la organizacin estadounidense de example.com.
Para resumir: el propietario puede delegar, en todo lo que quiera, nada a la izquierda del
dominio nombrar su propiedad (o fueron delegadas). El propietario delegado tambin es
responsable de la administracin de esta delegacin. La unidad de delegacin se conoce como
una zona en las especificaciones de DNS.

Nota
www.example.com y www.us.example.com son comnmente - pero errneamente referidos como nombres totales de dominio (FQDN). Tcnicamente, un FQDN define sin
equivocacin (inequvocamente) un nombre de dominio a la raz y por lo que se debe
terminar normalmente con el punto en silencio; por ejemplo, www.example.com. (Con el
punto) es una vlida FQDN, pero www.example.com (sin el punto) no lo es.

Implementacin y Estructura de DNS (DNS Implementation and Structure)

La implementacin del DNS de Internet con exactitud los mapas la estructura de delegacin
de nombres de dominio descrito previamente. Hay servidores de nombres (servidores que
ejecutan el software DNS) en cada nivel de la delegada jerarqua, y la responsabilidad de
ejecutar el servidor de nombres se encuentra con el control de autoridad en ese nivel. La
figura 1-2 muestra esquemticamente esto.

CAPTULO 1 INTRODUCCIN A DNS

Los servidores de nombres raz (en adelante denominados los servidores raz) son los
recursos ms crticos sobre el Internet. Cuando cualquier servidor de nombres en todo el
mundo se pregunt para obtener informacin sobre un nombre de dominio para el que
actualmente no tienen la informacin, primero se pregunta (consultas) uno de los servidores
DNS raz. Hay actualmente 13 servidores raz de todo el mundo, que se describe con mayor
detalle ms adelante en este captulo. Los servidores raz saben de cada servidor de nombres
en el mundo a travs de un especial de archivo de la zona, que se distribuye con todo software
DNS.
Los servidores de nombres de dominio de nivel superior (gTLD y ccTLD) son operados por
una variedad de organizaciones, denominado Registro de operadores, en virtud de acuerdos
de ICANN y se describen de forma ms completa ms adelante en este captulo.
El propietario de un nombre de dominio se ha delegado la autoridad para administrar el
nombre de dominio y por lo tanto tiene la responsabilidad de la operacin del usuario (o
nombre de dominio) Nombre servidores-all debe tener un mnimo de dos para la resiliencia.
El nombre de la responsabilidad operativa del servidor puede ser delegado por el propietario
del dominio a un ISP, una empresa de alojamiento web o cada vez un nombre de dominio de
registro. Muchas empresas y los propietarios de nombres de dominio, sin embargo, optan por
ejecutar sus propios servidores de nombres e incluso delegar la autoridad y la responsabilidad
de los servidores de nombres de subdominio para separar las partes de su organizacin.
Cuando cualquier servidor de nombres no puede responder o resolver, una solicitud de un
nombre, por ejemplo, fred.example.com, la consulta se pasa a un servidor raz (discutido en
la siguiente seccin), que devuelve una referencia al servidor de nombres TLD adecuado,
que a su vez proporciona una referencia para el dominio apropiado Servidor (usuario) que
devuelve el nombre real (autoritaria respuesta). La figura 1-3 ilustra este proceso.

Operaciones DNS Raz (Root DNS Operations)

Los servidores raz (DNS raz) es responsabilidad de la ICANN, pero son operados bajo un
acuerdo conocido como el Acuerdo Cooperativo de Investigacin y Desarrollo (CRADA)
que fue firmado entre ICANN y el Departamento de Comercio de Estados Unidos
(www.icann.org/committees/dns-root/crada.htm). Este acuerdo cubre los mtodos y procesos
por los que las actualizaciones a los sistemas de nombres raz se llevan a cabo. ICANN
tambin cre el Comit Asesor del Sistema de Servidores Raz (RSSAC) para proporcionar
asesoramiento y orientacin en cuanto a la operacin y el desarrollo de este recurso crtico.
El IETF fue solicitado por el RSSAC para desarrollar los estndares de ingeniera para el
funcionamiento de los servidores raz. Esta peticin dio lugar a la publicacin de la RFC
2870.
Actualmente hay 13 servidores raz. Ocupan un nombre de dominio reservado: rootservers.net. Cada root-server comprende tpicamente muchos servidores fsicos pero, usando
un proceso llamado anycasting, cada servidor fsico (llamado root-server instancia en la
jerga) comparte una nica direccin IP. Root-servidores son llamado de a.root-servers.net a
travs de m.root-servers.net, como se muestra en la Tabla 1-1. A partir de 2010, mientras que
hay 13 servidores raz con nombre, hay poco ms de 200 casos en todo el mundo. Corriendo
informacin acerca de los servidores raz se puede obtener de www.root-servers.org.

CAPTULO 1 INTRODUCCIN A DNS

CAPTULO 1 INTRODUCCIN A DNS

Nota Los sitios con un * soporte IPv6. El nmero 13 no es un deseo perverso por cualquier
persona para operar un nmero de servidores vistos por algunas culturas como de mala suerte,
sino ms bien un lmite determinado tcnicamente permite root-server comn preguntas a ser
respondidas dentro de una sola transaccin de 512 bytes UDP y por lo tanto reducen las
cargas de la raz del servidor. Transacciones DNS seguro (DNSSEC; vase el captulo 12)
aumentan significativamente el tamao medio de las transacciones DNS; As, aunque el
lmite de la raz del servidor puede permanecer en el 13, ya no es el mismo argumento tamao
de bloque abrumadora para justificar la nmero.

El trabajo de los servidores raz es proporcionar una referencia a los servidores de nombres
autorizados para la necesaria TLDs (gTLDs o ccTLDs). Por ejemplo, si un usuario solicita
informacin sobre fred.example.com, entonces la root-servers suministrar una lista de los
servidores de nombres autorizados para el TLD .com. En 2004, la ICANN tom sobre la
responsabilidad del mantenimiento del maestro TLD archivo en el archivo de servidores raz
que enumera los servidores autorizados para cada TLD. La distribucin de este archivo a
cada uno de los servidores raz de funcionamiento es llevado a cabo usando transacciones
seguras. Para aumentar an ms la seguridad, el servidor que proporciona las ctualizaciones
de raz es accesible slo desde los servidores raz operacionales. No es un servidor visible
pblicamente. Figura 1-4 ilustra este proceso.

Dominios de nivel superior (Top-Level Domains)

Como se mencion anteriormente en este captulo, dominios de nivel superior se dividen
en genricos dominios de nivel superior y Cdigos de pas de dominios de nivel. Cada
grupo se administra de forma ligeramente diferente, pero todos son controlados por la
ICANN. ICANN controla los gTLDs por un proceso puramente contractual. En el caso de
los ccTLDs, debido a mltiples pases y cuestiones de soberana nacional estn involucrados,
el proceso es esencialmente consultiva y no puramente contractual.
Genrico dominios de nivel superior
Genrico dominios de nivel superior o gTLDs, son controlados por la ICANN mediante un
proceso contractual. Cuando la competencia se introdujo en el registro de nombres de
dominio, ICANN estableci dos por separado entidades:
Operadores de Registro : contrato de Operadores de Registro con la ICANN
autorizada para operar los gTLD de los servidores DNS (vase la Figura 1.2 anterior).
Hay un solo registro Operador para cada uno de los gTLD, por ejemplo, el
Departamento de Defensa de Estados Unidos, Centro de Informacin de la Red, es el
operador de registro para el gTLD .mil, pero cada Operador de Registro operar
mltiples servidores de nombres. Consultas DNS al root-servers devuelven una
referencia a los servidores de gTLDs autorizadas para el gTLD especfica; por
ejemplo, si la consulta es para example.net, entonces los servidores raz suministrar
la lista de servidores DNS autorizados .net. Operadores de Registro obtener la lista
de domicilio nombres de dominio para el dominio de nivel superior de uno o ms
registradores. El pblico no tiene contacto con el Operador de Registro. Sin embargo,
un nmero de Registro de Operadores son tambin Registradores; por ejemplo,
VeriSign, Inc., es el operador de registro para el gTLD .com pero tambin es un
Registrador conocido.
Registradores: Registradores estn acreditados por ICANN a travs de un proceso
contractual de interactuar con el pblico para registrar uno o ms gTLD. Cuando
usted compra o renueva un nombre de dominio, tiene que tratar con un Registrador.
El Registrador mantiene todos los detalles necesarios, incluyendo el nombre del
propietario, contacto administrativo, contacto de facturacin, contacto tcnico, los
servidores de nombres autorizados para el nombre de dominio, y as sucesivamente.
El Secretario es responsable de proporcionar el operador de registro para el gTLD
con un extracto de los datos, que consiste en el nombre de dominio registrado y el

CAPTULO 1 INTRODUCCIN A DNS

nombre y las direcciones IP de los servidores DNS autorizados para el dominio. Esta
informacin es utilizada exclusivamente para responder a las consultas DNS.

Nota El intercambio seguro de informacin de dominio entre registradores y operadores

de registro est controlado por el Protocolo de Aprovisionamiento extendido (EPP)
definido por el RFC 5730.

La separacin de funciones entre el Operador de Registro y el Registrador permite a las

organizaciones relevantes involucradas para concentrar experiencia y-importante-asegura
que los especialistas manejan operacin de los servidores de nombres de dominio de primer
nivel. La figura 1-5 ilustra este proceso.

ICANN hered los gTLD que figuran en la Tabla 1-2 en su creacin en 1998.

Los acuerdos de ICANN con los operadores de registro que cubren los gTLD post-2000 han
especificado que los servicios de registro de la informacin y servicios de WHOIS sean ms
fciles de conseguir, al reservar el uso de nombres SLD nic y whois para cada uno de los
gTLD. Por ejemplo, para obtener el registro informacin para el gTLD .coop, necesita
introducir slo www.nic.coop (o simplemente nic.coop). Para obtener servicios de WHOIS
para el gTLD .museum, necesitas introducir solo www.whois.museum y (o whois.museum).
Aunque muchos de los dominios de primer nivel nuevos soportan tales nombres fciles de
recordar, lamentablemente no todos lo hacen.
Nota WHOIS es, literalmente, un servicio por el cual cualquier persona puede encontrar "que
es" el dueo, y otros detalles pertinentes, de nombres de dominio o direcciones IP.
Registradores y en algunos casos, terceros proporcionan acceso al registro bases de datos
utilizando el protocolo WHOIS estndar (RFC 3912).

Como puede verse en la lista en la Tabla 1-3, algunos de los gTLD, como .aero, han limitado
la inscripcin polticas; otros no lo hacen. Durante 2004, la ICANN llev a cabo una revisin
de la poltica de gTLD, uno de los efectos de la que consista en crear un nuevo gTLD
subconjunto llamado TLD patrocinados (sTLD) para aclarar la forma de registro acceso a ser
ofrecido por los nuevos gTLD. Los dominios .museum, .coop, .aero, .gov, .mil, .edu, y .int
son todos ahora clasificado como sTLDs. Desde noviembre de 2000, la ICANN ha autorizado
seis nuevos dominios de primer nivel, todos sTLDs: .travel, .jobs, .mobi, .cat, .tel y .asia.
Autorizar nuevos gTLD siempre ha generado controversia. En junio de 2008, la ICANN
aprob un nuevo gTLD sobre la base de un informe elaborado por sus nombres genricos
Organizacin de Apoyo (GNSO) Grupo de trabajo de polticas. Esencialmente, esta poltica
no impone lmites en el nmero de nuevos gTLD que se puede crear en el futuro y permite
que cualquiera de las partes competentes para proponer un nuevo gTLD que ser juzgado en
contra de un conjunto objetivo de criterios. A la fecha de la escritura, sin solicitud de gTLD
se ha autorizado en la nueva poltica.

CAPTULO 1 INTRODUCCIN A DNS

Nota Una lista completa de todos los gTLD actuales (y sTLD), junto con una descripcin de
su uso, la fecha de la ICANN autorizacin, sus patrocinadores y el Registro de Operadores,
as como ms informacin sobre y las referencias al revisado las polticas de ICANN gTLD
se define en el Apndice A la pregunta 4: Qu TLD disponibles Cdigo del pas de dominios
de nivel superior.

Cdigos de pas de dominios de nivel son controlados por la ICANN y se componen de un

cdigo de dos caracteres definido por la norma ISO 3166. ICANN ha eludido prolijamente
el espinoso tema de lo que es un pas con el uso de ISO 3166. ISO 3166 es controlado por
una rama de las Naciones Unidas, que est bastante experiencia en el cuestin de la definicin
de lo que es (y qu no es) un pas!
ccTLD son delegadas por la ICANN a un gestor de cdigo de pas. Gestor de cdigo de pas
es un trmino histricolo que refleja un momento en que la Internet era un lugar ms pequeo
e ntimo menudo hoy en da el cdigo del pas gerente es una rama del gobierno, y el cdigo
de pas se ha convertido en un recurso econmico valioso.
La relacin entre la ICANN y los administradores de cdigo de pas es complicada por la
soberana y la sensibilidad cultural, y el proceso es en gran medida consultiva y no
contractual. Es un testimonio de la buena voluntad de todas las partes que el proceso funciona
tan bien como lo hace. En general, los administradores de los pases son responsables de la
administracin y operacin de sus cdigos de pas delegados y el TLD asociado servidores
con respecto a sus circunstancias locales y dentro del espritu de la RFC 1591 y de la ICANN
ICP-1 (www.icann.org/en/icp/icp-1.htm). Como parte del movimiento para hacer que
Internet sea ms accesible en todo el mundo,se estn introduciendo nombres de dominio
internacionalizados (IDN) ccTLD. Consulte el Captulo 17 para obtener detalles de IDN y
Apndice A para obtener ms informacin sobre IDN ccTLD.
Los modelos de la delegacin del pas se basan normalmente en un modelo federado; por
ejemplo, por el estado o provincia-example.md.us-o un modelo funcional, por ejemplo,
example.co.uk o example.com.br.
Sin embargo, existen muchas excepciones, lo que refleja las condiciones y necesidades
locales. El ms famoso que la primavera a la mente son .tv (Tuvala) y .la (Laos), mediante el
cual los pases han tratado de optimizar el econmico valor del recurso de nombre de
dominio.
La Internet Assigned Numbers Authority (IANA) mantiene una lista actualizada de los
gestores de cdigo de pas en www.iana.org/domains/root/db/ en nombre de la ICANN.
DNS en Accin (DNS in Action)
Hasta ahora, nos hemos centrado en los nombres de dominio y servidores de nombres
autorizados utilizados en DNS. Pero para el DNS para ser til debe entregar la informacin,
en forma de respuestas a las consultas, a partir de un nombre de autoridad de servidor para
la PC de un usuario o de cualquier aplicacin (como un servidor SMTP [mail] agente o un
cliente FTP) que necesita resolver nombres a direcciones IP. Figura 1-6 ilustra cmo un
navegador que se ejecuta en un PC utiliza y accede a la DNS e introduce todas las piezas que
pueden hacer operacional el puzle DNS.

Nota Como todos los sistemas, DNS tiene su parte justa de la terminologa, algunos de los
cuales se aplica de manera inconsistente. Dentro de DNS hay esencialmente dos tipos de
sistemas: los servidores de nombres autorizados que ofrecen respuestas autoritarias
(Datos) en respuesta a las consultas. Las consultas se originan en lo que se llaman
resolutores. Una resolucin es simplemente una parte de la infraestructura DNS que emite
las consultas con el fin de resolver (traducir) nombres en direcciones IP. Resolvers, que
puede venir en todas las formas y tamaos, se explican con ms detalle en la siguiente seccin
y en todo el libro.

Como puede verse en la Figura 1-6, DNS hace uso extensivo de almacenamiento en cach,
que puede jugar un papel significativo en la reduccin de la complejidad del sistema y la
aceleracin de los tiempos de respuesta de DNS. Caching simplemente significa que
cualquier resultados (respuestas a las preguntas) se guardan en el almacenamiento temporal.
Si la solicitud de los mismos datos llega a la resolucin, la cach se inspecciona primero y si
los datos requeridos se presenta la respuesta es suministrado directamente de la cach. Por lo
tanto, se evita la comunicacin externa innecesaria, y el resultado se suministra mucho ms
rpidamente. El proceso por el cual los datos rancio se descarta de la cach utiliza un perodo
de vida (TTL) valor que se explica en el captulo 2.
Los nmeros utilizados en las descripciones siguientes se refieren a los de la Figura 1-6:

Cuando los usuarios entran en una URL, como w ww.example.com, en su navegador

favorito, (1) se busca primero su cach interna para ver si ya tiene los datos. Si no, el
navegador llama a una biblioteca de software interno o programa llamado un resolver
(2). El mtodo normal, con lo que los datos viejos se eliminan de una cach DNS (la
TTL) no es posible dentro del navegador, haciendo de este cach slo marginalmente
eficaz o en algunos casos contraproducente (vase el captulo 8).

Una resolucin de DNS puede ser una muy compleja pieza de software, pero las
normas de DNS permitir una versin simplificada llamada stub-resolver. Stubresolutores estn instalados en todas las plataformas, como los sistemas Windows y
*nix (por ejemplo, Linux, UNIX y BSD). La mayora de los modernos stubresolutores tambin proporcionan servicios de almacenamiento en cach, por lo que
si que disfrute con descripciones largas que podra ser llamado un almacenamiento

CAPTULO 1 INTRODUCCIN A DNS

en cach stub-resolver. Como era de esperar, el taln-resolver inspecciona su cach
primero e inmediatamente suministra la resultar si est presente. Si no, se crea una
consulta DNS (una pregunta) y la enva a ya sea una Mdem DSL (3) o directamente
a una resolucin de DNS (4) dependiendo de cmo el PC o servidor se ha configurado.

En la mayora de los casos residenciales y pequeas empresas, alguna forma de

mdem DSL o router local, normalmente suministrado por el proveedor de servicio
de Internet, se utiliza para acceso a Internet. PCs o servidores estn conectados a
travs de una LAN (a menudo un LAN inalmbrica) conexin con este dispositivo.
El mdem DSL o router normalmente ofrece una dinmica Servicios (DHCP)
Protocolo de configuracin de host. En este tipo de conexin, cuando una PC o
servidor est encendido, se ejecuta a travs de una secuencia de arranque durante el
cual un nmero de transacciones DHCP se produzca. Al final de este proceso, la
configuracin parmetros se habrn suministrado notablemente incluyendo una
direccin IP y una o ms direcciones DNS. Aunque en algunos casos la direccin
DNS (es) suministrado voluntad apunte al resolutor del proveedor de servicio DNS
(4), cada vez ms el DNS direccin apunta al mdem DSL o router local (3), que
contendr un DNS Proxy. Dependiendo del fabricante del dispositivo y las polticas
del proveedor de servicios de Internet, Funcionalidad de proxy DNS vara
enormemente de una operacin de traspaso sencilla (No se cambia nada), para el
almacenamiento en cach y otras operaciones ms intrusivos en su mayora diseada
para reducir la carga y la velocidad de las respuestas del usuario, pero pueden tener
efectos secundarios no deseados. No hay normas se definen para proxies DNS, pero
RFC 5625 contiene una serie de recomendaciones diseado para minimizar operativa
problemas. En todos los casos, si los datos no estn disponible en ninguna cach local,
las consultas son remitido (transmitido) para la resolucin de DNS (4).

Un PC o servidor pueden acceder indirectamente a la resolucin de DNS (4) a travs

del ADSL mdem / enrutador (3), como se describe anteriormente, o directamente a
travs Manual configuracin o un servicio DHCP. Esta resolucin es el verdadero
negocio: un servicio completo, las funciones, bestia peso pesado que realiza una gran
cantidad de trabajo en nombre de sus clientes. Siempre contiene un cach que primero
inspecciona para cualquier respuestas disponibles a consultas de los clientes. Slo
para ilustrar la rica gama de terminologa disponible para el usuario DNS, este
resolver puede ser y con frecuencia se conoce como un servidor de nombres de
almacenamiento en cach o incluso un servidor de nombres recursivo (recursivo se
explica en el captulo 3). Debido a que esta resolucin normalmente proporciona
servicios para un nmero muy grande de resolucin de clientes y servidores proxy,
su cach es probable que ya contienen un montn de respuestas, por lo que la
probabilidad de una memoria cach "Hit" (existen los datos necesarios en la memoria
cach) ser alta. Sin embargo, si la respuesta es no presentar en su cach, esta
resolucin, a diferencia de todos los anteriores stub-resolutores y Proxies DNS que
hemos visto hasta ahora, va a perseguir abajo en la jerarqua de autoridad DNS (5),
(6), y (7) para obtener la respuesta autorizada a la consulta del usuario, que
posteriormente enva al usuario y lugares en su cach para su uso futuro por otras
consultas.

Hay muchas posibles variaciones tcticas en el escenario descrito anteriormente, pero para
la gran mayora de los usuarios de Internet es el mtodo normal por el que el nombre de un
recurso, como www.example.com, se resolvi (traducido) en direcciones uno (o ms) de
propiedad intelectual obtenida de una autoridad nombre del servidor. Los puntos clave a tener
en cuenta en este escenario son el papel desempeado por diversos cachs que son en gran
medida diseado para acelerar la respuesta del usuario, pero tambin puede tener
consecuencias no deseadas, y la funcionalidad de la resolucin de DNS (4), lo que reduce la
complejidad de la resolucin de cliente (stub-resolvers) y la representacin por concentrar el
trabajo complejo y potencialmente peligrosa de acceder a la jerarqua autoritaria DNS. La
configuracin y funcionalidad de una resolucin de DNS (4) y los servidores DNS de
nombres autorizados (5), (6), y (7) se explican con ms detalle en el captulo 4, y las muestras
de configuracin detalladas se proporcionan en el Captulo Programa de DNS 7. Entonces,
ya sea una resolucin de DNS o un servidor de nombres con autoridad, por lo general
hace tres cosas:

Se lee uno o ms archivos de zona (que se describe en el texto siguiente), que

describen los dominios de los que sea responsable o que lo utilizar.

Dependiendo de la funcionalidad del software DNS, se lee un archivo de

configuracin, que describe varios comportamientos necesarios (por ejemplo,
para almacenar en cach o no).

Responde a las preguntas (consultas) de los clientes locales o remotos (otro

nombre servidores, resolutores, o proxies).

Zonas y archivos de zona (Zones an Zone File)

Los servidores de nombres soportan las denominadas zonas. El trmino zona y su relacin
con un nombre de dominio puede ser muy confuso. Una zona se describe el uso de un archivo
de zona que traduce el nombre de dominio en funcionamiento entidades, como anfitriones,
servidores de correo, servicios y otras caractersticas para el uso de software de DNS.
Subdominios delegados por el propietario del nombre de dominio tambin se pueden
describir utilizando archivos de zona separadas. La Especificaciones DNS originales
llamadas por ellos subzonas-a trmino que ha desaparecido gracias a Dios a travs del tiempo.
Por lo tanto, el archivo de zona describe, utilizando registros de recursos textuales (RR),
la parte del nombre de dominio es manejado por el software de un DNS de zona designa
un operativo (y autoritaria parte) de un dominio nombre gestionado por un servidor DNS
o nombre. El formato de los archivos de zona y sus RR ha sido estandarizado en el RFC
1035. Los archivos de zona son, por tanto, portables a travs de todo el software DNS
estndar. Un archivo de zona normalmente consistir de los siguientes tipos de RRs:

Los datos que se describen las propiedades de la zona, conocido como el inicio
de autoridad ( SOA) Registro de recursos. Este RR es obligatorio en todos los
archivos de zona.

CAPTULO 1 INTRODUCCIN A DNS

Todos los hosts dentro de la zona tpicamente definido registros de recursos

usando Direccin (A) para IPv4 y de recursos AAAA Registros para IPv6.

Los datos que describe la informacin global para la zona tpicamente MX

Recursos registrados que describen los servidores de correo del dominio y los
registros de recursos NS que describen los servidores de nombres que estn
autorizados para el dominio.

En el caso de delegacin subdominio, los servidores de nombres responsables de

esta subdominio-utilizando NS registros de recursos.

En el caso de delegacin subdominio, un registro (llamado pegamento registro y

descrito en el captulo 8) que permite que el servidor de nombres para alcanzar el
nombre de subdominio servidor (s) -tpicamente uno o ms A o AAAA registros de
recursos.

A continuacin se muestra un ejemplo sencillo de un archivo de zona que muestra la mayora

de los artculos mencionados en la lista anterior. No es importante en esta etapa para entender
el detalle de cualquier lnea, que se describe en el siguiente captulo.

Los RR individuales se describen en el captulo 2; muchos archivos de zona ms muestras se

presentan en Captulo 7, y una referencia RR completa se proporciona en el Captulo 13.
Maestro y esclavo Servidores DNS (Master and Slave DNS Servers)
Al principio de este captulo, que vio que se requiere ms de un servidor de nombres con
autoridad para aumentar fiabilidad y rendimiento. No es poco comn hoy en da para ver
sitios con cuatro, cinco, o ms servidores de nombres, cada uno de los cuales pueden estar en

una ubicacin fsicamente diferentes, y cada uno de los cuales deben tener acceso a el archivo
de zona. Con el fin de reducir los gastos generales de gestin que intervienen en la
sincronizacin de archivos de zona, las especificaciones DNS permiten un nico servidor
DNS de poseer un maestro copia del archivo de zona y permitir zona transferencias
(descritos en el captulo 3) para los dems (esclavo servidores) de nombre. El trminos
master zone, o maestro DNS; y esclavos de la zona, o DNS esclavo, se aplican habitualmente
a los respectivos servidores de nombres. Los trminos maestro y esclavo simplemente
definir qu servidor de nombres tiene el maestro copia del archivo de zona (cargado de
una sistema de archivos local) y que tiene una copia (cargado a travs de la
transferencia de zona); no implican ninguna prioridad acceso. Ambos maestros y
esclavos responden con autoridad para la zona. La relacin maestro-esclavo es se ilustra
en la Figura 1-7.

Nota En un mundo perfecto, toda la terminologa no es ambigua. Las especificaciones

originales DNS utilizan los trminos primarios y / o maestro y Secundaria (llamado esclavo
previamente) para describir el proceso de transferencia de zona. Los trminos de primaria
y Secundaria estn siendo ampliamente utilizados para describir el orden de DNS en
muchos lugares, tales como el registro de nombres de dominio y a la hora de definir las
propiedades de red en PC o hosts. En un intento de reducir la confusin, Berkeley Internet
Name Domain (BIND) introdujo los trminos maestro y esclavo en el contexto de las
transferencias de zona, como se muestra anteriormente. Este libro utilizar estos trminos a
lo largo. Al leer otros documentos y puramente en el contexto de las transferencias de zona,
Primaria = principal y Secundaria = esclavo.

Software DNS (DNS Software)

Existe una variedad vertiginosa de software DNS adaptada a una amplia gama de necesidades
de los usuarios. Berkeley Internet Name Domain -siempre referido como BIND- es una
implementacin de cdigo abierto actualmente desarrollado por el Internet Systems
Consortium, Inc. (www.isc.org). Es, probablemente, es el ampliamente conocido ms y
desplegado de las implementaciones de DNS, y de hecho la mayor parte de este libro
documenta sus caractersticas. BIND, sin embargo, de ninguna manera es la nica solucin
DNS disponibles o para el caso la nica Open Source DNS solucion.

CAPTULO 1 INTRODUCCIN A DNS

BIND histricamente se ha visto como la implementacin de referencia de alta calidad de la
Internet Engineering Task Force (IETF) RFCs que especifican la funcionalidad DNS. Como
consecuencia, BIND tiene generalmente negociados rendimiento para la funcionalidad
genrica. BIND, incluyendo las versiones actuales de produccin de BIND 9, es una "talla
nica" solucin proporcionando tanto de resolucin de DNS y el servidor de nombres con
autoridad funcionalidad dentro del mismo paquete de software.
Los usuarios de Microsoft Windows estn bien provistos de soluciones DNS. Los paquetes
de Microsoft Server vienen equipados con un servidor DNS nativo (que proporciona
resolucin de DNS y el servidor de nombres con autoridad funcionalidad). Las versiones de
produccin de BIND 9 proporcionan un paquete binario que se ejecutar en Windows XP,
Windows Server 2003 y Windows 2008 Server.
Pero el mundo de DNS ha experimentado una transicin seria, especialmente en los ltimos
cinco aos ms o menos, a partir de siendo un estable servicio esencial, tal vez incluso
aburrido de ser ahora reconocido como un crtico (si no el crtico) recurso que mantiene el
Internet viva.
Software DNS est cambiando para reflejar las fuerzas en el trabajo dentro de Internet ms
grandes, en particular:

Fuente de datos: Cada vez aprovisionamiento IP y sistemas de gestin significa que

las organizaciones ms grandes, especialmente, pero no exclusivamente, mantener
datos IP y nombre en otros formatos. Software DNS tiene que ser ms flexible en el
suministro de datos alternativa fuentes, tales como a partir de bases de datos
transaccionales y LDAP, as como su tradicional basado en texto formato de archivo
de zona.

Complejidad: DNSSEC particularmente ha aadido considerablemente a la

complejidad del Funcionalidad DNS. Una de las respuestas clsicas a la complejidad
es aumentar especializacin. Software DNS est siguiendo cada vez ms esta
tendencia con la separacin de funcionalidad de resolucin de la funcionalidad
de servidor de nombres con autoridad. En la mayora de los casos, la feliz
consecuencia de esta especializacin es tambin un aumento en el rendimiento.

Gestin: El software DNS tradicional ha suministrado estilo de lnea de comandos y

torpes interfaces de gestin. Cada vez ms usuarios web estn exigiendo basados
moderna interfaces de gestin, tanto para mejorar la capacidad de respuesta y para
disminuir los errores.

Los datos dinmicos: Una de las principales crticas formuladas en los ltimos aos
en contra de muchos de las implementaciones de software DNS es la falta de
capacidad de agregar de forma dinmica o eliminar zonas sin tener que parar y
arrancar el servidor DNS. Esta crtica refleja tanto la naturaleza cada vez ms
dinmico de los cambios de Internet-ms, con ms frecuencia, y el aumento del
volumen de trfico en cuestin. Muchos usuarios estn reacios a dejar de contestar
consultas, incluso para los segundos necesarios para detener y reiniciar software
DNS. Aunque DNS dinmico (DDNS), con el apoyo de BIND y descrito en el
captulo 3, permite la edicin de los RR individuales dentro de las zonas, no

puede aadir o eliminar zonas enteras. Tal limitacin es cada vez menos aceptable;
zonas necesitan ser aadidas y eliminadas de forma dinmica sin interrumpir el
servicio.
Histricamente, todos los servidores raz utilizan software BIND. Con el fin de fomentar la
diversidad, para algunos de los root-server ahora corren el software NSD
(www.nlnetlabs.nl/projects/nsd), que proporciona un cdigo abierto, DNSSEC listos,
implementacin optimizado para un alto rendimiento cuando acta como nombres con
autoridad nico servidor; no proporciona la funcionalidad de resolucin de DNS. Se ha
negociado funcionalidad genrica para crudos rendimientos, que puede ser hasta dos veces
la ofrecida por una configuracin equivalente BIND 9.
Sin consolidar es una solucin de resolucin DNS Open Source (www.unbound.net) que
proporciona unos resultados altos de ejecucin C de un ejercicio de diseo basada en Java
original que tambin apoya plenamente la ltimos estndares DNSSEC.
Incluso BIND no es invulnerable a los cambios. BIND 10 es un programa de reestructuracin
radical de varios aos diseado para traer beneficios funcionales y de rendimiento
significativos a la amplia base de usuarios de BIND. El primer lanzamiento de esta nueva
generacin de productos BIND 10 es una nica autoritativa de los servidores de nombres que
es totalmente descrito en el captulo 14 con las muestras de configuracin en el captulo 7
actualizado para cubrir tanto BIND 10 y BIND 9 en su caso. Una resolucin de slo producto
BIND 10 y un producto multifuncin 10 BIND (Equivalente de hoy a BIND 9) se dar a
conocer progresivamente en los prximos aos. BIND 9 continuar mantenindose
agresivamente durante todo este perodo de varios aos y continuar a ser utilizado en
muchos ambientes para los prximos aos.
Qu obras mejores DNS solution para cualquier usuario reflejarn el funcional y
organizacional requisito y, como siempre, se requieren comprensin clara de las ventajas y
desventajas y limitaciones que pueden estar involucrados.
Es importante recordar que el formato de los archivos de zona utilizada por el software DNS
est estandarizada por RFC 1035. Migracin de una implementacin de software DNS a otro
puede pues ser considerablemente aliviado. Cuando una funcin es exclusiva de BIND (no
normalizado), se indicar claramente en el texto.
Resumen
En este captulo se introdujo una gran cantidad de terminologa y conceptos que se utilizar
durante todo el resto de la libro. El texto describe la necesidad de servidores de nombres, lo
que se traduce el nombre descriptivo de un recurso a su direccin de red fsica, y ellos
identificado como siendo esencial para el funcionamiento de una dinmica y red flexible de
cualquier tamao.
Sistema de nombres de dominio de Internet (DNS) se introdujo como una aplicacin
especfica del concepto de servidor de nombres. Usted aprendi acerca jerarqua de nombres
de dominio DNS de Internet, en particular, la separacin de los dominios de nivel superior
en TLDs genricos, para los que la ICANN est completamente autorizada, y Cdigo de pas
TLDs, que son administrados por los pases soberanos individuales. Ahora tambin sabe las
partes componentes de un nombre de dominio; por ejemplo, www.example.com estafadores
consiste de un nombre de host (www), un SLD (example), y un TLD (.com). Tambin se
encontr con los conceptos clave de una autoridad, la entidad o persona responsable de un
nodo en particular en la jerarqua de nombres de dominio; y la delegacin, el proceso por el

CAPTULO 1 INTRODUCCIN A DNS

que la autoridad en un nivel superior en la jerarqua de nombres de dominio pueden transferir
autoridad para bajar los niveles. El captulo de software DNS finalmente introducido, los
programas de servidor y del resolver que ejecutan la Funcin DNS, incluyendo BIND, el
software del servidor DNS ms utilizado y aplicado.
Captulo 2 desentraa los misterios de archivos de zona y los registros de recursos ms
comunes (RR) utilizados en estos archivos.