Sistema de nombres de dominio

"DNS" vuelve a dirigir aquí. Para otras aplicaciones, vea DNS (desambiguación).

Conjunto de protocolos de Internet
Capa de aplicación
BGP DHCP DNS FTP HTTP IMAP LDAP MGCP NNTP NTP POP ONC/RPC RTP RTSP RIP SIP SMTP SNMP SSH Telnet TLS/SSL XMPP más...
Capa de transporte
TCP UDP DCCP SCTP RSVP más...
Capa de Internet
IP IPv4 IPv6 ICMP ICMPv6 ECN IGMP IPsec más...
Capa de enlace
ARP NDP OSPF Túneles L2TP PPP MAC Ethernet DSL ISDN (RDSI) FDDI más...

El Sistema de nombres de dominio (DNS) es un jerárquico sistema de nomenclatura para computadoras, servicios o cualquier recurso conectado a distribuido el Internet o un red privada. Se asocia a diversas informaciones con nombres de dominio asignados a cada una de las entidades participantes. Más prominente, se traduce nombres de dominio, que se pueden memorizar fácilmente por los seres humanos, a la numérica Direcciones IP necesarias a los efectos de los dispositivos y servicios informáticos en todo el mundo. El Domain Name System es un componente esencial de la funcionalidad de la mayoría Internet servicios porque es primaria de Internet servicio de directorio.

El Domain Name System distribuye la responsabilidad de asignar nombres de dominio y asignación de esos nombres a direcciones IP mediante la designación de servidores de nombres autoritarios para cada dominio. Servidores de nombres autoritarios se asignan a ser responsable por sus dominios admitidos y podrán delegar autoridad sobre subdominios a otros servidores de nombre. Este mecanismo ofrece distribuido y servicio tolerante de fallos y fue diseñado para evitar la necesidad de una única base de datos central.

El Domain Name System también especifica la funcionalidad técnica de la base de datos servicio que está en su núcleo. Define el protocolo DNS, una especificación detallada de las estructuras de datos y comunicación de datos intercambia utilizado en DNS, como parte de la Conjunto de protocolos de Internet. Históricamente, otros servicios de directorio, DNS anteriores no eran escalables a directorios grandes o globales como originalmente estaban basadas en archivos de texto, un lugar destacado el HOSTS.TXT discernidor de imágenes. DNS ha estado en uso desde la década de 1980.

Internet mantiene dos principales espacios de nombres, la jerarquía de nombre de dominio y el Protocolo de Internet (IP) espacios de direcciones. El Domain Name System mantiene la jerarquía de nombre de dominio y ofrece servicios de traducción entre él y los espacios de direcciones. Internet servidores de nombres y una comunicación Protocolo implementar el sistema de nombres de dominio. Un servidor de nombres DNS es un servidor que almacena los registros DNS de un nombre de dominio; un servidor de nombres DNS responde con respuestas a consultas contra su base de datos.

Los tipos más comunes de los registros almacenados en la base de datos DNS son los relacionados con una Autoridad de la zona DNS autoridad (SOA), Direcciones IP (A y AAAA), SMTP Intercambiadores de correo (MX), servidores de nombres (NS), punteros para búsquedas de DNS inversa (PTR), y alias de nombre de dominio (CNAME). Aunque no pretende ser una base de datos de propósito general, DNS puede almacenar registros de otros tipos de datos para las búsquedas de cualquier máquina automática para cosas como DNSSEC registros, o para consultas humanas como persona responsable (RP) records. Para una lista completa de tipos de registros de DNS, consulte la Lista de tipos de registros DNS. Como una base de datos de propósito general, DNS también ha visto usar en la lucha contra la correo electrónico no solicitado (spam) utilizando un lista negra en tiempo real almacenados en una base de datos DNS. Si para dar nombre a Internet o para aplicaciones de propósito general, la base de datos DNS tradicionalmente se almacena en una estructura archivo de zona.

Función

Una analogía utilizados con frecuencia para explicar el sistema de nombres de dominio es que sirve como el directorio telefónico para el Internet por traducir humanos respetuosos con el ordenador nombres de host en direcciones IP. Por ejemplo, el nombre de dominio www.example.com se traduce en las direcciones 93.184.216.119)IPv4) y 2606:2800:220:6 d: 26bf:1447:1097:aa7 ()IPv6). A diferencia de una guía telefónica, el DNS puede ser rápidamente actualizado, permitiendo la localización de un servicio en la red para cambiar sin afectar a los usuarios finales, que continúan utilizando el mismo nombre de host. Los usuarios aprovechar esto cuando usan significativo Uniform Resource Locators (URL), y direcciones de correo electrónico sin tener que saber cómo la computadora realmente localiza los servicios.

Historia

Usando un más simple, más memorable nombre en lugar de dirección numérica del host se remonta a la ARPANET época. El Stanford Research Institute (ahora SRI International) mantiene un archivo de texto denominado HOSTS.TXT asignan nombres de host a las direcciones numéricas de ordenadores de ARPANET. Los operadores host obtienen copias del archivo maestro. El rápido crecimiento de la red emergente requiere un sistema automatizado para el mantenimiento de los nombres de host y direcciones.

Paul Mockapetris diseñado el sistema de nombres de dominio en el Universidad de California, Irvine en 1983 y escribió la primera aplicación a petición del Jon Postel De UCLA. El Internet Engineering Task Force publicó las especificaciones originales en RFC 882 y RFC 883 en noviembre de 1983, que han mantenido el estándar para los nombres de hosts Internet.

En 1984, cuatro UC Berkeley los estudiantes — Douglas Terry, Mark pintor, David Riggle y Songnian Zhou — escribió la primera Unix implementación de servidor de nombre, llamada al (Berkeley Internet Name DomainBIND) Servidor. En 1985, Kevin Dunlap de DEC substancialmente revisó la implementación de DNS. Mike Karels, Phil Almquist, y Paul Vixie han mantenido BIND desde entonces. BIND fue portado para el Windows NT plataforma en la década de 1990. BIND fue ampliamente distribuido, especialmente en sistemas Unix y sigue siendo el más ampliamente utilizado software DNS en Internet.

En noviembre de 1987, RFC 1034 y RFC 1035 reemplazado las especificaciones DNS 1983. Varios adicionales Solicitud de comentarios tienen extensiones propuestas a los protocolos DNS principal.

Estructura

Espacio de nombres de dominio

El espacio de nombres de dominio se compone de un árbol de nombres de dominio. Cada nodo hoja en el árbol tiene cero o más registros de recursos, que tienen información relacionada con el nombre de dominio. El árbol secundario se divide en zonas comenzando en el zona de la raíz. A Zona DNS puede consistir en solamente un dominio, o puede consistir en muchos dominios y subdominios, dependiendo de la autoridad administrativa delegadas al gerente.

El Domain Name System jerárquico, organizado en zonas, cada una servida por un servidor de nombres

Responsabilidad administrativa por cualquier zona puede ser dividida mediante la creación de las zonas adicionales. Dice que es autoridad Delegado por una parte del antiguo espacio, generalmente bajo la forma de subdominios, a otro nombre de servidor y entidad administrativa. La antigua zona deja de ser autorizado para la zona nueva.

Sintaxis de nombre de dominio

Las descripciones de las reglas para la formación de nombres de dominio definitivas aparecen en RFC 1035, RFC 1123, y RFC 2181. A nombre de dominio consiste en una o más partes, técnicamente denominadas Etiquetas, que convencionalmente son concatenados y delimitada por puntos, como ejemplo.com.

• Transmite la etiqueta más a la derecha el dominio de nivel superior; por ejemplo, el dominio nombre www.example.com pertenece al dominio de alto nivel com.
• La jerarquía de dominios desciende de derecha a izquierda; cada etiqueta a la izquierda especifica una subdivisión, o subdominio el dominio a la derecha. Por ejemplo: la etiqueta ejemplo especifica un subdominio de la com dominio, y www es un subdominio de ejemplo.com. Este árbol de subdivisiones puede tener hasta 127 niveles.
• Cada etiqueta puede contener hasta 63 caracteres. El nombre de dominio completo no puede superar la longitud de 253 caracteres en su representación textual. En la representación binaria interna del DNS la longitud máxima requiere 255 octetos de almacenamiento, ya que también almacena la longitud del nombre.
• Nombres DNS técnicamente pueden consistir de cualquier carácter representable en un octeto. Sin embargo, la formulación permitida de nombres de dominio en la zona de raíz DNS y la mayoría de otros subdominios, utiliza un preferido y el formato de juego de caracteres. Los caracteres permitidos en una etiqueta son un subconjunto de la ASCII conjunto de caracteres e incluye los personajes a a través de z, A a través de Z, dígitos 0 a través de 9y el guión. Esta regla es conocida como la Regla LDH (letras, números, guión). Nombres de dominio se interpretan de manera independiente del caso. Las etiquetas no pueden empezar o terminar con un guión. Hay una regla adicional que requiere esencialmente que nombres de dominio de primer nivel no sean todos numéricos.
• A nombre de host es un nombre de dominio que puede estar asociado con direcciones IP. Por ejemplo, el dominio nombres www.example.com y example.com son también los nombres de host, mientras que com no es.

Nombres de dominio internacionalizados

El limitado conjunto de caracteres ASCII en el DNS permitida prevenir la representación de nombres y palabras de varios idiomas en su nativas alfabetos o scripts. Para hacer esto posible, ICANN aprobado el Internacionalización de nombres de dominio en aplicaciones Sistema (IDNA), por el cual las aplicaciones de usuario, tales como navegadores web, mapa Unicode cuerdas en el personaje DNS válido definir mediante Punycode. En 2009 la ICANN aprobó la instalación de dominios de alto nivel de códigos de países de nombre de dominio internacionalizado. Además, muchos registros (los nombres de los dominios de nivel superior existenteTLD) s han adoptado el sistema IDNA.

Servidores de nombres

El Domain Name System es mantenido por un base de datos distribuida sistema, que utiliza el modelo cliente – servidor. Los nodos de esta base de datos son la servidores de nombres. Cada dominio tiene al menos un servidor DNS autorizado que publica información sobre el dominio y los servidores de nombres de dominios de cualquier subordinados a él. La parte superior de la jerarquía es servida por el servidores de nombres raíz, los servidores para consultar cuando mirando hacia arriba ()resolver) un TLD.

Servidor de nombres autorizado

Un autorizada nombre de servidor es un servidor de nombres que le da respuestas se han configurado por una fuente original, por ejemplo, el administrador del dominio o por métodos de DNS dinámicos, en contraste con las respuestas que se obtuvieron mediante una consulta DNS regular a otro servidor de nombre. Un servidor de nombres sólo autorizada sólo devuelve las respuestas a las preguntas sobre nombres de dominio que se han configurado específicamente por el administrador.

En otras palabras, permite a un servidor de nombres autorizado recursivo servidores de nombres saben qué DNS datos (la IP IPv4, IPv6 IP, una lista de servidores de correo entrante, etc.) tiene un nombre de host determinado (por ejemplo, "www.example.com"). Como un ejemplo, el servidor de nombres autorizado para "ejemplo.com" le dice a los servidores de nombre recursivos que "www.example.com" la dirección IP IPv4 192.0.43.10.

Un servidor de nombres autorizado puede ser un Maestro servidor o un esclavo servidor. Un servidor maestro es un servidor que almacena el (original)Maestro) copias de los registros de la zona. Un servidor esclavo utiliza un mecanismo de actualización automática del protocolo DNS en comunicación con su maestro para mantener una copia idéntica de los registros maestros.

Un conjunto de servidores de nombres autoritarios tiene que ser asignado para cada zona DNS. Un registro NS sobre direcciones de ese conjunto debe almacenarse en la zona principal y servidores propios (como autorreferencia).

Cuando se registran los nombres de dominio con un registrador de nombres de dominio, su instalación en el registro de dominio de un dominio de nivel superior requiere la asignación de un primaria nombre de servidor y al menos uno secundaria servidor de nombres. El requisito de múltiples servidores de nombre pretende convertir el dominio aún funcional aunque se convierte en un servidor de nombres inaccesibles o inoperables. La designación de un servidor de nombres primario está determinada exclusivamente por la prioridad otorgada al registrador de nombres de dominio. Para este propósito, generalmente solamente el nombre de dominio completamente calificado del nombre servidor es necesario, salvo que los servidores están contenidos en el dominio registrado, en cuyo caso el correspondiente Dirección IP es necesario también.

Servidores de nombres primarios son a menudo los servidores de nombre principal, mientras que los servidores de nombre secundario pueden aplicarse como servidores esclavos.

Un servidor autorizado indica su condición de suministrar respuestas definitivas, consideradas autorizada, estableciendo un indicador de software (un poco de la estructura del protocolo), llamado el Respuesta autorizada (AA) un poco en sus respuestas. Esta bandera generalmente figura prominentemente en la producción de herramientas de consulta de administración de DNS (tales como Cave) para indicar que el servidor de nombres respondieron a esta pregunta es una autoridad para el nombre de dominio en cuestión.

Operación

Mecanismo de resolución de dirección

Resoluciones de nombre de dominio para determinar una secuencia de consultas a partir de la etiqueta de dominio (nivel superior) más a la derecha los servidores de nombres de dominio responsables del nombre de dominio en cuestión.

Un DNS recursor consulta tres servidores de nombre para resolver la dirección www.copro.org.

El proceso implica:

1. Un host de red está configurado con un caché inicial (los llamados Consejos) de las direcciones de los servidores de nombres raíz conocidas. Un archivo indirecta se actualiza periódicamente por un administrador de una fuente confiable.
2. Una consulta a uno de los servidores raíz para encontrar el servidor autoritativo para el dominio de primer nivel.
3. Una consulta al servidor TLD obtenido por la dirección de un servidor DNS autoritativo para el dominio de segundo nivel.
4. Repetición del paso anterior para procesar cada etiqueta de nombre de dominio en secuencia, hasta el paso final que devuelve la dirección IP del host buscado.

El diagrama ilustra este proceso para el anfitrión www.copro.org.

El mecanismo en este sencillo formulario colocaría una gran carga operativa en los servidores raíz, con cada búsqueda para una dirección a partir mediante la consulta de uno de ellos. Siendo tan importante como son la función general del sistema, tal uso pesado crearía un cuello de botella insalvable para los millones de consultas colocadas todos los días. En la práctica almacenamiento en caché se utiliza en DNS servidores para superar este problema y como resultado, los servidores de nombre de raíz en realidad están involucrados con muy poco del tráfico total.

Recursivos y servidor de nombres de almacenamiento en caché

En teoría, los servidores de nombre autorizados son suficientes para el funcionamiento de la Internet. Sin embargo, con sólo servidores de nombres autoritarios de funcionamiento, cada consulta DNS debe comenzar con consultas recursivas en el zona de la raíz el Domain Name System y que cada usuario sistema tendría que implementar software de resolución capaz de operación recursiva.

Para mejorar la eficiencia, reducir el tráfico DNS a través de Internet y aumentar el rendimiento en las aplicaciones del usuario final, el Domain Name System compatible con servidores de caché DNS que almacenar los resultados de consulta DNS para un período de tiempo determinado en la configuración del registro de nombres de dominio en cuestión (time-to-live). Típicamente, tales almacenamiento en caché Servidores DNS, también llamados Cachés de DNS, también implementar el algoritmo recursivo necesario para resolver un nombre dado a partir de la raíz DNS a través de los servidores de nombres autoritarios del dominio consultado. Con esta función, implementada en el servidor de nombres, las aplicaciones de usuario ganan eficiencia en el diseño y operación.

Como ejemplo, si un cliente quiere saber la dirección de "www.example.com", enviará, a un servidor de nombres caché recursivo, una petición DNS afirmando que "Me gustaría la dirección IPv4 de 'www.example.com'". Luego se consulta el servidor de nombres recursivos servidores de nombres autoritarios hasta que se pone una respuesta a esa consulta (o retorno un error si no es posible obtener una respuesta)--en este caso 192.0.43.10.

La combinación de almacenamiento en caché de DNS y funciones recursivas en un servidor de nombres no es obligatoria; las funciones pueden implementarse independientemente en los servidores para fines especiales.

Proveedores de servicios de Internet proporcionan típicamente recursivos y almacenamiento en caché de los servidores de nombre para sus clientes. Además, muchos routers redes casa implementan cachés de DNS y recursors para mejorar la eficiencia de la red local.

Resoluciones DNS

Vea también: resolv.conf

El lado del cliente del DNS se llama a una resolución DNS. Es responsable de iniciar y secuenciación de las consultas que en última instancia conducen a una resolución completa (traducción) del recurso solicitado, por ejemplo, traducción de un nombre de dominio a una dirección IP.

Una consulta DNS puede ser una consulta recursiva no o una consulta recursiva:

• A consulta no recursiva es uno en el que el servidor DNS proporciona un registro de un dominio por lo que es autoridad propia, o proporciona un resultado parcial sin consultar a otros servidores.
• A consultas recursivas uno para que el servidor DNS totalmente a responder la consulta (o da un error) es mediante la consulta de otros servidores de nombres según sea necesario. Servidores DNS no están obligados a apoyar consultas recursivas.

La resolución, u otro servidor DNS representando el resolver, de forma recursiva negocia uso de servicio recursivo usando pedacitos en las cabeceras de consulta.

Resolución generalmente implica iterar a través de varios servidores de nombre para encontrar la información necesaria. Sin embargo, algunas resoluciones funcionan más simplemente por comunica solamente con un solo nombre. Estas resoluciones simples (llamadas "trozo resoluciones") dependen de un servidor de nombres recursivos para realizar el trabajo de encontrarlos.

Dependencias circulares y pegamento records

Servidores de nombres en las delegaciones se identifican por su nombre, en lugar de dirección IP. Esto significa que un servidor de nombres de resolución deberá emitir otra petición DNS para averiguar la dirección IP del servidor al que se ha hecho referencia. Si el nombre de la delegación es un subdominio del dominio para el que está procediendo a la delegación, hay un dependencia circular. En este caso el servidor de nombres proporciona la delegación debe proporcionar también una o más direcciones IP para el servidor de nombres autorizado mencionado en la delegación. Esta información se llama pegamento. El servidor de nombre delegar proporciona este pegamento en forma de registros en el sección adicional de la respuesta DNS y proporciona la delegación en el sección de autoridad de la respuesta.

Por ejemplo, si el servidor de nombres autorizado para ejemplo.org es ns1.example.org, una computadora tratando de resolver www.example.org primero resuelve ns1.example.org. Desde ns1 está contenida en ejemplo.org, esto requiere resolver ejemplo.org en primer lugar, que presenta una dependencia circular. Para romper la dependencia, el servidor de nombres para el dominio de nivel superior org incluye pegamento junto con la delegación para ejemplo.org. Los registros de pegamento son dirección que proporcionan direcciones IP para ns1.example.org. El resolutor utiliza uno o más de estas direcciones IP para consulta de uno de los servidores autoritativos de dominio, que permite completar la consulta DNS.

Almacenamiento en caché de registro

El proceso de resolución de DNS reduce la carga en los servidores individuales por almacenamiento en caché Registros de petición DNS para un período de tiempo después de una respuesta. Esto implica la grabación local y posterior consulta de la copia en lugar de iniciar una nueva solicitud de aguas arriba. El tiempo para que un resolutor almacena en caché una respuesta DNS está determinado por un valor llamado el tiempo para vivir (TTL) asociado con cada registro. El TTL es fijado por el administrador del servidor DNS distribuyendo la respuesta autoritaria. El período de validez puede variar desde pocos segundos a días o incluso semanas.

Como una consecuencia notable de esta arquitectura distribuida y almacenamiento en caché, cambios en los registros de DNS no se propagan a través de la red inmediatamente, pero requieren todos escondites a caducar y refrescarse después del TTL. RFC 1912 transmite reglas básicas para la determinación de los valores apropiados de la TTL.

Algunas resoluciones pueden omitir los valores TTL, como el protocolo de las ayudas de caché de hasta 68 años o sin almacenamiento en caché en absoluto. Negativa de caché, es decir, el almacenamiento en caché del hecho de la inexistencia de un registro, está determinada por los servidores de nombre autoritativos para una zona que debe incluir la Principio de autoridad Existe un registro (SOA) al no informar de ningún dato del tipo solicitado. El valor de la mínimo campo del registro SOA y el TTL de la SOA se utiliza para establecer el TTL para la respuesta negativa.

Búsqueda inversa

Una búsqueda inversa es una consulta al DNS para nombres de dominio cuando se conoce la dirección IP. Múltiples nombres de dominio se pueden asociar una dirección IP. El DNS almacena las direcciones IP en forma de nombres de dominio como nombres especialmente formateados en registros de puntero (PTR) dentro del dominio de nivel superior de infraestructura arpa. Para IPv4, el dominio es in-addr.arpa. Para IPv6, el dominio de búsqueda inversa es ip6.arpa. La dirección IP se representa como un nombre de representación reversa-ordenó octeto para IPv4 y representación reversa-ordenó nibble para IPv6.

Cuando se realiza una búsqueda inversa, el cliente DNS convierte la dirección en estos formatos antes de consultar el nombre para un registro PTR siguiendo la cadena de delegación en cuanto a cualquier consulta DNS. Por ejemplo, asumiendo la dirección IPv4 208.80.152.2 se asigna a Wikimedia, se representa como un nombre DNS en orden inverso: 2.152.80.208.in-addr.arpa. Cuando la resolución DNS recibe una solicitud de puntero (PTR), se inicia mediante la consulta a los servidores raíz, que apunten a los servidores de Registro americano para números de Internet (ARIN) para la zona de 208.in-addr.arpa. Los servidores de ARIN delegan 152.80.208.in-addr.arpa a Wikimedia para que la resolución envía otra consulta para 2.152.80.208.in-addr.arpa, que se traduce en una respuesta autorizada.

Búsqueda de cliente

Secuencia de resolución DNS

Los usuarios generalmente no se comunican directamente con una resolución DNS. En su lugar lleva a cabo transparentemente en aplicaciones tales como resolución de DNS navegadores web, clientes de correo electrónicoy otras aplicaciones de Internet. Cuando una aplicación hace una petición que requiere una búsqueda de nombres de dominio, tales programas deberán enviar una solicitud de resolución a la Resolución de DNS en el sistema operativo local, que a su vez encarga de las comunicaciones necesarias.

La resolución de DNS casi invariablemente tendrá una caché (véase más arriba) que contiene las búsquedas recientes. Si la memoria caché puede proporcionar la respuesta a la solicitud, el resolutor devolverá el valor en la memoria caché al programa que hizo la petición. Si la caché no contiene la respuesta, el resolutor enviará la solicitud a uno o más servidores DNS designados. En el caso de la mayoría de los usuarios domésticos, el proveedor de servicios de Internet al que se conecta la máquina generalmente suministrará este servidor DNS: tal usuario habrá configurado manualmente la dirección de ese servidor o permitido DHCP para configurarlo; Sin embargo, donde los administradores de sistemas han configurado sistemas para usar sus propios servidores DNS, su punto de resoluciones DNS para mantenido por separado los servidores de nombre de la organización. En cualquier caso, el servidor de nombres cuestionó así seguirá el proceso descrito por encima de, hasta que ya sea con éxito encuentra un resultado o no. Luego devuelve sus resultados a la resolución de DNS; Asumiendo que ha encontrado un resultado, el resolutor debidamente cachés ese resultado para su uso futuro y da el resultado detrás del software que inició la petición.

Resoluciones rotas

Algunos grandes ISPs han configurado sus servidores DNS para violar las reglas, como por desobedecer TTLs o indicando que un nombre de dominio no existe sólo porque uno de sus servidores de nombre no responde.

Algunas aplicaciones, como navegadores web, mantengan una caché DNS interna para evitar repetidas búsquedas mediante la red. Esta práctica puede agregar dificultad adicional cuando problemas de depuración de DNS, obscurece la historia de dichos datos. Estos escondites suelen utilizan muy cortos tiempos del orden de un minuto de caché.

Internet Explorer representa una excepción notable: versiones hasta IE 3.x en caché los registros DNS durante 24 horas por defecto. Internet Explorer 4.x y versiones posteriores (hasta IE 8) disminuyen el valor predeterminado de tiempo de espera a una media hora, que puede cambiarse en las claves del registro correspondiente.

Otras aplicaciones

El Domain Name System incluye varias otras funciones:

• Ningún requisito existe los nombres de host y direcciones IP deben coincidir en una uno-de-en moda. Múltiples nombres de host pueden corresponder a una única dirección IP y vice-versa. Hosting virtual en que una sola dirección se asocia con múltiples nombres de host permite un único servidor para servir a muchos sitios web. Alternativamente, un nombre de host único puede corresponder a muchas direcciones IP para facilitar tolerancia a fallos y distribución de la carga.
• DNS sirve para otros propósitos además de traducir nombres a direcciones IP. Por ejemplo, agentes de transferencia de correo Use DNS para encontrar el mejor servidor de correo entregar correo electrónico. El dominio al intercambiador de correo asignación proporcionado por Registros MX puede presentar una capa adicional de tolerancia a fallos y distribución de la carga.
• El DNS se utiliza para el almacenamiento eficiente y distribución de direcciones IP de servidores de correo electrónico en la lista negra. El método habitual es poner la dirección IP del host sujeto en el subdominio de un nombre de dominio de nivel superior y resolver ese nombre a los diferentes registros para indicar un positivo o una negativa indicaciones. Aquí es una ejemplo hipotético lista negra:
  • 102.3.4.5 está en la lista negra → crea 5.4.3.102.blacklist.example y resuelve a 127.0.0.1
  • 102.3.4.6 no es 6.4.3.102.blacklist.example → no se encuentra, o por defecto a 127.0.0.2
  • Servidores de correo electrónico pueden consultar entonces blacklist.example a través del mecanismo DNS para averiguar si un determinado host conectarse a ellas está en la lista negra. Hoy en día muchos de tales listas negras, gratis o suscripción, están disponibles principalmente para su uso por los administradores de correo electrónico y software anti-spam.
• Sender Policy Framework y DomainKeys, en lugar de crear sus propios tipos de registros, fueron diseñados para tomar ventaja de otro tipo de registro DNS, el Registro TXT.
• Para proporcionar capacidad de recuperación en caso de falla en la computadora, varios servidores DNS se proporcionan generalmente para la cobertura de cada dominio, y en el nivel superior, existen servidores de nombres raíz trece muy potente, con "copias adicionales" de varios de ellos distribuidos en todo el mundo a través Anycast.
• DNS dinámico (a veces llamada DDNS) permite a los clientes actualizar su entrada DNS como sus cambios de dirección IP, como lo hace, por ejemplo, cuando se mueve entre ISPs o móvil puntos calientes.
• Objetos de programación remotos DNS permite que un objeto programación remoto para acceder a través de búsqueda de DNS.

Formato de mensaje de DNS

Existen dos tipos de mensajes de DNS: preguntas y respuestas y ambos tienen el mismo formato. Cada mensaje se compone de una cabecera y cuatro secciones: pregunta, respuesta, autoridad y adicional. Las Rúbrica campo "banderas" controla el contenido de estas cuatro secciones pero la estructura de todos los mensajes DNS son los mismos.

La sección de encabezado contiene los campos: identificación, banderas, número de preguntas, número de respuestas, número de registros de autoridad de recursos (RR) y número de RRs adicionales. El campo de identificación consta de 16 bits que identifica la consulta. El cliente DNS puede emparejar una respuesta con una consulta usando este campo. El campo bandera consta de cuatro bits. El primer bit indica si el mensaje es una consulta (0) o una respuesta (1). La segunda parte se establece (sólo en los mensajes de respuesta) si un servidor DNS es autoritativo para el nombre de host consultado. La tercera parte se fija (1) cuando el cliente quiere enviar una consulta recursiva. El cuarto bit está establecido (1) en una respuesta si el servidor DNS respuesto admite recursividad, puesto que no todos los servidores DNS están configurados para realizar esta tarea. La sección pregunta tiene un campo nombre que es el nombre de host que está siendo consultado por y un campo de tipo que indica el tipo (A, AAAA, MX, etc.) que desea resolver. La sección de respuesta tiene los registros de recursos del nombre consultado. Puede haber varios registros si el nombre de host tiene múltiples direcciones IP asociadas con él.

Transporte de protocolo

DNS utiliza principalmente Protocolo de datagramas de usuario (UDP) en número de Puerto 53 para servir las peticiones. Las consultas DNS constan de una sola solicitud de UDP seguida de una sola respuesta UDP desde el servidor del cliente. El Transmission Control Protocol (TCP) se utiliza cuando el tamaño de datos respuesta supera los 512 bytes, o para tareas como transferencias de zona. Algunas implementaciones de resolutor utilizan TCP para todas las consultas.

Registros de recursos DNS

Para obtener más información: Lista de tipos de registros DNS

Un registro de recursos (RR) es el elemento de datos básicos en el sistema de nombres de dominio. Cada registro tiene un tipo (A, MX, etc.), un plazo de vencimiento, una clase y algunos datos específicos del tipo. Los registros de recursos del mismo tipo definen un conjunto de registros de recursos (RRset). El orden de los registros de recursos en un conjunto, devuelta por una resolución para una aplicación, no está definido, pero a menudo servidores implementan pedidos de round robin para lograr Equilibrio de carga de servidor global. DNSSEC, sin embargo, trabajos sobre el registro de recursos completa fija en un orden canónico.

Cuando se envían por una red IP, todos los registros utilizan el formato común especificado en RFC 1035:

Campos RR (registro de recursos)

Campo	Descripción	Longitud)octetos)
NOMBRE	Nombre del nodo al que se refiere este documento	(variable)
TIPO	Tipo de RR en forma numérica (por ejemplo 15 por RRs MX)	2
CLASE	Código de clase	2
TTL	Cuenta que el RR permanece válido (la máxima es de 2 segundos31-1, que es de unos 68 años)	4
RDLENGTH	Longitud de campo RDATA	2
RDATA	Datos adicionales específicos RR	(variable)

NOMBRE es el nombre de dominio completamente calificado del nodo en el árbol. En el cable, puede acortarse el nombre usando compresión etiqueta donde termina de nombres de dominio mencionados anteriormente en el paquete puede sustituirse por el final del nombre de dominio actual. Un pié @ se utiliza para denotar el origen actual.

TIPO es el tipo de registro. Indica el formato de los datos y da un toque de su uso previsto. Por ejemplo, la A registro se utiliza para traducir desde un nombre de dominio a un Dirección IPv4, la NS las listas de registro que servidores de nombres pueden responder consultas sobre un Zona DNSy el MX registro especifica el servidor de correo utilizado para manejar correo para un dominio especificado en una dirección de correo electrónico.

RDATA son datos de relevancia tipo-específicas, tales como la dirección IP para registros de direcciones, o la prioridad y nombre de host para registros MX. Conocidos tipos de registro pueden utilizar compresión de etiqueta en el campo RDATA, pero "desconocidos" tipos de registro deben no)RFC 3597).

El CLASE de un registro se establece en IN (para Internet) para DNS común de registros relacionados con los nombres de host de Internet, servidores, o IP direcciones. Además, las clases Caos (CH) y Hesíodo Existen (HS). Cada clase es un espacio de nombres independiente con delegaciones potencialmente diferentes de zonas DNS.

Además de los registros de recursos definidos en un archivo de zona, el sistema de nombres de dominio también define varios tipos de solicitudes que se utilizan sólo en la comunicación con otros (nodos) DNSen el alambre), tal como cuando zona realizando transferencias (AXFR/IXFR) o para EDNS (OPCIONAL).

Registros DNS wildcard

Es compatible con el sistema de nombres de dominio registros DNS comodín que especificar nombres que comienzan con la etiqueta de asterisco, ' *', por ejemplo, * .example. Los registros DNS pertenecientes a nombres de dominio comodín especifican reglas para la generación de registros de recursos dentro de una zona DNS sustituyendo toda etiquetas con componentes del nombre de la consulta, incluyendo cualquier descendientes especificados que emparejan. Por ejemplo, en la zona DNS x.example, la siguiente configuración especifica que todos los subdominios, incluyendo subdominios de subdominios, de x.example utilizar al intercambiador de correo a.x.example. Los registros de a.x.example son necesarios para especificar al intercambiador de correo. Como esto tiene el resultado de excluir este nombre de dominio y sus subdominios de los partidos de comodín, todos los subdominios de a.x.example debe definirse en una declaración separada comodín.

El papel de comodín registros fue refinado en RFC 4592, porque la definición original en RFC 1034 era incompleta y dio lugar a malas interpretaciones por los ejecutores.

Extensiones del protocolo

El protocolo DNS original había limitado las disposiciones para la extensión con las nuevas características. En 1999, Paul Vixie publicado en RFC 2671 un mecanismo de extensión, llamado Mecanismos de extensión para DNS (EDNS) introdujo elementos del Protocolo Facultativo sin aumentar la carga cuando no esté en uso. Esto se logró mediante el registro de pseudo recursos OPT que sólo existe en las transmisiones de alambre del protocolo, pero no en los archivos de zona. Extensiones iniciales también fueron sugeridas (EDNS0), como aumentar el tamaño del mensaje DNS en datagramas UDP.

Actualizaciones dinámicas de la zona

Actualizaciones dinámicas de DNS utilizar la operación de actualización DNS para agregar o quitar registros de recursos dinámicamente desde una base de datos de zona mantenida en un servidor DNS autorizado. La función se describe en RFC 2136. Esta instalación es útil para registrar a clientes de la red en el DNS cuando arranca o se disponga lo contrario en la red. Desde un cliente de arranque puede ser asignado una dirección IP diferente cada vez de un DHCP servidor, no es posible proporcionar asignaciones estáticas DNS para clientes.

Cuestiones de seguridad

Originalmente, las preocupaciones de seguridad no eran consideraciones de diseño importantes para software DNS o cualquier software para su implementación en Internet temprano, ya que la red no fue abierta a la participación del público en general. Sin embargo, la expansión de Internet en el sector comercial en la década de 1990 cambió los requisitos para las medidas de seguridad proteger la autenticación de usuario y la integridad de datos.

Varios problemas de vulnerabilidad fueron descubiertos y explotados por parte de usuarios maliciosos. Es un tema tan Envenenamiento de caché DNS, en que los datos se distribuyen a caché resoluciones bajo el pretexto de ser un servidor de origen autoritario, contaminando así los datos almacenan con información potencialmente falsa y largos tiempos de expiración (time-to-live). Posteriormente, las solicitudes de aplicación legítima pueden redirigirse a hosts de la red operadas con intenciones maliciosas.

Las respuestas de DNS son tradicionalmente no criptográficamente firmadas, llevando a muchas posibilidades de ataque; el Extensiones de seguridad de sistema de nombres de dominio (DNSSEC) modificar DNS para agregar compatibilidad con respuestas criptográficamente firmadas. DNSCurve se ha propuesto como una alternativa a DNSSEC. Otras extensiones, tales como TSIG, añadir soporte para autenticación criptográfica entre pares confianza y son comúnmente usados para autorizar la transferencia de zona o las operaciones de actualización dinámica.

Algunos nombres de dominio pueden utilizarse para conseguir efectos de suplantación. Por ejemplo, paypal.com y paypa1.com son nombres diferentes, sin embargo, los usuarios pueden ser incapaces de distinguir en una interfaz gráfica de usuario dependiendo del elegido del usuario tipo de letra. En muchas fuentes la carta l y el numeral 1 Mira muy similar o incluso idéntica. Este problema es agudo en sistemas que soportan nombres de dominio internacionalizados, desde muchos códigos de caracteres en ISO 10646, puede parecer idéntico en las pantallas de ordenador típico. Esta vulnerabilidad se explota ocasionalmente en "phishing".

Técnicas tales como DNS inverso hacia adelante-confirmado también puede utilizarse para ayudar a validar los resultados DNS.

Registro de nombres de dominio

El derecho a utilizar un nombre de dominio es delegado por los registradores de nombre de dominio que están acreditados por la Corporación de Internet para números y nombres asignados (ICANN) u otras organizaciones tales como OpenNIC, que está encargada de supervisar el nombre y el número de sistemas de Internet. Además de ICANN, cada dominio de primer nivel (TLD) se mantenga y mantenimiento técnico por una organización administrativa, un registro de funcionamiento. Un registro es responsable de mantener la base de datos de nombres registrados en el TLD que administra. El registro recibe información de registro de cada registrador de nombres de dominio autorizado para asignar nombres en el TLD correspondiente y publica la información usando un servicio especial, la WHOIS Protocolo.

ICANN publica la lista completa de los TLD registros y registradores de nombre de dominio. Información del registrante asociado con los nombres de dominio se mantiene en una base de datos en línea accesible con el servicio WHOIS. Para la mayoría de los más de 290 Dominios de nivel superior de código de país (ccTLD), los registros de dominio mantienen la información WHOIS (Registrante, servidores de nombres, fechas de caducidad, etc.). Por ejemplo, DENIC, Alemania NIC, contiene los datos de dominio DE. Desde el año 2001 aproximadamente, la mayoría gTLD Los registros (dominio de nivel superior genéricos) han adoptado este supuesto grueso enfoque de registro, es decir, mantener los datos WHOIS en registros centrales en vez de bases de datos de registro.

COM y NET de nombres de dominio, un Delgado modelo de registro es utilizado. El registro de dominio (por ejemplo, VeriSign) contiene los datos básicos de WHOIS (es decir, registro y nombre de servidores, etc.) Uno puede encontrar el WHOIS detallado (Registrante, servidores de nombres, fechas de caducidad, etc.) a los registradores.

Algunos registros de nombre de dominio, a menudo llamados red de centros de información (NIC), también funcionan como los registradores a los usuarios finales. Los registros de dominio de nivel superior genéricos principales, tales como los dominios COM, NET, ORG, INFO, utilizan un modelo de registro y registrador consiste en muchos registradores de nombre de dominio. En este método de gestión, el registro sólo administra la base de datos de nombre de dominio y la relación con los registradores. El registrantes (los usuarios de un nombre de dominio) son clientes del registrador, en algunos casos mediante capas adicionales de revendedores.

Estándares de Internet

El sistema de nombres de dominio se define por Solicitud de comentarios (RFC) documentos publicados por el Internet Engineering Task Force (Estándares de Internet). La siguiente es una lista de RFC que define el protocolo DNS.

• RFC 920, Requisitos de dominio – Dominios de nivel superior originales especificados
• RFC 1032, Guía del administrador de dominio
• RFC 1033, Guía de operaciones de los administradores de dominio
• RFC 1034, Los nombres de dominio - conceptos e instalaciones
• RFC 1035, Nombres de dominio - implementación y especificación
• RFC 1101, DNS codificaciones de nombres de red y otros tipos
• RFC 1123, Requisitos para Hosts Internet — aplicación y soporte
• RFC 1178, Elegir un nombre para tu ordenador (FYI 5)
• RFC 1183, Nuevas definiciones de DNS RR
• RFC 1591, Delegación y estructura de sistema de nombre de dominio (Informativo)
• RFC 1912, DNS común operativa y errores de configuración
• RFC 1995, Transferencia de zona incremental en DNS
• RFC 1996, Un mecanismo para la pronta notificación de cambios de zona (notificar DNS)
• RFC 2100, El nombramiento de los ejércitos (Informativo)
• RFC 2136, Actualizaciones dinámicas en el domain name system (DNS UPDATE)
• RFC 2181, Aclaraciones a la especificación de DNS
• RFC 2182, Selección y operación de los servidores DNS secundario
• RFC 2308, Negativa de almacenamiento en caché de consultas DNS (DNS NCACHE)
• RFC 2317, Categoría "Classless" IN-ADDR.Delegación de ARPA (BCP 20)
• RFC 2671, Mecanismos de extensión para DNS (EDNS0)
• RFC 2672, Redirección de nombre DNS no Terminal
• RFC 2845, Autenticación de transacciones clave secreta para el DNS (TSIG)
• RFC 3225, Indicando la resolución apoyo de DNSSEC
• RFC 3226, DNSSEC y IPv6 A6 requisitos de tamaño de mensaje consciente de servidor/resolución
• RFC 3597, Manejo de tipos de registro (RR) de recursos DNS desconocido
• RFC 3696, Técnicas de aplicación para el control y la transformación de nombres (Informativo)
• RFC 4343, Nombre de dominio sistema (DNS) caso insensibilidad aclaración
• RFC 4592, El papel de comodines en el Domain Name System
• RFC 4635, Identificadores de algoritmo HMAC SHA TSIG
• RFC 4892, Necesidad de un mecanismo de identificación de una instancia de servidor de nombre (Informativo)
• RFC 5001, Opción DNS Name Server identificador (NSID)
• RFC 5452, Medidas para hacer más resistentes contra forjadas respuestas DNS
• RFC 5625, Directrices para la aplicación Proxy DNS (BCP 152)
• RFC 5890, Para las aplicaciones (IDNA) los nombres de dominio internacionalizados: documento marco y definiciones
• RFC 5891, Internacionalización de nombres de dominio en aplicaciones (IDNA): Protocolo
• RFC 5892, Los puntos de código Unicode y nombres de dominio internacionalizados para aplicaciones (IDNA)
• RFC 5893, Secuencias de comandos de derecha a izquierda para nombres de dominio internacionalizados para aplicaciones (IDNA)
• RFC 5894, Para las aplicaciones (IDNA) los nombres de dominio internacionalizados: fondo, explicación y justificación (Informativo)
• RFC 5895, Mapeo de caracteres para nombres de dominio internacionalizados en aplicaciones (IDNA) 2008 (Informativo)
• RFC 5966, Transporte de DNS sobre TCP - requisitos de aplicación
• RFC 6195, Nombre de dominio (DNS) sistema IANA consideraciones (BCP 42)

Seguridad

• RFC 4033, Los requisitos y la introducción de seguridad DNS
• RFC 4034, Registros de recursos para las extensiones de seguridad DNS
• RFC 4035, Protocolo modificaciones para las extensiones de seguridad DNS
• RFC 4509, Uso de SHA-256 en registros de recursos DNSSEC delegación firmante (DS)
• RFC 4470, Cubriendo mínimamente registros NSEC y DNSSEC firma on-line
• RFC 5011, Actualizaciones automatizadas de DNS (DNSSEC) seguridad confianza anclas
• RFC 5155, Seguridad DNS (DNSSEC) hash autenticado la negación de la existencia
• RFC 5702, Uso de algoritmos SHA-2 con RSA en registros de recursos RRSIG y DNSKEY para DNSSEC
• RFC 5910, Dominio (DNS) sistema seguridad extensiones mapeo del protocolo Extensible de aprovisionamiento (EPP)
• RFC 5933, Uso de algoritmos de firma GOST en registros de recursos RRSIG y DNSKEY para DNSSEC

Véase también

• Raíz DNS alternativo
• Comparación de software de servidor DNS
• Secuestro de DNS
• Software de administración de DNS
• Lista de tipos de registros DNS
• Lista de proveedores DNS gestionados
• IPv6 quebrantamiento y lista blanca DNS
• Multicast DNS
• Horizonte dividido DNS

Enlaces externos

• Vixie, Paul (2007-04-01). "Complejidad DNS". ACM Queue.
• Zytrax.com, Abrir fuente guía – DNS para científicos.
• Sistema de nombres de dominio en Microsoft TechNet
• Gobernanza de Internet y el dominio nombre sistema: ediciones para el Congreso Servicio de investigación del Congreso
• Bola, James (28 de febrero de 2014). "Conocer a las siete personas que tienen la llave de seguridad en internet en todo el mundo". El guardián (Guardian News & Media Limited). 28 de febrero 2014.

Otras Páginas

• Craie tufau
• Inactivacion de X
• Voz sobre IP (redireccion de marcacion Backdoor)
• Rheumaptera
• TPI-teoria
• Pleuresia (seccion computarizada (tomografia CT))