Sistema de nombres de dominio

El Sistema de Nombres de Dominio ( DNS ) es un servicio de nombres jerárquico y distribuido que proporciona un sistema de nombres para computadoras, servicios y otros recursos en Internet u otras redes de Protocolo de Internet (IP). Asocia diversa información con nombres de dominio ( cadenas de identificación ) asignados a cada una de las entidades asociadas. Principalmente, traduce nombres de dominio fáciles de memorizar a las direcciones IP numéricas necesarias para localizar e identificar servicios y dispositivos informáticos con los protocolos de red subyacentes . ^[¹^] El Sistema de Nombres de Dominio ha sido un componente esencial del funcionamiento de Internet desde 1985.

El Sistema de Nombres de Dominio (DNS) delega la responsabilidad de asignar nombres de dominio y mapearlos a recursos de Internet mediante la designación de servidores de nombres autoritativos para cada dominio. Los administradores de red pueden delegar la autoridad sobre subdominios de su espacio de nombres asignado a otros servidores de nombres. Este mecanismo proporciona un servicio distribuido y tolerante a fallos , y fue diseñado para evitar una única base de datos central de gran tamaño. Además, el DNS especifica la funcionalidad técnica del servicio de base de datos que constituye 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 . ^{[ 2 ]}^{[ 1 ]}

Internet mantiene dos espacios de nombres principales : la jerarquía de nombres de dominio y los espacios de direcciones IP . ^[³^] El Sistema de Nombres de Dominio (DNS) mantiene la jerarquía de nombres de dominio y proporciona servicios de traducción entre esta 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 las consultas a su base de datos.

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

El Sistema de Nombres de Dominio (DNS) originalmente utilizaba el Protocolo de Datagramas de Usuario (UDP) como protocolo de transporte sobre IP. Las preocupaciones sobre fiabilidad, seguridad y privacidad propiciaron el uso del Protocolo de Control de Transmisión (TCP), así como el desarrollo de numerosos otros protocolos.

Función

Una analogía común para explicar el DNS es que funciona como la guía telefónica de Internet, traduciendo nombres de host fáciles de recordar en direcciones IP. Por ejemplo, el nombre de host www.example.comdel dominio example.com se traduce a las direcciones 93.184.216.34 ( IPv4 ) y 2606:2800:220:1:248:1893:25c8:1946 ( IPv6 ). El DNS se actualiza de forma rápida y transparente, lo que permite que la ubicación de un servicio en la red cambie sin afectar a los usuarios finales, quienes siguen utilizando el mismo nombre de host. Los usuarios se benefician de esto al usar URL y direcciones de correo electrónico descriptivas sin necesidad de saber cómo el ordenador localiza realmente 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 . ^{[ 4 ]} Cuando un usuario accede a un servicio de Internet distribuido mediante 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 que se aprovecha aquí es que diferentes usuarios pueden recibir simultáneamente distintas traducciones para el mismo nombre de dominio, un punto clave de divergencia con la visión tradicional del DNS como una guía telefónica. Este proceso de usar el DNS para asignar servidores cercanos a los usuarios es fundamental para proporcionar respuestas más rápidas y fiables en Internet y es ampliamente utilizado por la mayoría de los principales servicios de Internet. ^{[ 5 ]}

El DNS refleja la estructura de responsabilidad administrativa en Internet. ^{[ 6 ]} Cada subdominio es una zona de autonomía administrativa delegada a un administrador. Para las zonas operadas por un registro , la información administrativa suele complementarse con los servicios RDAP y WHOIS del registro . Estos datos pueden utilizarse para comprender y rastrear la responsabilidad de un host determinado en Internet. ^{[ 7 ]}

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 ) mantenía un archivo de texto llamado HOSTS.TXT que asignaba nombres de host a las direcciones numéricas de las computadoras en ARPANET. ^{[ 8 ]}^{[ 9 ]} Elizabeth Feinler desarrolló y mantuvo el primer directorio de ARPANET. ^{[ 10 ]}^{[ 11 ]} El mantenimiento de las direcciones numéricas, denominada Lista de Números Asignados, estaba a cargo de Jon Postel en el Instituto de Ciencias de la Información (ISI) de la Universidad del Sur de California, cuyo equipo trabajaba en estrecha colaboración con SRI. ^{[ 12 ]}

Las direcciones se asignaban manualmente. Los ordenadores, incluidos sus nombres de host y direcciones, se añadían al archivo principal contactando con el Centro de Información de la Red SRI (NIC), dirigido por Feinler, por teléfono durante el horario laboral. ^{[ 13 ]} Posteriormente, Feinler configuró un directorio WHOIS en un servidor del NIC para recuperar información sobre recursos, contactos y entidades. ^{[ 14 ]} Ella y su equipo desarrollaron el concepto de dominios. ^{[ 14 ]} Feinler sugirió que los dominios se basaran en la ubicación de la dirección física del ordenador. ^{[ 15 ]} Los ordenadores de las instituciones educativas tendrían el dominio edu , por ejemplo. ^{[ 16 ]} Ella y su equipo gestionaron el Registro de Nombres de Host desde 1972 hasta 1989. ^{[ 17 ]}

A principios de la década de 1980, mantener una tabla de hosts única y centralizada se había vuelto lento y engorroso, y la red emergente requería un sistema de nombres automatizado para abordar problemas técnicos y de personal. Postel encargó a Paul Mockapetris la tarea de encontrar un compromiso entre cinco propuestas de solución en competencia . Mockapetris, en cambio, creó el Sistema de Nombres de Dominio (DNS) en 1983 mientras trabajaba en la Universidad del Sur de California . ^{[ 13 ]}^{[ 18 ]}

El Grupo de Trabajo de Ingeniería de Internet publicó las especificaciones originales en RFC 882 y RFC 883 en noviembre de 1983. ^{[ 19 ]}^{[ 20 ]} Estas se actualizaron en RFC 973 en enero de 1986. ^{[ 21 ]}

En 1984, cuatro estudiantes de la UC Berkeley , Douglas Terry, Mark Painter, David Riggle y Songnian Zhou, escribieron la primera implementación de servidor de nombres Unix para el dominio de nombres de Internet de Berkeley, comúnmente conocido como BIND . ^{[ 22 ]} En 1985, Kevin Dunlap de DEC revisó sustancialmente la implementación de DNS. Mike Karels , Phil Almquist y Paul Vixie asumieron entonces el mantenimiento de BIND. El Consorcio de Sistemas de Internet ( ISC ) 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 a partir de la 4.9.3 fueron desarrolladas y mantenidas por ISC, con el apoyo de sus patrocinadores. 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 el año 2000, más de 43 desarrolladores principales diferentes han trabajado en BIND. ^{[ 23 ]}

En noviembre de 1987, los RFC 1034 ^{[ 24 ]} y RFC 1035 ^{[ 6 ]} reemplazaron las especificaciones DNS de 1983. Varias solicitudes de comentarios adicionales propusieron extensiones a los protocolos DNS centrales. ^{[ 25 ]}

Estructura

espacio de nombres de dominio

El espacio de nombres de dominio consiste en 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í consiste en la etiqueta, concatenada con el nombre de su nodo padre a la derecha, separados por un punto. ^{[ 24 ]}^{: §3.1}

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 puede particionarse según la clase , donde las clases separadas pueden considerarse como una matriz de árboles de espacios de nombres paralelos. ^{[ 24 ]}^{: §4.2}

La responsabilidad administrativa de cualquier zona puede dividirse 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 ser autoritativa para la nueva zona. ^{[ 24 ]}^{: §4.2}

Sintaxis de nombres de dominio, internacionalización

Las descripciones definitivas de las reglas para la formación de nombres de dominio aparecen en los RFC 1035, RFC 1123, RFC 2181 y RFC 5892. Un nombre de dominio consta de una o más partes, técnicamente llamadas etiquetas , que se concatenan convencionalmente y se delimitan con puntos, como example.com.

La etiqueta situada más a la derecha indica 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 example especifica un subdominio del dominio .com , y www es un subdominio de example.com. Este árbol de subdivisiones puede tener hasta 127 niveles. ^{[ 26 ]}

Una etiqueta puede contener de cero a 63 caracteres, ya que la longitud solo puede ocupar 6 bits. La etiqueta nula de longitud cero está reservada para la zona raíz. El nombre de dominio completo no puede exceder la longitud de 253 caracteres en su representación textual (o 254 con el punto final). ^{[ 24 ]} En la representación binaria interna del DNS, esta longitud máxima de 253 requiere 255 octetos de almacenamiento, ya que también almacena la longitud de la primera de muchas etiquetas y agrega el último byte nulo. ^{[ 6 ]} La longitud de 255 solo se alcanza con al menos 6 etiquetas (contando la última etiqueta nula). ^{[ 6 ]}

Aunque no existe ninguna limitación técnica que impida que las etiquetas de los nombres de dominio utilicen cualquier carácter que pueda representarse con un octeto, los nombres de host utilizan un formato y un conjunto de caracteres preferidos. Los caracteres permitidos en las etiquetas son un subconjunto del conjunto de caracteres ASCII , que consta de los caracteres de la a a la z , de la A a la Z , los dígitos del 0 al 9 y el guion. Esta regla se conoce como la regla LDH (letras, dígitos, guion). Los nombres de dominio se interpretan sin distinción de mayúsculas y minúsculas. ^{[ 27 ]} Las etiquetas no pueden comenzar ni terminar con un guion. ^{[ 28 ]} Una regla adicional exige que los nombres de dominio de nivel superior no sean exclusivamente numéricos. ^{[ 28 ]}

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 nativas. Para posibilitar esto, la ICANN aprobó el sistema de Internacionalización de Nombres de Dominio en Aplicaciones (IDNA), mediante el cual las aplicaciones de usuario, como los navegadores web, asignan cadenas Unicode al conjunto de caracteres DNS válido utilizando Punycode . En 2009, la ICANN aprobó la instalación de dominios de nivel superior de código de país ( ccTLD ) internacionalizados . Además, muchos registros de los dominios de nivel superior ( TLD ) existentes han adoptado el sistema IDNA, guiados por los RFC 5890, 5891, 5892 y 5893.

Delegación

El mecanismo mediante el cual se asigna la responsabilidad de diferentes partes del espacio de nombres DNS a diferentes servidores de nombres se denomina delegación . Cada dominio de red pública bajo los dominios de nivel superior se delega, al tener un registro NS en el dominio padre que apunta a los nombres DNS de los servidores de nombres para el dominio delegado (o hijo). Si esos servidores de nombres están en el dominio delegado, el dominio padre también debe contener registros de enlace , que contienen las direcciones IP de los servidores de nombres del dominio hijo. ^{[ 29 ]}

Servidores de nombres

El Sistema de Nombres de Dominio (DNS) 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 autoritativo que publica información sobre ese dominio y los servidores de nombres de cualquier dominio subordinado. La parte superior de la jerarquía la gestionan los servidores raíz , que son los servidores a los que se consulta al buscar ( resolver ) un TLD .

Servidor de nombres autoritativo

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

Un servidor de nombres autoritativo puede ser un servidor primario o secundario . Históricamente, los términos maestro/esclavo y primario/secundario se usaban a veces indistintamente ^{[ 30 ]} , pero actualmente se utiliza la segunda forma. Un servidor primario 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 para comunicarse con su servidor primario y mantener una copia idéntica de los registros primarios.

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

Un servidor autoritativo indica su condición de proporcionar respuestas definitivas, consideradas autoritativas , estableciendo un indicador de protocolo, denominado bit de " Respuesta Autorizada " ( AA ), en sus respuestas. ^[⁶^] Este indicador suele reproducirse de forma destacada en la salida 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 es designado como servidor autoritativo para un nombre de dominio para el cual no tiene datos autoritativos, presenta un tipo de error llamado "delegación débil" o "respuesta débil". ^{[ 31 ]}^{[ 32 ]}

Operación

Mecanismo de resolución de direcciones

Los resolvedores 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 comienza con la etiqueta de dominio de nivel superior (más a la derecha).

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

Suponiendo que el resolvedor no tenga registros en caché para acelerar el proceso, este comienza con una consulta a uno de los servidores raíz. En condiciones normales, los servidores raíz no responden directamente, sino que remiten a servidores con mayor autoridad; por ejemplo, una consulta para "www.wikipedia.org" se remite a los servidores .org . El resolvedor consulta entonces a los servidores remitidos y repite este proceso iterativamente hasta recibir una respuesta autorizada. El diagrama ilustra este proceso para el host con el nombre de dominio completo "www.wikipedia.org".

Este mecanismo sobrecargaría enormemente los servidores raíz si cada resolución en Internet requiriera comenzar desde la raíz. En la práctica, los servidores DNS utilizan el almacenamiento en caché para aliviar la carga de los servidores raíz, por lo que estos solo intervienen en una fracción relativamente pequeña del total de solicitudes.

Servidor de nombres recursivo y con almacenamiento en caché

En teoría, los servidores de nombres autoritativos son suficientes para el funcionamiento de Internet. Sin embargo, si solo operan servidores de nombres autoritativos, cada consulta 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 de forma recursiva. ^{[ 33 ]}

Para mejorar la eficiencia, reducir el tráfico DNS en Internet y aumentar el rendimiento de las aplicaciones de usuario final, el Sistema de Nombres de Dominio (DNS) admite servidores de caché DNS que almacenan los resultados de las consultas DNS durante un período de tiempo determinado en la configuración ( tiempo de vida ) del registro del nombre de dominio en cuestión. Por lo general, estos servidores DNS de caché también implementan el algoritmo recursivo necesario para resolver un nombre dado, desde la raíz DNS hasta los servidores de nombres autoritativos del dominio consultado. Con esta función implementada en el servidor de nombres, las aplicaciones de usuario ganan en eficiencia tanto en el diseño como en el funcionamiento.

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

Los proveedores de servicios de Internet (ISP) suelen ofrecer servidores de nombres recursivos y con almacenamiento en caché a sus clientes. Además, muchos routers domésticos implementan cachés DNS y recursión para mejorar la eficiencia de la red local.

Resolutores DNS

El lado del cliente del DNS se denomina resolvedor DNS. Un resolvedor es responsable de iniciar y secuenciar las consultas que, en última instancia, conducen a la resolución completa (traducción) del recurso buscado, por ejemplo, la traducción de un nombre de dominio a una dirección IP. Los resolvedores DNS se clasifican según diversos métodos de consulta, como recursivos , no recursivos e iterativos . Un proceso de resolución puede utilizar una combinación de estos métodos. ^{[ 24 ]}

En una consulta no recursiva , un resolvedor DNS consulta a un servidor DNS que proporciona un registro para el cual el servidor es autoritativo, o bien proporciona un resultado parcial sin consultar a otros servidores. En el caso de un resolvedor DNS con caché , la consulta no recursiva a su caché DNS local proporciona 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 dichos servidores.

En una consulta recursiva , un resolvedor DNS consulta a un único servidor DNS, que a su vez puede consultar a otros servidores DNS en nombre del solicitante. Por ejemplo, un resolvedor simple que se ejecuta en un enrutador doméstico suele realizar una consulta recursiva al servidor DNS del proveedor de servicios de Internet (ISP) del usuario. Una consulta recursiva es aquella en la que el servidor DNS responde completamente a la consulta consultando a otros servidores de nombres según sea necesario. En el funcionamiento habitual, un cliente emite una consulta recursiva a un servidor DNS recursivo con caché, que posteriormente emite consultas no recursivas para determinar la respuesta y enviar una única respuesta al cliente. El resolvedor, u otro servidor DNS que actúe recursivamente en nombre del resolvedor, negocia el uso del servicio recursivo mediante bits en las cabeceras de la consulta. Los servidores DNS no están obligados a admitir consultas recursivas.

El procedimiento de consulta iterativa es un proceso en el que un resolvedor 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 primero un servidor raíz global, luego un servidor ".com" y, finalmente, un servidor "example.com".

Dependencias circulares y registros de pegamento

Los servidores de nombres en las delegaciones se identifican por su nombre, no por su dirección IP. Esto significa que un servidor de nombres que resuelve un nombre debe realizar otra solicitud DNS para descubrir la dirección IP del servidor al que se le ha remitido. Si el nombre especificado 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 del servidor de nombres autoritativo mencionado en la delegación. Esta información se denomina "pegamento" . El servidor de nombres delegador 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 pegamento es una combinación del servidor de nombres y la dirección IP.

Por ejemplo, si el servidor de nombres autoritativo para example.org es ns1.example.org, un ordenador que intenta resolver www.example.org primero resuelve ns1.example.org. Como ns1 está contenido en example.org, esto requiere resolver primero example.org, lo que genera una dependencia circular. Para romper esta dependencia, el servidor de nombres del dominio de nivel superior org incluye registros de enlace junto con la delegación para example.org. Los registros de enlace son registros de direcciones que proporcionan direcciones IP para ns1.example.org. El resolvedor utiliza una o más de estas direcciones IP para consultar uno de los servidores autoritativos del dominio, lo que le permite completar la consulta DNS.

Almacenamiento en caché de registros

Un método común para reducir la carga de consultas en los servidores DNS consiste en almacenar en caché los resultados de la resolución de nombres localmente o en servidores de resolución intermedios. Cada resultado de consulta DNS incluye un tiempo de vida (TTL), que indica cuánto tiempo permanece válida la información antes de que deba descartarse o actualizarse. Este TTL lo determina el administrador del servidor DNS autoritativo y puede variar desde unos pocos segundos hasta varios días o incluso semanas. ^{[ 34 ]}

Como resultado de esta arquitectura de almacenamiento en caché distribuido, los cambios en los registros DNS no se propagan inmediatamente por toda la red, sino que requieren que todas las cachés caduquen y se actualicen después del TTL. El RFC 1912 transmite reglas básicas para determinar los valores TTL apropiados, con valores típicos de 1 a 5 días, y de 1 a 2 semanas para registros como direcciones de hosts de correo o servidores de nombres que no se espera que cambien con frecuencia. Los valores TTL para registros individuales se pueden reducir anticipándose a un cambio, aumentando el tráfico de la red hasta que se realice el cambio.

Algunos resolvedores pueden sobrescribir los valores TTL, ya que el protocolo admite el almacenamiento en caché hasta por sesenta y ocho años o la ausencia total de almacenamiento en caché. El almacenamiento en caché negativo , es decir, el almacenamiento en caché de la inexistencia de un registro, lo determinan los servidores de nombres autorizados para una zona, que deben incluir el registro de Inicio de Autoridad (SOA) al informar que no existen datos del tipo solicitado. El valor del campo mínimo del registro SOA y el TTL del propio SOA se utilizan para establecer el TTL de la respuesta negativa.

Búsqueda inversa

Una búsqueda DNS inversa es una consulta al DNS para obtener nombres de dominio cuando se conoce la dirección IP. Una dirección IP puede estar asociada a varios nombres de dominio. 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 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 en representación de nibbles 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 para 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 está asignada a Wikimedia, se representa como un nombre DNS en orden inverso: 2.152.80.208.in-addr.arpa. Cuando el resolvedor 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 la cual el resolvedor envía otra consulta para 2.152.80.208.in-addr.arpa, lo que resulta en una respuesta autorizada.

Búsqueda de clientes

Por lo general, los usuarios no se comunican directamente con un servidor DNS. En cambio, la resolución DNS se realiza 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 la búsqueda de un nombre de dominio, envía una solicitud de resolución al servidor DNS del sistema operativo local, que a su vez gestiona las comunicaciones necesarias.

El resolvedor DNS casi siempre tendrá una caché (ver más arriba) con las consultas recientes. Si la caché puede proporcionar la respuesta a la solicitud, el resolvedor devolverá el valor almacenado en la caché al programa que realizó la solicitud. Si la caché no contiene la respuesta, el resolvedor 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 (ISP) al que se conecta el equipo suele proporcionar este servidor DNS: dicho usuario habrá configurado la dirección de ese servidor manualmente o habrá permitido que DHCP la asigne. Sin embargo, cuando los administradores de sistemas han configurado los sistemas para usar sus propios servidores DNS, sus resolvedores DNS apuntan a servidores de nombres de la organización que se mantienen por separado. En cualquier caso, el servidor de nombres consultado seguirá el proceso descrito anteriormente hasta que encuentre un resultado o no. Luego, devuelve sus resultados al resolvedor DNS; si ha encontrado un resultado, el resolvedor lo almacena en caché para su uso futuro y lo devuelve al software que inició la solicitud.

Resolutores rotos

Algunos grandes ISP han configurado sus servidores DNS para violar las reglas, como desobedecer los TTL o indicar que un nombre de dominio no existe simplemente porque uno de sus servidores de nombres no responde. ^{[ 35 ]}

Algunas aplicaciones, como los navegadores web, mantienen una caché DNS interna para evitar consultas repetidas a través de la red. Esta práctica puede dificultar la depuración de problemas DNS, ya que oculta el historial de dichos datos. Estas cachés suelen utilizar tiempos de almacenamiento muy cortos, del orden de un minuto. ^{[ 36 ]}

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.

Los nombres de host y las direcciones IP no tienen por qué coincidir exactamente. Varias direcciones IP pueden estar asociadas a un mismo nombre de host, lo cual resulta útil en el alojamiento virtual , donde muchos sitios web se sirven desde un único servidor. Asimismo, un único nombre de host puede resolverse en varias direcciones IP para facilitar la tolerancia a fallos y la distribución de carga entre múltiples instancias de servidor en una empresa o en Internet.

El DNS cumple otras funciones además de traducir nombres a direcciones IP. Por ejemplo, los agentes de transferencia de correo utilizan el DNS para encontrar el mejor servidor de correo para entregar correos electrónicos : un registro MX establece una correspondencia entre un dominio y un servidor de correo; esto puede proporcionar una capa adicional de tolerancia a fallos 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 bloqueados. Un método común consiste en colocar la dirección IP del servidor en cuestión en el subdominio de un dominio de nivel superior y resolver ese dominio a un registro que indique si está bloqueado o no.

Por ejemplo:

La dirección 203.0.113.5 está en la lista de bloqueo. Apunta a 5.113.0.203.blocklist.example , que se resuelve en 127.0.0.1 .
La dirección 203.0.113.6 no está en la lista de bloqueo y apunta a 6.113.0.203.blocklist.example . Este nombre de host no está configurado o se resuelve a 127.0.0.2 .

Los servidores de correo electrónico pueden consultar blocklist.example para averiguar si un host específico que se conecta a ellos está en la lista de bloqueo. Existen muchas listas de bloqueo de este tipo, tanto de pago como gratuitas, que pueden utilizar los administradores de correo electrónico y el software antispam.

Para garantizar la resiliencia en caso de fallos informáticos o de red, normalmente se proporcionan varios servidores DNS para cubrir cada dominio. En el nivel superior del DNS global, existen trece grupos de servidores raíz , con copias adicionales de estos distribuidas por todo el mundo mediante direccionamiento anycast .

El DNS dinámico (DDNS) actualiza un servidor DNS con la dirección IP del cliente sobre la marcha, por ejemplo, al cambiar de proveedor de servicios de Internet o de punto de acceso móvil , 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 una cabecera y cuatro secciones: pregunta, respuesta, autoridad y un espacio adicional. Un campo de cabecera ( flags ) controla el contenido de estas cuatro secciones. ^{[ 24 ]}

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 16 bits de longitud y aparece en el orden indicado. El campo de identificación se utiliza para relacionar las respuestas con las consultas. Tras la palabra "Indicadores", el encabezado finaliza con cuatro enteros de 16 bits que contienen el número de registros en cada una de las secciones siguientes, en el mismo orden.

ID de transacción : 16 bits

ID de transacción

Banderas : 16 bits

El campo de la bandera consta de los siguientes subcampos:

QR : 1 bit

Indica si el mensaje es una consulta (0) o una respuesta (1).

CÓDIGO DE OPERACIÓN : 4 bits

El tipo puede ser QUERY (consulta estándar, 0), IQUERY (consulta inversa, 1) o STATUS (solicitud de estado del servidor, 2).

AA : 1 bit

La respuesta autorizada indica si el servidor DNS es la fuente autorizada para el nombre de host consultado.

TC : 1 bit

TrunCation indica que este mensaje fue truncado debido a su longitud excesiva.

RD : 1 bit

Recursion Desired indica si el cliente se refiere a una consulta recursiva.

RA : 1 bit

En una respuesta, la opción "Recursión disponible" indica si el servidor DNS que responde admite la recursión.

Z : 1 bit ; (Z) == 0

Cero, reservado para uso futuro.

AD : 1 bit

Los datos auténticos, en una respuesta, indican si el servidor DNS que responde verificó los datos.

CD : 1 bit

Al marcar la opción "Deshabilitado" en una consulta, se indica que se aceptan datos no verificados en la respuesta.

RCODE : 4 bits

El código de respuesta puede ser NOERROR (0), FORMERR (1, error de formato), SERVFAIL (2), NXDOMAIN (3, dominio inexistente), etc. ^{[ 37 ]}

Número de preguntas : 16 bits

Número de preguntas.

Número de respuestas : 16 bits

Número de respuestas.

Número de registros de autoridad : 16 bits

Número de registros de recursos de autoridad.

Número de RR adicionales : 16 bits

Número de registros de recursos adicionales.

Sección de preguntas

La sección de preguntas tiene un formato más sencillo que el formato de registro de recursos utilizado en las demás secciones. Cada registro de preguntas (normalmente 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. ^{[ 38 ]}

Registros de recursos

El Sistema de Nombres de Dominio (DNS) especifica una base de datos de elementos de información para los recursos de red. Los tipos de elementos de información se clasifican y organizan mediante 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 resolvedores DNS devuelven el conjunto completo al realizar una consulta, pero los servidores pueden implementar un ordenamiento round-robin para lograr el equilibrio de carga . En cambio, las Extensiones de Seguridad del Sistema de Nombres de Dominio (DNSSEC) trabajan con 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 (respuesta, autoridad y secciones adicionales) utilizan el formato común especificado en RFC 1035: ^{[ 39 ]}^{: §3}

NAME es el nombre de dominio completo del nodo en el árbol. En la red, el nombre puede acortarse mediante compresión de etiquetas, donde los extremos de los nombres de dominio mencionados anteriormente en el paquete pueden sustituir al final del nombre de dominio actual.

TIPO es el tipo de registro. Indica el formato de los datos y da una idea de su uso previsto. Por ejemplo, el registro A se utiliza para traducir un nombre de dominio a una dirección IPv4 , el registro NS enumera qué servidores de nombres pueden responder a las consultas en una zona DNS , y el registro MX especifica el servidor de correo utilizado para gestionar el correo de un dominio especificado en una dirección de correo electrónico.

RDATA son datos de relevancia específica para cada tipo de registro, 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 registro conocidos pueden usar compresión de etiquetas en el campo RDATA, pero los tipos de registro "desconocidos" no deben hacerlo (RFC 3597).

La CLASE de un registro se establece en IN (de Internet ) para los registros DNS comunes que involucran nombres de host, servidores o direcciones IP de Internet. Además, existen las clases Chaos (CH) y Hesiod (HS). ^{[ 39 ]}^{: 11} Cada clase es un espacio de nombres independiente con delegaciones potencialmente diferentes de zonas DNS.

Además de los registros de recursos definidos en un archivo de zona , el sistema de nombres de dominio también define varios tipos de solicitudes que se utilizan únicamente en la comunicación con otros nodos DNS ( en la red ), como al realizar 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. ^{[ 24 ]}^{[ 40 ]} Los registros DNS pertenecientes a nombres de dominio comodín especifican reglas para generar registros de recursos dentro de una única zona DNS sustituyendo 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 utilizan el intercambiador de correo (MX) axexample . El registro AAAA para axexample es 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 comodín, también se debe definir un registro MX adicional para el subdominio axexample , así como un registro MX comodín para todos sus subdominios, en la zona DNS.

x.ejemplo. MX 10 a.x.ejemplo. *.x.ejemplo. MX 10 a.x.ejemplo. axexample. MX 10 a.x.ejemplo. *.axexample. MX 10 a.x.ejemplo. axexample. AAAA 2001:db8::1

El rol de los registros comodín se perfeccionó en RFC 4592 , porque la definición original en RFC 1034 era incompleta y dio lugar a interpretaciones erróneas por parte de los implementadores. ^[⁴⁰^]

Extensiones de protocolo

El protocolo DNS original tenía limitaciones para la extensión con nuevas funcionalidades. En 1999, Paul Vixie publicó en el RFC 2671 (sustituido por el RFC 6891) un mecanismo de extensión, denominado Mecanismos de Extensión para DNS (EDNS), que introducía elementos de protocolo opcionales sin aumentar la sobrecarga cuando no se utilizaban. Esto se lograba mediante el registro de pseudorrecurso OPT, que solo existe en las transmisiones por cable del protocolo, pero no en los archivos de zona. También se sugirieron extensiones iniciales (EDNS0), como el aumento del tamaño de los mensajes DNS en los datagramas UDP.

Actualizaciones dinámicas de zonas

Las actualizaciones dinámicas de DNS utilizan el código de operación UPDATE DNS para agregar o eliminar registros de recursos de forma dinámica de una base de datos de zona mantenida en un servidor DNS autoritativo. ^{[ 41 ]} Esta función es útil para registrar clientes de red en el DNS cuando se inician o se conectan a la red. Dado que a un cliente que se inicia se le puede asignar una dirección IP diferente cada vez desde un servidor DHCP , no es posible proporcionar asignaciones DNS estáticas para dichos clientes.

protocolos de transporte

Desde su creación en 1983, el DNS ha utilizado el Protocolo de Datagramas de Usuario (UDP) para la transmisión a través de IP. Sus limitaciones han motivado numerosos desarrollos de protocolos en las décadas siguientes para mejorar la fiabilidad, la seguridad, la privacidad y otros criterios.

Convencional: DNS sobre UDP y puerto TCP 53 (Do53)

UDP reserva el puerto 53 para servidores que escuchan consultas. ^{[ 6 ]} Dicha consulta consiste en una solicitud en texto plano enviada en un único paquete UDP desde el cliente, a la que el servidor responde con una respuesta en texto plano enviada en un único paquete UDP. 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. ^{[ 42 ]} El uso de DNS sobre UDP está limitado, entre otras cosas, por su falta de cifrado de capa de transporte, autenticación, entrega confiable y longitud de mensaje. En 1989, el RFC 1123 especificó el transporte opcional del Protocolo de Control de Transmisión (TCP) para consultas DNS, respuestas y, en particular, transferencias de zona . Mediante la fragmentación de respuestas largas, TCP permite respuestas más largas, entrega confiable y reutilización de conexiones de larga duración entre clientes y servidores. Para respuestas más grandes, el servidor remite al cliente al transporte TCP.

DNS sobre TLS (DoT)

DNS sobre TLS surgió como estándar IETF para DNS cifrado en 2016, utilizando Transport Layer Security (TLS) para proteger toda la conexión, en lugar de solo la carga útil de DNS. Los servidores DoT escuchan en el puerto TCP 853. El RFC 7858 especifica que se puede admitir el cifrado oportunista y el cifrado autenticado, pero no hizo obligatoria la autenticación del servidor ni del cliente.

DNS sobre HTTPS (DoH)

DNS sobre HTTPS se desarrolló en 2018 como un estándar alternativo para el transporte de consultas DNS, que tuneliza los datos de las consultas DNS a través de HTTPS, el cual transporta HTTP sobre TLS. DoH se promovió como una alternativa más amigable para la web que DNS, ya que, al igual que DNSCrypt, utiliza el puerto TCP 443 y, por lo tanto, se parece al tráfico web, aunque en la práctica son fácilmente diferenciables sin el relleno adecuado. ^{[ 43 ]}

DNS sobre QUIC (DoQ)

El RFC 9250, publicado en 2022 por el Grupo de Trabajo de Ingeniería de Internet (IETF ), describe DNS sobre QUIC . Presenta "propiedades de privacidad similares a DNS sobre TLS (DoT) [...] y características de latencia similares a las de DNS sobre UDP clásico". Este método no es lo mismo que DNS sobre HTTP/3 . ^{[ 44 ]}

DNS sobre CoAP (DoC)

El RFC 9953, publicado en 2026 por el Grupo de Trabajo de Ingeniería de Internet , describe DNS sobre CoAP . El caso de uso de DoC se inspira en DNS sobre HTTPS (DoH) (RFC 8484). Sin embargo, DoC está diseñado para su implementación en el Internet de las Cosas (IoT) con recursos limitados, lo que suele entrar en conflicto con los requisitos introducidos por HTTPS. ^{[ 45 ]} DoC supera a otros mecanismos de resolución DNS en escenarios con recursos limitados. ^{[ 46 ]}

Oblivious DoH (ODoH) y su predecesor Oblivious DNS (ODNS)

El DNS opaco (ODNS) fue inventado e implementado por investigadores de la Universidad de Princeton y la Universidad de Chicago como una extensión del DNS no cifrado, ^{[ 47 ]} antes de que DoH se estandarizara y se implementara ampliamente. Posteriormente, Apple y Cloudflare implementaron la tecnología en el contexto de DoH, como Oblivious DoH (ODoH). ^{[ 48 ]} ODoH combina la separación de entrada/salida (inventada en ODNS) con el túnel HTTPS de DoH y el cifrado de la capa de transporte TLS en un solo protocolo. ^{[ 49 ]}

DNS sobre Tor

El DNS puede ejecutarse sobre redes privadas virtuales (VPN) y protocolos de tunelización . Las ventajas en privacidad del DNS opaco se pueden obtener mediante el uso de la red Tor preexistente de nodos de entrada y salida, junto con el cifrado de la capa de transporte proporcionado por TLS. ^{[ 50 ]}

DNSCrypt

El protocolo DNSCrypt , desarrollado en 2011 fuera del marco de estándares de la IETF , introdujo el cifrado DNS en el lado descendente de los resolvedores 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 autoridades de certificación de terceros) y que a su vez pueden estar protegidas por firmas DNSSEC . ^{[ 51 ]} DNSCrypt utiliza el puerto TCP 443, el mismo puerto que el tráfico web cifrado HTTPS , o el puerto UDP 443. Esto introdujo no solo privacidad con respecto al contenido de la consulta, sino también una medida significativa de capacidad de atravesar cortafuegos. En 2019, DNSCrypt se amplió aún más para admitir un modo "anonimizado", similar al propuesto "Oblivious DNS", en el que un nodo de entrada recibe una consulta que ha sido cifrada con la clave pública de un servidor diferente y la reenvía a ese servidor, que actúa como un nodo de salida, realizando la resolución recursiva. ^{[ 52 ]} Se crea privacidad para los pares usuario/consulta, ya que el nodo de entrada desconoce el contenido de la consulta, mientras que el nodo de salida desconoce la identidad del cliente. DNSCrypt fue implementado por primera vez en producción por OpenDNS en diciembre de 2011. Existen varias implementaciones de software libre y de código abierto que integran ODoH. ^{[ 53 ]} Está disponible para diversos sistemas operativos, incluidos Unix, Apple iOS, Linux, Android y Windows.

Problemas de seguridad

Originalmente, las cuestiones de seguridad no eran consideraciones importantes en el diseño del software DNS ni de ningún otro software destinado a 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 al 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 de los usuarios .

Se descubrieron y explotaron varias vulnerabilidades. Una de ellas es el envenenamiento de la caché DNS , en el que se distribuyen datos a los servidores de caché haciéndose pasar por un servidor de origen autorizado, contaminando así el almacén de datos con información potencialmente falsa y tiempos de caducidad prolongados (tiempo de vida). Posteriormente, las solicitudes legítimas de las aplicaciones pueden ser redirigidas a hosts de red operados con intenciones maliciosas.

Las respuestas 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 DNS para agregar soporte para respuestas firmadas criptográficamente. ^{[ 54 ]} 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 utilizan comúnmente para autorizar operaciones de transferencia de zona o actualización dinámica.

También se pueden utilizar técnicas como el DNS inverso con confirmación directa para ayudar a validar los resultados de DNS.

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

Suplantación de DNS

Algunos nombres de dominio pueden utilizarse para lograr efectos de suplantación de identidad. Por ejemplo, paypal.com y paypa1.com son nombres diferentes, pero los usuarios pueden no distinguirlos en una interfaz gráfica de usuario dependiendo de la tipografía elegida . En muchas fuentes, la letra l y el número 1 se ven muy similares o incluso idénticos. Este problema, conocido como ataque de homógrafo IDN , es especialmente grave en sistemas que admiten nombres de dominio internacionalizados , ya que muchos códigos de caracteres en ISO 10646 pueden aparecer idénticos en pantallas de ordenador típicas. Esta vulnerabilidad se explota ocasionalmente en ataques de phishing . ^[⁵⁵^]

Mensajero DNS

DNSMessenger ^{[ 56 ]}^{[ 57 ]}^{[ 58 ]}^{[ 59 ]} es un tipo de técnica de ciberataque que utiliza el DNS para comunicarse y controlar malware de forma remota sin depender de protocolos convencionales que podrían levantar sospechas. El ataque DNSMessenger es encubierto porque el DNS se utiliza principalmente para la resolución de nombres de dominio y, a menudo, no es monitoreado de cerca por las herramientas de seguridad de red, lo que lo convierte en un canal efectivo para que los atacantes lo exploten.

Esta técnica implica el uso de registros DNS TXT para enviar comandos a sistemas infectados. Una vez que el malware se ha instalado subrepticiamente en la máquina de la víctima, se conecta a un dominio controlado para obtener comandos codificados en registros DNS de texto. Esta forma de comunicación del malware es sigilosa, ya que las solicitudes DNS suelen ser permitidas a través de los cortafuegos, y dado que el tráfico DNS a menudo se considera inofensivo, estas comunicaciones pueden eludir muchas defensas de seguridad de la red.

Los ataques DNSMessenger permiten una amplia gama de actividades maliciosas, desde la exfiltración de datos hasta la entrega de cargas útiles adicionales, todo ello sin ser detectado por las medidas de seguridad de red tradicionales. Comprender y protegerse contra estos métodos es fundamental para mantener una ciberseguridad sólida.

Problemas de privacidad y seguimiento

Diseñado originalmente como una base de datos pública, jerárquica, distribuida y con un amplio almacenamiento en caché, el protocolo DNS carece de controles de confidencialidad. Las consultas de los usuarios y las respuestas de los servidores de nombres se envían sin cifrar, lo que permite la interceptación de paquetes de red , el secuestro de DNS , el envenenamiento de la caché DNS y los ataques de intermediario (man-in-the-middle) . Esta deficiencia es utilizada habitualmente por ciberdelincuentes y operadores de red con fines de marketing, autenticación de usuarios en portales cautivos y censura . ^{[ 60 ]}

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

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

Las VPN , que transfieren la resolución de DNS al operador de VPN y ocultan el tráfico del usuario al proveedor de servicios de Internet local.
Tor , que reemplaza la resolución DNS tradicional con dominios .onion anónimos , oculta tanto la resolución de nombres como el tráfico de usuarios detrás de un sistema de contravigilancia de enrutamiento onion .
Los servidores proxy y los servidores DNS públicos trasladan la resolución DNS real a un proveedor externo de confianza.
- Algunos servidores DNS públicos pueden admitir extensiones de seguridad como DNS sobre HTTPS , DNS sobre TLS y DNSCrypt .

Las soluciones que impiden la inspección de DNS por parte del operador de red local han sido criticadas por obstaculizar las políticas de seguridad de red corporativas y la censura en Internet. Los servidores DNS públicos también son criticados por contribuir a la centralización de Internet al poner el control sobre la resolución de DNS en manos de unas pocas grandes empresas que pueden permitirse operar servidores DNS públicos. ^{[ 60 ]}

Google es el proveedor dominante de la plataforma en Android , el navegador en Chrome y el servidor DNS en el servicio 8.8.8.8. ¿Sería este escenario un caso en el que una sola entidad corporativa tuviera el control absoluto de todo el espacio de nombres de Internet? Netflix ya lanzó una aplicación que utilizaba su propio mecanismo de resolución DNS, independiente de la plataforma en la que se ejecutaba. ¿Qué pasaría si la aplicación de Facebook incluyera DoH? ¿Qué pasaría si iOS de Apple utilizara un mecanismo de resolución DoH para eludir la resolución DNS local y dirigir todas las consultas DNS de las plataformas de Apple a un conjunto de servidores DNS operados por Apple?

— Privacidad del DNS y la IETF

Registro de nombres de dominio

El derecho a usar un nombre de dominio es delegado por los registradores de nombres de dominio acreditados por la Corporación de Internet para la Asignación de Nombres y Números (ICANN) u otras organizaciones como OpenNIC , encargadas de supervisar los sistemas de nombres y números de Internet. Además de ICANN, cada dominio de nivel superior (TLD) es mantenido y gestionado 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 solicita el registro de un dominio. ^{[ 25 ]} 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 . ^{[ 61 ]}

ICANN publica la lista completa de TLD, registros de TLD y registradores de nombres de dominio. La información del registrante asociada a los nombres de dominio se mantiene en una base de datos en línea accesible mediante el servicio WHOIS. Para la mayoría de los más de 290 dominios de nivel superior de código de país (ccTLD), los registros de dominio mantienen la información WHOIS (registrante, servidores de nombres, fechas de vencimiento, etc.). Por ejemplo, DENIC , el NIC de Alemania, almacena los datos del dominio DE. Desde aproximadamente 2001, la mayoría de los registros de dominios genéricos de nivel superior (gTLD) han adoptado este enfoque de registro centralizado , es decir, mantienen los datos WHOIS en registros centrales en lugar de en las bases de datos de los registradores.

Para los dominios de nivel superior en COM y NET, se utiliza un modelo de registro simplificado . El registro de dominios ( GoDaddy , BigRock, PDR , VeriSign , etc.) almacena datos WHOIS básicos (es decir, registrador, servidores de nombres, etc.). Por otro lado, las organizaciones, es decir, los registrantes que utilizan ORG, se encuentran exclusivamente en el Registro de Interés Público .

Algunos registros de nombres de dominio, a menudo denominados centros de información de red (NIC), también funcionan como registradores para usuarios finales, además de proporcionar acceso a los conjuntos de datos WHOIS. Los registros de dominios de nivel superior, como los de los dominios COM, NET y ORG, utilizan un modelo de registro-registrador que consta de muchos registradores de nombres de dominio. ^{[ 62 ]} En este método de gestión, el registro solo administra 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 la subcontratación de revendedores.

Referencias

1 2 Wu, Hao; Dang, Xianglei; Wang, Lidong; He, Longtao (2016). "Método basado en fusión de información para la detección e identificación de ataques de envenenamiento de caché de sistemas de nombres de dominio distribuidos" . IET Information Security . 10 (1): 37– 44. doi : 10.1049/iet-ifs.2014.0386 . ISSN 1751-8717 . S2CID 45091791 .
↑ Goodwin, Chrystal R. China, Michael (04/11/2025). "¿Qué es DNS (Sistema de nombres de dominio)? | IBM" . www.ibm.com . Consultado el 10/07/2026 .{{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace )
↑ J. Postel , ed. ( septiembre de 1981). PROTOCOLO DE INTERNET - ESPECIFICACIÓN DEL PROTOCOLO DEL PROGRAMA DE INTERNET DE DARPA . IETF . doi : 10.17487/RFC0791 . STD 5. RFC 791. IEN 128, 123, 111, 80, 54, 44, 41, 28, 26.Estándar de Internet 5. Sustituye a RFC 760. Actualizado por RFC 1349 , 2474 y 6864 .
↑ J. Dilley, B. Maggs, J. Parikh, H. Prokop, R. Sitaraman y B. Weihl. «Entrega de contenido distribuido globalmente», IEEE Internet Computing, septiembre/octubre de 2002, págs. 50-58 (PDF) . Archivado (PDF) del original el 17 de abril de 2015.
↑ Nygren, E.; Sitaraman RK; Sun, J. (2010). "The Akamai Network: A Platform for High-Performance Internet Applications" ( PDF) . ACM SIGOPS Operating Systems Review . 44 (3): 2– 19. doi : 10.1145/1842733.1842736 . S2CID 207181702. Archivado (PDF) del original el 2 de diciembre de 2010. Recuperado el 19 de noviembre de 2012 .
1 2 3 4 5 6 7 P. Mockapetris (noviembre de 1987). NOMBRES DE DOMINIO: IMPLEMENTACIÓN Y ESPECIFICACIÓN . Grupo de Trabajo de Redes. doi : 10.17487/RFC1035 . STD 13. RFC 1035 .Estándar de Internet 13. Deja obsoletos los RFC 882 , 883 y 973. Actualizado por los RFC 1101 , 1183 , 1348 , 1876 , 1982 , 1995 , 1996 , 2065 , 2136 , 2137 , 2181 , 2308 , 2535 , 2673 , 2845 , 3425 , 3658 , 4033 , 4034 , 4035 , 4343 , 5936 , 5966 , 6604 , 7766 , 8482 , 8490 y 8767 .
^ Champika Wijayatunga (febrero de 2015). "Manejo de abuso de DNS" (PDF) . APNIC . Archivado (PDF) desde el original el 22 de diciembre de 2015 . Consultado el 18 de diciembre de 2016 .
↑ J. Klensin (febrero de 2003). Papel del sistema de nombres de dominio (DNS) . Grupo de trabajo de redes. doi : 10.17487/RFC3467 . RFC 3467 .Informativo.
↑ Liu, Cricket; Albitz, Paul (2006). DNS y BIND (5.ª ed.). O'Reilly Media. pág. 3. ISBN 978-0-596-10057-5.
↑ Evans 2018 , pág. 112.
↑ Evans 2018 , pág. 113.
↑ Anales del IEEE [3B2-9] man2011030074.3d 29/7/011 11:54 Página 74
1 2 "¿Por qué Internet sigue funcionando en Navidad? Paul Mockapetris - Salón de la Fama de Internet" . internethalloffame.org . 23 de julio de 2012.
1 2 Evans 2018 , pág. 119.
↑ Evans 2018 , pág. 120.
↑ Evans 2018 , págs. 120–121.
↑ "Elizabeth Feinler" . Salón de la Fama de Internet . Archivado del original el 14 de septiembre de 2018. Consultado el 25 de noviembre de 2018 .
↑ "Paul Mockapetris | Salón de la Fama de Internet" . internethalloffame.org . Consultado el 12 de febrero de 2020 .
↑ Andrei Robachevsky (26 de noviembre de 2013). "¡Feliz 30.º cumpleaños, DNS!" . Internet Society . Consultado el 18 de diciembre de 2015 .
↑ Elizabeth Feinler, IEEE Annals, 3B2-9 man2011030074.3d 29/7/011 11:54 Página 74
↑ P. Mockapetris (febrero de 1986). Cambios y observaciones del sistema de dominios . Grupo de trabajo de redes. doi : 10.17487/RFC0973 . RFC 973 .Obsoleto. Obsoleto según las RFC 1034 y 1035. Actualiza las RFC 882 y 883 .
↑ Terry, Douglas B.; et al. (12–15 de junio de 1984). "El servidor de nombres de dominio de Internet de Berkeley" . Conferencia de verano, Salt Lake City 1984: Actas . USENIX Association Software Tools Users Group. págs. 23–31 .
↑ Consorcio de Sistemas de Internet. "La historia de BIND" . Historia de BIND. Archivado del original el 30 de junio de 2019. Consultado el 4 de abril de 2022 .
1 2 3 4 5 6 7 8 P. Mockapetris (noviembre de 1987). NOMBRES DE DOMINIO: CONCEPTOS Y FACILIDADES . Grupo de Trabajo de Redes. doi : 10.17487/RFC1034 . STD 13. RFC 1034 .Estándar de Internet 13. Deja obsoletos los RFC 882 , 883 y 973. Actualizado por los RFC 1101 , 1183 , 1348 , 1876 , 1982 , 2065 , 2181 , 2308 , 2535 , 4033 , 4034 , 4035 , 4343 , 4592 , 5936 , 8020 , 8482 y 8767 .
1 2 P. Hoffman; A. Sullivan; K. Fujiwara (diciembre de 2015). Terminología DNS . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7719 . ISSN 2070-1721 . RFC 7719 . Obsoleto. Obsoleto según RFC 8499 .
↑ Lindsay, David (2007). Derecho internacional de los nombres de dominio: ICANN y la UDRP . Bloomsbury Publishing. pág. 8. ISBN 978-1-84113-584-7.
↑ D. Eastlake, 3.º (enero de 2006). Aclaración sobre la insensibilidad a mayúsculas y minúsculas del sistema de nombres de dominio (DNS) . Grupo de trabajo de redes. doi : 10.17487/RFC4343 . RFC 4343 .Estándar propuesto. Actualizado por RFC 5890. Actualiza RFC 1034 , 1035 y 2181 .
1 2 J. Klensin (febrero de 2004). Técnicas de aplicación para la verificación y transformación de nombres . Grupo de trabajo de redes. doi : 10.17487/RFC3696 . RFC 3696 .Informativo.
↑ Lui, Cricket; Albitz, Paul (1993). DNS y BIND . O'Reilly & Associates. pág. 183. ISBN 1-56592-010-4.
↑ Fujiwara, Kazunori; Sullivan, Andrew; Hoffman, Paul (2024). "Terminología DNS" . tools.ietf.org . doi : 10.17487/RFC9499 . Recuperado el 1 de julio de 2024 .
↑ Nemeth, Evi; Snyder, Garth; Hein, Trent R. (30 de octubre de 2006). Manual de administración de Linux . Addison-Wesley Professional. ISBN 978-0-13-700275-7.
^ Bissyande, Tegawendé F.; Sí, Oumarou (9 de octubre de 2017). Infraestructura electrónica y servicios electrónicos para países en desarrollo: Octava Conferencia Internacional, AFRICOMM 2016, Uagadugú, Burkina Faso, 6 y 7 de diciembre de 2016, Actas . Saltador. ISBN 978-3-319-66742-3.
↑ "Zona DNS" . Guía digital de IONOS . 27 de enero de 2022. Consultado el 31 de marzo de 2022 .
↑ "¿Qué es la propagación de DNS?" . IONOS Digitalguide . Consultado el 22 de abril de 2022 .
↑ "¿Los proveedores ignoran el TTL de DNS?" . Slashdot . 2005 . Consultado el 7 de abril de 2012 .
↑ Ben Anderson (7 de septiembre de 2011). "Ben Anderson: Por qué el almacenamiento en caché DNS del navegador web puede ser algo malo" . Consultado el 20 de octubre de 2014 .
↑ "Parámetros del Sistema de Nombres de Dominio (DNS)" . IANA . DNS RCODE . Consultado el 14 de junio de 2019 .
↑ James F. Kurose y Keith W. Ross, Redes informáticas: Un enfoque descendente, 6.ª ed. Essex, Inglaterra: Pearson Educ. Limited, 2012
1 2 D. Eastlake 3rd (abril de 2013). Consideraciones de la IANA sobre el Sistema de Nombres de Dominio (DNS) . Grupo de Trabajo de Ingeniería de Internet . doi : 10.17487/RFC6895 . ISSN 2070-1721 . BCP 42. RFC 6895 . Mejores prácticas actuales 42. Deja obsoleto el RFC 6195. Actualiza los RFC 2845 , 2930 , 1183 y 3597 .
1 2 E. Lewis (julio de 2006). El papel de los comodines en el sistema de nombres de dominio . Grupo de trabajo de redes. doi : 10.17487/RFC4592 . RFC 4592 .Norma propuesta. Actualiza los RFC 2672 y 1034 .
↑ S. Thomson; Y. Rekhter ; J. Bound (abril de 1997). P. Vixie (ed.). Actualizaciones dinámicas en el sistema de nombres de dominio (DNS UPDATE) . Grupo de trabajo de la red IETF . doi : 10.17487/RFC2136 . RFC 2136 .Estándar propuesto. Actualiza RFC 1035. Actualizado por RFC 3007 , 4033 , 4034 y 4035 .
↑ RFC 2671 , Mecanismos de extensión para DNS (EDNS0) , P. Vixie (agosto de 1999)
↑ Csikor, Levente; Divakaran, Dinil Mon (febrero de 2021). "Privacidad de DNS sobre HTTPS: ¿Réquiem por un sueño?" (PDF) . Universidad Nacional de Singapur. Investigamos si el tráfico DoH se puede distinguir del tráfico web cifrado. Para ello, entrenamos un modelo de aprendizaje automático para clasificar el tráfico HTTPS como web o DoH. Con nuestro modelo de identificación DoH implementado, demostramos que un ISP autoritario puede identificar correctamente ≈97,4% de los paquetes DoH, mientras que solo clasifica erróneamente 1 de cada 10 000 paquetes web.
↑ Huitema, Christian; Dickinson, Sara; Mankin, Allison (mayo de 2022). DNS sobre conexiones QUIC dedicadas . Grupo de trabajo de ingeniería de Internet. doi : 10.17487/RFC9250 . RFC 9250 .
↑ Lenders, Martine Sophie; Amsüss, Christian; Gündoğan, Cenk; Schmidt, Thomas C.; Wählisch, Matthias (marzo de 2026). DNS sobre CoAP (DoC) (Informe). Grupo de trabajo de ingeniería de Internet. doi : 10.17487/RFC9953 .
↑ Lenders, Martine S.; Amsüss, Christian; Gündogan, Cenk; Nawrocki, Marcin; Schmidt, Thomas C.; Wählisch, Matthias (2023-09-28). "Asegurando la resolución de nombres en el IoT: DNS sobre CoAP" . Actas de la ACM sobre redes . 1 (CoNEXT2): 1–25 . doi : 10.1145/3609423 . ISSN 2834-5509 .
↑ Schmitt, Paul; Edmundson, Anne; Feamster, Nick (2019). "Oblivious DNS: Privacidad práctica para consultas DNS" ( PDF) . Privacy Enhancing Technologies . 2019 (2): 228–244 . arXiv : 1806.00276 . doi : 10.2478/popets-2019-0028 . S2CID 44126163. Archivado (PDF) del original el 21 de enero de 2022.
↑ "Cloudflare y Apple implementaron DNS de forma opaca" . 9 de diciembre de 2020. Consultado el 27 de julio de 2022 .
↑ Pauly, Tommy (2 de septiembre de 2021). "DNS inconsciente sobre HTTPS" . IETF.
↑ Muffett, Alec (febrero de 2021) ."No hay puerto 53, ¿quién es?" Un año de DNS sobre HTTPS sobre Tor" (PDF) . Simposio de seguridad de redes y sistemas distribuidos. Archivado (PDF) del original el 21/03/2021. DNS sobre HTTPS (DoH) evita muchos, pero no todos, los riesgos, y su protocolo de transporte (es decir, HTTPS) plantea preocupaciones de privacidad debido a (por ejemplo) las "cookies". La red Tor existe para proporcionar a los circuitos TCP cierta libertad de seguimiento, vigilancia y bloqueo. Por lo tanto: En combinación con Tor, DoH y el principio de "No hagas eso, entonces" (DDTT) para mitigar la huella digital de las solicitudes, describo DNS sobre HTTPS sobre Tor (DoHoT).
↑ Ulevitch, David (6 de diciembre de 2011). "DNSCrypt: crítico, fundamental y ya era hora" . Cisco Umbrella . Archivado del original el 1 de julio de 2020.
↑ "Especificación DNSCrypt anonimizada" . GitHub . DNSCrypt. Archivado del original el 25 de octubre de 2019.
↑ "Oblivious DoH · Wiki de DNSCrypt/dnscrypt-proxy" . GitHub . Proyecto DNSCrypt . Consultado el 28 de julio de 2022 .
↑ Herzberg, Amir; Shulman, Haya (2014-01-01). "Retrofitting Security into Network Protocols: The Case of DNSSEC". IEEE Internet Computing . 18 (1): 66– 71. Bibcode : 2014IIC....18a..66H . doi : 10.1109/MIC.2014.14 . ISSN 1089-7801 . S2CID 12230888 .
↑ APWG. "Encuesta global sobre phishing: uso de nombres de dominio y tendencias en el primer semestre de 2010." 15/10/2010 apwg.org Archivado el 03/10/2012 en Wayback Machine
↑ "DNSMessenger (Familia de malware)" . malpedia.caad.fkie.fraunhofer.de . Consultado el 11 de diciembre de 2024 .
↑ Khandelwal, Swati (6 de marzo de 2017). "Nuevo malware sin archivos utiliza consultas DNS para recibir comandos de PowerShell" . The Hacker News . Recuperado el 11 de diciembre de 2024 .
↑ Brumaghin, Edmund (2017-03-02). "Canales encubiertos y malas decisiones: la historia de DNSMessenger" . Blog de Cisco Talos . Recuperado el 11 de diciembre de 2024 .
↑ Bombal, David (26-05-2023). Es DNS otra vez 😢 ¿Sabías de este hack de malware? . Recuperado el 11-12-2024 – vía YouTube.
1 2 Huston, Geoff (julio de 2019). "Privacidad del DNS y la IETF" (PDF) . The Internet Protocol Journal . Archivado (PDF) del original el 30 de septiembre de 2019.
↑ "Perfil operativo del Protocolo de acceso a datos de registro (RDAP) para registros y registradores de gTLD" . ICANN . 3 de diciembre de 2015. Archivado del original el 22 de diciembre de 2015. Consultado el 18 de diciembre de 2015 .
↑ "Buscar un registrador" . VeriSign, Inc. Consultado el 18 de diciembre de 2015 .

Fuentes

Evans, Claire L. (2018). Broad Band: La historia jamás contada de las mujeres que hicieron posible Internet . Nueva York: Portfolio/Penguin. ISBN 9780735211759.

Lecturas adicionales

Vía de estándares

RFC 1034 – " NOMBRES DE DOMINIO - CONCEPTOS Y FACILIDADES " , Estándar de Internet 13.
RFC 1035 – " NOMBRES DE DOMINIO - IMPLEMENTACIÓN Y ESPECIFICACIÓN " , Estándar de Internet 13.
RFC 1123 – " Requisitos para hosts de Internet: aplicación y soporte " , Estándar de Internet 3.
RFC 1995 – " Transferencia de zona incremental en DNS " , Norma propuesta.
RFC 1996 – " Un mecanismo para la notificación inmediata de cambios de zona (DNS NOTIFY) " , Norma propuesta.
RFC 2136 – " Actualizaciones dinámicas en el sistema de nombres de dominio (DNS UPDATE) " , Estándar propuesto.
RFC 2181 – " Aclaraciones a la especificación DNS", " Estándar propuesto.
RFC 2308 – " Almacenamiento en caché negativo de consultas DNS (DNS NCACHE) " , Estándar propuesto.
RFC 3225 – " Indicación de la compatibilidad del resolvedor con DNSSEC " , Estándar propuesto.
RFC 3226 – " Requisitos de tamaño de mensaje de servidor/resolutor compatibles con DNSSEC e IPv6 A6 " , Norma propuesta.
RFC 3596 – " Extensiones DNS para admitir la versión 6 de IP " , Estándar de Internet 88.
RFC 3597 – " Manejo de tipos de registros de recursos DNS (RR) desconocidos " , Estándar propuesto.
RFC 4343 – " Aclaración sobre la insensibilidad a mayúsculas y minúsculas del sistema de nombres de dominio (DNS) " , Norma propuesta.
RFC 4592 – " El papel de los comodines en el sistema de nombres de dominio " , Norma propuesta.
RFC 5001 – " Opción de identificador de servidor de nombres DNS (NSID) " , Estándar propuesto.
RFC 5011 – " Actualizaciones automatizadas de anclas de confianza de seguridad DNS (DNSSEC) " , Estándar de Internet 74.
RFC 5452 – " Medidas para hacer que el DNS sea más resistente a las respuestas falsificadas " , Norma propuesta.
RFC 5890 – " Nombres de dominio internacionalizados para aplicaciones (IDNA): definiciones y marco de documentación " , Norma propuesta.
RFC 5891 – " Nombres de dominio internacionalizados en aplicaciones (IDNA): Protocolo " , Norma propuesta.
RFC 5892 – " Puntos de código Unicode y nombres de dominio internacionalizados para aplicaciones (IDNA) " , Norma propuesta.
RFC 5893 – " Scripts de derecha a izquierda para nombres de dominio internacionalizados para aplicaciones (IDNA) " , Norma propuesta.
RFC 6672 – " Redirección de DNAME en el DNS " , Estándar propuesto.
RFC 6891 – " Mecanismos de extensión para DNS (EDNS(0)), " Estándar de Internet 75.
RFC 7766 – " Transporte DNS sobre TCP - Requisitos de implementación " , Norma propuesta.
RFC 8490 – " Operaciones con estado de DNS " , Estándar propuesto.
RFC 8945 – " Autenticación de transacciones de clave secreta para DNS (TSIG), " Estándar de Internet 93.
RFC 9103 – " Transferencia de zona DNS sobre TLS " , Estándar propuesto.
RFC 9156 – " Minimización del nombre de consulta DNS para mejorar la privacidad " , Norma propuesta.

Normas de seguridad propuestas

RFC 4033 – " Introducción y requisitos de seguridad DNS " , Norma propuesta.
RFC 4034 – " Registros de recursos para las extensiones de seguridad DNS " , Norma propuesta.
RFC 4035 – " Modificaciones del protocolo para las extensiones de seguridad DNS " , Norma propuesta.
RFC 4470 – " Cobertura mínima de registros NSEC y firma en línea DNSSEC " , Norma propuesta.
RFC 4509 – " Uso de SHA-256 en los registros de recursos (RR) del firmante de delegación (DS) de DNSSEC " , Estándar propuesto.
RFC 5155 – " Seguridad DNS (DNSSEC) Denegación de existencia autenticada mediante hash " , Estándar propuesto.
RFC 5702 – " Uso de algoritmos SHA-2 con RSA en registros de recursos DNSKEY y RRSIG para DNSSEC " , Norma propuesta.
RFC 5910 – " Mapeo de extensiones de seguridad del sistema de nombres de dominio (DNS) para el protocolo de aprovisionamiento extensible (EPP) " , Estándar propuesto.
RFC 5933 – « Uso de algoritmos de firma GOST en registros de recursos DNSKEY y RRSIG para DNSSEC » . Histórico. Su estado cambió a histórico en 2024 mediante la RFC 9558. Actualizado por la RFC 6944. (Véase en RFC informativas) .
RFC 7830 – " La opción de relleno EDNS(0) " , estándar propuesto.
RFC 7858 – " Especificación para DNS sobre Transport Layer Security (TLS) " , Estándar propuesto.
RFC 8310 – " Perfiles de uso para DNS sobre TLS y DNS sobre DTLS " , Norma propuesta.
RFC 8484 – " Consultas DNS sobre HTTPS (DoH) " , Estándar propuesto.

RFC experimentales

RFC 1183 – " Nuevas definiciones de DNS RR " , Experimental.

Mejores prácticas actuales

RFC 2182 – " Selección y operación de servidores DNS secundarios", " Mejor práctica actual 16.
RFC 2317 – " Delegación IN-ADDR.ARPA sin clases", " Mejor práctica actual 20.
RFC 5625 – " Directrices para la implementación de proxies DNS", " Mejor práctica actual 152.
RFC 6895 – " Consideraciones de IANA sobre el Sistema de Nombres de Dominio (DNS)", " Mejor práctica actual 42.
RFC 7720 – " Protocolo de servicio de nombres raíz DNS y requisitos de implementación " , Mejor práctica actual 40.
RFC 9499 – " Terminología DNS", " Mejor práctica actual 219.

RFC informativos

Estos RFC son de carácter consultivo, pero pueden proporcionar información útil a pesar de no definir ni un estándar ni un BCP. ^{[ 1 ]}

RFC 1178 – " Elegir un nombre para su computadora " , Informativo, Para su información 5.
RFC 1591 – " Estructura y delegación del sistema de nombres de dominio " , Informativo.
RFC 1912 – " Errores comunes de operación y configuración de DNS " , Informativo.
RFC 2100 – " Nomenclatura de hosts " , Informativo.
RFC 3696 – " Técnicas de aplicación para la verificación y transformación de nombres " , Informativo.
RFC 3833 – " Análisis de amenazas del sistema de nombres de dominio (DNS) " , Informativo.
RFC 4892 – " Autenticación criptográfica RIPv2 " , Informativo.
RFC 5894 – " Nombres de dominio internacionalizados para aplicaciones (IDNA): antecedentes, explicación y fundamentos " , informativo.
RFC 5895 – " Asignación de caracteres para nombres de dominio internacionalizados en aplicaciones (IDNA) 2008 " , Informativo.
RFC 8806 – " Ejecutar un servidor raíz local a un resolvedor " , Informativo.
RFC 9076 – " Consideraciones sobre la privacidad del DNS " , Informativo.
RFC 9558 – " Uso de algoritmos de firma GOST 2012 en registros de recursos DNSKEY y RRSIG para DNSSEC " , Informativo.

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 " , Estado desconocido. – Dominios de nivel superior originales especificados
RFC 1032 – " GUÍA DE ADMINISTRADORES DE DOMINIO " , Estado desconocido.
RFC 1033 – " GUÍA DE OPERACIONES PARA ADMINISTRADORES DE DOMINIO " , Estado desconocido.
RFC 1101 – " Codificación DNS de nombres de red y otros tipos " , Estado desconocido.

Enlaces externos

Vixie, Paul (4 de mayo de 2007). "Complejidad del DNS" . ACM Queue . Archivado del original el 29 de marzo de 2023.
Ball, James (28 de febrero de 2014). «Conozca a las siete personas que tienen las claves de la seguridad mundial en internet» . The Guardian . Guardian News & Media Limited . Consultado el 28 de febrero de 2014 .
Kruger, Lennard G. (18 de noviembre de 2016). "Gobernanza de Internet y el Sistema de Nombres de Dominio: Cuestiones para el Congreso" (PDF) . Servicio de Investigación del Congreso . Recuperado el 27 de julio de 2024 .
Zytrax.com , Guía de código abierto: DNS para científicos aeroespaciales.
Experimenta con DNS : sitio web donde puedes realizar experimentos con DNS.

↑ C. Huitema ; J. Postel ; S. Crocker (abril de 1995). No todos los RFC son estándares . Grupo de trabajo de redes. doi : 10.17487/RFC1796 . RFC 1796 .Informativo.

[:0-1] 1 2 Wu, Hao; Dang, Xianglei; Wang, Lidong; He, Longtao (2016). "Método basado en fusión de información para la detección e identificación de ataques de envenenamiento de caché de sistemas de nombres de dominio distribuidos" . IET Information Security . 10 (1): 37– 44. doi : 10.1049/iet-ifs.2014.0386 . ISSN 1751-8717 . S2CID 45091791 .

[2] Goodwin, Chrystal R. China, Michael (04/11/2025). "¿Qué es DNS (Sistema de nombres de dominio)? | IBM" . www.ibm.com . Consultado el 10/07/2026 .{{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace )

[rfc791-3] J. Postel , ed. ( septiembre de 1981). PROTOCOLO DE INTERNET - ESPECIFICACIÓN DEL PROTOCOLO DEL PROGRAMA DE INTERNET DE DARPA . IETF . doi : 10.17487/RFC0791 . STD 5. RFC 791. IEN 128, 123, 111, 80, 54, 44, 41, 28, 26.Estándar de Internet 5. Sustituye a RFC 760. Actualizado por RFC 1349 , 2474 y 6864 .

[4] J. Dilley, B. Maggs, J. Parikh, H. Prokop, R. Sitaraman y B. Weihl. «Entrega de contenido distribuido globalmente», IEEE Internet Computing, septiembre/octubre de 2002, págs. 50-58 (PDF) . Archivado (PDF) del original el 17 de abril de 2015.

[5] Nygren, E.; Sitaraman RK; Sun, J. (2010). "The Akamai Network: A Platform for High-Performance Internet Applications" ( PDF) . ACM SIGOPS Operating Systems Review . 44 (3): 2– 19. doi : 10.1145/1842733.1842736 . S2CID 207181702. Archivado (PDF) del original el 2 de diciembre de 2010. Recuperado el 19 de noviembre de 2012 .

[rfc1035-6] 1 2 3 4 5 6 7 P. Mockapetris (noviembre de 1987). NOMBRES DE DOMINIO: IMPLEMENTACIÓN Y ESPECIFICACIÓN . Grupo de Trabajo de Redes. doi : 10.17487/RFC1035 . STD 13. RFC 1035 .Estándar de Internet 13. Deja obsoletos los RFC 882 , 883 y 973. Actualizado por los RFC 1101 , 1183 , 1348 , 1876 , 1982 , 1995 , 1996 , 2065 , 2136 , 2137 , 2181 , 2308 , 2535 , 2673 , 2845 , 3425 , 3658 , 4033 , 4034 , 4035 , 4343 , 5936 , 5966 , 6604 , 7766 , 8482 , 8490 y 8767 .

[7] Champika Wijayatunga (febrero de 2015). "Manejo de abuso de DNS" (PDF) . APNIC . Archivado (PDF) desde el original el 22 de diciembre de 2015 . Consultado el 18 de diciembre de 2016 .

[rfc3467-8] J. Klensin (febrero de 2003). Papel del sistema de nombres de dominio (DNS) . Grupo de trabajo de redes. doi : 10.17487/RFC3467 . RFC 3467 .Informativo.

[9] Liu, Cricket; Albitz, Paul (2006). DNS y BIND (5.ª ed.). O'Reilly Media. pág. 3. ISBN 978-0-596-10057-5.

[FOOTNOTEEvans2018112-10] Evans 2018 , pág. 112.

[FOOTNOTEEvans2018113-11] Evans 2018 , pág. 113.

[12] Anales del IEEE [3B2-9] man2011030074.3d 29/7/011 11:54 Página 74

[internethalloffame.org-13] 1 2 "¿Por qué Internet sigue funcionando en Navidad? Paul Mockapetris - Salón de la Fama de Internet" . internethalloffame.org . 23 de julio de 2012.

[FOOTNOTEEvans2018119-14] 1 2 Evans 2018 , pág. 119.

[FOOTNOTEEvans2018120-15] Evans 2018 , pág. 120.

[FOOTNOTEEvans2018120–121-16] Evans 2018 , págs. 120–121.

[17] "Elizabeth Feinler" . Salón de la Fama de Internet . Archivado del original el 14 de septiembre de 2018. Consultado el 25 de noviembre de 2018 .

[18] "Paul Mockapetris | Salón de la Fama de Internet" . internethalloffame.org . Consultado el 12 de febrero de 2020 .

[19] Andrei Robachevsky (26 de noviembre de 2013). "¡Feliz 30.º cumpleaños, DNS!" . Internet Society . Consultado el 18 de diciembre de 2015 .

[20] Elizabeth Feinler, IEEE Annals, 3B2-9 man2011030074.3d 29/7/011 11:54 Página 74

[rfc973-21] P. Mockapetris (febrero de 1986). Cambios y observaciones del sistema de dominios . Grupo de trabajo de redes. doi : 10.17487/RFC0973 . RFC 973 .Obsoleto. Obsoleto según las RFC 1034 y 1035. Actualiza las RFC 882 y 883 .

[Terry_USENIX_2004-22] Terry, Douglas B.; et al. (12–15 de junio de 1984). "El servidor de nombres de dominio de Internet de Berkeley" . Conferencia de verano, Salt Lake City 1984: Actas . USENIX Association Software Tools Users Group. págs. 23–31 .

[BIND_Home_Page-23] Consorcio de Sistemas de Internet. "La historia de BIND" . Historia de BIND. Archivado del original el 30 de junio de 2019. Consultado el 4 de abril de 2022 .

[rfc1034-24] 1 2 3 4 5 6 7 8 P. Mockapetris (noviembre de 1987). NOMBRES DE DOMINIO: CONCEPTOS Y FACILIDADES . Grupo de Trabajo de Redes. doi : 10.17487/RFC1034 . STD 13. RFC 1034 .Estándar de Internet 13. Deja obsoletos los RFC 882 , 883 y 973. Actualizado por los RFC 1101 , 1183 , 1348 , 1876 , 1982 , 2065 , 2181 , 2308 , 2535 , 4033 , 4034 , 4035 , 4343 , 4592 , 5936 , 8020 , 8482 y 8767 .

[rfc7719-25] 1 2 P. Hoffman; A. Sullivan; K. Fujiwara (diciembre de 2015). Terminología DNS . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC7719 . ISSN 2070-1721 . RFC 7719 . Obsoleto. Obsoleto según RFC 8499 .

[26] Lindsay, David (2007). Derecho internacional de los nombres de dominio: ICANN y la UDRP . Bloomsbury Publishing. pág. 8. ISBN 978-1-84113-584-7.

[rfc4343-27] D. Eastlake, 3.º (enero de 2006). Aclaración sobre la insensibilidad a mayúsculas y minúsculas del sistema de nombres de dominio (DNS) . Grupo de trabajo de redes. doi : 10.17487/RFC4343 . RFC 4343 .Estándar propuesto. Actualizado por RFC 5890. Actualiza RFC 1034 , 1035 y 2181 .

[rfc3696-28] 1 2 J. Klensin (febrero de 2004). Técnicas de aplicación para la verificación y transformación de nombres . Grupo de trabajo de redes. doi : 10.17487/RFC3696 . RFC 3696 .Informativo.

[29] Lui, Cricket; Albitz, Paul (1993). DNS y BIND . O'Reilly & Associates. pág. 183. ISBN 1-56592-010-4.

[30] Fujiwara, Kazunori; Sullivan, Andrew; Hoffman, Paul (2024). "Terminología DNS" . tools.ietf.org . doi : 10.17487/RFC9499 . Recuperado el 1 de julio de 2024 .

[31] Nemeth, Evi; Snyder, Garth; Hein, Trent R. (30 de octubre de 2006). Manual de administración de Linux . Addison-Wesley Professional. ISBN 978-0-13-700275-7.

[32] Bissyande, Tegawendé F.; Sí, Oumarou (9 de octubre de 2017). Infraestructura electrónica y servicios electrónicos para países en desarrollo: Octava Conferencia Internacional, AFRICOMM 2016, Uagadugú, Burkina Faso, 6 y 7 de diciembre de 2016, Actas . Saltador. ISBN 978-3-319-66742-3.

[33] "Zona DNS" . Guía digital de IONOS . 27 de enero de 2022. Consultado el 31 de marzo de 2022 .

[34] "¿Qué es la propagación de DNS?" . IONOS Digitalguide . Consultado el 22 de abril de 2022 .

[35] "¿Los proveedores ignoran el TTL de DNS?" . Slashdot . 2005 . Consultado el 7 de abril de 2012 .

[36] Ben Anderson (7 de septiembre de 2011). "Ben Anderson: Por qué el almacenamiento en caché DNS del navegador web puede ser algo malo" . Consultado el 20 de octubre de 2014 .

[37] "Parámetros del Sistema de Nombres de Dominio (DNS)" . IANA . DNS RCODE . Consultado el 14 de junio de 2019 .

[38] James F. Kurose y Keith W. Ross, Redes informáticas: Un enfoque descendente, 6.ª ed. Essex, Inglaterra: Pearson Educ. Limited, 2012

[rfc6895-39] 1 2 D. Eastlake 3rd (abril de 2013). Consideraciones de la IANA sobre el Sistema de Nombres de Dominio (DNS) . Grupo de Trabajo de Ingeniería de Internet . doi : 10.17487/RFC6895 . ISSN 2070-1721 . BCP 42. RFC 6895 . Mejores prácticas actuales 42. Deja obsoleto el RFC 6195. Actualiza los RFC 2845 , 2930 , 1183 y 3597 .

[rfc4592-40] 1 2 E. Lewis (julio de 2006). El papel de los comodines en el sistema de nombres de dominio . Grupo de trabajo de redes. doi : 10.17487/RFC4592 . RFC 4592 .Norma propuesta. Actualiza los RFC 2672 y 1034 .

[rfc2136-41] S. Thomson; Y. Rekhter ; J. Bound (abril de 1997). P. Vixie (ed.). Actualizaciones dinámicas en el sistema de nombres de dominio (DNS UPDATE) . Grupo de trabajo de la red IETF . doi : 10.17487/RFC2136 . RFC 2136 .Estándar propuesto. Actualiza RFC 1035. Actualizado por RFC 3007 , 4033 , 4034 y 4035 .

[42] RFC 2671 , Mecanismos de extensión para DNS (EDNS0) , P. Vixie (agosto de 1999)

[43] Csikor, Levente; Divakaran, Dinil Mon (febrero de 2021). "Privacidad de DNS sobre HTTPS: ¿Réquiem por un sueño?" (PDF) . Universidad Nacional de Singapur. Investigamos si el tráfico DoH se puede distinguir del tráfico web cifrado. Para ello, entrenamos un modelo de aprendizaje automático para clasificar el tráfico HTTPS como web o DoH. Con nuestro modelo de identificación DoH implementado, demostramos que un ISP autoritario puede identificar correctamente ≈97,4% de los paquetes DoH, mientras que solo clasifica erróneamente 1 de cada 10 000 paquetes web.

[44] Huitema, Christian; Dickinson, Sara; Mankin, Allison (mayo de 2022). DNS sobre conexiones QUIC dedicadas . Grupo de trabajo de ingeniería de Internet. doi : 10.17487/RFC9250 . RFC 9250 .

[45] Lenders, Martine Sophie; Amsüss, Christian; Gündoğan, Cenk; Schmidt, Thomas C.; Wählisch, Matthias (marzo de 2026). DNS sobre CoAP (DoC) (Informe). Grupo de trabajo de ingeniería de Internet. doi : 10.17487/RFC9953 .

[46] Lenders, Martine S.; Amsüss, Christian; Gündogan, Cenk; Nawrocki, Marcin; Schmidt, Thomas C.; Wählisch, Matthias (2023-09-28). "Asegurando la resolución de nombres en el IoT: DNS sobre CoAP" . Actas de la ACM sobre redes . 1 (CoNEXT2): 1–25 . doi : 10.1145/3609423 . ISSN 2834-5509 .

[47] Schmitt, Paul; Edmundson, Anne; Feamster, Nick (2019). "Oblivious DNS: Privacidad práctica para consultas DNS" ( PDF) . Privacy Enhancing Technologies . 2019 (2): 228–244 . arXiv : 1806.00276 . doi : 10.2478/popets-2019-0028 . S2CID 44126163. Archivado (PDF) del original el 21 de enero de 2022.

[48] "Cloudflare y Apple implementaron DNS de forma opaca" . 9 de diciembre de 2020. Consultado el 27 de julio de 2022 .

[49] Pauly, Tommy (2 de septiembre de 2021). "DNS inconsciente sobre HTTPS" . IETF.

[50] Muffett, Alec (febrero de 2021) ."No hay puerto 53, ¿quién es?" Un año de DNS sobre HTTPS sobre Tor" (PDF) . Simposio de seguridad de redes y sistemas distribuidos. Archivado (PDF) del original el 21/03/2021. DNS sobre HTTPS (DoH) evita muchos, pero no todos, los riesgos, y su protocolo de transporte (es decir, HTTPS) plantea preocupaciones de privacidad debido a (por ejemplo) las "cookies". La red Tor existe para proporcionar a los circuitos TCP cierta libertad de seguimiento, vigilancia y bloqueo. Por lo tanto: En combinación con Tor, DoH y el principio de "No hagas eso, entonces" (DDTT) para mitigar la huella digital de las solicitudes, describo DNS sobre HTTPS sobre Tor (DoHoT).

[51] Ulevitch, David (6 de diciembre de 2011). "DNSCrypt: crítico, fundamental y ya era hora" . Cisco Umbrella . Archivado del original el 1 de julio de 2020.

[Anonymized_DNSCrypt_specification-52] "Especificación DNSCrypt anonimizada" . GitHub . DNSCrypt. Archivado del original el 25 de octubre de 2019.

[ODoH_(2022)-53] "Oblivious DoH · Wiki de DNSCrypt/dnscrypt-proxy" . GitHub . Proyecto DNSCrypt . Consultado el 28 de julio de 2022 .

[54] Herzberg, Amir; Shulman, Haya (2014-01-01). "Retrofitting Security into Network Protocols: The Case of DNSSEC". IEEE Internet Computing . 18 (1): 66– 71. Bibcode : 2014IIC....18a..66H . doi : 10.1109/MIC.2014.14 . ISSN 1089-7801 . S2CID 12230888 .

[55] APWG. "Encuesta global sobre phishing: uso de nombres de dominio y tendencias en el primer semestre de 2010." 15/10/2010 apwg.org Archivado el 03/10/2012 en Wayback Machine

[56] "DNSMessenger (Familia de malware)" . malpedia.caad.fkie.fraunhofer.de . Consultado el 11 de diciembre de 2024 .

[57] Khandelwal, Swati (6 de marzo de 2017). "Nuevo malware sin archivos utiliza consultas DNS para recibir comandos de PowerShell" . The Hacker News . Recuperado el 11 de diciembre de 2024 .

[58] Brumaghin, Edmund (2017-03-02). "Canales encubiertos y malas decisiones: la historia de DNSMessenger" . Blog de Cisco Talos . Recuperado el 11 de diciembre de 2024 .

[59] Bombal, David (26-05-2023). Es DNS otra vez 😢 ¿Sabías de este hack de malware? . Recuperado el 11-12-2024 – vía YouTube.

[Huston-2019-60] 1 2 Huston, Geoff (julio de 2019). "Privacidad del DNS y la IETF" (PDF) . The Internet Protocol Journal . Archivado (PDF) del original el 30 de septiembre de 2019.

[61] "Perfil operativo del Protocolo de acceso a datos de registro (RDAP) para registros y registradores de gTLD" . ICANN . 3 de diciembre de 2015. Archivado del original el 22 de diciembre de 2015. Consultado el 18 de diciembre de 2015 .

[62] "Buscar un registrador" . VeriSign, Inc. Consultado el 18 de diciembre de 2015 .

[rfc1796-63] C. Huitema ; J. Postel ; S. Crocker (abril de 1995). No todos los RFC son estándares . Grupo de trabajo de redes. doi : 10.17487/RFC1796 . RFC 1796 .Informativo.

[ 2 ]

[

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]

[ 11 ]

[ 12 ]

[ 13 ]

[ 14 ]

[ 15 ]

[ 16 ]

[ 17 ]

[ 18 ]

[ 19 ]

[ 20 ]

[ 21 ]

[ 22 ]

[ 23 ]

[ 24 ]

[ 25 ]

[ 26 ]

[ 27 ]

[ 28 ]

[ 29 ]

[ 30 ]

[ 31 ]

[ 32 ]

[ 33 ]

[ 34 ]

[ 35 ]

[ 36 ]

[ 37 ]

[ 38 ]

[ 39 ]

[ 40 ]

[ 41 ]

[ 42 ]

[ 43 ]

[ 44 ]

[ 45 ]

[ 46 ]

[ 47 ]

[ 48 ]

[ 49 ]

[ 50 ]

[ 51 ]

[ 52 ]

[ 53 ]

[ 54 ]

[

[ 56 ]

[ 57 ]

[ 58 ]

[ 59 ]

[ 60 ]

[ 61 ]

[ 62 ]

[ 1 ]