DNS herramientas
Una referencia práctica de los tipos de registro DNS, el TTL y los tiempos de conmutación, la delegación y los registros TXT de correo, con la herramienta de consulta a la que recurrir cuando un nombre no resuelve.
1 herramientas
El DNS es una jerarquía de cachés, no una base de datos
Cuando «cambias un registro DNS» editas una zona en un conjunto de servidores de
nombres autoritativos, y casi nadie lee esa zona. Las respuestas de tus usuarios
vienen de resolutores recursivos (el de un ISP, 8.8.8.8, un resolutor
corporativo, el punto DoH propio de un navegador), y cada uno conserva una copia que
caduca según su propio calendario. Hay una respuesta autoritativa y N aproximaciones
en caché de ella, más tu propio portátil, cuya caché del sistema y cuyo /etc/hosts
prevalecen sobre todo lo demás.
La resolución empieza en la raíz: un resolutor frío pregunta a un servidor raíz por
www.example.com, se le remite a los servidores de nombres de .com y después a
los registros NS que el registrador publicó para example.com. Cada eslabón de esa
cadena de delegación es a su vez un registro en caché con su propio TTL, y el
conjunto NS del TLD suele quedar en caché de 1 a 2 días, que es la razón por la que
cambiar de proveedor de DNS no se parece en nada a cambiar un registro A.
La «propagación» es por tanto un nombre engañoso: nada se empuja, simplemente
caducan las respuestas antiguas, incluidas las negativas. NXDOMAIN se guarda en
caché durante el intervalo que deriva del SOA de la zona (habitualmente 300–3600 s),
así que un nombre puede parecer inexistente durante minutos después de crearlo.
Los tipos de registro que de verdad tocas
| Tipo | Contiene | Uso típico | A tener en cuenta |
|---|---|---|---|
A | una dirección IPv4 | nombre → host | varios A = reparto rotatorio, no conmutación por fallo |
AAAA | una dirección IPv6 | pila dual | un AAAA roto rompe a los clientes que prefieren IPv6 |
CNAME | otro nombre | CDN, endpoints SaaS | ilegal en el ápice; excluye otros registros |
MX | host de correo + prioridad | correo entrante | gana el número más bajo; un host, nunca una IP |
TXT | cadenas libres | SPF, DKIM, DMARC, verificación | 255 caracteres por cadena; las claves largas se trocean |
NS | servidores de nombres delegados | delegación de zona | lo que cuenta es el conjunto que está en el padre |
SOA | temporizadores de zona, número de serie | TTL de la caché negativa | MINIMUM fija la vida del NXDOMAIN |
PTR | nombre para una dirección | DNS inverso, reputación del remitente | in-addr.arpa (IPv4) / ip6.arpa (IPv6); pertenece a quien posee la IP |
CAA | AC permitidas | control de emisión | se comprueba al emitir, no en la negociación TLS |
DS / DNSKEY | anclas DNSSEC | delegación firmada | un DS obsoleto tras rotar la clave = fallo total |
TTL, conmutaciones y ventanas de reversión
Elige los TTL según la rapidez con la que podrías necesitar moverte: 60 para un
registro que quizá reapuntes en minutos, 300–900 durante una migración, 3600
en régimen estable y 86400 para los NS y MX que no tocas nunca. Los TTL cortos
no son gratis: multiplican el volumen de consultas y reducen el colchón que te
protege si los servidores autoritativos quedan inalcanzables.
La reversión importa tanto como la conmutación: un TTL en caché es un suelo para la recuperación, así que un TTL de 300 s mantiene a los últimos resolutores apuntando a un endpoint muerto durante cinco minutos después de publicar. Dos episodios así al mes son unos 10 minutos de caída, y la Calculadora SLA muestra si eso encaja: un 99,99 % permite 4,3 minutos por mes de 30 días. Más sobre presupuestos en la página de herramientas SRE.
Qué demuestra cada uno de SPF, DKIM y DMARC
| Mecanismo | Se publica como | Un resultado correcto demuestra | No demuestra |
|---|---|---|---|
| SPF | TXT en el dominio, v=spf1 … | que la IP que conecta puede enviar por el dominio del sobre MAIL FROM | nada sobre el From: visible; se rompe al reenviar |
| DKIM | TXT en selector._domainkey.dominio, v=DKIM1; p=… | que los encabezados firmados y el cuerpo no han cambiado desde que d= los firmó | que d= sea tu dominio; se pueden añadir encabezados sin firmar |
| DMARC | TXT en _dmarc.dominio, v=DMARC1; p=… | que SPF o DKIM pasó y que ese dominio se alinea con el From: | que haya aplicación: p=none solo pide informes |
De los tres, solo el registro SPF del ápice se puede leer con
DNS Lookup: su pestaña TXT muestra la cadena v=spf1 que
publicaste, pero la herramienta solo acepta etiquetas de nombre de host, así que los
nombres con guion bajo como _dmarc.example.com y
selector._domainkey.example.com se rechazan con Invalid domain format. Esos
léelos con dig TXT _dmarc.example.com o desde el editor de zona de tu proveedor de
DNS. Lo que concluyó quien recibió el correo es otra cuestión, y
Análisis de Encabezados la responde a partir de los
encabezados Authentication-Results, Received-SPF, DKIM-Signature y ARC de un
mensaje entregado. Antes de añadir un mecanismo ip4:, confirma la dirección desde
la que sale realmente tu tráfico con Ver IP en lugar de confiar en
un archivo de configuración. Si un registro DKIM se reconstruyó a partir de cadenas
troceadas, pega el valor p= en Base64: rechaza los caracteres
sueltos y el relleno roto, lo que detecta una clave estropeada. Más sobre
encabezados de autenticación: el hub de correo.
Qué herramienta para cada trabajo
Dado un dominio, DNS Lookup resuelve A, AAAA, CNAME, MX,
TXT y NS en una sola consulta, e imprime TYPE / NAME / VALUE / TTL con la
prioridad MX; las pestañas de tipo filtran en el cliente las filas ya recuperadas,
así que pasar de MX a TXT no cuesta ninguna consulta adicional. CNAME no tiene
pestaña propia, así que esas filas — las que te dicen que un nombre es un alias y no
una dirección — aparecen en la vista ALL. Lee la barra de estado de forma literal:
SERVER es siempre api.sitekits.dev y LATENCY es la ida y vuelta navegador→API, ni
el resolutor recursivo que respondió ni el tiempo de consulta DNS. La resolución se
ejecuta en el servidor mediante Cloudflare DoH, que es lo que te da un punto de
observación fuera de tu propia caché; para determinar qué resolutor respondió,
pregunta a uno directamente con dig @8.8.8.8 example.com. Dada una URL en cambio,
Parseador de URL aísla hostname de host (que incluye el
puerto), localmente y sin solicitar nada.
Cuando los registros son correctos pero se sirve el contenido equivocado, ya no es DNS: Cabeceras HTTP solicita desde el servidor y devuelve el estado, la cadena de redirecciones y todos los encabezados de respuesta, suficiente para separar «sigue siendo la IP antigua» de «IP correcta, caché de CDN obsoleta». Nunca recupera el cuerpo y rechaza las direcciones privadas.
El DNS solo transporta etiquetas ASCII, así que
Convertidor IDN muestra la forma xn-- que realmente se
consulta, lo que además desenmascara a los homógrafos que imitan a otros. Los
valores AAAA que parecen distintos a menudo no lo son:
Compresión IPv6 normaliza ambas escrituras y expande los
grupos que necesita un nombre ip6.arpa. Haz una instantánea de una zona antes de
una migración y compara el antes y el después en
Diff de Texto.
Trampas que cuestan horas
CNAME en el ápice de la zona
example.com debe tener SOA y NS, y un CNAME no puede coexistir con otros
registros en un mismo nombre, así que un CNAME en el ápice no es válido por mucho
que lo acepte el panel de control. ALIAS/ANAME y el aplanamiento son funciones
del proveedor, no del protocolo.
Dos registros SPF en lugar de uno
Un segundo registro TXT v=spf1 en el mismo nombre produce un permerror. Fusiona
todos los mecanismos en un único registro y cuenta las consultas: include:, a,
mx, ptr, exists y redirect= consumen cada uno una de las 10 consultas DNS que
permite una evaluación (RFC 7208 §4.6.4), un tope que las cadenas de proveedores
apiladas revientan en silencio.
Nombres relativos y puntos finales que faltan
En la sintaxis de los archivos de zona, un destino sin punto final es relativo, así
que www.example.com pasa a ser www.example.com.example.com., exactamente lo que
ocurre cuando pegas un destino completamente cualificado en una interfaz que ya
añade la zona.
Registros huérfanos que apuntan a servicios liberados
Un CNAME que sigue apuntando a un bucket, una plataforma de aplicaciones o un
nombre de host de CDN dados de baja puede ser reclamado por quien registre ese
nombre a continuación, lo que entrega a un atacante un subdominio que es tuyo;
consulta las herramientas de seguridad.