¿El TLD .de está fuera de línea por DNSSEC?

 (dnssec-analyzer.verisignlabs.com)
1 puntos por GN⁺ 1 시간 전 | 1 comentarios | Compartir por WhatsApp
  • El resultado del depurador DNSSEC de nic.de está basado en 2026-05-06 00:38:26 UTC y valida paso a paso la cadena de confianza desde la raíz, pasando por .de, hasta nic.de
  • La zona raíz incluye DS=20326/SHA-256 y DS=38696/SHA-256, y el DS de la delegación de .de, keytag 26755, se valida con la firma de DNSKEY=54393 de la raíz
  • La zona .de incluye DNSKEY=26755/SEP y DNSKEY=32911, y DS=26755/SHA-256 valida el DNSKEY RRset de .de
  • La delegación de nic.de incluye los servidores de nombres ns1.denic.de, ns2.denic.de, ns3.denic.de, ns4.denic.net, y DS=26155/SHA-256 se valida con DNSKEY=32911 de .de
  • El registro A de nic.de se confirma como 81.91.170.12 en todas las consultas a los servidores de nombres autoritativos, y RRSIG=36463 junto con DNSKEY=36463 validan ese RRset

nic.de flujo de validación DNSSEC

  • El objetivo de la verificación es nic.de, y en la pantalla de DNSSEC Debugger aparecen las opciones de ajuste Detail como more(+) y less(-)
  • La hora mostrada es 2026-05-06 00:38:26 UTC
  • El estado DNSSEC de nic.de también puede probarse en dnsviz.net

Cadena de confianza desde la raíz hasta .de

  • Validación de DNSKEY de la zona raíz

    • Los DS=20326/SHA-256 y DS=38696/SHA-256 de la raíz (.) forman parte de la cadena de confianza
    • Se consultó ./DNSKEY a j.root-servers.net y se recibió una respuesta de 1139 bytes desde 192.58.128.30, con código de respuesta NOERROR
    • En la zona raíz se confirmaron 3 registros DNSKEY
      • DNSKEY keytag 54393, flags 256, algoritmo 8
      • DNSKEY keytag 20326, flags 257, algoritmo 8
      • DNSKEY keytag 38696, flags 257, algoritmo 8
    • DNSKEY=20326/SEP y DNSKEY=38696/SEP forman parte de la cadena de confianza y se validan respectivamente con DS=20326/SHA-256 y DS=38696/SHA-256
    • El DNSKEY RRset de la raíz tiene 1 RRSIG, y RRSIG=20326 junto con DNSKEY=20326/SEP validan ese DNSKEY RRset
    • DNSKEY=54393 también forma parte de la cadena de confianza

  • Verificación de la delegación de .de desde la raíz

    • Se consultó nic.de/A a k.root-servers.net y se recibió una respuesta de 742 bytes desde 193.0.14.129; la sección de respuesta estaba vacía y la sección de autoridad incluía la información de delegación de .de
    • Como servidores de nombres de .de se devolvieron a.nic.de, f.nic.de, l.de.net, n.de.net, s.de.net, z.nic.de
    • El registro DS de .de se devolvió con keytag 26755, algoritmo 8, digest type 2, y digest SHA-256 f341357809a5954311ccb82ade114c6c1d724a75c0395137aa3978035425e78d
    • El RRset DS de .de incluía RRSIG, y el firmante es DNSKEY=54393 de la raíz
    • La sección adicional incluía las direcciones IPv4/IPv6 de los servidores de nombres de .de
      • a.nic.de: 194.0.0.53, 2001:678:2::53
      • f.nic.de: 81.91.164.5, 2a02:568:0:2::53
      • z.nic.de: 194.246.96.1, 2a02:568:fe02::de
      • l.de.net: 77.67.63.105, 2001:668:1f:11::105
      • n.de.net: 194.146.107.6, 2001:67c:1011:1::53
      • s.de.net: 195.243.137.26, 2003:8:14::53

  • Validación del RRset DS de .de

    • Se consultó de/DS a b.root-servers.net y se recibió una respuesta de 366 bytes desde 170.247.170.2, con código de respuesta NOERROR
    • En la zona raíz se confirmó 1 registro DS para .de
    • DS=26755/SHA-256 usa el algoritmo RSASHA256
    • El RRset DS de .de tiene 1 RRSIG, y RRSIG=54393 junto con DNSKEY=54393 validan ese RRset DS
    • DS=26755/SHA-256 forma parte de la cadena de confianza

  • Validación del DNSKEY RRset de .de

    • Se consultó de/DNSKEY a f.nic.de y se recibió una respuesta de 745 bytes desde 81.91.164.5, con código de respuesta NOERROR
    • En .de se confirmaron 2 registros DNSKEY
      • DNSKEY keytag 32911, flags 256, algoritmo 8, TTL 3600
      • DNSKEY keytag 26755, flags 257, algoritmo 8, TTL 3600
    • DNSKEY=26755/SEP forma parte de la cadena de confianza y DS=26755/SHA-256 valida DNSKEY=26755/SEP
    • El DNSKEY RRset de .de tiene 1 RRSIG, y RRSIG=26755 junto con DNSKEY=26755/SEP validan ese RRset
    • DNSKEY=32911 forma parte de la cadena de confianza

Delegación y validación DS desde .de hasta nic.de

  • Verificación de la subzona nic.de

    • Se consultó nic.de/A a l.de.net y se recibió una respuesta de 464 bytes desde 77.67.63.105; la sección de respuesta estaba vacía y la información de delegación de nic.de apareció en la sección de autoridad
    • Como servidores de nombres de nic.de se devolvieron ns1.denic.de, ns2.denic.de, ns3.denic.de, ns4.denic.net
    • El registro DS de nic.de se devolvió con keytag 26155, algoritmo 8, digest type 2, y digest SHA-256 2f06c8cdf8673a2e98d72c8b7ab6067d9318458b3d9edccde1c5ef793c0c565d
    • El RRset DS de nic.de incluía RRSIG, y el firmante es DNSKEY=32911 de .de
    • La sección adicional incluía algunas direcciones de los servidores de nombres de nic.de
      • ns1.denic.de: 77.67.63.106, 2001:668:1f:11::106
      • ns2.denic.de: 81.91.164.6, 2a02:568:0:2::54
      • ns3.denic.de: 195.243.137.27, 2003:8:14::106
    • Al consultar nic.de/DNSKEY a l.de.net también se devolvieron la misma delegación de nic.de, el mismo DS, RRSIG y la misma información adicional de direcciones, confirmando la subzona nic.de

  • Validación del RRset DS de nic.de

    • Se consultó nic.de/DS a a.nic.de y se recibió una respuesta de 245 bytes desde 194.0.0.53, con código de respuesta NOERROR
    • En la zona de se confirmó 1 registro DS para nic.de
    • El DS confirmado es keytag 26155, algoritmo 8, digest type 2, y se muestra como basado en SHA-256
    • El DS RRset tiene 1 RRSIG, y RRSIG=32911 junto con DNSKEY=32911 validan el DS RRset
    • DS=26155/SHA-256 forma parte de la cadena de confianza
nic.de. 86400 IN DS (
  26155 8 2 2f06c8cdf8673a2e98d72c8b7ab6067d9318458b3d9edccde1c5ef793c0c565d
)

Validación de DNSKEY y registros de nic.de

  • Validación de DNSKEY de nic.de

    • Se consultó nic.de/DNSKEY a ns4.denic.net y se recibió una respuesta de 625 bytes desde 194.246.96.28, con código de respuesta NOERROR
    • En nic.de se confirmaron 2 registros DNSKEY
    • keytag 26155 es un DNSKEY con formato 257 3 8, y DNSKEY=26155/SEP forma parte de la cadena de confianza
    • DS=26155/SHA-256 valida DNSKEY=26155/SEP
    • El DNSKEY RRset tiene 1 RRSIG, y RRSIG=26155 junto con DNSKEY=26155/SEP validan el DNSKEY RRset
    • DNSKEY=36463 también forma parte de la cadena de confianza
nic.de. 3600 IN DNSKEY (
  257 3 8 AwEAAb/xrM2MD+xm84YNYby6TxkMaC6PtzF2bB9WBB7ux7iqzhViob4GKvQ6L7CkXjyAxfKbTzrd
  vXoAPpsAPW4pkThReDAVp3QxvUKrkBM8/uWRF3wpaUoPsAHm1dbcL9aiW3lqlLMZjDEwDfU6lxLc
  Pg9d14fq4dc44FvPx6aYcymkgJoYvR6P1wECpxqlEAR2K1cvMtqCqvVESBQV/EUtWiALNuwR2Pbh
  wtBWJd+e8BdFI7OLkit4uYYux6Yu35uyGQ==
) ; keytag 26155

nic.de. 3600 IN DNSKEY (
  256 3 8 AwEAAdkJ06nJ8Cutng7f9HACMUhuYnF0CX7uCZ06CyauTxQIpOQpQBKI03/EPn8fI518pvOqxAO7
  XWaGsSovRyI3UPd963JZpYrEOcVDFPA2Qrz5eFj8MIBKH6HcQGnum0UFxmIRVaKT5K5WM+xeUeP5
  Xr4P54Jkyo18rz0LwzDp9gjj
) ; keytag 36463

  • Validación del registro A y la firma de nic.de

    • Todas las consultas nic.de/A a ns1.denic.de, ns2.denic.de, ns3.denic.de, ns4.denic.net respondieron con NOERROR
    • Las fuentes de respuesta por servidor de nombres fueron ns1.denic.de desde 77.67.63.106, ns2.denic.de desde 81.91.164.6, ns3.denic.de desde 195.243.137.27 y ns4.denic.net desde 194.246.96.28
    • En todas las consultas A, el valor del registro A de nic.de se confirmó como 81.91.170.12
    • Cada respuesta incluía un RRSIG firmado por la zona nic.de, y en el A RRset se confirmó 1 RRSIG
    • RRSIG=36463 junto con DNSKEY=36463 validan el A RRset
nic.de. 3600 IN A 81.91.170.12

nic.de. 3600 IN RRSIG (
  A 8 2 3600 20260519222346 20260505205346 36463 nic.de.
  VIyuPDO6Bf029ILioOvWPhkPmQctDIepz+bK/7s7GS1hHEIZrs/9pDGblfW19sjmVpJGIslYmiGh
  QUDTgJcv8lcWqrfUK3pTv9QxmYRDOMM/zTZz50hqfcNkvzL7dg/7A/yPoPk3aTMXH3pFNY0N2RnU
  t8THHOfUcu3w19fma4w=
)

  • Servidores de nombres autoritativos y respuesta SOA

    • Los servidores de nombres autoritativos de nic.de que aparecen en la respuesta son ns1.denic.de, ns2.denic.de, ns3.denic.de, ns4.denic.net
    • Se consultó nic.de/SOA a ns3.denic.de, ns4.denic.net y ns2.denic.de, y todos devolvieron respuestas de 507 bytes con NOERROR
    • El registro SOA muestra ns1.denic.de. como servidor de nombres principal y dns-operations.denic.de. como responsable
    • Los valores SOA son los mismos: serial 1778019826, refresh 10800, retry 1800, expire 3600000, minimum 1800
    • Las respuestas SOA también incluyen RRSIG, y el firmante se muestra como 36463 nic.de.
nic.de. 3600 IN SOA (
  ns1.denic.de. dns-operations.denic.de.
  1778019826 ;serial
  10800 ;refresh
  1800 ;retry
  3600000 ;expire
  1800 ;minimum
)

Lecturas relacionadas

1 comentarios

 
GN⁺ 1 시간 전
Comentarios de Hacker News

  • Parece un problema de DNSSEC, no una caída de los servidores de nombres. Los resolvers que validan están devolviendo SERVFAIL con EDE para todos los nombres .de
    dig +cd amazon.de @8.8.8.8 y dig amazon.de @a.nic.de sí funcionan, así que los datos de la zona parecen estar íntegros. DENIC distribuyó un RRSIG de un registro NSEC3 que no valida con la ZSK 33834, y por eso todos los resolvers que validan están rechazando las respuestas
    Que funcione de forma intermitente coincide con anycast. Algunas instancias de [a-n].nic.de todavía parecen estar sirviendo la firma anterior que sí era válida, así que en los reintentos a veces se llega a un servidor autoritativo sano. Según el FAQ de DENIC, la ZSK de .de rota cada 5 semanas con prepublicación, así que huele a falla en el rollover

    • Básicamente, un solo error de configuración en un lugar dejó sin accesibilidad externa a una gran economía. Pasó en la noche hora local y, aun considerando el TTL del caché, deberían poder arreglarlo para la mañana, así que el alcance del daño probablemente será algo limitado
      Aun así, una infraestructura frágil a este nivel es un riesgo político. La famosa propiedad de Internet de “rodear las partes dañadas” aquí no está funcionando muy bien. Seguro saldrá un análisis post mortem interesante
    • Llevo 20 años trabajando en IT y aquí no entiendo ni una sola sigla aparte de DNSSEC

  • Parece que el equipo de DENIC estaba en una fiesta esta noche. Qué bueno que se divirtieran, pero no deberían haberse pasado
    https://bsky.app/profile/denic.de/post/3ml4r2lvcjg2h

    • Interesante bus factor el de un escenario donde, en una emergencia, todas las personas con la capacidad, experiencia y confianza necesarias para hacer cambios operativos, revertir un mantenimiento arruinado o ejecutar un rollback no están completamente sobrias

  • Nunca he usado DNSSEC ni he intentado implementarlo, pero si entendí bien, ¿no es básicamente poner una jerarquía centralizada de certificados con punto único de falla encima del DNS, que originalmente era descentralizado? ¿Y ahora todos los dominios se rompen de facto a la vez por una falla en la organización central que administra esos certificados?

    • El dominio de nivel superior .de en esencia lo administra una sola organización, y aunque sus servidores de nombres se cayeran, la situación tampoco sería mucho mejor. Algunos registros quedarían cacheados en resolvers descendentes, pero no todos ni por mucho tiempo
      DNSSEC en realidad hace al DNS más descentralizado. Sin DNSSEC, para garantizar una respuesta confiable tendrías que preguntarle directamente al servidor autoritativo. Con DNSSEC, puedes consultar a un resolver con caché de terceros y confiar en él, porque solo las respuestas legítimas tendrán firmas válidas
      Del mismo modo, sin DNSSEC el dueño del dominio tiene que confiar ciegamente en los servidores de nombres autoritativos, porque esos servidores pueden falsificar fácilmente resultados aparentemente confiables. Con DNSSEC, puedes confiar mucho menos en los servidores autoritativos [0], así que es posible hospedar parte de eso de forma segura con terceros
      [0]: https://news.ycombinator.com/item?id=47409728
    • DNSSEC no cambia el grado de descentralización del DNS. DNS siempre fue una estructura jerárquica. Sin caché, toda consulta DNS empieza consultando a los servidores raíz
      En el caso de foo.com o foo.de, primero se consulta a los servidores raíz para averiguar qué servidores de nombres llevan .com y .de, y después se les pregunta a los servidores de .com o .de cuáles son los servidores de nombres de foo.com y foo.de. Lo único que hace DNSSEC es firmar esas respuestas y agregar claves públicas para poder autenticar la respuesta del siguiente paso
      La lista de IP de los servidores raíz ya viene incluida en todos los resolvers DNS recursivos locales. Esa lista cambia lentamente a lo largo de los años. Con DNSSEC, esa lista también incluye las claves públicas de los servidores raíz, y esas también se rotan lentamente
    • Lo que estamos viendo ahora es la descentralización funcionando. El problema está en el operador del dominio de nivel superior .de, así que solo ese TLD está afectado
      DNS no está descentralizado en el sentido de que la infraestructura de un mismo TLD la operen varias organizaciones. Un TLD siempre lo opera una sola entidad. .com y .net los opera Verisign
      Así que los problemas del operador no cambian el alcance del impacto

  • Cloudflare ahora está desactivando la validación DNSSEC en su resolver 1.1.1.1: https://www.cloudflarestatus.com/incidents/vjrk8c8w37lz

    • A estas alturas, parecería que DNSSEC ya murió
    • Si resulta que este problema de DNSSEC fue causado por un actor malicioso, quizá ese era precisamente el efecto secundario que buscaban

  • Dejo aquí el excelente texto de Thomas Ptacek sobre DNSSEC
    https://sockpuppet.org/blog/2015/01/15/against-dnssec/

  • Qué locura. Ni recuerdo si algo así había pasado antes, ¿y todavía no lo arreglan? .de probablemente sea el dominio no restringido más importante después de .com desde el punto de vista económico. Es como si millones de empresas estuvieran “caídas”

  • Sí, todos los dominios .de se cayeron por la falla de DNSSEC de DENIC
    https://dnsviz.net/d/de/dnssec/

  • Llegué demasiado temprano. Todavía no hay ni una sola diatriba sobre DNSSEC de tptacek en este hilo

    • ¿Qué necesidad habría de que yo hablara largo y tendido? A veces el mundo habla por uno
    • ¿No habla este incidente por sí solo?

  • No podía conectarme para nada a servicios y apps con mi dominio, y me estaba estresando muchísimo. Solo funcionaba con datos móviles, pero al menos esta vez no fue culpa mía

    • Aun así, somos alemanes, así que necesitamos a alguien a quien culpar

  • En https://status.denic.de/ el DNS Nameservice ahora figura como “Partial Service Disruption”
    Edit: ahora cambió a “Service Disruption”

    • Qué curioso que incluso si se caen todos los sitios de la tercera economía del mundo, siga siendo una interrupción “parcial” del servicio :D
    • Toda Alemania está offline y DENIC dice “Partial Service Disruption”. Tienen una forma muy particular de expresarlo
    • Ahora aparece “Server Not Found”
    • “All Systems Operational”