ハクソク

世界を動かす技術を、日本語で。

.de TLDがDNSSECの影響でオフライン？

3時間前原文(dnssec-analyzer.verisignlabs.com)

概要

  • nic.deドメインのDNSSEC検証結果の要約
  • DSレコードやRRSIGの検証状況
  • 一部ネームサーバーへの接続失敗
  • DS RRset署名検証の失敗
  • 追加調査や二次診断の提案

nic.deのDNSSEC問題解析結果

  • deゾーンにて、1件のDSレコード（DS=26755/SHA-256, アルゴリズムRSASHA256）を検出
  • DS RRset上に1件のRRSIG（RRSIG=54393）を検出し、DNSKEY=54393でDS RRsetの検証に成功
  • a.nic.de、l.de.netホスト名の解決に失敗
  • deゾーンのDNSKEYレコードを3件検出
    • DS=26755/SHA-256がDNSKEY=26755/SEPの検証に成功
    • DNSKEY RRset上のRRSIG=26755とDNSKEY=26755/SEPでDNSKEY RRsetの検証に成功
  • z.nic.de、f.nic.deホスト名の解決に失敗

nic.deゾーンの詳細

  • deゾーン内でnic.deの1件のDSレコード（DS=26155/SHA-256, アルゴリズムRSASHA256）を検出
  • DS RRset上に1件のRRSIG（RRSIG=33834）を検出
    • DNSKEY=33834によるDS RRsetの署名検証が失敗
    • DS RRsetが信頼済み鍵で署名されていない
  • ns2.denic.de、ns3.denic.de、ns1.denic.de、ns4.denic.netホスト名の解決に失敗
  • nic.deゾーンのDNSKEY RRset取得に失敗
    • nic.deネームサーバーから応答なし

推奨対応・追加調査

  • 各ネームサーバー（特にnic.de関連）の到達性確認
  • DS RRset署名検証失敗の原因調査（DNSKEYやRRSIGの不整合確認）
  • dnsviz.netなどの外部ツールによる二次診断実施
  • DNSSEC設定の再確認と信頼チェーンの修復

DNSSEC検証フローのポイント

  • DSレコード：親ゾーンに登録された子ゾーンの署名検証用情報
  • RRSIGレコード：リソースレコードセットに対する署名情報
  • DNSKEYレコード：ゾーン署名に用いる公開鍵情報
  • 信頼チェーン：ルートから各ゾーンまで正しく署名が連鎖しているか確認

参考リンク

  • dnsviz.net：DNSSEC診断用外部サービス
  • Verisign Labs Tools：DNSSEC関連ツール提供元

Hackerたちの意見

DNSSECの問題みたいだね、ネームサーバーのダウンじゃない。検証するリゾルバが、EDEでRRSIGの不正な署名を見つけて、すべての.deドメインでSERVFAIL出してる。a0d5d1p51kijsevll74k523htmq406bk.de/nsec3（keytag=33834）に対して、dig +cd amazon.de @8.8.8.8は動くし、dig amazon.de @a.nic.deも動く。ゾーンデータは無事なんだけど、DENICが検証できないNSEC3レコードに対してRRSIGを公開しちゃったから、すべての検証リゾルバが応答を拒否してる。断続的な問題はanycastに合ってるね。一部の[a-n].nic.deインスタンスは前の（正常な）署名をまだ提供してるから、リトライすると時々健康な認証に当たる。DENICのFAQによると、.deのZSKは5週間ごとに事前公開でローテーションするから、これはロールオーバーの失敗っぽい。
└
たった一つの設定ミスで、主要な経済圏の外部アクセスが消えちゃったんだよね。現地時間の夕方に起こったみたいで、キャッシュのTTLを除けば朝には修正できるはず。これで影響範囲は少し狭まるけど、やっぱりこのレベルだと脆弱なインフラは政治的リスクになるよね。インターネットの「障害を回避する」という有名な言葉も、ここではあまり機能してないみたい。面白い事後分析になりそう。
└
IT業界で20年働いてるのに、ここで出てくる略語はDNSSEC以外全然わからないっていうのが面白い。
はい、すべての.deドメインがDenicのDNSSECの失敗でダウンしてるよ。https://dnsviz.net/d/de/dnssec/
└
https://i.imgur.com/eAwdKEC.png 編集: 代替リンク: https://www.cyberciti.biz/media/new/cms/2017/04/dns.jpg
俺、unboundとpiholeのデバッグに30分以上かけちゃったよ。自分の問題だと思ってたからさ…でもいいニュースがある！unboundの設定にdomain-insecure: "de"を追加すれば、すべてうまくいくよ。
└
同じく笑
└
同じすぎる！！！
└
- https://technologychecker.io/blog/dnssec-adoption
サービスやアプリに全然接続できなくて、めっちゃストレス溜まってた…携帯のデータ使うとだけ動くの？…今回は自分のせいじゃなくてよかった。
└
でも俺たちはドイツ人だから、誰かを責める必要があるんだよね。
俺は早すぎたのかな。このスレにはまだtptacekのDNSSECに関する愚痴が一つもないね。
└
彼はMathAcademyでXP-SECを稼ぐのに忙しいんだ。
└
もしかしたら彼は死にかけてるのかも。
└
この出来事は自明じゃない？
すごいな。こんなことが起こったのは記憶にないし、まだ修正されてないの？ .deは経済的観点から見ても、.comの次に重要な制限なしドメインだよ。何百万ものビジネスが「ダウン」してる。
└
ドイツだから、悲観的な時間見積もりに1/3足せば、問題が解決する現実的な時間枠になるよ。
└
.comがダウンした時のことを思い出すな、1997年7月に。 https://archive.nytimes.com/www.nytimes.com/library/cyber/we...
└
DENICは2010年にすべての.deドメインをNXDOMAINにしたらしいよ: https://www.theregister.com/2010/05/12/germany_top_level_dom...
DNSSECは使ったことないし、実装するのも面倒だったけど、理解してるつもりなのは、分散型プラットフォームだったDNSの上に、単一障害点の証明書レイヤーを追加しちゃって、それが今、証明書を管理してる中央組織がダウンして、ほぼすべてのドメインが影響を受けてるってことだよね？
└
ここで見えるのは、分散化が機能してるってこと。問題は.de TLDの運営者にあって、そのために影響を受けるのはそのTLDだけ。DNSは、複数の組織がTLDのインフラを運営するようには分散されてなくて、常に一つのエンティティが運営してるんだよね。（.comや.netはVerisignが運営してる）だから、運営者が抱える問題は、影響を変えないんだよ。
彼らは（かなり長い）TLDのDNSSEC障害のリストに加わることになるね: https://ianix.com/pub/dnssec-outages.html
どうやらDENICチームは今晩パーティーをしてたみたい！楽しむのはいいけど、やりすぎないでね。https://bsky.app/profile/denic.de/post/3ml4r2lvcjg2h
└
見た中で本当にパーティーをぶち壊すやつだね。
Denicは「主要なDNSSEC障害と検証失敗」のリストに追加されることになるよ: https://ianix.com/pub/dnssec-outages.html