Saltar a contenido

Capítulo 4 — DNS: El directorio telefónico de Internet

Diagramas del capítulo

D-016 - Resolución de un dominio

D-016 - Resolución de un dominio

D-017 - Árbol DNS

D-017 - Árbol DNS

D-018 - Resolución DNS

D-018 - Resolución DNS

D-019 - Root Servers

D-019 - Root Servers

D-021 - Zona DNS

D-021 - Zona DNS

D-022 - Registros DNS

D-022 - Registros DNS

D-023 - Propagación DNS

D-023 - Propagación DNS

D-024 - DNSSEC

D-024 - DNSSEC

Objetivos / ¿Qué aprenderás?

Al terminar este capítulo serás capaz de:

  • Explicar con precisión qué ocurre desde que un usuario escribe elprofe.org en el navegador hasta que aparece la página.
  • Identificar cada actor en la cadena de resolución DNS: resolvers recursivos, root servers, servidores TLD y servidores autoritativos.
  • Conocer los 13 root servers de Internet, sus operadores y la tecnología Anycast que los multiplica en más de 2,000 instancias físicas.
  • Configurar todos los tipos de registros DNS (A, AAAA, CNAME, MX, TXT, NS, CAA, SRV, PTR, SOA, wildcard) con criterio profesional.
  • Entender qué es el TTL, por qué el TTL viejo es el que manda en una migración, y cómo planificar cambios con riesgo mínimo.
  • Activar DNSSEC en Cloudflare y entender la cadena de confianza criptográfica.
  • Diagnosticar problemas de DNS con dig, nslookup y herramientas web.
  • Configurar el DNS completo de elprofe.org paso a paso en Cloudflare.

Introducción

Imagina un mundo sin directorios telefónicos. Cada vez que quieres hablar con alguien tienes que memorizar su número exacto. Si cambian de compañía, pierdes el contacto. Si una empresa tiene cinco líneas diferentes para distintos departamentos, tienes que recordar cada una. Ese era el mundo de Internet antes de 1987.

Hoy escribes github.com y en milisegundos tu navegador encuentra el servidor correcto entre los miles de millones de dispositivos conectados a Internet. No tienes que saber que la IP es 140.82.121.4. No tienes que actualizar nada cuando GitHub cambia de servidor. Simplemente funciona.

DNS —Domain Name System— es el sistema que hace posible esa magia. Pero no es una base de datos centralizada que alguien mantiene en un sótano. Es un sistema distribuido en millones de servidores alrededor del planeta, organizado en jerarquías, con caché en múltiples niveles, capaz de responder miles de millones de consultas por segundo. Es, sin exageración, una de las infraestructuras más críticas y más elegantes que la humanidad ha construido.

Este capítulo desmonta el DNS completamente. Cuando termines, no solo sabrás configurarlo: entenderás por qué está diseñado así, qué falla cuando algo sale mal, y cómo pensar como un ingeniero de red cuando el sitio web "no carga" a las 2 de la mañana antes de un lanzamiento.

¿Qué es DNS y por qué existe?

El problema antes del DNS

En el capítulo anterior vimos brevemente el archivo HOSTS.TXT de ARPANET. Cada computadora en la red lo descargaba periódicamente desde el Stanford Research Institute. Contenía la lista completa de nombres y sus IPs. Cuando Internet tenía 200 nodos, funcionaba. Cuando empezó a crecer, se rompió.

Tres problemas fundamentales:

Escalabilidad. Con miles de hosts y creciendo exponencialmente, el archivo se volvió inmanejable. Cada cambio requería edición manual y redistribución centralizada.

Consistencia. Entre una descarga y la siguiente podían pasar horas o días. Dos computadoras podían tener versiones diferentes del archivo al mismo tiempo.

Centralización. Un solo punto de fallo. Un solo cuello de botella. Una sola organización cargando con toda la responsabilidad de actualizar el directorio global.

Por qué nació DNS

Paul Mockapetris publicó en 1987 los RFCs 1034 y 1035, que definieron el sistema DNS. La solución elegante a los tres problemas anteriores:

  • Jerarquía distribuida: En lugar de un archivo plano centralizado, una estructura de árbol donde cada nodo delega autoridad hacia abajo.
  • Descentralización: Cualquier organización puede administrar su propia zona sin depender de una autoridad central.
  • Delegación: .com delega github.com a GitHub; GitHub delega api.github.com a sus servidores de API. Cada uno controla lo suyo.

La RFC 1034 define el modelo conceptual y el RFC 1035 define los formatos de mensajes y los registros de recursos. Son documentos de 1987 que siguen siendo la base del sistema que usas hoy. Eso es ingeniería de calidad.

DNS en un párrafo

DNS es un sistema de base de datos distribuida jerárquicamente que traduce nombres de dominio legibles por humanos (como elprofe.org) en direcciones IP que las computadoras necesitan para comunicarse (como 104.21.15.33). Opera principalmente sobre UDP en el puerto 53, aunque usa TCP para respuestas grandes. Está organizado en zonas de autoridad delegadas, donde cada zona es administrada de forma independiente, y usa caché con TTL para reducir la carga en los servidores y mejorar el rendimiento global.

¿Cómo funciona DNS? El recorrido completo

Cuando escribes elprofe.org en tu navegador, no ocurre magia. Ocurren hasta 10 pasos distintos, cada uno con su propia lógica. Vamos a recorrerlos uno por uno.

DIAGRAMA ASCII 1 — Flujo completo de resolución DNS
═══════════════════════════════════════════════════════════════════════════

  [USUARIO]
  "quiero ver elprofe.org"
       │
       ▼
  ┌─────────────────────────────────────┐
  │  1. CACHÉ DEL NAVEGADOR             │
  │     ¿Tengo elprofe.org cacheado?    │
  │     Si SÍ → usar IP directamente   │
  │     Si NO → continuar              │
  └───────────────┬─────────────────────┘
                  │ NO encontrado
                  ▼
  ┌─────────────────────────────────────┐
  │  2. CACHÉ DEL SISTEMA OPERATIVO     │
  │     /etc/hosts + OS resolver cache  │
  │     Si SÍ → usar IP directamente   │
  │     Si NO → continuar              │
  └───────────────┬─────────────────────┘
                  │ NO encontrado
                  ▼
  ┌─────────────────────────────────────┐
  │  3. RESOLVER RECURSIVO              │
  │     (1.1.1.1 / 8.8.8.8 / ISP)      │
  │     ¿Tengo elprofe.org en caché?    │
  │     Si SÍ → devolver al cliente    │
  │     Si NO → iniciar búsqueda       │
  └───────────────┬─────────────────────┘
                  │ NO en caché
                  ▼
  ┌─────────────────────────────────────┐
  │  4. ROOT SERVER                     │
  │     Pregunta: ¿quién sabe de .org?  │
  │     Respuesta: "Aquí están los NS   │
  │     del TLD .org"                   │
  │     (ej: a0.org.afilias-nst.info)   │
  └───────────────┬─────────────────────┘
                  │
                  ▼
  ┌─────────────────────────────────────┐
  │  5. SERVIDOR TLD .org               │
  │     Pregunta: ¿quién sabe de        │
  │     elprofe.org?                    │
  │     Respuesta: "Aquí están los NS   │
  │     autoritativos de elprofe.org"   │
  │     (ej: ken.ns.cloudflare.com)     │
  └───────────────┬─────────────────────┘
                  │
                  ▼
  ┌─────────────────────────────────────┐
  │  6. SERVIDOR AUTORITATIVO           │
  │     (Cloudflare DNS para            │
  │     elprofe.org)                    │
  │     Respuesta FINAL: "elprofe.org   │
  │     → 104.21.15.33" (TTL: 300s)    │
  └───────────────┬─────────────────────┘
                  │
                  ▼
  ┌─────────────────────────────────────┐
  │  7. RESOLVER RECURSIVO              │
  │     Cachea la respuesta (300 seg)   │
  │     Devuelve IP al cliente          │
  └───────────────┬─────────────────────┘
                  │
                  ▼
  ┌─────────────────────────────────────┐
  │  8. NAVEGADOR                       │
  │     Cachea la IP                    │
  │     Establece conexión TCP/TLS      │
  │     con 104.21.15.33                │
  └───────────────┬─────────────────────┘
                  │
                  ▼
            [PÁGINA WEB]

═══════════════════════════════════════════════════════════════════════════

Paso 1: El navegador revisa su caché interna

Chrome, Firefox y Safari mantienen su propia caché DNS independiente del sistema operativo. Almacenan las IPs de los dominios visitados recientemente con sus TTL. En Chrome puedes ver esta caché en chrome://net-internals/#dns. Si el registro no ha expirado, el navegador usa esa IP directamente y nunca sale a la red. Cero latencia adicional.

Paso 2: El sistema operativo revisa su caché

Si el navegador no tiene la respuesta, consulta al resolver del sistema operativo. Esto incluye dos fuentes:

El archivo /etc/hosts (o C:\Windows\System32\drivers\etc\hosts en Windows): Es literalmente el descendiente directo del HOSTS.TXT de ARPANET. Tiene prioridad sobre DNS. Si pones 127.0.0.1 facebook.com en ese archivo, tu computadora nunca llegará a Facebook. Los desarrolladores lo usan frecuentemente para pruebas locales.

La caché del OS: Windows, macOS y Linux mantienen una caché de resoluciones recientes. Si elprofe.org fue visitado hace 10 minutos y el TTL es de 5 minutos, la caché del OS ya expiró y se consulta la siguiente capa.

Paso 3: El resolver recursivo entra en acción

Si ni el navegador ni el OS tienen la respuesta, la consulta llega al resolver recursivo. Este es el servidor DNS configurado en tu red: puede ser el de tu ISP (que probablemente no elegiste), Cloudflare (1.1.1.1) o Google (8.8.8.8).

El resolver recursivo también tiene caché. Si otro usuario en la misma red preguntó por elprofe.org hace dos minutos y el TTL es de 5 minutos, el resolver responde inmediatamente desde caché sin ir más lejos.

Si no tiene la respuesta, aquí empieza el trabajo real: el resolver va a recorrer la jerarquía DNS desde arriba.

Paso 4: El resolver pregunta a un Root Server

El resolver tiene hardcodeada una lista de 13 direcciones IP de root servers (los veremos en detalle más adelante). Envía una consulta a uno de ellos preguntando por elprofe.org.

El root server no sabe la IP de elprofe.org. Pero sí sabe quién administra .org. Responde con los nameservers del TLD .org. Eso es todo. Una pregunta, una respuesta parcial, seguir.

Paso 5: El resolver pregunta al servidor TLD

Ahora el resolver tiene los nameservers de .org. Les pregunta: "¿quién sabe de elprofe.org?"

El servidor TLD tampoco sabe la IP. Pero sí sabe qué nameservers están registrados para elprofe.org. Responde con esos nameservers: en este caso, los de Cloudflare.

Paso 6: El resolver pregunta al servidor autoritativo

Finalmente, el resolver pregunta a los nameservers autoritativos de elprofe.org, que son los servidores de Cloudflare DNS. Estos sí tienen la respuesta definitiva: la IP del servidor, con su TTL exacto.

Esta respuesta viene directamente del archivo de zona del dominio, configurado por el administrador del dominio.

Paso 7 y 8: La respuesta llega al usuario

El resolver cachea la respuesta según el TTL indicado, la devuelve al cliente, y el navegador establece la conexión TCP con el servidor web. Todo este proceso, en condiciones normales, toma entre 20 y 120 milisegundos en total.

Componentes del DNS

Resolver recursivo

Es el detective del sistema DNS. Cuando no tiene la respuesta en caché, sale a buscarla recorriendo la jerarquía completa: root → TLD → autoritativo. Se llama "recursivo" porque resuelve el problema completamente, sin pedirte que hagas más pasos. Los más conocidos son Cloudflare (1.1.1.1), Google (8.8.8.8) y los de los ISPs.

DNS Cache

La caché DNS es el mecanismo de rendimiento más importante del sistema. Sin ella, cada visita a cualquier sitio web generaría entre 3 y 8 consultas a servidores distribuidos por el mundo. Con caché, la mayoría de las consultas se resuelven localmente en microsegundos. Existe en el navegador, en el OS, en el resolver recursivo y en los servidores intermedios.

Root Server

Los 13 servidores raíz son el punto de entrada a la jerarquía DNS. No almacenan información sobre dominios específicos, solo saben qué servidores administran cada TLD. Son el ancla del sistema; sin ellos, Internet tal como la conocemos dejaría de funcionar.

Servidor TLD

Administra la zona de un Top-Level Domain: .com, .org, .mx, .uk, .ai. Sabe qué nameservers están registrados para cada dominio dentro de su TLD. Cuando registras un dominio y apuntas a los nameservers de Cloudflare, el registrar actualiza estos servidores TLD con esa información.

Servidor Autoritativo

El servidor que tiene la respuesta definitiva para un dominio. Almacena el "zone file": el conjunto completo de registros DNS del dominio. Cuando usas Cloudflare DNS, sus servidores son los autoritativos para tu dominio. La diferencia fundamental con un resolver recursivo: el autoritativo no busca nada, solo responde con lo que tiene.

Zone File

El archivo de texto que contiene todos los registros DNS de un dominio. Define las IPs, los servidores de correo, los alias, las políticas de seguridad, etc. Es la fuente de verdad del dominio. Aunque en plataformas como Cloudflare se edita a través de una interfaz web, internamente siempre existe este archivo en algún formato.

TTL (Time To Live)

El tiempo en segundos que un registro DNS puede ser cacheado por cualquier resolver. Un TTL de 300 significa que la respuesta puede cachearse 5 minutos. Después, el resolver tiene que volver a preguntar al servidor autoritativo. El administrador del dominio lo controla en el zone file.

Delegación de zona

El mecanismo por el cual una zona delega la autoridad sobre una sub-zona a otros nameservers. Cuando elprofe.org quiere que api.elprofe.org sea administrado por un servidor diferente, crea registros NS apuntando a esos servidores. A partir de ese momento, cualquier consulta por api.elprofe.org es redirigida a esos nameservers.

Los 13 Root Servers: el núcleo de Internet

Por qué exactamente 13

Esto tiene una respuesta técnica precisa y fascinante. El protocolo DNS original (RFC 1035, 1987) usa UDP como transporte. Un paquete UDP no puede superar 512 bytes sin fragmentarse. Una respuesta que lista los nameservers de los root servers incluye las IPs y los hostnames de cada uno. Los ingenieros de la época calcularon que el máximo que cabía en esos 512 bytes era... 13 registros. No 12, no 14: exactamente 13.

Ese límite de 512 bytes de UDP determinó la arquitectura de root servers de Internet para las siguientes décadas.

Los 12 operadores

Hay 13 direcciones lógicas pero 12 operadores, porque Verisign opera dos: la letra A y la letra J.

DIAGRAMA ASCII 2 — Los 13 Root Servers de Internet
═══════════════════════════════════════════════════════════════════════════

  ID  HOSTNAME                     IPv4              OPERADOR
  ══  ═══════════════════════════  ════════════════  ═══════════════════════
   A  a.root-servers.net           198.41.0.4        Verisign, Inc. (EE.UU.)
   B  b.root-servers.net           170.247.170.2     USC-ISI (EE.UU.)
   C  c.root-servers.net           192.33.4.12       Cogent Communications
   D  d.root-servers.net           199.7.91.13       Univ. of Maryland (EE.UU.)
   E  e.root-servers.net           192.203.230.10    NASA Ames Research (EE.UU.)
   F  f.root-servers.net           192.5.5.241       ISC (EE.UU.)
   G  g.root-servers.net           192.112.36.4      DoD / DISA (EE.UU.)
   H  h.root-servers.net           198.97.190.53     U.S. Army Research Lab
   I  i.root-servers.net           192.36.148.17     Netnod (Suecia)
   J  j.root-servers.net           192.58.128.30     Verisign, Inc. (EE.UU.)
   K  k.root-servers.net           193.0.14.129      RIPE NCC (Países Bajos)
   L  l.root-servers.net           199.7.83.42       ICANN (EE.UU.)
   M  m.root-servers.net           202.12.27.33      WIDE Project (Japón)
  ══  ═══════════════════════════  ════════════════  ═══════════════════════

  IPv6 (ejemplos):
   A  → 2001:503:ba3e::2:30        I → 2001:7fe::53
   K  → 2001:7fd::1                L → 2001:500:9f::42
   M  → 2001:dc3::35

  GEOGRAFÍA ORIGINAL vs. ACTUAL:
  ┌─────────────────────────────────────────────────────────┐
  │ 1992: 10 de 13 servidores en EE.UU.                     │
  │       1 en Suecia (I), 1 en Países Bajos (K),           │
  │       1 en Japón (M)                                    │
  │                                                         │
  │ 2026: >2,002 instancias físicas en todo el mundo         │
  │       gracias a ANYCAST                                 │
  └─────────────────────────────────────────────────────────┘

═══════════════════════════════════════════════════════════════════════════

Anycast: cómo 13 se convirtieron en 2,000+

Aquí entra una de las tecnologías más elegantes de Internet. Anycast permite que múltiples servidores en distintas ubicaciones físicas anuncien la misma dirección IP. Cuando envías un paquete a esa IP, el sistema de enrutamiento de Internet lo dirige automáticamente al servidor más cercano.

El root server A tiene la IP 198.41.0.4. Pero esa misma IP está activa en decenas de ubicaciones físicas: Nueva York, São Paulo, Frankfurt, Tokio, Sydney. Cuando un resolver en México consulta esa IP, su paquete va al servidor físico más cercano en América Latina, no cruzando el océano a Virginia.

Según datos de root-servers.org al 28 de junio de 2026, hay más de 2,002 instancias físicas reales operando bajo las 13 direcciones lógicas. Lo que en 1992 era 13 computadoras (la mayoría en EE.UU.) es hoy una red global distribuida en todos los continentes.

Esta es la razón por la que Internet no colapsa cuando un root server tiene problemas. Si la instancia de f.root-servers.net en São Paulo falla, el tráfico se redirige automáticamente a la siguiente instancia más cercana. El fallo es transparente para los usuarios.

¿Qué pasa si todos fallan?

En teoría, si todos los root servers del mundo fallaran simultáneamente, la resolución DNS de dominios no cacheados sería imposible. Pero la caché masiva que existe en millones de resolvers alrededor del mundo significaría que la mayoría del tráfico seguiría funcionando por horas o días. Y dado que hay más de 2,000 instancias físicas distribuidas globalmente, un evento de esa escala requeriría una catástrofe sin precedentes en la historia de Internet.

Cuántos TLDs existen

El root zone —la zona que administran los root servers— contiene actualmente 1,443 TLDs (dato de IANA, marzo 2025). Desde los clásicos .com, .org, .net hasta los nuevos gTLDs como .photography, .berlin, .tienda, pasando por ccTLDs como .mx, .uk, .ai, .io.

Servidores TLD

El servidor TLD es como el gerente de un edificio enorme. No vive en ningún apartamento específico, pero sabe exactamente en qué piso vive cada inquilino y puede darte las instrucciones para llegar.

Cuando un resolver pregunta al servidor TLD de .org por elprofe.org, la respuesta es: "No tengo la IP, pero los nameservers de ese dominio son ken.ns.cloudflare.com y dara.ns.cloudflare.com". Eso es todo lo que hace el TLD: señalar hacia el servidor autoritativo correcto.

¿Quién administra cada TLD?

TLD Operador Sede
.com Verisign, Inc. EE.UU.
.org Public Interest Registry (PIR) EE.UU.
.net Verisign, Inc. EE.UU.
.mx NIC México (ITESM) México
.uk Nominet Reino Unido
.ai Gobierno de Anguilla Caribe
.io Internet Computer Bureau Reino Unido
.edu Educause EE.UU.

El caso de .ai es interesante: es el ccTLD de Anguilla, una pequeña isla caribeña con ~18,000 habitantes. El boom de la Inteligencia Artificial convirtió .ai en uno de los TLDs más demandados del mundo, generando millones de dólares en ingresos para ese pequeño territorio.

Servidores Autoritativos

Si el root server es el índice y el TLD es el índice del capítulo, el servidor autoritativo es la página exacta donde está la información.

El servidor autoritativo tiene la respuesta final. No necesita preguntar a nadie más. Almacena el zone file completo del dominio: todos los registros A, CNAME, MX, TXT y el resto que el administrador configuró.

¿Por qué Cloudflare DNS es tan rápido?

Cloudflare opera su DNS autoritativo usando la misma tecnología Anycast que los root servers. Sus servidores están en más de 300 ciudades alrededor del mundo. Cuando un resolver pregunta por tu dominio, la consulta llega al data center de Cloudflare más cercano al resolver, no a un servidor central. El resultado es latencia típica de 10-20ms para resolución autoritativa.

La diferencia crítica entre autoritativo y recursivo:

Servidor Autoritativo Resolver Recursivo
Función Tiene la respuesta final Busca la respuesta
Datos Zone file propio Caché de otros
Configura El dueño del dominio El usuario o ISP
Ejemplos Cloudflare DNS, Route 53 1.1.1.1, 8.8.8.8, ISP

TTL: Time To Live

El TTL es el número que controla cuánto tiempo puede vivir una respuesta DNS en caché. Se mide en segundos y lo configura el administrador del dominio en cada registro.

TTL 300   = 5 minutos
TTL 3600  = 1 hora
TTL 86400 = 24 horas

Cuándo usar TTL bajo vs. TTL alto

TTL bajo (60–300 segundos): Para registros que cambian frecuentemente, servicios en desarrollo, durante migraciones activas o cuando necesitas control rápido sobre los cambios.

TTL alto (3600–86400 segundos): Para registros estables en producción. Reduce la carga en tus nameservers y mejora el rendimiento para los usuarios porque más resolvers tendrán la respuesta cacheada.

El truco profesional: bajar TTL antes de una migración

Este es el conocimiento que separa a los profesionales de los que aprenden con dolor. Si tienes un registro A con TTL de 86400 y quieres cambiar la IP, todos los resolvers del mundo que cachearon ese registro seguirán usando la IP vieja hasta 24 horas después de tu cambio. Durante ese tiempo, parte del tráfico irá al servidor viejo y parte al nuevo.

El procedimiento correcto: 1. 48–72 horas antes de la migración: Baja el TTL a 300 segundos. 2. Espera el TTL viejo (24 horas): Todos los caches expirarán y empezarán a usar el TTL nuevo de 300 segundos. 3. Haz el cambio de IP: Ahora la propagación toma máximo 5–10 minutos. 4. Después de confirmar que todo funciona: Sube el TTL de vuelta a 3600 o 86400.

La regla de oro del TTL

El TTL que importa en una migración es el TTL VIEJO, no el nuevo. Si cambias un registro A que tenía TTL=86400, el resolver que lo cacheó hace 1 hora seguirá usando la IP vieja por las próximas 23 horas, aunque ya cambiaste el registro en tu nameserver. No puedes acelerar ese proceso para los resolvers externos.

Caché DNS en todos los niveles

La caché DNS no es una sola cosa. Es un sistema multicapa donde cada nivel puede retener respuestas de forma independiente.

Nivel 1: Caché del navegador

Chrome mantiene su propia caché DNS separada del sistema operativo. La puedes ver y vaciar en chrome://net-internals/#dns. Cuando visitas un sitio frecuente, Chrome ya tiene la IP lista sin consultar nada. Los TTL son respetados, pero Chrome puede implementar sus propias heurísticas adicionales.

Nivel 2: Caché del sistema operativo

El sistema operativo mantiene su propia caché. Para limpiarla:

```bash

macOS (Monterey / Ventura / Sonoma)

Windows

Linux (systemd-resolved)

Linux (nscd)

Registro A del dominio

Servidores de correo

Nameservers

Registros TXT (SPF, DKIM, verificaciones)

Traza completa desde root hasta autoritativo

Forzar consulta a resolver específico (omite caché local)

Forzar consulta a Cloudflare (comparar resultados)

Respuesta corta (solo el resultado)

Registros DNSSEC

dig +trace — el comando más poderoso para debugging

Muestra exactamente el camino: root → TLD → autoritativo

Output parcial:

. 518400 IN NS a.root-servers.net. ← root server

org. 172800 IN NS a0.org.afilias-nst.info. ← TLD .org

elprofe.org. 86400 IN NS ken.ns.cloudflare.com. ← autoritativo

elprofe.org. 300 IN A 104.21.15.33 ← respuesta final

Consulta básica

Consulta de tipo específico

Consulta a servidor específico

Información del registrar, fechas de expiración, nameservers registrados

Debe devolver: ken.ns.cloudflare.com. y dara.ns.cloudflare.com.

Con proxy activo: 104.21.X.X (IPs de Cloudflare, no tu servidor)

Sin proxy: 104.21.15.33 (tu IP directa)

Debe devolver la misma IP que elprofe.org

Debe mostrar los 5 servidores de Google con sus prioridades

Debe mostrar el registro SPF entre los TXT

0 issue "letsencrypt.org"

0 issuewild "letsencrypt.org"

0 iodef "mailto:security@elprofe.org"

La respuesta debe incluir registros RRSIG

Verificar desde el autoritativo directamente

Verificar desde Google (sin caché local)

Verificar desde Cloudflare

Traza completa

Verificar todos los tipos principales

Referencias bibliográficas

Capítulo 4 de "Arquitectura Web Moderna — De cero a una infraestructura profesional para Internet"