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 El servicio web de la empresa

ftp.example.com El servidor de protocolo de transferencia de archivo de empresa

pc17.example.com Una PC normal

accounting.example.com 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: root-

servers.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. Stub-

resolutores estn instalados en todas las plataformas, como los sistemas Windows y

*nix (por ejemplo, Linux, UNIX y BSD). La mayora de los modernos stub-

resolutores 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.