Saltar al contenido principal

Glosario DNS

Referencia concisa de la terminología DNS – tipos de registros, DNSSEC, operaciones, autenticación de correo y protocolos modernos.

Conceptos básicos

DNS (Domain Name System)
Sistema jerárquico de nombres que asigna dominios legibles por humanos (como example.com) a direcciones IP y otros registros. El DNS es una base de datos distribuida operada por una red de servidores autoritativos y resolvers.
Dominio
Nombre registrado bajo un dominio de nivel superior (TLD). Un dominio es un punto de delegación en el DNS bajo el cual el titular puede crear cualquier número de subdominios y registros. Se adquiere y renueva a través de un registrador de dominios.
TLD (Top-Level Domain)
Último segmento de un nombre de dominio – .com, .org, .co.uk, .io, etc. Gestionados por registries bajo la supervisión de la ICANN. Las dos grandes categorías son los TLD genéricos (gTLD) y los TLD de código de país (ccTLD).
Servidor de nombres
Servidor que responde a las consultas DNS. Los servidores de nombres autoritativos almacenan los registros reales de una zona; los resolvers recursivos obtienen registros de los servidores autoritativos en nombre de los clientes. Los registros NS de un dominio apuntan a sus servidores de nombres autoritativos.
Servidor autoritativo
Servidor de nombres que contiene los registros originales de una zona y responde con respuestas autoritativas (con la bandera AA establecida). Al alojar el DNS en NexDNS, nuestros servidores NS se convierten en autoritativos para sus zonas.
Resolver recursivo
Servidor DNS que toma una consulta del cliente, recorre la jerarquía DNS (raíz → TLD → autoritativo) y devuelve la respuesta final. Los resolvers cachean los resultados según la TTL. Ejemplos: 1.1.1.1, 8.8.8.8, el resolver de su proveedor de internet.
Zona
Porción contigua del espacio de nombres DNS gestionada como una unidad. Un archivo de zona enumera todos los registros de una zona (SOA, NS, A, AAAA, MX, etc.). Cada zona se aloja en uno o varios servidores de nombres autoritativos.
Registro
Entrada individual de datos DNS dentro de una zona. Los registros tienen un tipo (A, AAAA, MX, CNAME…), un nombre, una TTL y un valor específico del tipo. Una zona contiene muchos registros; las modificaciones de registros son la parte central de la gestión DNS.
TTL (Time To Live)
Tiempo en segundos durante el cual los resolvers pueden cachear un registro antes de volver a consultar al servidor autoritativo. Valores habituales: 300 (5 min), 3600 (1 hora), 86400 (1 día). Una TTL menor implica una propagación más rápida de los cambios, pero más consultas al servidor autoritativo.
Propagación
Proceso por el que los cambios DNS se difunden por los resolvers de todo el mundo. Está limitado por la TTL del registro anterior: tras modificar un registro, los resolvers siguen sirviendo el valor cacheado hasta que expira la TTL. Utiliza un comprobador de propagación para verificar la visibilidad en resolvers públicos.

Tipos de registros

Registro A
Asigna un nombre de host a una dirección IPv4. www.example.com A 203.0.113.10 indica que www se resuelve a la IPv4 203.0.113.10. Es el tipo de registro más habitual.
Registro AAAA
Asigna un nombre de host a una dirección IPv6. Funciona como los registros A pero con direcciones IPv6 (128 bits). Se pronuncia «cuádruple-A».
CNAME (Canonical Name)
Alias de un nombre de host a otro. shop.example.com CNAME commerce-platform.net indica que las consultas a shop deben resolverse como si se hubiera consultado commerce-platform.net. Un CNAME no puede coexistir con otros registros del mismo nombre, tampoco con MX.
Registro MX
Indica el servidor de correo de un dominio. Incluye una prioridad (menor = preferido). example.com MX 10 mail.example.com indica a los servidores remitentes que entreguen en mail.example.com.
Registro TXT
Datos de texto arbitrarios asociados a un nombre. Muy usados para verificación (pruebas de titularidad del dominio) y autenticación de correo (SPF, DKIM y DMARC utilizan registros TXT).
Registro NS
Especifica los servidores de nombres autoritativos de una zona. Toda zona debe tener al menos dos registros NS. Los NS de la zona padre (su registrador) apuntan a su proveedor de DNS; los NS dentro de su propia zona replican esa lista.
Registro SRV
Localiza un servicio en host + puerto, con prioridad y peso. Lo utilizan SIP, XMPP, Minecraft, Matrix y otros protocolos que se benefician del descubrimiento de servicios. Formato: _service._proto.name TTL SRV priority weight port target.
CAA (Certification Authority Authorization)
Restringe qué autoridades de certificación pueden emitir certificados para un dominio. example.com CAA 0 issue "letsencrypt.org" indica que solo Let's Encrypt puede emitir certificados para example.com. Las CA lo verifican antes de emitir; se recomienda como defensa en profundidad.
PTR (Pointer)
Asigna una dirección IP a un nombre de host (DNS inverso). Se emplea para consultas IP → nombre, habitualmente requerido por los servidores de correo para evitar clasificarse como spam. Reside en las zonas in-addr.arpa (IPv4) o ip6.arpa (IPv6), gestionadas por el titular del rango de IP.
Registro ALIAS
Similar a un CNAME, pero resoluble en el ápice de la zona (el dominio desnudo). Resuelve en tiempo de consulta los registros A/AAAA del destino y los devuelve al cliente. Útil cuando CNAME está técnicamente prohibido y aun así se quiere apuntar a un nombre de host en lugar de a una IP.
TLSA (DANE)
Publica a través de DNS el certificado TLS o la clave pública esperados de un servicio, habilitando DANE (DNS-based Authentication of Named Entities). Requiere DNSSEC para ser fiable. El formato incluye usage, selector, matching type y los datos de asociación del certificado.
Registro DS
Delegation Signer – publicado en la zona padre para establecer la cadena de confianza DNSSEC de una zona hija. Contiene el hash de la KSK de la zona. Se publica actualizando el registro DS en su registrador tras habilitar DNSSEC.
SOA (Start of Authority)
Metadatos de la zona – servidor de nombres primario, correo responsable, número de serie y temporizadores refresh/retry/expire/minimum. Cada zona tiene exactamente un registro SOA; los resolvers lo usan para negociar caché y transferencias de zona.

DNSSEC

DNSSEC (DNS Security Extensions)
Conjunto de extensiones que añaden firmas criptográficas a las respuestas DNS, permitiendo a los resolvers verificar que los registros no han sido manipulados en tránsito. Protege frente al spoofing y al envenenamiento de caché. Se establece mediante una cadena de confianza raíz → TLD → su zona.
KSK (Key Signing Key)
Clave DNSSEC que firma otras claves DNSSEC – en concreto el conjunto de registros DNSKEY. El hash de la clave pública KSK se publica como registro DS en la zona padre, anclando la cadena de confianza. Se rota con menos frecuencia que las ZSK (normalmente una vez al año).
ZSK (Zone Signing Key)
Clave DNSSEC utilizada para firmar los registros reales de una zona. Se rota con más frecuencia que la KSK (cada pocos meses), de modo que un compromiso no afecte a registros de larga vida. La ZSK está firmada por la KSK.
Registro DNSKEY
Publica la parte pública de las claves de firma DNSSEC (KSK y ZSK) en la zona. Los resolvers recuperan los DNSKEY para verificar las firmas de otros registros. El registro DS en la zona padre apunta a la KSK mediante su hash.
RRSIG (Resource Record Signature)
Firma de un conjunto de registros, producida por la ZSK (o por la KSK en el caso del conjunto DNSKEY). Los resolvers verifican las RRSIG contra la DNSKEY correspondiente para confirmar la autenticidad. Aparece junto a cada conjunto firmado en una zona con DNSSEC.
NSEC / NSEC3
Registros que permiten a DNSSEC demostrar que un nombre no existe (sin revelar información sobre los demás nombres). NSEC3 hashea los nombres antes de publicarlos, dificultando el zone-walking. NexDNS utiliza NSEC3 por defecto.
NSEC3
Variante de NSEC que hashea los nombres de los registros antes de publicarlos, dificultando la enumeración de todos los nombres de una zona. NSEC3 es la opción recomendada para zonas públicas.
Cadena de confianza
Vínculo criptográfico desde la zona raíz (cuya KSK se distribuye fuera de banda) a través de cada TLD hasta llegar a una zona concreta. Los resolvers validan las firmas eslabón a eslabón: raíz → TLD → su zona. Se rompe si falta u obsoleta un registro DS en alguna zona padre.

Autenticación de correo

SPF (Sender Policy Framework)
Registro TXT que lista los servidores autorizados a enviar correo en nombre de un dominio. Los receptores comprueban SPF durante la entrega; las discrepancias influyen en la puntuación de spam. Formato: v=spf1 include:_spf.example.com ~all.
DKIM (DomainKeys Identified Mail)
Firma criptográfica que el servidor remitente añade a los correos salientes y que se verifica mediante una clave pública publicada en un registro TXT en selector._domainkey.example.com. Demuestra que el mensaje no se ha manipulado en tránsito y que procede del dominio declarado.
DMARC (Domain-based Message Authentication, Reporting & Conformance)
Política que se apoya en SPF y DKIM para indicar a los receptores qué hacer cuando un mensaje falla la autenticación (none / quarantine / reject) y dónde enviar los informes agregados. Se publica como registro TXT en _dmarc.example.com.

Operaciones

Transferencia de zona
Copia de una zona de un servidor de nombres a otro. AXFR transfiere la zona completa; IXFR transfiere solo los registros modificados desde un número de serie determinado. Se utiliza entre servidores master y slave para mantenerlos sincronizados.
AXFR
Transferencia de zona completa – un servidor secundario/slave solicita la zona íntegra al primario/master. Rara vez expuesta públicamente; suele restringirse mediante ACL de IP o TSIG. Útil para migraciones puntuales entre proveedores DNS.
IXFR
Transferencia de zona incremental – el servidor secundario solicita solo los cambios desde un número de serie SOA concreto. Más eficiente que AXFR en zonas con muchas actualizaciones pequeñas. Recurre a AXFR si el primario no puede atender la petición incremental.
Zona master (zona primaria)
Zona cuyos registros se editan directamente en el servidor de nombres (frente a las que se reciben por transferencia desde otra fuente). La mayoría de las zonas son master en su proveedor de DNS. En NexDNS puede crear zonas master desde el panel, la API o la CLI.
Zona slave (zona secundaria)
Zona cuyos registros se transfieren desde otro servidor de nombres (el master) mediante AXFR/IXFR. Se utiliza para replicar una zona existente por redundancia o para preparar una migración. NexDNS admite zonas slave a partir del plan Pro.

Protocolos modernos

DoH (DNS over HTTPS)
Consultas DNS encapsuladas en HTTPS, indistinguibles del tráfico web normal y resistentes a la inspección en el camino. La utilizan navegadores, sistemas operativos y resolvers centrados en la privacidad. DoH es un protocolo del lado del resolver; servidores autoritativos como NexDNS responden a la consulta DNS subyacente del resolver.
DoT (DNS over TLS)
Consultas DNS sobre una conexión TLS dedicada en el puerto 853. Ofrece propiedades de privacidad similares a DoH, pero es distinguible por el puerto, por lo que resulta más fácil de bloquear en redes restrictivas. Al igual que DoH, es del lado del resolver; los servidores autoritativos no intervienen directamente.
ECH (Encrypted Client Hello)
Extensión de TLS 1.3 que cifra el ClientHello, impidiendo que los observadores de la red aprendan a qué sitio se está conectando el cliente (antes filtrado mediante SNI). Requiere que el sitio publique un registro DNS de tipo HTTPS con los parámetros ECH.
EDNS (Extension Mechanisms for DNS)
Conjunto de extensiones del protocolo DNS original que permiten mensajes mayores, flags adicionales y nuevas opciones sin romper la compatibilidad. Requerido por DNSSEC; algunos proveedores utilizan EDNS Client Subnet (ECS) para respuestas con geolocalización.

Utilizamos cookies para garantizar el correcto funcionamiento de este sitio web y mejorar su experiencia. Algunas cookies son estrictamente necesarias para el funcionamiento del sitio, mientras que otras son opcionales.

Puede aceptar todas las cookies o limitar su elección a las estrictamente necesarias. Para más información, consulte nuestra Política de privacidad y nuestra Política de cookies.