Tema: dns
-
Cambiar un registro DNS con una vía de reversión: reducción del TTL, corte y verificación
Un cambio de DNS llega a los usuarios solo tan rápido como expira el TTL antiguo en las cachés, así que hay que bajar el TTL un período completo del TTL antiguo antes del cambio, mantener el destino anterior en servicio hasta confirmar el nuevo en todas partes, y tener en cuenta que algunos resolutores sirven datos obsoletos cuando los servidores autoritativos no están disponibles, como permite el RFC 8767.
-
Coherencia entre hostname, FQDN y DNS inverso: por qué fallan las comprobaciones de nombre de Kerberos y TLS cuando no coinciden
Los tickets de servicio de Kerberos y la verificación de nombre de host en TLS dependen de que el nombre que el cliente resuelve para un servidor coincida con el que el servicio cree tener. Una discrepancia entre el hostname configurado, /etc/hosts, el DNS directo y el registro PTR produce errores de autenticación y de certificado que parecen no tener relación con los nombres.
-
Inspeccionar y cambiar la configuración de red de macOS desde Terminal: networksetup, scutil y la caché de DNS
networksetup y scutil leen y cambian el servicio de red activo, los servidores DNS, los proxies y el nombre del equipo; dscacheutil y mDNSResponder vacían una caché de resolución obsoleta tras un cambio de DNS para que una nueva prueba no vea la respuesta anterior.
-
Administrar zonas y registros del servidor DNS desde PowerShell, y verificarlos con Resolve-DnsName
Get-DnsServerZone, la adición de registros A y CNAME, el listado de registros con Get-DnsServerResourceRecord, la configuración de scavenging/aging que caduca los registros obsoletos, y la limpieza de la caché del resolutor, comprobando cada escritura desde el lado del cliente y no solo desde la vista propia del servidor.
-
Un resolvedor DNS local con cache en Unbound: access-control, reenvío y validación DNSSEC
Para usar Unbound como resolvedor con cache hay que restringir quién puede consultarlo con access-control, elegir entre recursión completa y una forward-zone hacia un resolvedor upstream, mantener activa la validación DNSSEC con auto-trust-anchor-file y probar los cambios con unbound-checkconf antes de recargar.
-
Registros DNS de los que depende un servicio web
A, AAAA y CNAME asocian nombres a direcciones, MX enruta el correo, TXT lleva verificaciones y políticas, CAA restringe las entidades emisoras de certificados, NS delega zonas; hay que comprobar las respuestas autoritativas, no solo un resolvedor con caché, antes y después de los cambios.
-
Renovación de dominios, bloqueo del registrador e higiene de la propiedad DNS
Un dominio se pierde por una tarjeta caducada, un buzón de registrante en el propio dominio, o una cuenta sin bloquear, no solo por atacantes: mantener fijados clientTransferProhibited y los demás bloqueos del lado del cliente (RFC 5731), renovación automática a varios años, usar una dirección de registrante en un dominio distinto, leer el registro RDAP para caducidad y estado, y saber que tras la caducidad los registradores deben interrumpir la resolución antes de la eliminación y que los gTLD ofrecen un período de recuperación (redemption) de 30 días.
-
¿Durante cuánto tiempo siguieron los clientes usando la dirección antigua tras un cambio de DNS, y qué resolutores o clientes ignoraron el TTL?
Pregunta abierta: RFC 1035 define el TTL como el intervalo durante el cual un registro puede almacenarse en caché antes de volver a consultar la fuente, y RFC 8767 permite a los resolutores servir datos obsoletos cuando los servidores autoritativos no son alcanzables; tras un cambio real de registro con el TTL reducido de antemano, ¿durante cuánto tiempo persistió el tráfico hacia la dirección antigua, y qué resolutores, bibliotecas o procesos de larga duración fueron responsables de esa cola?
-
Autenticación de correo electrónico: SPF, DKIM y DMARC
SPF enumera los servidores autorizados a enviar correo en nombre de un dominio, DKIM firma los mensajes con una clave del dominio y DMARC indica a los receptores qué hacer cuando ambos fallan y adónde enviar los informes; los tres son registros TXT de DNS que deben conservarse cuando se modifican otros registros.
-
Autenticación de correo con SPF, DKIM y DMARC
SPF (RFC 7208) indica qué servidores pueden enviar correo en nombre de un dominio, DKIM (RFC 6376) firma los mensajes con una clave publicada en el DNS, y DMARC (RFC 7489) define qué hacen los receptores cuando la verificación falla y adónde envían los informes. Los tres son registros TXT del DNS que deben sobrevivir a cualquier cambio de DNS.
-
www frente al dominio apex: la restricción del CNAME, el alcance de las cookies y a cuál redirigir
El apex no puede ser un CNAME porque el RFC 1034 prohíbe que haya otros datos en un nodo que tiene uno y el apex siempre contiene registros SOA y NS; por eso, alojar el sitio en una dirección cambiante del proveedor exige registros A/AAAA o una función del proveedor como el CNAME flattening. Las cookies definidas en el apex con el atributo Domain llegan a todos los subdominios. Conviene elegir una forma, servir ambas en el certificado y redirigir la otra de forma permanente.
-
Diagnóstico de la resolución de nombres en un host con systemd: resolvectl, resolv.conf, nsswitch y getent frente a dig
En un host con systemd-resolved, /etc/resolv.conf normalmente solo apunta a un stub local, los servidores DNS reales por enlace se consultan con resolvectl, y /etc/nsswitch.conf decide si getent hosts llega siquiera a preguntar al DNS. Confundir estas capas explica la mayoría de los casos de «dig funciona pero la aplicación no».
Legible por máquina: JSON