Consulta DNS

Cada tipo de registro DNS resuelve un problema específico de la infraestructura de Internet: • A (Address) — Mapea un nombre de dominio a una dirección IPv4 de 32 bits (RFC 1035). Es el registro más fundamental. Un dominio puede tener multiples registros A para distribución de carga (DNS round-robin). Ejemplo: example.com → 93.184.216.34. • AAAA (IPv6 Address) — Equivalente del registro A para direcciones IPv6 de 128 bits (RFC 3596). Esencial para la adopción de IPv6 y la conectividad dual-stack. Los ISPs y redes moviles modernos rutean tráfico IPv6 de forma nativa, por lo que la ausencia de registros AAAA puede resultar en latencia adicional por traducción NAT64. • MX (Mail Exchange) — Define los servidores que aceptan correo para el dominio, con un valor de prioridad (menor = mayor preferencia) (RFC 5321). Multiples registros MX con distintas prioridades proporcionan failover. Ejemplo: 10 mx1.example.com, 20 mx2.example.com. Sin registros MX, los servidores SMTP intentan entregar al registro A del dominio. • CNAME (Canonical Name) — Alias que redirige un nombre a otro nombre canónico (RFC 1034). Util para apuntar subdominios a servicios externos (blog.example.com → example.ghost.io). Un CNAME no puede coexistir con otros registros en el mismo nombre, y nunca debe usarse en la raíz del dominio (zone apex) porque colisiona con SOA y NS. • TXT (Text) — Registros de texto libre utilizados para verificación de dominio, políticas de correo (SPF, DMARC, DKIM), claves ACME para certificados Let's Encrypt, y autenticación de servicios (Google Workspace, Microsoft 365). No hay límite de contenido más allá de los 65535 bytes por registro DNS, aunque la práctica común es mantenerlos por debajo de 450 caracteres para evitar fragmentación UDP. • NS (Name Server) — Define los servidores de nombres autoritativos para la zona DNS (RFC 1035). Un mínimo de dos NS en redes distintas es requisito de ICANN para dominios gTLD. La redundancia geográfica y de proveedor (no tener todos los NS en la misma infraestructura) es crítica para la resiliencia ante ataques DDoS. • SOA (Start of Authority) — Registro único por zona que contiene el servidor primario (MNAME), el contacto del administrador (RNAME), el número de serie (para sincronización de secundarios), y los intervalos de refresh, retry, expire y minimum TTL (RFC 1035). El serial debe incrementarse con cada cambio de zona para que los servidores secundarios detecten la actualización. • SRV (Service) — Localiza servicios específicos mediante nombre, protocolo y puerto (RFC 2782). Formato: _servicio._protocolo.dominio TTL IN SRV prioridad peso puerto host. Usado extensamente por SIP (VoIP), XMPP, LDAP y Active Directory. Los campos de prioridad y peso permiten balanceo de carga y failover granular. • CAA (Certification Authority Authorization) — Especifica que Autoridades de Certificación (CAs) están autorizadas a emitir certificados para el dominio (RFC 8659). Ejemplo: 0 issue "letsencrypt.org". Las CAs están obligadas a consultar registros CAA antes de emitir un certificado. Sin CAA, cualquier CA pública puede emitir un certificado válido para el dominio, aumentando el riesgo de emisión no autorizada.

Los tres pilares de la autenticación de correo electrónico trabajan en conjunto para prevenir suplantación (spoofing) y phishing: • SPF (Sender Policy Framework, RFC 7208) — Registro TXT en la raíz del dominio que lista las IPs y servidores autorizados para enviar correo en nombre del dominio. Sintaxis: v=spf1 ip4:203.0.113.0/24 include:_spf.google.com -all. El mecanismo -all (hard fail) rechaza correo de origenes no listados; ~all (soft fail) lo marca como sospechoso pero lo entrega. Errores comunes: superar el límite de 10 lookups DNS (causa PermError), usar +all (autoriza todo el mundo), y olvidar incluir servicios terceros que envían correo (marketing, transaccional). • DKIM (DomainKeys Identified Mail, RFC 6376) — Firma criptográfica anadida a cada correo saliente. El servidor firmante inserta una cabecera DKIM-Signature con un hash del cuerpo y cabeceras, firmado con una clave privada. La clave pública se publica como registro TXT en selector._domainkey.dominio. El servidor receptor verifica la firma consultando la clave pública. DKIM garantiza integridad (el mensaje no fue alterado en tránsito) y autenticación del dominio firmante. Se recomienda usar claves RSA de 2048 bits o Ed25519. • DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) — Política publicada como TXT en _dmarc.dominio que define como tratar correos que fallan SPF y DKIM. Los valores de política son none (solo reportar), quarantine (mover a spam) y reject (rechazar). DMARC requiere alineación: el dominio en el From debe coincidir con el dominio SPF o DKIM. La directiva rua= específica la dirección para reportes agregados XML (datos diarios de autenticación), y ruf= para reportes forenses de mensajes individuales fallidos. Una implementación progresiva típica es: p=none con reportes durante 4-8 semanas, luego p=quarantine al 25-50%, y finalmente p=reject al 100%. • Interrelación — SPF valida la IP del servidor emisor. DKIM valida la firma criptográfica del mensaje. DMARC une ambos con una política de aplicación y mecanismo de reporte. Sin DMARC, un dominio con SPF y DKIM configurados pero sin política de enforcement no impide que servidores receptores acepten correo spoofed. Las tres tecnologias son requisito para la implementación de BIMI (Brand Indicators for Message Identification), que muestra el logotipo de la marca junto al remitente en bandejas de entrada compatibles.

El sistema DNS fue diseñado sin seguridad criptográfica nativa. Las extensiones y protocolos modernos abordan distintas amenazas: • DNSSEC (DNS Security Extensions, RFC 4033-4035) — Anade firmas criptográficas a los registros DNS mediante registros RRSIG, DNSKEY, DS y NSEC/NSEC3. Cada respuesta DNS incluye una firma verificable con la clave pública de la zona, formando una cadena de confianza desde la raíz DNS (.) hasta el dominio. DNSSEC protege contra envenenamiento de cache (cache poisoning) y respuestas falsificadas, pero no cifra las consultas (son visibles en texto plano). La implementación requiere que tanto la zona como el resolver soporten DNSSEC. Los errores de configuración (claves expiradas, DS records inconsistentes) causan fallos de resolución completos (SERVFAIL). • DNS sobre HTTPS (DoH, RFC 8484) — Encapsula consultas DNS dentro de conexiones HTTPS al puerto 443, haciéndolas indistinguibles del tráfico web regular. Protege la privacidad del usuario contra observación por parte del ISP o redes intermedias. Navegadores como Chrome y Firefox soportan DoH de forma nativa. Los resolvers públicos de Cloudflare (1.1.1.1), Google (8.8.8.8) y Quad9 (9.9.9.9) ofrecen endpoints DoH. • DNS sobre TLS (DoT, RFC 7858) — Cifra las consultas DNS usando TLS sobre el puerto dedicado 853. A diferencia de DoH, es detectable y bloqueable por firewalls corporativos porque usa un puerto específico, lo cual es una ventaja para administradores de red que necesitan visibilidad del tráfico DNS. • Amenazas reales — El envenenamiento de cache DNS (demostrado por Dan Kaminsky en 2008) permite redirigir dominios a IPs maliciosas. El DNS hijacking a nivel de registrador (como el ataque Sea Turtle documentado por Talos en 2019) compromete la delegación de zona. Los ataques DDoS contra infraestructura DNS (como el ataque a Dyn en 2016 que afecto a Twitter, Netflix y Reddit) explotan la dependencia centralizada en pocos proveedores NS. La redundancia de NS en distintos proveedores (multi-provider DNS) es la mitigación recomendada.