DNS

DNS, Domain Name System o Sistema de Nombres de Dominio es el sistema de nombres jerárquico y descentralizado que se utiliza para identificar computadoras accesibles a través de Internet u otras redes de Protocolo de Internet (IP). Los registros de recursos contenidos en el DNS asocian nombres de dominio con otras formas de información. Estos se usan más comúnmente para asignar nombres de dominio amigables para los humanos a las direcciones IP numéricas que las computadoras necesitan para ubicar servicios y dispositivos usando los protocolos de red subyacentes, pero se han extendido con el tiempo para realizar muchas otras funciones también. El Sistema de Nombres de Dominio ha sido un componente esencial de la funcionalidad de Internet desde 1985.

Función

Una analogía que se usa con frecuencia para explicar el Sistema de Nombres de Dominio es que sirve como guía telefónica para Internet al traducir los nombres de host de las computadoras fáciles de usar en direcciones IP. Por ejemplo, el nombre de dominio www.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 papel 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 explotada aquí es que diferentes usuarios pueden recibir simultáneamente diferentes traducciones para el mismo nombre de dominio, un punto clave de divergencia con la vista tradicional del DNS de la guía telefónica. 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 asignaban 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 a partir de la zona de la raíz. Una zona DNS puede constar de un solo dominio o puede constar de muchos dominios y subdominios, según las opciones administrativas del administrador de la zona. El DNS también se puede particionar según la clase, donde las clases separadas se pueden considerar como una matriz de árboles de espacios de nombres paralelos.

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, técnicamente denominadas etiquetas, que se concatenan convencionalmente y están delimitadas por puntos, como 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 conjunto de caracteres ASCII, que consta de caracteres de la a a la z, de la A a la Z, de los dígitos del 0 al 9 y del 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 impedía 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 con código de país de nombres de dominio internacionalizados (ccTLD). 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 las consultas de DNS a partir de datos que han sido configurados por una fuente original, por ejemplo, el administrador del dominio o mediante métodos de DNS dinámicos, en contraste con 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 principal o un servidor secundario. Históricamente, los términos amo/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 bit de " Respuesta autorizada " (AA) 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 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 lame".

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

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 el resolutor 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 de "www.wikipedia.org" se remite a los servidores de la organización. 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 que tiene el nombre de dominio completo "www.wikipedia.org".

Este mecanismo colocaría una gran carga de tráfico en los servidores raíz, si cada resolución en Internet requiriera 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 de vida) de el registro del 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 resolutores de DNS se clasifican según una variedad de métodos de consulta, como recursivos, no recursivos e iterativos. 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, un resolutor de stub 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 solucionador 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 servidor "com" y finalmente un servidor "example.com".

Dependencias circulares y registros adhesivos

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 ejemplo.org es ns1.ejemplo.org, una computadora que intenta resolver www.ejemplo.org primero resuelve ns1.ejemplo.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 en la implementación de la resolución de nombres en las aplicaciones es reducir la carga en los servidores del sistema de nombres de dominio almacenando en caché los resultados localmente o en hosts de resolución intermedios. Los resultados obtenidos de una solicitud de DNS siempre están asociados 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é distribuida, los cambios en los registros DNS no se propagan por toda la red de inmediato, 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 Inicio de autoridad (SOA) cuando informa que no existe ningún dato 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 las 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

Los usuarios generalmente 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.

El sistema de 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 con éxito un resultado o no. Luego devuelve sus resultados al sistema de resolución de DNS; suponiendo que haya encontrado un resultado, el resolutor almacena debidamente en caché 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 propósitos 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 servidores 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á en la lista negra. Apunta a 5.4.3.102.blacklist.example, que se resuelve en 127.0.0.1.
• La dirección 102.3.4.6 no está en la lista negra y apunta a 6.4.3.102.blacklist.example. Este nombre de host no está configurado o se resuelve en 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 múltiples servidores DNS para la cobertura de cada dominio. En el nivel superior del DNS global, existen trece grupos de servidores de nombres raíz, con "copias" adicionales de ellos distribuidas 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, Indicadores, 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 dado. 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:

Campo	Descripción	Longitud (bits)
código QR	Indica si el mensaje es una consulta (0) o una respuesta (1)	1
CÓDIGO DE OPCIÓN	El tipo puede ser QUERY (consulta estándar, 0), IQUERY (consulta inversa, 1) o STATUS (solicitud de estado del servidor, 2)	4
Automóvil club británico	Respuesta autorizada, en una respuesta, indica si el servidor DNS tiene autoridad para el nombre de host consultado	1
CT	TrunCation, indica que este mensaje fue truncado debido a una longitud excesiva	1
RD	Recursion Desired, indica si el cliente se refiere a una consulta recursiva	1
REAL ACADEMIA DE BELLAS ARTES	Recursión Disponible, en una respuesta, indica si el servidor DNS que responde admite la recursión	1
Z	Cero, reservado para uso futuro	3
RCODE	El código de respuesta puede ser NOERROR (0), FORMERR (1, error de formato), SERVFAIL (2), NXDOMAIN (3, dominio inexistente), etc.	4

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:

Campo	Descripción	Longitud (octetos)
NOMBRE	Nombre del recurso solicitado	Variable
ESCRIBE	Tipo de RR (A, AAAA, MX, TXT, etc.)	2
CLASE	Código de clase	2

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

Protocolos de transporte DNS

Conjunto de protocolos de internet
Capa de aplicación
BGPDHCP (v6)DNSFTPHTTPHTTPSIMAPIRCLDAPMGCPMQTTNNTPNTPOSPFESTALLIDOPTPONC/RPCRTPRTSPROTURASORBOSMTPSNMPSSHTelnetTLS/SSLXMPPmás...
Capa de transporte
TCPUDPDCCPSCTPRSVPCUALQUIER COSAmás...
capa de Internet
IP IPv4IPv6ICMP (v6)PNDECNIGMPIPsecmás...
Capa de enlace
TúnelesPPAMACmás...
vtmi

DNS sobre UDP/53 ("Do53")

Desde el momento de su origen en 1983 hasta hace poco tiempo, el DNS ha respondido principalmente consultas sobre el puerto número 53 del Protocolo de datagramas de usuario (UDP). una respuesta de texto claro enviada en un solo paquete UDP desde el servidor. Cuando la longitud de la respuesta supera los 512 bytes y tanto el cliente como el servidor admiten mecanismos de extensión para DNS (EDNS), se pueden utilizar paquetes UDP más grandes. El uso de DNS sobre UDP está limitado, entre otras cosas, por la falta de encriptación de la capa de transporte, autenticación, entrega confiable y longitud del mensaje.

DNS sobre TCP/53 ("Do53/TCP")

En 1989, RFC 1123 especificó el transporte opcional del Protocolo de control de transmisión (TCP) para consultas DNS, respuestas y, en particular, transferencias de zona. A través de la fragmentación de respuestas largas, TCP permite respuestas más largas, entregas confiables y reutilización de conexiones de larga duración entre clientes y servidores.

DNSCrypt

El protocolo DNSCrypt, que se desarrolló en 2011 fuera del marco de estándares de IETF, introdujo el cifrado de DNS en el lado descendente de los resolutores recursivos, donde los clientes cifran las cargas útiles de las consultas utilizando las claves públicas de los servidores, que se publican en el DNS (en lugar de depender de terceros). autoridades de certificación de las partes) y que a su vez pueden estar protegidos por firmas DNSSEC.DNSCrypt utiliza el puerto 443 TCP o UDP, el mismo puerto que el tráfico web cifrado HTTPS. Esto introdujo no solo la privacidad con respecto al contenido de la consulta, sino también una medida significativa de la capacidad de atravesar el firewall. En 2019, DNSCrypt se amplió aún más para admitir un modo "anonimizado", similar al "DNS ajeno" propuesto, en el que un nodo de entrada recibe una consulta que se ha cifrado con la clave pública de un servidor diferente y la transmite a ese servidor, que actúa como un nodo de salida, realizando la resolución recursiva. Se crea la privacidad de los pares usuario/consulta, ya que el nodo de entrada no conoce el contenido de la consulta, mientras que los nodos de salida no conocen la identidad del cliente. OpenDNS implementó por primera vez DNSCrypt en producción en diciembre de 2011.

DNS sobre TLS ("DoT")

En 2016 surgió un estándar IETF para DNS encriptado, que utiliza la seguridad de la capa de transporte (TLS) estándar para proteger toda la conexión, en lugar de solo la carga útil de DNS. Los servidores DoT escuchan en el puerto TCP 853. RFC7858 especifica que se puede admitir el cifrado oportunista y el cifrado autenticado, pero no hizo obligatoria la autenticación del servidor o del cliente.

DNS sobre HTTPS ("DoH")

En 2018 se introdujo un estándar competitivo para el transporte de consultas de DNS, que tuneliza los datos de consultas de DNS a través de HTTPS (que a su vez transporta HTTP a través de TLS). DoH se promocionó como una alternativa más amigable para la web al DNS ya que, como DNSCrypt, viaja en el puerto TCP 443 y, por lo tanto, se parece al tráfico web, aunque en la práctica son fácilmente diferenciables. DoH ha sido ampliamente criticado por disminuir el anonimato del usuario en relación con DoT.

DNS sobre TOR

Al igual que otros protocolos de Internet, el DNS puede ejecutarse a través de VPN y túneles. Un uso que se ha vuelto lo suficientemente común desde 2019 como para justificar su propio acrónimo de uso frecuente es DNS-over-Tor. Las ganancias de privacidad de Oblivious DNS se pueden obtener mediante el uso de la red Tor preexistente de nodos de entrada y salida, junto con el cifrado de capa de transporte proporcionado por TLS.

DNS ajeno a HTTPS ("ODoH")

En 2021, se propuso una implementación "ajena" de DoH y se implementó en forma de borrador, combinando la separación de entrada/salida con túneles HTTPS y cifrado de capa de transporte TLS en un único protocolo definido.

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:

Campo	Descripción	Longitud (octetos)
NOMBRE	Nombre del nodo al que pertenece este registro	Variable
ESCRIBE	Tipo de RR en formato numérico (p. ej., 15 para MX RR)	2
CLASE	Código de clase	2
TTL	Recuento de segundos que el RR sigue siendo válido (El máximo es 2 −1, que son unos 68 años)	4
LONGITUD	Longitud del campo RDATA (especificado en octetos)	2
RDATA	Datos adicionales específicos de RR	Variable, según RDLENGTH

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

TIPO 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 registro MX especifica el servidor de correo que se usa 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 registros de direcciones o la prioridad y el nombre de host para registros MX. Los tipos de registros bien conocidos pueden usar la compresión de etiquetas en el campo RDATA, pero los tipos de registros "desconocidos" no deben hacerlo (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. (OPTAR).

Registros DNS 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 al sustituir 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) axexample. El registro A para axexamplees necesario 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 definir en la zona DNS un registro MX adicional para el subdominio axexample, así como un registro MX con comodines para todos sus subdominios.

x.ejemplo. Ejemplo de eje MX 10.
*.x.ejemplo. Ejemplo de eje MX 10.
*.axejemplo. Ejemplo de eje MX 10.
un ejemplo Ejemplo de eje MX 10.
por ejemplo. 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 funciones. En 1999, Paul Vixie publicó en RFC 2671 (reemplazado por 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 zonas dinámicas

Las actualizaciones de DNS dinámico utilizan el código de operación ACTUALIZAR DNS para agregar o eliminar registros de recursos dinámicamente de 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.

Temas de seguridad

Originalmente, las preocupaciones de seguridad no eran consideraciones de diseño importantes para el software 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.

Varios problemas de vulnerabilidad fueron descubiertos y explotados por usuarios malintencionados. 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 autenticación criptográfica entre pares confiables y se usan comúnmente para autorizar transferencias de zona o operaciones de 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 es posible que los usuarios no puedan 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.

También se pueden utilizar técnicas como el DNS inverso confirmado hacia adelante para ayudar a validar los resultados del DNS.

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

Problemas de privacidad y seguimiento

Originalmente diseñado 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 expone 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 transfieren la resolución de DNS al operador de VPN y ocultan el tráfico de usuarios del ISP local,
• Tor, que reemplaza la resolución de DNS tradicional con dominios.onion anónimos, ocultando tanto la resolución de nombres como el tráfico de usuarios detrás de la contravigilancia de enrutamiento de cebolla,
• Proxies y servidores DNS públicos, que transfieren la resolución DNS real a un proveedor externo, que generalmente promete poco o ningún registro de solicitudes y características adicionales opcionales, como publicidad a nivel de DNS o bloqueo de pornografía.
  • Los servidores DNS públicos se pueden consultar utilizando el protocolo DNS tradicional, en cuyo caso no brindan protección contra la vigilancia local, o DNS-over-HTTPS, DNS-over-TLS y DNSCrypt, que brindan dicha protección.

Las soluciones que impiden la inspección de 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 ceden 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 sistema de resolución de DNS en el servicio 8.8.8.8. ¿Sería este escenario un caso de una sola entidad corporativa en una posición de control general de todo el espacio de nombres de Internet? Netflix ya presentó una aplicación que usaba su propio mecanismo de resolución de DNS independiente de la plataforma en la que se ejecutaba la aplicación. ¿Qué pasaría si la aplicación de Facebook incluyera DoH? ¿Qué pasaría si el iOS de Apple utilizara un mecanismo de resolución DoH para eludir la resolución de DNS local y dirigir todas las consultas de DNS desde las plataformas de Apple a un conjunto de solucionadores de nombres operados por Apple?—  Privacidad de DNS y el IETF

Registro de nombre de dominio

El derecho a utilizar 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 de 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 registrador de nombres de dominio, que 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 dominios de nivel superior en COM y NET, se utiliza un modelo de registro reducido. El registro de dominio (p. ej., 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

Estándares

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.

• RFC 1034, Nombres de Dominio - Conceptos e Instalaciones
• RFC 1035, Nombres de dominio - Implementación y especificación
• RFC 1123, Requisitos para hosts de Internet: aplicación y soporte
• RFC 1995, Transferencia de zona incremental en DNS
• RFC 1996, Un mecanismo para la pronta notificación de cambios de zona (DNS NOTIFY)
• RFC 2136, Actualizaciones Dinámicas en el sistema de nombres de dominio (DNS UPDATE)
• RFC 2181, Aclaraciones a la Especificación DNS
• RFC 2308, almacenamiento en caché negativo de consultas DNS (DNS NCACHE)
• RFC 2672, Redirección de nombres DNS no terminales
• RFC 2845, autenticación de transacción de clave secreta para DNS (TSIG)
• RFC 3225, Indicando soporte de resolución de DNSSEC
• RFC 3226, DNSSEC e IPv6 A6 requisitos de tamaño de mensaje de resolución/servidor compatible
• RFC 3596, Extensiones de DNS para admitir la versión 6 de IP
• RFC 3597, Manejo de tipos de registros de recursos (RR) de DNS desconocidos
• RFC 4343, Sistema de nombres de dominio (DNS) Aclaración de insensibilidad a mayúsculas y minúsculas
• RFC 4592, El papel de los comodines en el sistema de nombres de dominio
• RFC 4635, identificadores de algoritmo HMAC SHA TSIG
• RFC 5001, opción de identificador de servidor de nombres DNS (NSID)
• RFC 5011, Actualizaciones automáticas de anclajes de confianza de seguridad DNS (DNSSEC)
• RFC 5452, Medidas para hacer que el DNS sea más resistente frente a respuestas falsificadas
• RFC 5890, Nombres de dominio internacionalizados para aplicaciones (IDNA): Definiciones y marco del documento
• 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 extensión para DNS (EDNS0)
• RFC 7766, Transporte de DNS sobre TCP - Requisitos de implementación

Normas de seguridad propuestas

• RFC 4033, Introducción y requisitos de seguridad de DNS
• RFC 4034, Registros de recursos para las extensiones de seguridad de DNS
• RFC 4035, Modificaciones de protocolo para las extensiones de seguridad de DNS
• RFC 4509, Uso de SHA-256 en registros de recursos de firmante de delegación (DS) de DNSSEC
• RFC 4470, cobertura mínima de registros NSEC y firma en línea de DNSSEC
• RFC 5155, Seguridad DNS (DNSSEC) Denegación de existencia autenticada con hash
• RFC 5702, Uso de algoritmos SHA-2 con RSA en registros de recursos DNSKEY y RRSIG para DNSSEC
• RFC 5910, Asignación de extensiones de seguridad del Sistema de nombres de dominio (DNS) para el Protocolo de aprovisionamiento extensible (EPP)
• RFC 5933, Uso de algoritmos de firma GOST en registros de recursos DNSKEY y RRSIG para DNSSEC
• RFC 7830, la 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, Consultas DNS sobre HTTPS (DoH)

RFC experimentales

• RFC 1183, nuevas definiciones de DNS RR

Mejores prácticas actuales

• RFC 2182, Selección y Operación de Servidores DNS Secundarios (BCP 16)
• RFC 2317, delegación IN-ADDR.ARPA sin clases (BCP 20)
• RFC 5625, Directrices de implementación de proxy DNS (BCP 152)
• RFC 6895, Sistema de nombres de dominio (DNS) Consideraciones de la IANA (BCP 42)
• RFC 7720, Protocolo de servicio de nombres raíz DNS y requisitos de implementación (BCP 40)

RFC informativos

Estos RFC son de naturaleza consultiva, 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, Estructura y delegación del sistema de nombres de dominio
• RFC 1912, Errores comunes de configuración y funcionamiento de DNS
• RFC 2100, La denominación de 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 que identifica una instancia de servidor de nombres
• RFC 5894, Nombres de dominio internacionalizados para aplicaciones (IDNA): Antecedentes, explicación y justificación
• RFC 5895, Asignación de caracteres para nombres de dominio internacionalizados en aplicaciones (IDNA) 2008
• RFC 7626, Consideraciones de privacidad de DNS
• RFC 7706, Disminución del tiempo de acceso a los servidores raíz mediante la ejecución de uno en loopback
• RFC 8499, Terminología DNS

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 nivel superior originales especificados
• RFC 1032, Guía de administradores de dominio
• RFC 1033, Guía de operaciones de administradores de dominio
• RFC 1101, Codificaciones DNS de nombres de red y otros tipos