O TLD .de está offline por causa do DNSSEC?

 (dnssec-analyzer.verisignlabs.com)
1 pontos por GN⁺ 1 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O resultado do DNSSEC Debugger de nic.de é de 2026-05-06 00:38:26 UTC e valida passo a passo a cadeia de confiança do root até .de e então até nic.de
  • A zona root inclui DS=20326/SHA-256 e DS=38696/SHA-256, e o DS da delegação de .de, keytag 26755, é validado pela assinatura do DNSKEY=54393 da root
  • A zona .de inclui DNSKEY=26755/SEP e DNSKEY=32911, e DS=26755/SHA-256 valida o DNSKEY RRset de .de
  • A delegação de nic.de inclui os nameservers ns1.denic.de, ns2.denic.de, ns3.denic.de, ns4.denic.net, e DS=26155/SHA-256 é validado pelo DNSKEY=32911 de .de
  • O registro A de nic.de é confirmado como 81.91.170.12 em consultas a todos os nameservers autoritativos, e RRSIG=36463 e DNSKEY=36463 validam esse RRset

Fluxo de validação DNSSEC de nic.de

  • O alvo da verificação é nic.de, e a tela do DNSSEC Debugger mostra as opções de controle more(+) e less(-) em Detail
  • O horário exibido é 2026-05-06 00:38:26 UTC
  • O status DNSSEC de nic.de também pode ser testado em dnsviz.net

Cadeia de confiança da root até .de

  • Validação do DNSKEY da zona root

    • A DS=20326/SHA-256 e a DS=38696/SHA-256 da root(.) fazem parte da cadeia de confiança
    • Foi feita uma consulta ./DNSKEY ao j.root-servers.net, recebendo uma resposta de 1139 bytes de 192.58.128.30, com código de resposta NOERROR
    • Foram confirmados 3 registros DNSKEY na zona root
      • DNSKEY keytag 54393, flags 256, algoritmo 8
      • DNSKEY keytag 20326, flags 257, algoritmo 8
      • DNSKEY keytag 38696, flags 257, algoritmo 8
    • DNSKEY=20326/SEP e DNSKEY=38696/SEP foram incluídos na cadeia de confiança e validados respectivamente por DS=20326/SHA-256 e DS=38696/SHA-256
    • O DNSKEY RRset da root tem 1 RRSIG, e RRSIG=20326 e DNSKEY=20326/SEP validam esse DNSKEY RRset
    • DNSKEY=54393 também faz parte da cadeia de confiança

  • Verificação da delegação de .de a partir da root

    • Foi feita uma consulta nic.de/A ao k.root-servers.net, recebendo uma resposta de 742 bytes de 193.0.14.129; a seção de resposta estava vazia e a seção de autoridade continha a informação de delegação de .de
    • Foram retornados como nameservers de .de a.nic.de, f.nic.de, l.de.net, n.de.net, s.de.net, z.nic.de
    • O registro DS de .de foi retornado com keytag 26755, algoritmo 8, digest type 2 e digest SHA-256 f341357809a5954311ccb82ade114c6c1d724a75c0395137aa3978035425e78d
    • O RRset DS de .de incluía RRSIG, e o signatário é o DNSKEY=54393 da root
    • A seção adicional incluía endereços IPv4/IPv6 dos nameservers 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

  • Validação do RRset DS de .de

    • Foi feita uma consulta de/DS ao b.root-servers.net, recebendo uma resposta de 366 bytes de 170.247.170.2, com código de resposta NOERROR
    • Foi confirmado 1 registro DS para .de na zona root
    • DS=26755/SHA-256 usa o algoritmo RSASHA256
    • O RRset DS de .de tem 1 RRSIG, e RRSIG=54393 e DNSKEY=54393 validam esse RRset DS
    • DS=26755/SHA-256 foi incluído na cadeia de confiança

  • Validação do RRset DNSKEY de .de

    • Foi feita uma consulta de/DNSKEY ao f.nic.de, recebendo uma resposta de 745 bytes de 81.91.164.5, com código de resposta NOERROR
    • Foram confirmados 2 registros DNSKEY em .de
      • DNSKEY keytag 32911, flags 256, algoritmo 8, TTL 3600
      • DNSKEY keytag 26755, flags 257, algoritmo 8, TTL 3600
    • DNSKEY=26755/SEP foi incluído na cadeia de confiança, e DS=26755/SHA-256 valida DNSKEY=26755/SEP
    • O DNSKEY RRset de .de tem 1 RRSIG, e RRSIG=26755 e DNSKEY=26755/SEP validam esse RRset
    • DNSKEY=32911 foi incluído na cadeia de confiança

Delegação e validação de DS de .de até nic.de

  • Verificação da subzona nic.de

    • Foi feita uma consulta nic.de/A ao l.de.net, recebendo uma resposta de 464 bytes de 77.67.63.105; a seção de resposta estava vazia e a informação de delegação de nic.de estava na seção de autoridade
    • Foram retornados como nameservers de nic.de ns1.denic.de, ns2.denic.de, ns3.denic.de, ns4.denic.net
    • O registro DS de nic.de foi retornado com keytag 26155, algoritmo 8, digest type 2 e digest SHA-256 2f06c8cdf8673a2e98d72c8b7ab6067d9318458b3d9edccde1c5ef793c0c565d
    • O RRset DS de nic.de incluía RRSIG, e o signatário é o DNSKEY=32911 de .de
    • A seção adicional incluía alguns endereços dos nameservers 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
    • Ao consultar nic.de/DNSKEY em l.de.net, foram retornadas a mesma delegação de nic.de, o mesmo DS, RRSIG e as mesmas informações adicionais de endereço, confirmando a subzona nic.de

  • Validação do RRset DS de nic.de

    • Foi feita uma consulta nic.de/DS ao a.nic.de, recebendo uma resposta de 245 bytes de 194.0.0.53, com código de resposta NOERROR
    • Foi confirmado 1 registro DS para nic.de na zona de
    • O DS confirmado tem keytag 26155, algoritmo 8, digest type 2, e é exibido como baseado em SHA-256
    • O DS RRset tem 1 RRSIG, e RRSIG=32911 e DNSKEY=32911 validam esse DS RRset
    • DS=26155/SHA-256 foi incluído na cadeia de confiança
nic.de. 86400 IN DS (
  26155 8 2 2f06c8cdf8673a2e98d72c8b7ab6067d9318458b3d9edccde1c5ef793c0c565d
)

Validação de DNSKEY e registros de nic.de

  • Validação do DNSKEY de nic.de

    • Foi feita uma consulta nic.de/DNSKEY ao ns4.denic.net, recebendo uma resposta de 625 bytes de 194.246.96.28, com código de resposta NOERROR
    • Foram confirmados 2 registros DNSKEY em nic.de
    • keytag 26155 é um DNSKEY no formato 257 3 8, e DNSKEY=26155/SEP foi incluído na cadeia de confiança
    • DS=26155/SHA-256 valida DNSKEY=26155/SEP
    • O DNSKEY RRset tem 1 RRSIG, e RRSIG=26155 e DNSKEY=26155/SEP validam o DNSKEY RRset
    • DNSKEY=36463 também foi incluído na cadeia de confiança
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

  • Validação do registro A e da assinatura de nic.de

    • Todas as consultas nic.de/A para ns1.denic.de, ns2.denic.de, ns3.denic.de e ns4.denic.net responderam com NOERROR
    • As origens das respostas por nameserver foram 77.67.63.106 para ns1.denic.de, 81.91.164.6 para ns2.denic.de, 195.243.137.27 para ns3.denic.de e 194.246.96.28 para ns4.denic.net
    • Em todas as consultas A, o valor do registro A de nic.de foi confirmado como 81.91.170.12
    • Cada resposta inclui um RRSIG assinado pela zona nic.de, e foi confirmado 1 RRSIG no A RRset
    • RRSIG=36463 e DNSKEY=36463 validam o 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=
)

  • Nameservers autoritativos e resposta SOA

    • Os nameservers autoritativos de nic.de incluídos na resposta são ns1.denic.de, ns2.denic.de, ns3.denic.de, ns4.denic.net
    • Foram feitas consultas nic.de/SOA a ns3.denic.de, ns4.denic.net e ns2.denic.de, e todas retornaram respostas de 507 bytes com NOERROR
    • O registro SOA mostra ns1.denic.de. como nameserver primário e dns-operations.denic.de. como responsável
    • Os valores do SOA são os mesmos: serial 1778019826, refresh 10800, retry 1800, expire 3600000, minimum 1800
    • A resposta SOA também inclui RRSIG, e o signatário é exibido 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
)

Leituras relacionadas

1 comentários

 
GN⁺ 1 시간 전
Comentários no Hacker News

  • Parece ser um problema de DNSSEC, não uma falha dos servidores de nomes. Resolvers que validam estão retornando SERVFAIL com EDE para todos os nomes .de
    dig +cd amazon.de @8.8.8.8 e dig amazon.de @a.nic.de funcionam, então os dados da zona parecem íntegros. A DENIC distribuiu uma RRSIG de registro NSEC3 que não valida com a ZSK 33834, e por isso todos os resolvers validadores estão recusando as respostas
    O fato de funcionar de forma intermitente bate com anycast. Algumas instâncias de [a-n].nic.de aparentemente ainda estão servindo a assinatura anterior correta, então nas tentativas de novo às vezes se alcança um servidor autoritativo saudável. Segundo o FAQ da DENIC, a ZSK de .de é rotacionada a cada 5 semanas com pré-publicação, então isso tem cheiro de falha no rollover

    • Um único erro de configuração em um lugar acabou derrubando a acessibilidade externa de uma grande potência econômica. Aconteceu à noite no horário local e, mesmo considerando o TTL do cache, devem conseguir corrigir até de manhã, então o alcance do dano provavelmente fica um pouco limitado
      Ainda assim, uma infraestrutura frágil nesse nível é um risco político. A famosa característica da internet de “contornar os pontos danificados” não está funcionando muito bem aqui. Parece que vai render uma análise pós-incidente interessante
    • Trabalho com TI há 20 anos e, tirando DNSSEC, não consigo entender nenhuma das siglas daqui

  • Parece que a equipe da DENIC estava numa festa hoje à noite. Tudo bem se divertir, mas não precisava exagerar
    https://bsky.app/profile/denic.de/post/3ml4r2lvcjg2h

    • Interessante esse bus factor em que, numa emergência, as pessoas com qualificação, experiência e confiança suficientes para fazer commit de mudanças operacionais, reverter uma manutenção malfeita ou executar um rollback estão todas longe de estar completamente sóbrias

  • Nunca usei DNSSEC nem tentei implementar, mas, se entendi direito, isso não é basicamente colocar uma camada centralizada de certificados com ponto único de falha em cima do DNS, que era descentralizado? E agora, por causa de uma falha na organização central que administra esses certificados, praticamente todos os domínios quebram juntos?

    • O domínio de topo .de já é, por natureza, administrado por uma única organização, e se os servidores de nomes dela caírem a situação não fica muito melhor. Alguns registros ficariam em cache nos resolvedores descendentes, mas não todos, e não por muito tempo
      Na verdade, o DNSSEC torna o DNS mais descentralizado. Sem DNSSEC, para garantir uma resposta confiável você teria que consultar diretamente os servidores de nomes autoritativos. Com DNSSEC, você pode consultar um resolvedor de cache de terceiros e ainda confiar na resposta, porque só respostas legítimas terão assinaturas válidas
      Da mesma forma, sem DNSSEC o dono do domínio precisa confiar completamente nos servidores de nomes autoritativos, porque eles conseguem forjar facilmente resultados que pareçam confiáveis. Com DNSSEC, você precisa confiar muito menos nos servidores autoritativos [0], então parte disso pode ser hospedada com segurança por terceiros
      [0]: https://news.ycombinator.com/item?id=47409728
    • DNSSEC não muda o grau de descentralização do DNS. O DNS sempre foi hierárquico. Sem cache, toda consulta DNS começa com uma consulta aos servidores DNS raiz
      No caso de foo.com ou foo.de, primeiro você consulta um servidor raiz para descobrir quais servidores de nomes respondem por .com e .de, e depois pergunta aos servidores de .com ou .de quais são os servidores de nomes de foo.com e foo.de. O que o DNSSEC faz é apenas assinar essas respostas e adicionar as chaves públicas necessárias para autenticar as respostas da etapa seguinte
      A lista de IPs dos servidores raiz já vem incluída em todos os resolvers DNS recursivos locais. Essa lista muda lentamente ao longo dos anos. No DNSSEC, essa lista também inclui as chaves públicas dos servidores raiz, que também são trocadas lentamente
    • O que estamos vendo agora é a descentralização funcionando. O problema está no operador do domínio de topo .de, então só esse domínio de topo é afetado
      O DNS não é descentralizado no sentido de que a infraestrutura de um domínio de topo seja operada por várias organizações. Um domínio de topo é sempre operado por uma única entidade. .com e .net são operados pela Verisign
      Então um problema no operador não muda o escopo do impacto

  • A Cloudflare agora desativou a validação DNSSEC no resolvedor 1.1.1.1: https://www.cloudflarestatus.com/incidents/vjrk8c8w37lz

    • A essa altura, dá para considerar que o DNSSEC acabou
    • Se ficar claro que o problema de DNSSEC foi causado por um agente malicioso, talvez esse fosse exatamente o efeito secundário buscado

  • Deixo aqui o excelente texto do Thomas Ptacek sobre DNSSEC
    https://sockpuppet.org/blog/2015/01/15/against-dnssec/

  • Insano. Nem lembro se já houve algo assim antes, e ainda não consertaram? Do ponto de vista econômico, .de deve ser o domínio irrestrito mais importante depois de .com. Milhões de empresas ficaram “fora do ar”

  • Sim, todos os domínios .de caíram por causa da falha de DNSSEC da DENIC
    https://dnsviz.net/d/de/dnssec/

  • Acho que cheguei cedo demais. Ainda não apareceu nenhum textão sobre DNSSEC do tptacek nesta thread

    • O que eu precisaria discursar longamente? Às vezes o mundo fala por você
    • Este incidente em si já não diz tudo?

  • Eu estava muito estressado porque nada conseguia se conectar aos serviços e apps no meu domínio. Só funcionava usando os dados móveis do celular, mas pelo menos desta vez a culpa não era minha

    • Ainda assim, somos alemães e precisamos de alguém para culpar

  • Em https://status.denic.de/ o DNS Nameservice agora aparece como “Partial Service Disruption”
    Edit: agora mudou para “Service Disruption”

    • Mesmo com todos os sites da 3ª maior economia do mundo fora do ar, ainda é uma interrupção “parcial” :D
    • A Alemanha inteira está offline e a DENIC chama isso de “Partial Service Disruption”. É uma escolha de palavras curiosa
    • Agora aparece “Server Not Found”
    • “All Systems Operational”