Hispanopedia Wiki
Articulo de referencia

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

Hispanopedia WikiContenido en espanolLectura gratuita

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 . [ 1 ] 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 . [ 3 ] 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

El sistema de nombres de dominio jerárquico para la clase Internet , organizado en zonas, cada una atendida por un servidor de nombres.

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. [ 6 ] 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. [ 6 ]

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

Un resolvedor DNS que implementa el enfoque iterativo exigido por la RFC 1034; en este caso, el resolvedor consulta tres servidores de nombres para resolver el nombre de dominio completamente calificado "www.wikipedia.org".

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.

Assuming the resolver has no cached records to accelerate the process, the resolution process starts with a query to one of the root servers. In typical operation, the root servers do not answer directly, but respond with a referral to more authoritative servers, e.g., a query for "www.wikipedia.org" is referred to the org servers. The resolver now queries the servers referred to, and iteratively repeats this process until it receives an authoritative answer. The diagram illustrates this process for the host that is named by the fully qualified domain name "www.wikipedia.org".

This mechanism would place a large traffic burden on the root servers, if every resolution on the Internet required starting at the root. In practice caching is used in DNS servers to off-load the root servers, and as a result, root name servers actually are involved in only a relatively small fraction of all requests.

Recursive and caching name server

In theory, authoritative name servers are sufficient for the operation of the Internet. However, with only authoritative name servers operating, every DNS query must start with recursive queries at the root zone of the Domain Name System and each user system would have to implement resolver software capable of recursive operation.[33]

To improve efficiency, reduce DNS traffic across the Internet, and increase performance in end-user applications, the Domain Name System supports DNS cache servers which store DNS query results for a period of time determined in the configuration (time-to-live) of the domain name record in question. Typically, such caching DNS servers also implement the recursive algorithm necessary to resolve a given name starting with the DNS root through to the authoritative name servers of the queried domain. With this function implemented in the name server, user applications gain efficiency in design and operation.

The combination of DNS caching and recursive functions in a name server is not mandatory; the functions can be implemented independently in servers for special purposes.

Internet service providers (ISP) typically provide recursive and caching name servers for their customers. In addition, many home networking routers implement DNS caches and recursion to improve efficiency in the local network.

DNS resolvers

The client side of the DNS is called a DNS resolver. A resolver is responsible for initiating and sequencing the queries that ultimately lead to a full resolution (translation) of the resource sought, e.g., translation of a domain name into an IP address. DNS resolvers are classified by a variety of query methods, such as recursive, non-recursive, and iterative. A resolution process may use a combination of these methods.[24]

In a non-recursive query, a DNS resolver queries a DNS server that provides a record either for which the server is authoritative, or it provides a partial result without querying other servers. In case of a caching DNS resolver, the non-recursive query of its local DNS cache delivers a result and reduces the load on upstream DNS servers by caching DNS resource records for a period of time after an initial response from upstream DNS servers.

In a recursive query, a DNS resolver queries a single DNS server, which may in turn query other DNS servers on behalf of the requester. For example, a simple stub resolver running on a home router typically makes a recursive query to the DNS server run by the user's ISP. A recursive query is one for which the DNS server answers the query completely by querying other name servers as needed. In typical operation, a client issues a recursive query to a caching recursive DNS server, which subsequently issues non-recursive queries to determine the answer and send a single answer back to the client. The resolver, or another DNS server acting recursively on behalf of the resolver, negotiates use of recursive service using bits in the query headers. DNS servers are not required to support recursive queries.

The iterative query procedure is a process in which a DNS resolver queries a chain of one or more DNS servers. Each server refers the client to the next server in the chain, until the current server can fully resolve the request. For example, a possible resolution of www.example.com would query a global root server, then a "com" server, and finally an "example.com" server.

Circular dependencies and glue records

Name servers in delegations are identified by name, rather than by IP address. This means that a resolving name server must issue another DNS request to discover the IP address of the server to which it has been referred. If the name given in the delegation is a subdomain of the domain for which the delegation is being provided, there is a circular dependency.

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 establece las reglas básicas para determinar los valores TTL adecuados.

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

secuencia de resolución DNS

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 ]

Internet Explorer constituye una excepción notable: las versiones hasta IE 3.x almacenan en caché los registros DNS durante 24 horas de forma predeterminada. Internet Explorer 4.x y versiones posteriores (hasta IE 8) reducen el valor de tiempo de espera predeterminado a media hora, que puede modificarse cambiando la configuración predeterminada. [ 37 ]

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
En una respuesta, la opción "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. [ 38 ]
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. [ 39 ]

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: [ 40 ] : §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). [ 40 ] : 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 ] [ 41 ] 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. [ 41 ]  

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. [ 42 ] 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. [ 43 ] 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. [ 44 ]

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 DNS sobre UDP clásico". Este método no es lo mismo que DNS sobre HTTP/3 . [ 45 ]

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. [ 46 ] DoC supera a otros mecanismos de resolución DNS en escenarios con recursos limitados. [ 47 ]

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, [ 48 ] 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). [ 49 ] 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. [ 50 ]

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. [ 51 ]

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 . [ 52 ] 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. [ 53 ] 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. [ 54 ] 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.

DNS responses traditionally do not have a cryptographic signature, leading to many attack possibilities; the Domain Name System Security Extensions (DNSSEC) modify DNS to add support for cryptographically signed responses.[55]DNSCurve has been proposed as an alternative to DNSSEC. Other extensions, such as TSIG, add support for cryptographic authentication between trusted peers and are commonly used to authorize zone transfer or dynamic update operations.

Techniques such as forward-confirmed reverse DNS can also be used to help validate DNS results.

DNS can also "leak" from otherwise secure or private connections, if attention is not paid to their configuration, and at times DNS has been used to bypass firewalls by malicious persons, and exfiltrate data, since it is often seen as innocuous.

DNS spoofing

Some domain names may be used to achieve spoofing effects. For example, paypal.com and paypa1.com are different names, yet users may be unable to distinguish them in a graphical user interface depending on the user's chosen typeface. In many fonts the letter l and the numeral 1 look very similar or even identical. This problem, known as the IDN homograph attack, is acute in systems that support internationalized domain names, as many character codes in ISO 10646 may appear identical on typical computer screens. This vulnerability is occasionally exploited in phishing.[56]

DNSMessenger

DNSMessenger[57][58][59][60] is a type of cyber attack technique that uses the DNS to communicate and control malware remotely without relying on conventional protocols that might raise red flags. The DNSMessenger attack is covert because DNS is primarily used for domain name resolution and is often not closely monitored by network security tools, making it an effective channel for attackers to exploit.

This technique involves the use of DNS TXT records to send commands to infected systems. Once malware has been surreptitiously installed on a victim's machine, it reaches out to a controlled domain to retrieve commands encoded in DNS text records. This form of malware communication is stealthy, as DNS requests are usually allowed through firewalls, and because DNS traffic is often seen as benign, these communications can bypass many network security defenses.

DNSMessenger attacks can enable a wide array of malicious activities, from data exfiltration to the delivery of additional payloads, all while remaining under the radar of traditional network security measures. Understanding and defending against such methods are crucial for maintaining robust cybersecurity.

Privacy and tracking issues

Originally designed as a public, hierarchical, distributed and heavily cached database, the DNS protocol has no confidentiality controls. User queries and nameserver responses are sent unencrypted, enabling network packet sniffing, DNS hijacking, DNS cache poisoning and man-in-the-middle attacks. This deficiency is commonly used by cybercriminals and network operators for marketing purposes, user authentication on captive portals and censorship.[61]

User privacy is further exposed by proposals for increasing the level of client IP information in DNS queries (RFC 7871) for the benefit of content delivery networks.

The main approaches that are in use to counter privacy issues with DNS include:

  • VPNs, which move DNS resolution to the VPN operator and hide user traffic from the local ISP.
  • Tor, which replaces traditional DNS resolution with anonymous .onion domains, hiding both name resolution and user traffic behind onion routing counter-surveillance.
  • Proxies and public DNS servers, which move the actual DNS resolution to a trusted third-party provider.

Solutions preventing DNS inspection by the local network operator have been criticized for thwarting corporate network security policies and Internet censorship. Public DNS servers are also criticized for contributing to the centralization of the Internet by placing control over DNS resolution in the hands of the few large companies which can afford to run public resolvers.[61]

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 . Desde 2015, se está considerando el uso de RDAP . [ 62 ]

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. [ 63 ] 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.

Véase también

Referencias

  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 )
  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 . 
  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 .
  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.
  10. ↑ Evans 2018 , pág. 112.
  11. ↑ Evans 2018 , pág. 113.
  12. ↑ Anales del IEEE [3B2-9] man2011030074.3d 29/7/011 11:54 Página 74
  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.
  14. 1 2 Evans 2018 , pág. 119.
  15. ↑ Evans 2018 , pág. 120.
  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
  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 .  
  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 .  
  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 .
  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 .  
  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.
  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 .  
  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.; Sie, Oumarou (2017-10-09). e-Infrastructure and e-Services for Developing Countries: 8th International Conference, AFRICOMM 2016, Ouagadougou, Burkina Faso, December 6-7, 2016, Proceedings. Springer. ISBN 978-3-319-66742-3.
  33. ↑"DNS zone". IONOS Digitalguide. 27 January 2022. Retrieved 2022-03-31.
  34. ↑"What is DNS propagation?". IONOS Digitalguide. Retrieved 2022-04-22.
  35. ↑"Providers ignoring DNS TTL?". Slashdot. 2005. Retrieved 2012-04-07.
  36. ↑Ben Anderson (7 September 2011). "Ben Anderson: Why Web Browser DNS Caching Can Be A Bad Thing". Retrieved 20 October 2014.
  37. ↑"How Internet Explorer uses the cache for DNS host entries". Microsoft Corporation. 2004. Archived from the original on 2015-04-09. Retrieved 2010-07-25.
  38. ↑"Domain Name System (DNS) Parameters". IANA. DNS RCODEs. Retrieved 14 June 2019.
  39. ↑James F. Kurose and Keith W. Ross, Computer Networking: A Top-Down Approach, 6th ed. Essex, England: Pearson Educ. Limited, 2012
  40. 12D. Eastlake 3rd (April 2013). Domain Name System (DNS) IANA Considerations. Internet Engineering Task Force. doi:10.17487/RFC6895. ISSN 2070-1721. BCP 42.RFC6895.Best Current Practice 42. Obsoletes RFC 6195. Updates RFC 2845, 2930, 1183 and 3597.
  41. 12E. Lewis (July 2006). The Role of Wildcards in the Domain Name System. Network Working Group. doi:10.17487/RFC4592. RFC4592.Proposed Standard. Updates RFC 2672 and 1034.
  42. ↑S. Thomson; Y. Rekhter; J. Bound (April 1997). P. Vixie (ed.). Dynamic Updates in the Domain Name System (DNS UPDATE). IETF Network Working Group. doi:10.17487/RFC2136. RFC2136.Estándar propuesto. Actualiza RFC 1035. Actualizado por RFC 3007 , 4033 , 4034 y 4035 .  
  43. ↑ RFC 2671 , Mecanismos de extensión para DNS (EDNS0) , P. Vixie (agosto de 1999) 
  44. ↑ 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.
  45. ↑ 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 .
  46. ↑ 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 .
  47. ↑ 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 . 
  48. ↑ 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. 
  49. ↑ "Cloudflare y Apple implementaron DNS de forma oblicua" . 9 de diciembre de 2020. Consultado el 27 de julio de 2022 .
  50. ↑ Pauly, Tommy (2 de septiembre de 2021). "DNS Oblivious Over HTTPS" . IETF.
  51. ↑ 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).
  52. ↑ 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.
  53. ↑ "Especificación DNSCrypt anonimizada" . GitHub . DNSCrypt. Archivado del original el 25 de octubre de 2019.
  54. ↑ "Oblivious DoH · Wiki de DNSCrypt/dnscrypt-proxy" . GitHub . Proyecto DNSCrypt . Consultado el 28 de julio de 2022 .
  55. ↑ 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 .  
  56. ↑ 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
  57. ↑ "DNSMessenger (Familia de malware)" . malpedia.caad.fkie.fraunhofer.de . Consultado el 11 de diciembre de 2024 .
  58. ↑ 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 .
  59. ↑ 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 .
  60. ↑ Bombal, David (26-05-2023). Es DNS otra vez 😢 ¿Sabías de este hack de malware? . Recuperado el 11-12-2024 – vía YouTube.
  61. 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.
  62. ↑ "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 .
  63. ↑ "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. 
  • 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.
  1. ↑ 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.