Fundamentos del Sistema de Nombres de Dominio (DNS) y su Funcionamiento

Servicio de Nombres de Dominio (DNS)

El Sistema de Nombres de Dominio (DNS) es un servicio fundamental en internet. A continuación, se detallan sus características principales y cómo opera.

Comunicación por TCP o UDP

El DNS utiliza ambos protocolos para sus operaciones, principalmente el puerto 53.

El DNS es una base de datos distribuida que funciona con un protocolo cliente/servidor. Permite:

1. Mapear nombres ↔ direcciones IP.
2. Obtener información para el envío de correo electrónico.
3. Obtener información sobre servicios.

⚠️ Es importante destacar que ningún servidor conoce toda la información, de ahí que sea distribuido. Cada "sitio" mantiene su propia base de datos.

• El DNS proporciona el protocolo que permite a los clientes hacer consultas a los servidores y obtener respuestas.
  • El protocolo DNS también permite que los servidores intercambien información.
• Desde el punto de vista de una aplicación, el acceso al DNS se realiza a través de una librería llamada resolver.
• BIND es el software más utilizado para la implementación de DNS en la mayoría de los sistemas. Incluye:
  • Un servidor multipropósito llamado named.
  • Una librería de cliente llamada resolver.
  • El resolver incluye una API de consulta de las aplicaciones a los servidores de DNS.
  • El named implementa las funcionalidades de resolución.
  • BIND también incluye una herramienta para hacer consultas llamada dig (domain information groper).

El Espacio de Nombres DNS

Es el conjunto total de nombres gestionados con DNS.

Características del Espacio de Nombres DNS

📌 Sus características principales son:

1. No distingue mayúsculas/minúsculas.
2. Es una estructura jerárquica en forma de árbol de dominios:
   • Parte superior: Raíz (representada como .).
   • Siguiente nivel: TLD (Top Level Domain)
     • TLD de códigos por país: uk, eu, su, etc.
     • TLD genéricos (mín. 3 letras): edu, gov, com, org, net, etc.

Sintaxis de Nombres DNS

• Cada TLD se divide en subdominios, y estos se pueden dividir en más subdominios y así sucesivamente.
• Un nombre de dominio completo, como www.uc3m.es, se denomina FQDN (Fully Qualified Domain Name).

Restricciones de Nombres DNS

• Cada etiqueta debe tener ≤ 63 caracteres.
• El FQDN completo debe tener ≤ 255 caracteres.

Ventajas de la Jerarquía DNS

• La jerarquía permite que diferentes autoridades gestionen distintas partes del espacio de nombres.
• Este diseño es clave para la escalabilidad, ya que no hay una sola entidad centralizada.

Servidores de Nombres y Zonas DNS

• Cuando se asigna la responsabilidad de administrar uno (o más) dominios a una organización, esta debe mantener dos o más servidores de nombres (servidores DNS) que contengan información sobre ese espacio de nombres.
  • Los usuarios de Internet pueden realizar consultas sobre ese espacio de nombres a esos servidores.

Concepto de Zona DNS

• Un subárbol del espacio DNS, con administración independiente.
• Cada TLD pertenece a la zona raíz.

Delegación de Zonas

📌 Es la posibilidad de ceder la gestión de un subdominio a otra entidad.

Tipos de Servidores Autorizados

📡 Debe haber al menos 2 por zona:

• Servidores raíz:
  • Es el servidor autorizado del nivel raíz.
  • Todos los servidores de nombres de Internet conocen las IP de los servidores raíz.
• Servidores de nombres de los dominios de primer nivel (TLD):
  • Los dominios gTLD y ccTLD los administra la ICANN.
  • Determinan en qué autoridad delega cada dominio, y anotan en los servidores raíz los servidores autoritativos de cada TLD.
    • Ejemplo: .es es gestionado por RedIRIS, actualmente en la sede del Palacio Empresarial Ireds (https://www.dominios.es), dependiente de España.
  • Los servidores raíz almacenan en sus registros la IP de los servidores de nombres autoritativos para el dominio .es.
  • Los gTLDs de más tráfico, como COM y NET, usan los mismos servidores autoritativos, apuntados a gtd-servers.net, a m.gtd-servers.net.
    • Son administrados por Verisign.
• Dominios de segundo nivel:
  • Son los subdominios de los dominios TLD (de primer nivel).
  • Para delegar un dominio de segundo nivel, el titular de un dominio superior debe añadir un registro de delegación en su zona.
    • Ejemplo: delegar en una empresa de .es la autoridad para uc3m.es.
  • Para cada dominio de segundo nivel, el TLD anota las direcciones de los servidores que son responsables de la resolución de nombres DNS en el dominio.
  • Este proceso puede seguirse con dominios de tercer, cuarto, etc., nivel.
• Delegación:
  • Cuando se delega un subdominio, no es obligatorio delegarlo en otra autoridad.
  • Cuando se delega en otra autoridad, esta tiene que mantener los servidores autoritativos de la zona. Para ello puede:
    • Mantenerlos directamente.
    • Subcontratarlos a un tercero. Esto se llama DNS gestionado:
      • Ejemplo: servicios de Amazon Web Services (AWS), Akamai, CloudFlare, etc.

Almacenamiento en Caché (DNS Cache)

¿De dónde obtiene información un servidor DNS?

1. Desde la base de datos de la zona
   → Si es servidor primario.
2. Mediante transferencia de zona
   → Si es servidor secundario.
3. Desde otros servidores
   → Por resoluciones anteriores (mediante caché).

Mecanismo de Caché DNS

• La mayoría de servidores almacenan información aprendida de consultas anteriores.
• Cada entrada se guarda con un TTL (Time To Live) determinado por el servidor que responde.
• Cuando responden, indican si la información es:
  • Autorizada (respuesta oficial de la zona).
  • De caché (respuesta recordada de antes).

• Servidor de nombres local:
  • Es el servidor de nombres que los clientes de una organización utilizarán para iniciar el proceso de resolución de nombres.
  • Un ISP, por ejemplo, pondrá a disposición un servidor de nombres DNS local para sus clientes.
    • Este servidor de nombres almacena en caché los resultados anteriores para obtener respuestas rápidas y reenvía las solicitudes a otros servidores.
  • Se configura manualmente o por DHCP (más habitual hoy en día).
  • El servidor de nombres local puede ser un servidor autorizado para algún dominio, o un servidor solo de caché.
• Servidores DNS públicos:
  • En los últimos años han proliferado los servidores de nombres públicos (también denominados servidor público de resolución de DNS o DNS público recursivo).
  • Son servidores DNS gratuitos, no operados por nuestro proveedor de Internet.
  • Razones para usar estos servicios:
    • Velocidad, en comparación con el uso de servicios DNS provistos por el ISP.
    • Filtrado (seguridad, bloqueo de anuncios, bloqueo de pornografía, etc.).
    • Evitar la censura.
    • Redundancia.
    • Acceso a dominios de nivel superior alternativos no oficiales que no se encuentran en la zona raíz del DNS oficial.

Críticas a los Servidores DNS Públicos

• Recopilación masiva de datos (nada es gratis).
• Redirección poco eficiente en CDNs. La extensión EDNS Client Subnet (ECS) puede generar problemas de privacidad.

El Protocolo DNS

• Basado en un sistema consulta ↔ respuesta.
• Dos modos de consulta:
  • Recursiva.
  • Iterativa.

Otras Funcionalidades del Protocolo DNS

✉️ El protocolo DNS incluye otras funcionalidades importantes:

• DNS NOTIFY
  → Para avisar a los servidores secundarios de que hubo un cambio en la zona.
• DNS UPDATE
  → Para actualizar dinámicamente la información de una zona.

Tipos de Consulta DNS

Resumen del Funcionamiento DNS

• El resolver consulta a un servidor de nombres local.
• ¿El dominio consultado cae bajo su jurisdicción (es un servidor autorizado para ese dominio)?
  • Sí: devuelve registros del recurso.
    • Respuesta autorizada.
  • No: ¿Lo tiene en la caché?
    • Sí: devuelve registros del recurso.
      • Respuesta no autorizada.
    • No: dos posibilidades.

1. Consulta recursiva (es lo habitual):
   • Envía mensaje de consulta a otro servidor (que puede a su vez preguntar a otro servidor, etc.).
   • Devuelve la respuesta obtenida.
   • Guarda copia en caché durante el "tiempo de vida" del registro.
2. Consulta iterativa:
   • Nos devuelve la dirección de los siguientes servidores a contactar.

Tipos de Registros de Recursos DNS (RR)

Un registro de recurso es una tupla de cinco valores:

1. <nombre de dominio> <ttl> <clase> <tipo> <valor>

• Nombre de dominio: Es el nombre del objeto referenciado por el RR. Puede ser un nombre de estación o un nombre de dominio. Si se omite este campo, el registro aplica al último nombre usado.
• TTL: Es el tiempo de vida del registro (en segundos). Define la cantidad de segundos que la información sobre ese registro puede mantenerse en un servidor de caché.
• Clase: Define el espacio de nombres (en la práctica, solo se usa IN para Internet). Existen otras clases de registros, pero no se usan comúnmente.
• Tipo: Identifica el tipo de RR de acuerdo a la tabla siguiente.
• Valor: Es la información específica al tipo de RR.

Ejemplos de Consultas DNS con dig

A continuación, se muestran ejemplos de consultas DNS utilizando la herramienta dig.

Consultas Iterativas

Para realizar consultas iterativas, se puede usar:

dig @localhost +norecurse -t A www.lahora.com.ec (y luego seguir preguntando a los NS en vez de a localhost)

dig +trace www.lahora.com.ec

Nota: Al preguntar directamente a un servidor primario, este devuelve la información en la sección autorizada y con el flag AA (Autoritative Answer) activado.

Registro AXFR (Transferencia de Zona Completa)

Permite obtener todos los registros de recurso de una zona.

dig @<servidor_autorizado> lab.it.uc3m.es AXFR

Donde <servidor_autorizado> debe ser el nombre o la dirección IP del servidor de nombres autorizado para la zona lab.it.uc3m.es. Este servidor debe permitir las transferencias de zona para que el comando funcione.

Registro MX (Mail Exchanger)

Consulta los servidores de correo para un dominio.

dig -t MX uc3m.es

Registro SOA (Start of Authority)

Indica el servidor primario de la zona y el correo electrónico del administrador (donde el "." en el correo se reemplaza por "@").

dig -t SOA uc3m.es

Registro PTR (Pointer)

Es un puntero para consultas inversas que permite saber qué máquina tiene determinada IP. Realiza una consulta inversa para obtener el nombre de dominio a partir de una IP.

dig -t PTR 115.139.117.163.in-addr.arpa

Registro NS (Name Server)

Consulta los servidores de nombres autorizados para un dominio/zona. Es útil para identificar el servidor primario (SOA).

dig -t NS it.uc3m.es

Registro CNAME (Canonical Name)

Consulta el alias de un dominio. Se usa cuando un nombre no tiene directamente un registro A, sino que apunta a otro dominio.

dig -t CNAME www.it.uc3m.es

Registro AAAA (IPv6 Address)

Consulta la dirección IPv6 de un dominio.

dig -t AAAA www.uc3m.es

Registro A (IPv4 Address)

Consulta la dirección IPv4 de un host. Si aparecen varias direcciones, indica que el dominio tiene balance de carga.

dig -t A www.uc3m.es

Formato del Mensaje DNS

Indicadores (Flags) del Mensaje DNS

Campo ID (Identificador)

El campo ID se usa para identificar una consulta específica. Permite al cliente (por ejemplo, dig) reconocer qué respuesta corresponde a qué consulta, especialmente cuando hay múltiples consultas simultáneas. Por ejemplo, id: 35947 identifica esta consulta concreta.

• QR (1 bit): Indica si el mensaje es una consulta o una respuesta.
  • 0 = consulta
  • 1 = respuesta
• OpCode (4 bits): Código de operación del mensaje.
  • 0 = consulta estándar
  • 4 = notificación
  • 5 = actualización
  • Valores 1-3 están obsoletos.
• AA (1 bit): Respuesta autorizada.
  • 1 = la respuesta proviene de un servidor autorizado.
  • 0 = la respuesta es de caché o no autorizada.
• TC (1 bit): Mensaje truncado.
  • Indica que el mensaje excede los 512 bytes en UDP, y se trunca.
• RD (1 bit): Recursividad deseada.
• RA (1 bit): Recursividad disponible. Si está ausente, no disponible.
  • Se establece en una respuesta si el servidor soporta consultas recursivas.
• Z (1 bit): Reservado para uso futuro, debe ser 0.
• AD (1 bit): Autenticación de datos.
  • 1 = los datos de la respuesta están autenticados.
• CD (1 bit): Deshabilitar comprobación.
  • 1 = la verificación de seguridad está deshabilitada.
• RCODE (4 bits): Código de respuesta.
  • 0 = sin errores
  • 3 = error de nombre (dominio no existe, NXDOMAIN)
  • Otros valores indican distintos tipos de error.

Query Time

Indica el tiempo que tomó la consulta.

Tiempo de Vida (TTL) y Caché Local

El TTL (Time to Live) es el tiempo en segundos que el registro de recurso permanecerá almacenado en caché en el servidor DNS local. Para saber el TTL, hay que preguntar al servidor autorizado o hacer una primera consulta al localhost; luego irá disminuyendo.

• Observamos que el valor del TTL disminuye con cada consulta (de 3589 a 3582 en este caso). Esto significa que el servidor DNS local está almacenando en caché la respuesta durante el tiempo especificado por el TTL y que este valor disminuye a medida que el tiempo transcurre.
• Cuando el TTL llegue a 0, el servidor DNS local tendrá que realizar una nueva consulta para obtener la IP actualizada del dominio www.lasnoticiasdecuenca.es.

• El encabezado va seguido de cuatro secciones de longitud variable, conteniendo cero, uno o más registros de recursos (RR):
  • Preguntas (sección de consulta).
    • Nombre que se quiere resolver.
    • Tipo de registro que se busca.
  • Respuestas.
    • Respuestas correspondientes a la consulta.
  • Autoridad.
    • Información sobre los servidores autoritativos de la zona.
  • Información adicional.
    • Registros no solicitados (prefetching).
    • Responden a consultas que no habían sido pedidas.

• 

Envío de Consultas DNS: TCP vs. UDP

• DNS tiene reservado el puerto 53 tanto de TCP como UDP.
• Las consultas se envían en principio por UDP:
  • Si no hay respuesta, se implementa un temporizador de 4 segundos tras el cual se retransmite el mismo ID de consulta.
  • El tamaño máximo del mensaje en UDP es 512 bytes.
  • Si la respuesta excede este tamaño, se usa TCP (bit TC = 1).
  • Esto es relevante especialmente para registros grandes o respuestas con muchos registros.
  • En el caso de DNSSEC, debido al tamaño de las respuestas, se prefiere TCP.
• Recuerda:
  • En la práctica, las consultas DNS sobre UDP son más rápidas.
• Cuando un servidor secundario tiene que hacer una transferencia de zonas:
  • Puede hacerla por UDP si es incremental (IXFR).
  • Si es completa (AXFR) puede suponer muchos bytes, se hace por TCP.
• Esto sucede también cuando debe hacer una transferencia de zonas:
  • Cuando tras el tiempo de actualización indicado en el SOA, vuelve a solicitar el registro SOA del primario y observa que el número de serie se ha aumentado.
  • Entonces recibe un mensaje DNS NOTIFY del primario.

DNSSEC (Extensiones de Seguridad DNS)

• Inicialmente definido sin tener en cuenta la seguridad:
  • RFC 2535 propuso DNS-SEC en 1999.
  • RFC 4033-4035 lo actualizan en 2005.
• Se basa en criptografía de clave pública:
  • Cada zona tiene una clave pública y otra privada.
  • Los datos DNS se firman digitalmente:
    • RRSIG: Firma digital.
    • DNSKEY: Clave pública.
• Asegura:
  • Protección de datos: autenticidad y validez.
  • Protección contra inyecciones: evita datos falsos.
• DNSSEC no protege contra la denegación de servicio ni protege el tráfico DNS.
• Requiere compatibilidad entre servidores DNS y protocolos actualizados.
• Componentes:
  • Se añaden nuevos tipos de RR (RRSIG, DNSKEY, NSEC, etc.).
  • Cada entrada DNS está firmada.

Dynamic DNS (DDNS)

• Extensión de DNS para permitir que se puedan añadir, borrar o actualizar entradas:
  • Versión no segura: RFC 2136.
  • Versión segura: RFC 3007.
    • Añade el tipo de petición UPDATE.
    • Valor 5 en los 14 tipos de parámetros.
  • Además de la información de actualización, se pueden añadir prerrequisitos que verifica el servidor antes de realizar la actualización:
    • Si los RR ya existían o existían previamente.
    • Si el nombre estaba en uso.

El Formato de Extensión DNS (EDNS0)

• El formato de mensaje DNS básico tiene varias restricciones:
  • Tiene campos de longitud fija.
  • La principal es la limitación a 512 bytes cuando se usa con UDP (incluidos encabezados UDP e IP).
  • Espacio limitado para indicar tipos de error (el RCODE de 4 bits).
• Un mecanismo de extensión llamado EDNS0 se especifica en RFC2671:
  • Se utiliza para expandir la seguridad del DNS (DNSSEC, por ejemplo) y en casos de uso más generalizados.
  • Especifica un tipo de pseudo-RR (OPT) que se puede añadir a la sección adicional de una solicitud o respuesta para indicar el uso de EDNS0.
  • Cuando EDNS0 se usa, estos registros pueden estar presentes en una consulta o respuesta.
  • Permite exceder los 512 bytes y contener un conjunto ampliado de códigos de error.
• Ejemplos EDNS0:

DNS over TLS (DoT)

• RFC 7858.
• Protocolo para enviar las consultas/respuestas DNS sobre TLS.
  • Para aumentar la privacidad (escuchas) y la seguridad (manipulación de la respuesta).
• Puerto 853.
• También hay una versión sobre DTLS, pero menos usada en la práctica (RFC 8094).
• Desde 2019, varios servicios públicos de resolución de DNS (Cloudflare, Quad9, Google, Quadrant Information Security y CleanBrowsing) ofrecen soporte DoT.
• Críticas:
  • Dificulta el control parental (aunque algunos DNS públicos lo ofrecen).
  • Los servidores autorizados (habitualmente) no soportan DoT, con lo que únicamente se cifra salto a salto.
  • Algunos proveedores filtran este tráfico.

DNS over HTTPS (DoH)

• RFC 8454.
• Protocolo para enviar las consultas/respuestas DNS sobre HTTPS.
  • Puede usar HTTPS (1.1) o HTTP/2.
  • Envía los mensajes DNS en la carga útil de un mensaje HTTPS con el tipo MIME application/dns-message.
• Todavía poco soportado en sistemas operativos, pero cada vez más en navegadores.
  • El navegador no usa el resolver del sistema operativo para hacer las consultas al DNS, sino que envía las consultas por HTTPS usando otro servidor DNS.
• Soportado cada vez por más servidores DNS públicos.
• Mismas críticas que a DoT, pero es más difícil de filtrar (es un tráfico HTTPS).