Sistema de nombres de dominio

El Sistema de nombres de dominio (DNS) es un sistema de nombres jerárquico y distribuido para computadoras, servicios y otros recursos en Internet u otras redes de Protocolo de Internet (IP).. Asocia diversa información con los nombres de dominio asignados a cada una de las entidades asociadas. Lo más destacado es que traduce los nombres de dominio fácilmente memorizados a las direcciones IP numéricas necesarias para ubicar e identificar los servicios y dispositivos informáticos con los protocolos de red subyacentes. El Sistema de Nombres de Dominio ha sido un componente esencial de la funcionalidad de Internet desde 1985.

El Sistema de Nombres de Dominio delega la responsabilidad de asignar nombres de dominio y asignar esos nombres a los recursos de Internet mediante la designación de servidores de nombres autorizados para cada dominio. Los administradores de red pueden delegar la autoridad sobre los subdominios de su espacio de nombres asignado a otros servidores de nombres. Este mecanismo proporciona un servicio tolerante a fallas y distribuido y fue diseñado para evitar una sola base de datos central grande.

El Sistema de Nombres de Dominio también especifica la funcionalidad técnica del servicio de base de datos que es su núcleo. Define el protocolo DNS, una especificación detallada de las estructuras de datos y los intercambios de comunicación de datos utilizados en el DNS, como parte del conjunto de protocolos de Internet.

Internet mantiene dos espacios de nombres principales, la jerarquía de nombres de dominio y los espacios de direcciones del Protocolo de Internet (IP). El Sistema de Nombres de Dominio mantiene la jerarquía de nombres de dominio y proporciona servicios de traducción entre este y los espacios de direcciones. Los servidores de nombres de Internet y un protocolo de comunicación implementan el Sistema de Nombres de Dominio. Un servidor de nombres DNS es un servidor que almacena los registros DNS de un dominio; un servidor de nombres DNS responde con respuestas a consultas en su base de datos.

Los tipos más comunes de registros almacenados en la base de datos DNS son para inicio de autoridad (SOA), direcciones IP (A y AAAA), intercambiadores de correo SMTP (MX), servidores de nombres (NS), punteros para búsquedas inversas de DNS (PTR) y alias de nombre de dominio (CNAME). Aunque no pretende ser una base de datos de propósito general, DNS se ha ampliado con el tiempo para almacenar registros de otros tipos de datos para búsquedas automáticas, como registros DNSSEC, o para consultas humanas como persona responsable (RP) registros. Como base de datos de propósito general, el DNS también se ha utilizado para combatir el correo electrónico no solicitado (spam) mediante el almacenamiento de una lista de agujeros negros en tiempo real (RBL). La base de datos DNS se almacena tradicionalmente en un archivo de texto estructurado, el archivo de zona, pero son comunes otros sistemas de bases de datos.

El Sistema de nombres de dominio utilizó originalmente el Protocolo de datagramas de usuario (UDP) como transporte sobre IP. Los problemas de confiabilidad, seguridad y privacidad generaron el uso del Protocolo de control de transmisión (TCP), así como muchos otros desarrollos de protocolo.

Función

Una analogía que se usa a menudo para explicar el DNS es que sirve como guía telefónica para Internet al traducir los nombres de host de las computadoras en direcciones IP. Por ejemplo, el nombre de host www.example.com dentro del nombre de dominio example.com se traduce en las direcciones 93.184.216.34 (IPv4) y 2606:2800:220:1:248:1893:25c8:1946 (IPv6). El DNS se puede actualizar de forma rápida y transparente, lo que permite cambiar la ubicación de un servicio en la red sin afectar a los usuarios finales, que siguen utilizando el mismo nombre de host. Los usuarios aprovechan esto cuando utilizan localizadores uniformes de recursos (URL) y direcciones de correo electrónico sin tener que saber cómo localiza realmente la computadora los servicios.

Una función importante y omnipresente del DNS es su función central en los servicios de Internet distribuidos, como los servicios en la nube y las redes de entrega de contenido. Cuando un usuario accede a un servicio de Internet distribuido a través de una URL, el nombre de dominio de la URL se traduce a la dirección IP de un servidor cercano al usuario. La funcionalidad clave del DNS explotado aquí es que diferentes usuarios pueden simultáneamente recibir diferentes traducciones para el mismo nombre de dominio, un punto clave de divergencia con la visión tradicional de guía telefónica de el DNS. Este proceso de usar el DNS para asignar servidores proximales a los usuarios es clave para brindar respuestas más rápidas y confiables en Internet y es ampliamente utilizado por la mayoría de los principales servicios de Internet.

El DNS refleja la estructura de responsabilidad administrativa en Internet. Cada subdominio es una zona de autonomía administrativa delegada a un administrador. Para las zonas operadas por un registro, la información administrativa a menudo se complementa con los servicios RDAP y WHOIS del registro. Esos datos se pueden usar para obtener información y rastrear la responsabilidad de un host determinado en Internet.

Historia

El uso de un nombre más simple y fácil de recordar en lugar de la dirección numérica de un host se remonta a la era de ARPANET. El Instituto de Investigación de Stanford (ahora SRI International) mantuvo un archivo de texto llamado HOSTS.TXT que asignaba nombres de host a las direcciones numéricas de las computadoras en ARPANET. Elizabeth Feinler desarrolló y mantuvo el primer directorio ARPANET. Jon Postel del Instituto de Ciencias de la Información (ISI) de la Universidad del Sur de California, cuyo equipo trabajó en estrecha colaboración con SRI, se encargó del mantenimiento de las direcciones numéricas, denominada Lista de números asignados.

Las direcciones se asignaron manualmente. Las computadoras, incluidos sus nombres de host y direcciones, se agregaron al archivo principal comunicándose con el Centro de información de la red (NIC) de SRI, dirigido por Feinler, por teléfono durante el horario comercial. Más tarde, Feinler configuró un directorio de WHOIS en un servidor en la NIC para recuperar información sobre recursos, contactos y entidades. Ella y su equipo desarrollaron el concepto de dominios. Feinler sugirió que los dominios deberían basarse en la ubicación de la dirección física de la computadora. Las computadoras en las instituciones educativas tendrían el dominio edu, por ejemplo. Ella y su equipo administraron el Registro de nombres de host desde 1972 hasta 1989.

A principios de la década de 1980, mantener una única tabla de host centralizada se había vuelto lento y difícil de manejar, y la red emergente requería un sistema de nombres automatizado para abordar los problemas técnicos y de personal. Postel dirigió la tarea de forjar un compromiso entre cinco propuestas de soluciones en competencia a Paul Mockapetris. En cambio, Mockapetris creó el Sistema de Nombres de Dominio en 1983 mientras estaba en la Universidad del Sur de California.

El Grupo de trabajo de ingeniería de Internet publicó las especificaciones originales en RFC 882 y RFC 883 en noviembre de 1983. Estas se actualizaron en RFC 973 en enero de 1986.

En 1984, cuatro estudiantes de UC Berkeley, Douglas Terry, Mark Painter, David Riggle y Songnian Zhou, escribieron la primera implementación del servidor de nombres Unix para el dominio de nombres de Internet de Berkeley, comúnmente conocido como BIND. En 1985, Kevin Dunlap de DEC revisó sustancialmente la implementación de DNS. Mike Karels, Phil Almquist y Paul Vixie luego se hicieron cargo del mantenimiento de BIND. Internet Systems Consortium fue fundado en 1994 por Rick Adams, Paul Vixie y Carl Malamud, expresamente para proporcionar un hogar para el desarrollo y mantenimiento de BIND. Las versiones de BIND desde la 4.9.3 en adelante fueron desarrolladas y mantenidas por ISC, con el apoyo proporcionado por los patrocinadores de ISC. Como co-arquitectos/programadores, Bob Halley y Paul Vixie lanzaron la primera versión lista para producción de BIND versión 8 en mayo de 1997. Desde 2000, más de 43 desarrolladores principales diferentes han trabajado en BIND.

En noviembre de 1987, RFC 1034 y RFC 1035 reemplazaron las especificaciones de DNS de 1983. Varias Solicitudes de Comentarios adicionales han propuesto extensiones a los protocolos centrales de DNS.

Estructura

Espacio de nombres de dominio

El espacio de nombres de dominio consta de una estructura de datos de árbol. Cada nodo u hoja del árbol tiene una etiqueta y cero o más registros de recursos (RR), que contienen información asociada con el nombre de dominio. El nombre de dominio en sí consta de la etiqueta, concatenada con el nombre de su nodo principal a la derecha, separada por un punto.

El árbol se subdivide en zonas comenzando en la zona raíz. Una zona DNS puede constar de tantos dominios y subdominios como elija el administrador de la zona. El DNS también se puede particionar de acuerdo con clase, donde las clases separadas se pueden considerar como una matriz de árboles de espacios de nombres paralelos.

Sistema jerárquico de Nombre de Dominio para la clase Internet, organizado en zonas, cada uno servido por un servidor de nombres

La responsabilidad administrativa de cualquier zona se puede dividir mediante la creación de zonas adicionales. Se dice que la autoridad sobre la nueva zona se delega a un servidor de nombres designado. La zona principal deja de tener autoridad para la nueva zona.

Sintaxis de nombres de dominio, internacionalización

Las descripciones definitivas de las reglas para formar nombres de dominio aparecen en RFC 1035, RFC 1123, RFC 2181 y RFC 5892. Un nombre de dominio consta de una o más partes, denominadas técnicamente etiquetas, que están concatenados convencionalmente y delimitados por puntos, como ejemplo.com.

La etiqueta más a la derecha transmite el dominio de nivel superior; por ejemplo, el nombre de dominio www.example.com pertenece al dominio de nivel superior com.

La jerarquía de dominios desciende de derecha a izquierda; cada etiqueta a la izquierda especifica una subdivisión o subdominio del dominio a la derecha. Por ejemplo, la etiqueta ejemplo especifica un subdominio del dominio com y www es un subdominio de ejemplo.com. Este árbol de subdivisiones puede tener hasta 127 niveles.

Una etiqueta puede contener de cero a 63 caracteres. La etiqueta nula, de longitud cero, está reservada para la zona raíz. El nombre de dominio completo no podrá exceder 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.

Aunque no existe ninguna limitación técnica para evitar que las etiquetas de nombres de dominio utilicen cualquier carácter que se pueda representar mediante un octeto, los nombres de host utilizan un formato y conjunto de caracteres preferidos. Los caracteres permitidos en las etiquetas son un subconjunto del juego de caracteres ASCII, que consta de caracteres a a z, A a Z, dígitos 0 a 9 y guión. Esta regla se conoce como la regla LDH (letras, dígitos, guión). Los nombres de dominio se interpretan independientemente de las mayúsculas y minúsculas. Las etiquetas no pueden comenzar ni terminar con un guión. Una regla adicional requiere que los nombres de dominio de nivel superior no sean solo numéricos.

El conjunto limitado de caracteres ASCII permitidos en el DNS impidió la representación de nombres y palabras de muchos idiomas en sus alfabetos o escrituras nativos. Para que esto sea posible, la ICANN aprobó el sistema de internacionalización de nombres de dominio en aplicaciones (IDNA), mediante el cual las aplicaciones de los usuarios, como los navegadores web, asignan cadenas Unicode al conjunto de caracteres DNS válido mediante Punycode. En 2009, la ICANN aprobó la instalación de dominios de nivel superior (ccTLD) con código de país de nombres de dominio internacionalizados. Además, muchos registros de los nombres de dominio de nivel superior (TLD) existentes han adoptado el sistema IDNA, guiados por RFC 5890, RFC 5891, RFC 5892, RFC 5893.

Servidores de nombres

El Sistema de Nombres de Dominio se mantiene mediante un sistema de base de datos distribuida, que utiliza el modelo cliente-servidor. Los nodos de esta base de datos son los servidores de nombres. Cada dominio tiene al menos un servidor DNS autorizado que publica información sobre ese dominio y los servidores de nombres de cualquier dominio subordinado a él. La parte superior de la jerarquía está a cargo de los servidores de nombres raíz, los servidores para consultar al buscar (resolver) un TLD.

Servidor de nombres autorizado

Un servidor de nombres autorizado es un servidor de nombres que solo da respuestas a consultas de DNS a partir de datos que han sido configurados por una fuente original, por ejemplo, el administrador del dominio o por métodos de DNS dinámicos, en contraste a las respuestas obtenidas a través de una consulta a otro servidor de nombres que solo mantiene un caché de datos.

Un servidor de nombres autorizado puede ser un servidor primario o un servidor secundario. Históricamente, los términos maestro/esclavo y primario/secundario a veces se usaban indistintamente, pero la práctica actual es usar la última forma. Un servidor principal es un servidor que almacena las copias originales de todos los registros de zona. Un servidor secundario utiliza un mecanismo especial de actualización automática en el protocolo DNS en comunicación con su servidor primario para mantener una copia idéntica de los registros primarios.

A cada zona DNS se le debe asignar un conjunto de servidores de nombres autorizados. Este conjunto de servidores se almacena en la zona de dominio principal con registros de servidor de nombres (NS).

Un servidor autorizado indica su estado de suministro de respuestas definitivas, consideradas autorizadas, mediante la configuración de un indicador de protocolo, denominado "Respuesta autorizada" (AA) bit en sus respuestas. Este indicador suele reproducirse de forma destacada en el resultado de las herramientas de consulta de administración de DNS, como dig, para indicar que el servidor de nombres que responde es una autoridad para el nombre de dominio en cuestión.

Cuando un servidor de nombres se designa como el servidor autorizado para un nombre de dominio para el que no tiene datos autorizados, presenta un tipo de error llamado "delegación lame" o "respuesta poco convincente".

Operación

Mecanismo de resolución de direcciones

Los solucionadores de nombres de dominio determinan los servidores de nombres de dominio responsables del nombre de dominio en cuestión mediante una secuencia de consultas que comienzan con la etiqueta de dominio más a la derecha (nivel superior).

Una resolución DNS que implementa el enfoque iterativo encomendado por RFC 1034; en este caso, la resolución consulta tres servidores de nombres para resolver el nombre de dominio plenamente calificado "www.wikipedia.org".

Para el correcto funcionamiento de su resolución de nombres de dominio, un host de red se configura con un caché inicial (sugerencias) de las direcciones conocidas de los servidores de nombres raíz. Un administrador actualiza periódicamente las sugerencias recuperando un conjunto de datos de una fuente confiable.

Suponiendo que la resolución no tenga registros en caché para acelerar el proceso, el proceso de resolución comienza con una consulta a uno de los servidores raíz. En una operación típica, los servidores raíz no responden directamente, sino que responden con una referencia a servidores más autorizados, por ejemplo, una consulta para "www.wikipedia.org" se remite a los servidores org. El resolutor ahora consulta los servidores a los que se hace referencia y repite iterativamente este proceso hasta que recibe una respuesta autorizada. El diagrama ilustra este proceso para el host cuyo nombre de dominio completo es "www.wikipedia.org".

Este mecanismo generaría una gran carga de tráfico en los servidores raíz, si todas las resoluciones en Internet requirieran comenzar desde la raíz. En la práctica, el almacenamiento en caché se usa en los servidores DNS para descargar los servidores raíz y, como resultado, los servidores de nombres raíz en realidad están involucrados solo en una fracción relativamente pequeña de todas las solicitudes.

Servidor de nombres recursivo y de almacenamiento en caché

En teoría, los servidores de nombres autorizados son suficientes para el funcionamiento de Internet. Sin embargo, con solo servidores de nombres autorizados en funcionamiento, cada consulta de DNS debe comenzar con consultas recursivas en la zona raíz del Sistema de nombres de dominio y cada sistema de usuario tendría que implementar un software de resolución capaz de operar recursivamente.

Para mejorar la eficiencia, reducir el tráfico de DNS a través de Internet y aumentar el rendimiento en las aplicaciones de los usuarios finales, el Sistema de nombres de dominio admite servidores de caché de DNS que almacenan los resultados de las consultas de DNS durante un período de tiempo determinado en la configuración (tiempo -to-live) del registro de nombre de dominio en cuestión. Por lo general, dichos servidores DNS de almacenamiento en caché también implementan el algoritmo recursivo necesario para resolver un nombre dado, comenzando con la raíz DNS hasta los servidores de nombres autorizados del dominio consultado. Con esta función implementada en el servidor de nombres, las aplicaciones de usuario ganan eficiencia en diseño y operación.

La combinación de almacenamiento en caché de DNS y funciones recursivas en un servidor de nombres no es obligatoria; las funciones se pueden implementar de forma independiente en servidores para fines especiales.

Los proveedores de servicios de Internet suelen proporcionar servidores de nombres recursivos y de almacenamiento en caché para sus clientes. Además, muchos enrutadores de redes domésticas implementan cachés de DNS y recursividad para mejorar la eficiencia en la red local.

Resolutores de DNS

El lado del cliente del DNS se denomina resolución de DNS. Un resolutor es responsable de iniciar y secuenciar las consultas que finalmente conducen a una resolución completa (traducción) del recurso buscado, por ejemplo, la traducción de un nombre de dominio a una dirección IP. Los solucionadores de DNS se clasifican según una variedad de métodos de consulta, como recursivo, no recursivo e iterativo. Un proceso de resolución puede utilizar una combinación de estos métodos.

En una consulta no recursiva, un solucionador de DNS consulta un servidor DNS que proporciona un registro para el cual el servidor tiene autoridad o proporciona un resultado parcial sin consultar a otros servidores. En el caso de un sistema de resolución de DNS de almacenamiento en caché, la consulta no recursiva de su caché DNS local ofrece un resultado y reduce la carga en los servidores DNS ascendentes al almacenar en caché los registros de recursos DNS durante un período de tiempo después de una respuesta inicial de los servidores DNS ascendentes.

En una consulta recursiva, un solucionador de DNS consulta un solo servidor DNS, que a su vez puede consultar otros servidores DNS en nombre del solicitante. Por ejemplo, una resolución de código auxiliar simple que se ejecuta en un enrutador doméstico generalmente realiza una consulta recursiva al servidor DNS ejecutado por el ISP del usuario. Una consulta recursiva es aquella en la que el servidor DNS responde a la consulta por completo consultando a otros servidores de nombres según sea necesario. En una operación típica, un cliente emite una consulta recursiva a un servidor DNS recursivo de almacenamiento en caché, que posteriormente emite consultas no recursivas para determinar la respuesta y enviar una sola respuesta al cliente. El resolutor, u otro servidor DNS que actúa recursivamente en nombre del resolutor, negocia el uso del servicio recursivo utilizando bits en los encabezados de consulta. Los servidores DNS no están obligados a admitir consultas recursivas.

El procedimiento de consulta iterativa es un proceso en el que un sistema de resolución de DNS consulta una cadena de uno o más servidores DNS. Cada servidor remite al cliente al siguiente servidor de la cadena, hasta que el servidor actual pueda resolver completamente la solicitud. Por ejemplo, una posible resolución de www.example.com consultaría un servidor raíz global, luego un "com" servidor y, finalmente, un "example.com" servidor.

Dependencias circulares y registros de unión

Los servidores de nombres en las delegaciones se identifican por nombre, en lugar de por dirección IP. Esto significa que un servidor de nombres de resolución debe emitir otra solicitud de DNS para averiguar la dirección IP del servidor al que se ha referido. Si el nombre proporcionado en la delegación es un subdominio del dominio para el que se proporciona la delegación, existe una dependencia circular.

En este caso, el servidor de nombres que proporciona la delegación también debe proporcionar 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 nombres que delega proporciona este pegamento en forma de registros en la sección adicional de la respuesta DNS y proporciona la delegación en la sección de autoridad de la respuesta. Un registro de conexión es una combinación del servidor de nombres y la dirección IP.

Por ejemplo, si el servidor de nombres autorizado para example.org es ns1.example.org, una computadora que intente resolver www.example.org primero resuelve ns1.example.org. Como ns1 está contenido en example.org, esto requiere resolver primero example.org, que presenta una dependencia circular. Para romper la dependencia, el servidor de nombres para la organización de dominio de nivel superior incluye pegamento junto con la delegación para ejemplo.org. Los registros de conexión son registros de direcciones que proporcionan direcciones IP para ns1.example.org. El resolutor usa una o más de estas direcciones IP para consultar uno de los servidores autorizados del dominio, lo que le permite completar la consulta de DNS.

Almacenamiento en caché de registros

Una práctica estándar para implementar la resolución de nombres en las aplicaciones es reducir la carga en los servidores del sistema de nombres de dominio mediante el almacenamiento en caché de los resultados localmente o en hosts de resolución intermedios. Los resultados obtenidos de una solicitud de DNS siempre se asocian con el tiempo de vida (TTL), un tiempo de vencimiento después del cual los resultados deben descartarse o actualizarse. El TTL lo establece el administrador del servidor DNS autorizado. El período de validez puede variar desde unos pocos segundos hasta días o incluso semanas.

Como resultado de esta arquitectura de almacenamiento en caché distribuido, los cambios en los registros DNS no se propagan por toda la red inmediatamente, sino que requieren que todos los cachés caduquen y se actualicen después del TTL. RFC 1912 transmite reglas básicas para determinar los valores TTL apropiados.

Algunos resolutores pueden anular los valores TTL, ya que el protocolo admite el almacenamiento en caché durante un máximo de sesenta y ocho años o ningún almacenamiento en caché. El almacenamiento en caché negativo, es decir, el almacenamiento en caché del hecho de la inexistencia de un registro, lo determinan los servidores de nombres autorizados para una zona que debe incluir el registro de inicio de autoridad (SOA) cuando se informa que no existen datos del tipo solicitado. El valor del campo mínimo del registro SOA y el TTL de la propia SOA se utiliza para establecer el TTL para la respuesta negativa.

Búsqueda inversa

Una búsqueda DNS inversa es una consulta del DNS para nombres de dominio cuando se conoce la dirección IP. Se pueden asociar varios nombres de dominio con una dirección IP. El DNS almacena direcciones IP en forma de nombres de dominio como nombres con formato especial en registros de puntero (PTR) dentro del dominio de nivel superior de la 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 en representación de octetos en orden inverso para IPv4 y representación de nibble en orden inverso para IPv6.

Al realizar una búsqueda inversa, el cliente DNS convierte la dirección a estos formatos antes de consultar el nombre de un registro PTR siguiendo la cadena de delegación como para cualquier consulta DNS. Por ejemplo, suponiendo que 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 el sistema de resolución de DNS recibe una solicitud de puntero (PTR), comienza consultando los servidores raíz, que apuntan a los servidores del Registro Americano de Números de Internet (ARIN) para la zona 208.in-addr.arpa. Los servidores de ARIN delegan 152.80.208.in-addr.arpa a Wikimedia, a lo que el resolutor envía otra consulta para 2.152.80.208.in-addr.arpa, lo que da como resultado una respuesta autorizada.

Búsqueda de clientes

secuencia de resolución DNS

Por lo general, los usuarios no se comunican directamente con un solucionador de DNS. En cambio, la resolución de DNS se lleva a cabo de forma transparente en aplicaciones como navegadores web, clientes de correo electrónico y otras aplicaciones de Internet. Cuando una aplicación realiza una solicitud que requiere una búsqueda de nombre de dominio, dichos programas envían una solicitud de resolución al sistema de resolución de DNS en el sistema operativo local, que a su vez maneja las comunicaciones requeridas.

La resolución de DNS casi siempre tendrá un caché (ver arriba) que contiene búsquedas recientes. Si la memoria caché puede proporcionar la respuesta a la solicitud, el resolutor devolverá el valor de la memoria caché al programa que realizó la solicitud. 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 proporcionará este servidor DNS: dicho usuario habrá configurado la dirección de ese servidor manualmente o permitirá que DHCP la configure; sin embargo, cuando los administradores de sistemas han configurado sistemas para usar sus propios servidores DNS, sus resolutores de DNS apuntan a servidores de nombres mantenidos por separado de la organización. En cualquier caso, el servidor de nombres así consultado seguirá el proceso descrito anteriormente, hasta que encuentre un resultado con éxito o no lo encuentre. Luego devuelve sus resultados al sistema de resolución de DNS; suponiendo que haya encontrado un resultado, el resolutor almacena debidamente ese resultado para uso futuro y devuelve el resultado al software que inició la solicitud.

Resolutores rotos

Algunos ISP grandes han configurado sus servidores DNS para violar las reglas, como desobedecer los TTL o indicar que un nombre de dominio no existe solo porque uno de sus servidores de nombres no responde.

Algunas aplicaciones, como los navegadores web, mantienen una caché DNS interna para evitar búsquedas repetidas a través de la red. Esta práctica puede agregar dificultad adicional al depurar problemas de DNS, ya que oscurece el historial de dichos datos. Estos cachés suelen utilizar tiempos de almacenamiento en caché muy cortos, del orden de un minuto.

Internet Explorer representa una notable excepción: las versiones hasta IE 3.x almacenan en caché los registros DNS durante 24 horas de forma predeterminada. Internet Explorer 4.xy versiones posteriores (hasta IE 8) reducen el valor de tiempo de espera predeterminado a media hora, que se puede cambiar modificando la configuración predeterminada.

Cuando Google Chrome detecta problemas con el servidor DNS, muestra un mensaje de error específico.

Otras aplicaciones

El Sistema de Nombres de Dominio incluye varias otras funciones y características.

No es necesario que los nombres de host y las direcciones IP coincidan en una relación de uno a uno. Múltiples nombres de host pueden corresponder a una sola dirección IP, lo cual es útil en el alojamiento virtual, en el que muchos sitios web se sirven desde un solo host. Alternativamente, un solo nombre de host puede resolverse en muchas direcciones IP para facilitar la tolerancia a fallas y la distribución de carga a múltiples instancias de servidor en una empresa o Internet global.

DNS sirve para otros fines además de traducir nombres a direcciones IP. Por ejemplo, los agentes de transferencia de correo utilizan DNS para encontrar el mejor servidor de correo para entregar el correo electrónico: un registro MX proporciona una asignación entre un dominio y un intercambiador de correo; esto puede proporcionar una capa adicional de tolerancia a fallas y distribución de carga.

El DNS se utiliza para el almacenamiento y la distribución eficientes de las direcciones IP de los hosts de correo electrónico incluidos en la lista negra. Un método común es colocar la dirección IP del host en cuestión en el subdominio de un nombre de dominio de nivel superior y resolver ese nombre en un registro que indique una indicación positiva o negativa.

Por ejemplo:

• La dirección 102.3.4.5 está lista negra. Indica 5.4.3.102.negrolist.example, que resuelve 127.0.0.1.
• La dirección 102.3.4.6 no está lista negra y apunta a 6.4.3.102.blacklist.example. Este nombre de host no está configurado, o se resuelve a 127.0.0.2.

Los servidores de correo electrónico pueden consultar blacklist.example para averiguar si un host específico que se conecta a ellos está en la lista negra. Muchas de estas listas negras, ya sea por suscripción o gratuitas, están disponibles para que las utilicen los administradores de correo electrónico y el software antispam.

Para brindar resiliencia en caso de falla de la computadora o la red, generalmente se proporcionan varios servidores DNS para cubrir cada dominio. En el nivel superior del DNS global, existen trece grupos de servidores de nombres raíz, con "copias" de ellos distribuidos en todo el mundo a través de direccionamiento anycast.

El DNS dinámico (DDNS) actualiza un servidor DNS con una dirección IP de cliente sobre la marcha, por ejemplo, cuando se mueve entre ISP o hotspots móviles, o cuando la dirección IP cambia administrativamente.

Formato de mensaje DNS

El protocolo DNS utiliza dos tipos de mensajes DNS, consultas y respuestas; ambos tienen el mismo formato. Cada mensaje consta de un encabezado y cuatro secciones: pregunta, respuesta, autoridad y un espacio adicional. Un campo de encabezado (banderas) controla el contenido de estas cuatro secciones.

La sección de encabezado consta de los siguientes campos: Identificación, Banderas, Número de preguntas, Número de respuestas, Número de registros de recursos de autoridad (RR) y Número de RR adicionales. Cada campo tiene una longitud de 16 bits y aparece en el orden indicado. El campo de identificación se utiliza para hacer coincidir las respuestas con las consultas. El campo de bandera consta de subcampos de la siguiente manera:

Después de la bandera, el encabezado termina con cuatro números enteros de 16 bits que contienen el número de registros en cada una de las secciones que siguen, en el mismo orden.

Sección de preguntas

La sección de preguntas tiene un formato más simple que el formato de registro de recursos utilizado en las otras secciones. Cada registro de pregunta (generalmente solo hay uno en la sección) contiene los siguientes campos:

El nombre de dominio se divide en etiquetas discretas que se concatenan; cada etiqueta tiene como prefijo la longitud de esa etiqueta.

Registros de recursos

El Sistema de Nombres de Dominio especifica una base de datos de elementos de información para recursos de red. Los tipos de elementos de información se clasifican y organizan con una lista de tipos de registros DNS, los registros de recursos (RR). Cada registro tiene un tipo (nombre y número), un tiempo de caducidad (tiempo de vida), una clase y datos específicos del tipo. Los registros de recursos del mismo tipo se describen como un conjunto de registros de recursos (RRset), sin un orden especial. Los resolutores de DNS devuelven el conjunto completo tras la consulta, pero los servidores pueden implementar el ordenamiento por turnos para lograr el equilibrio de carga. Por el contrario, las extensiones de seguridad del sistema de nombres de dominio (DNSSEC) funcionan en el conjunto completo de registros de recursos en orden canónico.

Cuando se envían a través de una red de protocolo de Internet, todos los registros usan el formato común especificado en RFC 1035:

NOMBRE es el nombre de dominio completo del nodo en el árbol. En el cable, el nombre se puede acortar mediante la compresión de etiquetas donde los extremos de los nombres de dominio mencionados anteriormente en el paquete se pueden sustituir por el final del nombre de dominio actual.

TYPE es el tipo de registro. Indica el formato de los datos y da una pista de su uso previsto. Por ejemplo, el registro A se usa para traducir de un nombre de dominio a una dirección IPv4, el registro NS enumera qué servidores de nombres pueden responder búsquedas en una zona DNS y el El registro MX especifica el servidor de correo utilizado para manejar el correo para un dominio especificado en una dirección de correo electrónico.

RDATA son datos de relevancia específica del tipo, como la dirección IP para los registros de direcciones o la prioridad y el nombre de host para los registros MX. Los tipos de registros conocidos pueden usar compresión de etiquetas en el campo RDATA, pero "desconocido" los tipos de registro no deben (RFC 3597).

La CLASE de un registro se establece en IN (para Internet) para registros DNS comunes que involucran nombres de host, servidores o direcciones IP de Internet. Además, existen las clases Chaos (CH) y Hesiod (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 usan solo en la comunicación con otros nodos DNS (en el cable), como cuando se realizan transferencias de zona (AXFR/IXFR) o para EDNS (OPT).

Registros comodín

El sistema de nombres de dominio admite registros DNS comodín que especifican nombres que comienzan con la etiqueta de asterisco, '*', por ejemplo, *.example. Los registros DNS que pertenecen a nombres de dominio comodín especifican reglas para generar registros de recursos dentro de una sola zona DNS mediante la sustitución de etiquetas completas con componentes coincidentes del nombre de consulta, incluidos los descendientes especificados. Por ejemplo, en la siguiente configuración, la zona DNS x.example especifica que todos los subdominios, incluidos los subdominios de subdominios, de x.example usan el intercambiador de correo (MX) un.x.ejemplo. Se necesita el registro A para a.x.example para especificar la dirección IP del intercambiador de correo. Como esto tiene como resultado la exclusión de este nombre de dominio y sus subdominios de las coincidencias con comodines, también se debe crear un registro MX adicional para el subdominio a.x.example, así como un registro MX con comodines para todos sus subdominios. definirse en la zona DNS.

x.ejemplo. MX 10 a.x.ejemplo.
MX 10 a.x.ejemplo.
MX 10 a.x.ejemplo.
a.x.example. MX 10 a.x.example.
a.x.example. AAAA 2001:db8::1

La función de los registros comodín se perfeccionó en RFC 4592 porque la definición original en RFC 1034 estaba incompleta y dio lugar a interpretaciones erróneas por parte de los implementadores.

Extensiones de protocolo

El protocolo DNS original tenía disposiciones limitadas para la extensión con nuevas características. En 1999, Paul Vixie publicó en el RFC 2671 (reemplazado por el RFC 6891) un mecanismo de extensión, llamado Mecanismos de extensión para DNS (EDNS) que introdujo elementos de protocolo opcionales sin aumentar la sobrecarga cuando no estaba en uso. Esto se logró a través del registro de pseudo-recurso OPT que solo existe en las transmisiones por cable del protocolo, pero no en ningún archivo de zona. También se sugirieron extensiones iniciales (EDNS0), como aumentar el tamaño del mensaje DNS en datagramas UDP.

Actualizaciones de zona dinámica

Las actualizaciones de DNS dinámico utilizan el código de operación UPDATE DNS para agregar o eliminar registros de recursos de forma dinámica desde una base de datos de zona mantenida en un servidor DNS autorizado. La función se describe en RFC 2136. Esta función es útil para registrar clientes de red en el DNS cuando se inician o están disponibles en la red. Dado que a un cliente de arranque se le puede asignar una dirección IP diferente cada vez desde un servidor DHCP, no es posible proporcionar asignaciones de DNS estáticas para dichos clientes.

Protocolos de transporte

Desde su origen en 1983, el DNS ha utilizado el Protocolo de datagramas de usuario (UDP) para el transporte a través de IP. Sus limitaciones han motivado numerosos desarrollos de protocolos de confiabilidad, seguridad, privacidad y otros criterios en las décadas siguientes.

DNS over UDP/53 (Do53)

UDP se reserva puerto número 53 para servidores que escuchan consultas. Estas consultas consisten en una solicitud de texto claro enviada en un solo paquete UDP del cliente, respondió con una respuesta de texto claro enviada en un solo paquete UDP del servidor. Cuando la longitud de la respuesta supera los 512 bytes y los mecanismos de extensión de soporte cliente y servidor para DNS (EDNS), se pueden utilizar paquetes UDP más grandes. El uso de DNS sobre UDP está limitado por, entre otras cosas, su falta de encriptación, autenticación, entrega fiable y longitud de mensaje.

DNS over TCP/53 (Do53/TCP)

En 1989, la RFC 1123 especificó el transporte opcional del Protocolo de Control de Transmisiones (TCP) para consultas, respuestas y, en particular, transferencias de zonas. Mediante la fragmentación de respuestas largas, TCP permite respuestas más largas, entrega fiable y reutilización de conexiones de larga duración entre clientes y servidores.

DNS sobre TLS (DoT)

DNS sobre TLS surgió como un estándar de IETF para DNS cifrado en 2016, utilizando Seguridad de Capas de Transporte (TLS) para proteger toda la conexión, en lugar de sólo la carga de DNS. Los servidores DoT escuchan en el puerto TCP 853. RFC 7858 especifica que el cifrado oportunista y el cifrado autenticado pueden ser soportados, pero no hizo obligatorio la autenticación de servidor o cliente.

DNS sobre HTTPS (DoH)

DNS sobre HTTPS fue desarrollado como un estándar de competición para el transporte de consultas DNS en 2018, túnelizando datos de consulta DNS sobre HTTPS, que transporta HTTP sobre TLS. DoH fue promovido como una alternativa más amigable con el DNS ya que, como DNSCrypt, utiliza el puerto TCP 443, y por lo tanto se ve similar al tráfico web, aunque son fácilmente diferenciables en la práctica. DoH ha sido ampliamente criticado por disminuir el anonimato de los usuarios en relación con DoT.

DNS (ODNS) y DoH (ODoH)

Los investigadores de la Universidad de Princeton y la Universidad de Chicago inventaron y aplicaron DNS (ODNS) como una extensión al DNS no cifrado, antes de que DoH fuera estandarizado y ampliamente desplegado. Apple y Cloudflare desplegaron posteriormente la tecnología en el contexto de DoH, como DoH (ODoH). ODoH combina la separación de entrada/egreso (inventada en ODNS) con el túnel HTTPS de DoH y la encriptación de capas de transporte TLS en un solo protocolo.

DNS over TOR

DNS se puede ejecutar a través de redes privadas virtuales (VPNs) y protocolos de túnel. Un uso que se ha vuelto común desde 2019 para justificar su propio acrónimo usado frecuentemente es DNS sobre Tor. Las ganancias de privacidad de DNS Oblivious pueden obtenerse mediante el uso de la red Tor preexistente de nodos de entrada y egress, junto con la encriptación de la capa de transporte proporcionada por TLS.

DNS sobre QUIC (DoQ)

RFC 9250 by the Internet Engineering Task Force describes DNS over QUIC.

DNSCrypt

El protocolo DNSCrypt, que se desarrolló en 2011 fuera del marco de estándares de IETF, introdujo el cifrado DNS en la parte inferior de los soluciones recursivos, donde los clientes encriptan las cargas de pago de consultas utilizando las claves públicas de los servidores, que se publican en el DNS (en lugar de depender de las autoridades de certificados de terceros) y que a su vez pueden ser protegidas por firmas por DNSSEC. DNSCrypt utiliza el puerto TCP o UDP 443, el mismo puerto que el tráfico web cifrado HTTPS. Esto introdujo no sólo la privacidad respecto al contenido de la consulta, sino también una medida significativa de la capacidad de tráfico de cortafuegos. En 2019, DNSCrypt fue ampliado para apoyar un modo "anonymized", similar al propuesto "Oblivious DNS", en el que un nodo de entrada recibe una consulta que ha sido encriptada con la clave pública de un servidor diferente, y la transmite a ese servidor, que actúa como un nodo de égres, realizando la resolución recursiva. Se crea la privacidad de los pares de usuario/query, ya que el nodo de entrada no conoce el contenido de la consulta, mientras que los nodos egress no conocen la identidad del cliente. DNSCrypt fue implementado por primera vez en producción por OpenDNS en diciembre de 2011. Hay varias implementaciones de software libre y de código abierto que además integran ODoH. Está disponible para una variedad de sistemas operativos, incluyendo Unix, Apple iOS, Linux, Android y MS Windows.

Problemas de seguridad

Originalmente, las preocupaciones de seguridad no eran consideraciones de diseño importantes para el software de DNS o cualquier software para su implementación en los inicios de Internet, ya que la red no estaba 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 de las medidas de seguridad para proteger la integridad de los datos y la autenticación del usuario.

Usuarios maliciosos descubrieron y explotaron varios problemas de vulnerabilidad. Uno de estos problemas es el envenenamiento de caché de DNS, en el que los datos se distribuyen a los resolutores de almacenamiento en caché con el pretexto de ser un servidor de origen autorizado, lo que contamina el almacén de datos con información potencialmente falsa y tiempos de vencimiento prolongados (tiempo de vida). Posteriormente, las solicitudes de aplicaciones legítimas pueden redirigirse a hosts de red operados con intenciones maliciosas.

Las respuestas de DNS tradicionalmente no tienen una firma criptográfica, lo que genera muchas posibilidades de ataque; las Extensiones de seguridad del sistema de nombres de dominio (DNSSEC) modifican el DNS para agregar soporte para respuestas firmadas criptográficamente. DNSCurve se ha propuesto como una alternativa a DNSSEC. Otras extensiones, como TSIG, agregan soporte para la autenticación criptográfica entre pares de confianza y se usan comúnmente para autorizar operaciones de transferencia de zona o actualización dinámica.

Algunos nombres de dominio pueden usarse para lograr efectos de suplantación de identidad. Por ejemplo, paypal.com y paypa1.com son nombres diferentes, pero los usuarios es posible que no pueda distinguirlos en una interfaz gráfica de usuario según el tipo de letra elegido por el usuario. En muchas fuentes, la letra l y el número 1 se ven muy similares o incluso idénticos. Este problema es grave en los sistemas que admiten nombres de dominio internacionalizados, ya que muchos códigos de caracteres en ISO 10646 pueden aparecer idénticos en las pantallas de computadora típicas. Esta vulnerabilidad se aprovecha ocasionalmente en phishing.

Técnicas como el DNS inverso confirmado hacia adelante también se pueden usar para ayudar a validar los resultados del DNS.

El DNS también puede "filtrarse" de conexiones seguras o privadas, si no se presta atención a su configuración, y en ocasiones el DNS se ha utilizado para eludir los cortafuegos por parte de personas malintencionadas y filtrar datos, ya que a menudo se considera inocuo.

Problemas de privacidad y seguimiento

Diseñado originalmente como una base de datos pública, jerárquica, distribuida y con mucho almacenamiento en caché, el protocolo DNS no tiene controles de confidencialidad. Las consultas de los usuarios y las respuestas del servidor de nombres se envían sin cifrar, lo que permite la detección de paquetes de red, el secuestro de DNS, el envenenamiento de caché de DNS y los ataques de intermediarios. Esta deficiencia es comúnmente utilizada por los ciberdelincuentes y los operadores de redes con fines de marketing, autenticación de usuarios en portales cautivos y censura.

La privacidad del usuario se ve expuesta aún más por las propuestas para aumentar el nivel de información de IP del cliente en las consultas de DNS (RFC 7871) en beneficio de las redes de entrega de contenido.

Los principales enfoques que se utilizan para contrarrestar los problemas de privacidad con DNS:

• VPN, que traslada la resolución DNS al operador de VPN y oculta el tráfico de usuarios de ISP local,
• Tor, que reemplaza la resolución tradicional DNS con dominios anónimos.onion, ocultando tanto la resolución de nombres como el tráfico de usuarios detrás de la contravigilancia de la cebolla,
• Proxies and public DNS servers, which move the actual DNS resolution to a third-party provider, who usually promises little or no request logging and Optional added features, such as DNS-level advertisement or pornography blocking.
  • Los servidores públicos DNS pueden ser consultados usando protocolo DNS tradicional, en cuyo caso no proporcionan protección contra la vigilancia local, o DNS sobre HTTPS, DNS sobre TLS y DNSCrypt, que proporcionan esa protección

Las soluciones que impiden la inspección del DNS por parte del operador de la red local son criticadas por frustrar las políticas de seguridad de la red corporativa y la censura de Internet. También son criticados desde el punto de vista de la privacidad, ya que entregan la resolución de DNS a manos de un pequeño número de empresas conocidas por monetizar el tráfico de usuarios y por centralizar la resolución de nombres de DNS, lo que generalmente se percibe como dañino para Internet.

Google es el proveedor dominante de la plataforma en Android, el navegador en Chrome, y el resolver DNS en el servicio 8.8.8. ¿Este escenario sería un caso de que una sola entidad corporativa estuviera en una posición de control general de todo el espacio de nombres de Internet? Netflix ya puso en marcha una aplicación que utilizó su propio mecanismo de resolución DNS independiente de la plataforma sobre la que se estaba ejecutando la aplicación. ¿Y si la aplicación de Facebook incluye DoH? ¿Y si el iOS de Apple utiliza un mecanismo de resolución de DoH para evitar la resolución DNS local y dirigir todas las consultas DNS de las plataformas de Apple a un conjunto de resolución de nombres operados por Apple?

—DNS Privacy y el IETF

Registro de nombre de dominio

El derecho a usar un nombre de dominio lo delegan los registradores de nombres de dominio que están acreditados por la Corporación de Internet para la Asignación de Nombres y Números (ICANN) u otras organizaciones como OpenNIC, que se encargan de supervisar los sistemas de nombres y números del Internet. Además de ICANN, cada dominio de nivel superior (TLD) es mantenido y atendido técnicamente por una organización administrativa que opera un registro. Un registro es responsable de operar la base de datos de nombres dentro de su zona autorizada, aunque el término se usa con mayor frecuencia para los TLD. Un registrante es una persona u organización que solicitó el registro de un dominio. El registro recibe información de registro de cada nombre de dominio registrador, el cual está autorizado (acreditado) para asignar nombres en la zona correspondiente y publica la información utilizando el protocolo WHOIS. A partir de 2015, se está considerando el uso de RDAP.

ICANN publica la lista completa de TLD, registros de TLD y registradores de nombres de dominio. La información del registrante asociada 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 con código de país (ccTLD), los registros de dominio mantienen la información de WHOIS (Registrante, servidores de nombres, fechas de vencimiento, etc.). Por ejemplo, DENIC, NIC de Alemania, tiene los datos del dominio DE. Desde aproximadamente 2001, la mayoría de los registros de dominios de nivel superior genéricos (gTLD) han adoptado este llamado enfoque de registro grueso, es decir, mantener los datos de WHOIS en registros centrales en lugar de bases de datos de registradores.

Para los dominios de nivel superior en COM y NET, se utiliza un modelo de registro delgado. El registro de dominio (por ejemplo, GoDaddy, BigRock y PDR, VeriSign, etc., etc.) contiene datos básicos de WHOIS (es decir, registradores y servidores de nombres, etc.). Las organizaciones, o los registrantes que usan ORG, por otro lado, están exclusivamente en el Registro de Interés Público.

Algunos registros de nombres de dominio, a menudo llamados centros de información de red (NIC), también funcionan como registradores para los usuarios finales, además de proporcionar acceso a los conjuntos de datos de WHOIS. Los registros de dominio de nivel superior, como los dominios COM, NET y ORG, utilizan un modelo de registro-registrador que consta de muchos registradores de nombres de dominio. En este método de gestión, el registro solo gestiona la base de datos de nombres de dominio y la relación con los registradores. Los registrantes (usuarios de un nombre de dominio) son clientes del registrador, en algunos casos mediante subcontratación adicional de revendedores.

Documentos RFC

El Sistema de nombres de dominio se define mediante documentos de solicitud de comentarios (RFC) publicados por el Grupo de trabajo de ingeniería de Internet (estándares de Internet). La siguiente es una lista de RFC que definen el protocolo DNS.

Pista de estándares

• RFC 1034, Nombres de dominio - Conceptos e instalaciones
• RFC 1035, Nombres de dominio - Implementación y Especificación
• RFC 1123, Requisitos para anfitriones de Internet: aplicaciones y apoyo
• RFC 1995, Incremental Zone Transfer in DNS
• RFC 1996, Un mecanismo para una pronta notificación de los cambios en las zonas (NOCIA DNS)
• RFC 2136, Actualizaciones dinámicas en el sistema de nombres de dominio (DNS UPDATE)
• RFC 2181, Aclaraciones a la especificación DNS
• RFC 2308, Negative Caching of DNS Queries (DNS NCACHE)
• RFC 2672, Non-Terminal DNS Nombre Redirección
• RFC 2845, Secret Key Transaction Authentication for DNS (TSIG)
• RFC 3225, Indicando el Resolver Support of DNSSEC
• RFC 3226, DNSSEC y IPv6 A6 conscientes del tamaño del mensaje servidor/resolver
• RFC 3596, DNS Extensiones para soportar la versión 6
• RFC 3597, Handling of Unknown DNS Resource Record (RR) Types
• RFC 4343, Sistema de nombres de dominio (DNS)
• RFC 4592, El papel de las tarjetas silvestres en el sistema de nombres de dominio
• RFC 4635, Identificadores de Algoritmo HMAC SHA TSIG
• RFC 5001, DNS Nombre Identificador del servidor (NSID) Opción
• RFC 5011, Actualizaciones automatizadas de los anclajes de confianza DNS Security (DNSSEC)
• RFC 5452, Medidas para hacer DNS Más resistente contra las respuestas falsificadas
• RFC 5890, Nombres de dominio internacionalizados para aplicaciones (IDNA):Definiciones y Marco de documentos
• RFC 5891, Nombres de dominio internacionalizados en aplicaciones (IDNA): Protocolo
• RFC 5892, Puntos de Código Unicode y Nombres de dominio internacionalizados para aplicaciones (IDNA)
• RFC 5893, Escrituras de derecha a izquierda para nombres de dominio internacionalizados para aplicaciones (IDNA)
• RFC 6891, Mecanismos de prórroga del DNS (EDNS0)
• RFC 7766, DNS Transport over TCP - Implementation requirements

Estándares de seguridad propuestos

• RFC 4033, DNS Security Introduction and requirements
• RFC 4034, Documentos de recursos para las extensiones de seguridad del DNS
• RFC 4035, Modificaciones de protocolo para las extensiones de seguridad del DNS
• RFC 4509, Utilización de SHA-256 en DNSSEC Delegation Signer (DS) Resource Records
• RFC 4470, Minimally Covering NSEC Records and DNSSEC On-line Signing
• RFC 5155, DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
• RFC 5702, Uso de algoritmos SHA-2 con RSA en DNSKEY y RRSIG Documentos de recursos para DNSSEC
• RFC 5910, Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
• RFC 5933, Uso de algoritmos de firma GOST en DNSKEY y RRSIG Documentos de recursos para DNSSEC
• RFC 7830, Opción de relleno EDNS(0)
• RFC 7858, Especificación para DNS sobre seguridad de la capa de transporte (TLS)
• RFC 8310, Perfiles de uso para DNS sobre TLS y DNS sobre DTLS
• RFC 8484, DNS Consultas sobre HTTPS (DoH)

RFC experimentales

• RFC 1183, Nuevas definiciones de RR DNS

Mejores prácticas actuales

• RFC 2182, Selección y funcionamiento de servidores DNS secundarios (BCP 16)
• RFC 2317, Delegación IN-ADDR sin clases. (BCP 20)
• RFC 5625, DNS Proxy Implementation Guidelines (BCP 152)
• RFC 6895, Sistema de nombres de dominio (DNS) Consideraciones de IANA (BCP 42)
• RFC 7720, DNS Root Name Service Protocol and Deployment requirements (BCP 40)

RFC informativos

Estos RFC son de carácter consultivo, pero pueden proporcionar información útil a pesar de no definir un estándar o BCP. (RFC 1796)

• RFC 1178, Elegir un nombre para su computadora (FYI 5)
• RFC 1591, Domain Name System Structure and Delegation
• RFC 1912, DNS comunes Errores operativos y de configuración
• RFC 2100, The Naming of Hosts
• RFC 3696, Técnicas de aplicación para la verificación y transformación de nombres
• RFC 3833. Análisis de amenazas del sistema de nombres de dominio (DNS)
• RFC 4892, Requisitos para un mecanismo Identificar una instalación de servidor de nombre
• RFC 5894, Nombres de dominio internacionalizados para aplicaciones (IDNA):Background, Explication y Rationale
• RFC 5895, Carácteres de Mapping para Nombres de Dominio Internacionalizados en Aplicaciones (IDNA) 2008
• RFC 7626, Consideraciones de privacidad del DNS
• RFC 7706, Disminuir el tiempo de acceso a los servidores Root por Running One en Loopback
• RFC 7816, DNS Minimización para mejorar la privacidad
• RFC 8499, DNS Terminología

Desconocido

Estos RFC tienen un estado oficial de Desconocido, pero debido a su antigüedad no están claramente etiquetados como tales.

• RFC 920, Requisitos de dominio – Dominios de primer nivel especificados
• RFC 1032, Administradores de dominio Guía
• RFC 1033, Administradores de dominio Guía de Operaciones
• RFC 1101, DNS Codings of Network Names and Other Types