.de TLDはDNSSECのせいでオフラインなのか？

 (dnssec-analyzer.verisignlabs.com)
1 ポイント 投稿者 GN⁺ 1 시간 전 | 1件のコメント | WhatsAppで共有
  • nic.de DNSSEC Debuggerの結果は2026-05-06 00:38:26 UTC時点のもので、ルートから.deを経てnic.deに至る信頼チェーンを段階的に検証している
  • ルートゾーンにはDS=20326/SHA-256とDS=38696/SHA-256が含まれ、.de委任のDS keytag 26755はルートのDNSKEY=54393署名で検証される
  • .deゾーンにはDNSKEY=26755/SEPとDNSKEY=32911が含まれ、DS=26755/SHA-256が.deのDNSKEY RRsetを検証する
  • nic.de委任にはネームサーバーns1.denic.de、ns2.denic.de、ns3.denic.de、ns4.denic.netが含まれ、DS=26155/SHA-256が.deのDNSKEY=32911で検証される
  • nic.deのAレコードはすべての権威ネームサーバー問い合わせで81.91.170.12と確認され、RRSIG=36463とDNSKEY=36463がそのRRsetを検証する

nic.de DNSSEC検証フロー

  • 検査対象はnic.deで、DNSSEC Debugger画面にはDetail調整項目としてmore(+)とless(-)が表示される
  • 表示時刻は2026-05-06 00:38:26 UTC
  • nic.deのDNSSEC状態はdnsviz.netでもテストできる

ルートから.deまでの信頼チェーン

  • ルートゾーン DNSKEYの検証

    • ルート(.)のDS=20326/SHA-256とDS=38696/SHA-256が信頼チェーンに含まれる
    • j.root-servers.netに./DNSKEYを問い合わせ、192.58.128.30から1139バイトの応答を受け取り、応答コードはNOERRORだった
    • ルートゾーンでDNSKEYレコード3件が確認された
      • DNSKEY keytag 54393、フラグ256、アルゴリズム8
      • DNSKEY keytag 20326、フラグ257、アルゴリズム8
      • DNSKEY keytag 38696、フラグ257、アルゴリズム8
    • DNSKEY=20326/SEPとDNSKEY=38696/SEPが信頼チェーンに含まれ、それぞれDS=20326/SHA-256、DS=38696/SHA-256で検証される
    • ルートDNSKEY RRsetにはRRSIGが1件あり、RRSIG=20326とDNSKEY=20326/SEPがそのDNSKEY RRsetを検証する
    • DNSKEY=54393も信頼チェーンに含まれる

  • ルートから.de委任の確認

    • k.root-servers.netにnic.de/Aを問い合わせ、193.0.14.129から742バイトの応答を受け取り、回答セクションは空で、権威セクションに.de委任情報が含まれていた
    • .deのネームサーバーとしてa.nic.de、f.nic.de、l.de.net、n.de.net、s.de.net、z.nic.deが返された
    • .deのDSレコードはkeytag 26755、アルゴリズム8、digest type 2、SHA-256 digest f341357809a5954311ccb82ade114c6c1d724a75c0395137aa3978035425e78dとして返された
    • .de DS RRsetにはRRSIGが含まれ、署名者はルートのDNSKEY=54393
    • 追加セクションには.deネームサーバーのIPv4/IPv6アドレスが含まれる
      • 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

  • .de DS RRsetの検証

    • b.root-servers.netにde/DSを問い合わせ、170.247.170.2から366バイトの応答を受け取り、応答コードはNOERRORだった
    • ルートゾーンで.deに対するDSレコード1件が確認された
    • DS=26755/SHA-256はRSASHA256アルゴリズムを使用する
    • .de DS RRsetにはRRSIGが1件あり、RRSIG=54393とDNSKEY=54393がそのDS RRsetを検証する
    • DS=26755/SHA-256が信頼チェーンに含まれる

  • .de DNSKEY RRsetの検証

    • f.nic.deにde/DNSKEYを問い合わせ、81.91.164.5から745バイトの応答を受け取り、応答コードはNOERRORだった
    • .deでDNSKEYレコード2件が確認された
      • DNSKEY keytag 32911、フラグ256、アルゴリズム8、TTL 3600
      • DNSKEY keytag 26755、フラグ257、アルゴリズム8、TTL 3600
    • DNSKEY=26755/SEPが信頼チェーンに含まれ、DS=26755/SHA-256がDNSKEY=26755/SEPを検証する
    • .deのDNSKEY RRsetにはRRSIGが1件あり、RRSIG=26755とDNSKEY=26755/SEPがそのRRsetを検証する
    • DNSKEY=32911が信頼チェーンに含まれる

.deからnic.deへ続く委任とDS検証

  • nic.de下位ゾーンの確認

    • l.de.netにnic.de/Aを問い合わせ、77.67.63.105から464バイトの応答を受け取り、回答セクションは空で、nic.de委任情報が権威セクションに含まれていた
    • nic.deのネームサーバーとしてns1.denic.de、ns2.denic.de、ns3.denic.de、ns4.denic.netが返された
    • nic.de DSレコードはkeytag 26155、アルゴリズム8、digest type 2、SHA-256 digest 2f06c8cdf8673a2e98d72c8b7ab6067d9318458b3d9edccde1c5ef793c0c565dとして返された
    • nic.de DS RRsetにはRRSIGが含まれ、署名者は.deのDNSKEY=32911
    • 追加セクションには一部の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
    • l.de.netにnic.de/DNSKEYを問い合わせた場合も、同じnic.de委任、DS、RRSIG、追加アドレス情報が返され、下位ゾーンnic.deが確認された

  • nic.de DS RRsetの検証

    • a.nic.deにnic.de/DSを問い合わせ、194.0.0.53から245バイトの応答を受け取り、応答コードはNOERRORだった
    • deゾーンでnic.deに対するDSレコード1件が確認された
    • 確認されたDSはkeytag 26155、アルゴリズム8、digest type 2で、SHA-256ベースとして表示される
    • DS RRsetにはRRSIGが1件あり、RRSIG=32911とDNSKEY=32911がDS RRsetを検証する
    • DS=26155/SHA-256が信頼チェーンに含まれる
nic.de. 86400 IN DS (
  26155 8 2 2f06c8cdf8673a2e98d72c8b7ab6067d9318458b3d9edccde1c5ef793c0c565d
)

nic.de DNSKEYとレコードの検証

  • nic.de DNSKEYの検証

    • ns4.denic.netにnic.de/DNSKEYを問い合わせ、194.246.96.28から625バイトの応答を受け取り、応答コードはNOERRORだった
    • nic.deでDNSKEYレコード2件が確認された
    • keytag 26155は257 3 8形式のDNSKEYで、DNSKEY=26155/SEPが信頼チェーンに含まれる
    • DS=26155/SHA-256がDNSKEY=26155/SEPを検証する
    • DNSKEY RRsetにはRRSIGが1件あり、RRSIG=26155とDNSKEY=26155/SEPがDNSKEY RRsetを検証する
    • DNSKEY=36463も信頼チェーンに含まれる
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

  • nic.de Aレコードと署名の検証

    • ns1.denic.de、ns2.denic.de、ns3.denic.de、ns4.denic.netへのnic.de/A問い合わせはすべてNOERRORで応答した
    • ネームサーバーごとの応答元は、ns1.denic.deが77.67.63.106、ns2.denic.deが81.91.164.6、ns3.denic.deが195.243.137.27、ns4.denic.netが194.246.96.28
    • すべてのA問い合わせで、nic.deのAレコード値は81.91.170.12と確認された
    • 各応答にはnic.deゾーンが署名したRRSIGが含まれ、A RRsetにはRRSIGが1件確認された
    • RRSIG=36463とDNSKEY=36463が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=
)

  • 権威ネームサーバーとSOA応答

    • nic.deの権威ネームサーバーとしてns1.denic.de、ns2.denic.de、ns3.denic.de、ns4.denic.netが応答に含まれる
    • ns3.denic.de、ns4.denic.net、ns2.denic.deにnic.de/SOAを問い合わせ、いずれも507バイトの応答とNOERRORを返した
    • SOAレコードは主ネームサーバーをns1.denic.de.、担当者をdns-operations.denic.de.として示す
    • SOA値はserial 1778019826、refresh 10800、retry 1800、expire 3600000、minimum 1800で同一
    • SOA応答にもRRSIGが含まれ、署名者は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
)

関連記事

1件のコメント

 
GN⁺ 1 시간 전
Hacker Newsのコメント

  • DNSSECの問題のようで、ネームサーバー障害ではなさそう。検証を行うリゾルバが、すべての .de 名に対して EDE 付きで SERVFAIL を返している
    dig +cd amazon.de @8.8.8.8 と dig amazon.de @a.nic.de は動作するので、ゾーンデータ自体は無傷に見える。DENIC が ZSK 33834 で検証できない NSEC3レコードのRRSIG を配布してしまい、そのためすべての検証リゾルバが応答を拒否している状況
    断続的に動くのは anycast と整合する。一部の [a-n].nic.de インスタンスがまだ以前の正常な署名を返しており、再試行時にたまに正常な権威サーバーへ当たっているようだ。DENIC の FAQ によれば .de の ZSK は 5 週間ごとに事前公開方式でローテーションされるため、ロールオーバー失敗 の匂いがする

    • 1か所の設定ミスひとつで主要経済圏の対外的な到達性が吹き飛んだわけだ。現地時間の夕方に発生しており、キャッシュ TTL を考えても朝までには直せるだろうから、被害範囲はある程度限定されそう
      それでもこのレベルの 脆弱なインフラ は政治的リスクだ。インターネットが「壊れた場所を迂回する」という有名な性質は、ここではあまり機能していない。興味深い事後分析が出てきそう
    • IT の仕事を 20 年やってきたけど、ここで DNSSEC 以外の略語がひとつも分からない

  • DENIC チームは今夜パーティーに出ていたようだ。楽しく過ごすのはいいが、羽目を外しすぎるべきではなかった
    https://bsky.app/profile/denic.de/post/3ml4r2lvcjg2h

    • 緊急時に運用変更をコミットしたり、失敗したメンテナンスを戻したり、ロールバックしたりするだけの資格・経験・信頼を持つ人たちが、全員そろって完全に素面ではないというシナリオは、なかなか興味深い バスファクター だ

  • DNSSEC を使ったことも実装しようと苦労したこともないけれど、理解が合っているなら、本来は分散している DNS の上に 単一障害点の証明書階層 を載せたようなものではないのか。今やその証明書を管理する中央組織の障害で、事実上すべてのドメインがまとめて壊れる状況になっているのか？

    • .de トップレベルドメインは本質的に単一の組織が管理しており、そのネームサーバーが落ちても状況は大して良くならない。一部のレコードは下位のリゾルバにキャッシュされるだろうが、全部ではないし長くも続かない
      DNSSEC はむしろ DNS をより分散化する。DNSSEC がなければ、信頼できる応答を保証するには権威ネームサーバーに直接問い合わせる必要がある。DNSSEC があれば、第三者のキャッシュリゾルバに問い合わせても、正当な応答だけが有効な署名を持つので信頼できる
      同様に DNSSEC がなければ、ドメイン所有者は権威ネームサーバーを絶対的に信頼しなければならない。なぜならそのサーバーは信頼された結果を簡単に偽装できるからだ。DNSSEC があれば権威ネームサーバーをはるかに信頼しなくて済むので [0]、一部を第三者に安全にホスティングさせることもできる
      [0]: https://news.ycombinator.com/item?id=47409728
    • DNSSEC は DNS の分散性の度合いを変えるものではない。DNS はもともと 階層構造 だった。キャッシュがなければ、すべての DNS クエリはルート DNS サーバーへの問い合わせから始まる
      foo.com や foo.de の場合、まずルートサーバーに問い合わせて .com と .de を担当するネームサーバーを把握し、その次に .com または .de サーバーに foo.com と foo.de のネームサーバーを尋ねる。DNSSEC がやるのは、これらの応答に署名を付け、次の段階の応答を認証できるよう公開鍵を追加することだけだ
      ルートネームサーバーの IP 一覧は、すべてのローカル再帰 DNS リゾルバに含まれている。この一覧は何年もかけてゆっくり変わる。DNSSEC ではこの一覧にルートサーバーの公開鍵も含まれ、これもゆっくりローテーションされる
    • いま見えているのは 分散化が機能している様子 だ。問題は .de トップレベルドメインの運用者にあり、したがって影響を受けているのもそのトップレベルドメインだけだ
      DNS は、ひとつのトップレベルドメインのインフラを複数組織で運営する形には分散化されていない。トップレベルドメインは常に単一主体が運営する。.com と .net は Verisign が運営している
      だから運用者に問題が起きても、影響範囲そのものが変わるわけではない

  • Cloudflare が 1.1.1.1 リゾルバで DNSSEC 検証を無効化 した: https://www.cloudflarestatus.com/incidents/vjrk8c8w37lz

    • ここまで来ると DNSSEC は終わったと言ってよさそう
    • DNSSEC の問題が脅威アクターによるものだと判明したら、こうした 下流への影響 を狙ったものかもしれない

  • Thomas Ptacek による DNSSEC の名文をここに置いておく
    https://sockpuppet.org/blog/2015/01/15/against-dnssec/

  • とんでもない話だ。こういう事故が以前あったかどうかも思い出せないし、まだ直っていないのか？ .de は経済的観点では .com に次いで重要な 制限なしドメイン である可能性が高い。何百万もの企業が「ダウン」したも同然だ

  • その通り、DENIC の DNSSEC 障害のため、すべての .de ドメインがダウンしている
    https://dnsviz.net/d/de/dnssec/

  • 来るのが早すぎたようだ。まだこのスレッドには tptacek の DNSSEC 長広舌 がひとつもない

    • 私が長々と語る必要があるだろうか？ たまには世界が代わりに語ってくれる
    • この出来事そのものがすでに物語っているのでは？

  • 自分のドメイン経由でサービスやアプリにまったく接続できなくて、ものすごくストレスを感じていた。携帯回線では動いていたが、今回は自分のせいではないと分かって安心した

    • とはいえ、私たちはドイツ人なので責める相手は必要だ

  • https://status.denic.de/ では DNS Nameservice が現在「Partial Service Disruption」と表示されている
    修正: いまは「Service Disruption」に変わった

    • 世界第3位の経済圏のすべてのサイトが落ちても、なお「部分的」サービス障害なのか :D
    • ドイツ全体がオフラインなのに DENIC は「Partial Service Disruption」と言っている。なかなか独特な表現だ
    • いまは「Server Not Found」と出る
    • 「All Systems Operational」