「責任を負わなくて済むことに感謝する事柄」リストへの新たな記録

2026年7月3日、アルバニアの通信当局（AKEP）は、アルバニアの国コードトップレベルドメイン（TLD）である.alのDNSSECキーロールオーバーを試みました。しかし、何かがうまくいかず、DNSSEC検証の失敗を引き起こしました。これらの署名を受信した検証DNSリゾルバは、DNSSEC仕様により、それらを拒否し、クライアントにエラーを返す必要がありました。これにはCloudflareが運営するパブリックDNSリゾルバである1.1.1.1も含まれます。 .al TLDは、アルバニア政府サービス、銀行、メディアのオンラインホームであり、Cloudflare RadarのTLDランキングで191位にランクされています。検証リゾルバを使用していたこれらのサイトを訪問しようとした人は誰でも、インシデント中にアクセス不能になったことに気づきました。この障害は、ホストされている場所や権威ネームサーバが提供しているかに関わらず、すべての.alドメインに影響を与える可能性がありました。 わずか2ヶ月前、同様のインシデントがドイツのTLDである.deを襲いました。インシデントに関するブログ投稿で説明したように、私たちの対応は.deに対してNegative Trust Anchor（NTA）をインストールし、レジストリが問題を解決している間、ドメインを到達可能に保つために1.1.1.1でのDNSSEC検証を一時的に停止することでした。私たちは.alについても同様のことを行いました。 NTAは解決を復元しますが、サイレントに行われます。NTAの下で提供された応答を受信するクライアントは、応答自体からはDNSSEC検証がバイパスされたことを知る方法がなく、正当な回答と偽装された回答を区別できなくなります。.alインシデントでは、1.1.1.1は初めてこのギャップに対処し、NTAの存在を示して回答がDNSSEC検証されていないことを示すために、影響を受けたすべての応答とともに新しいExtended DNS Error（EDE）コードを返しました。 以下のグラフは、7月3日の1.1.1.1での.alクエリのSERVFAIL率とNOERROR率を示しています。SERVFAIL率は、キャッシュされたレコードの有効期限が切れ、リゾルバが再検証を強制されるにつれて上昇します。NTAが17:15 UTCに適用され、解決が復元されると、それは急激に低下します。 .alに何が起こったのか 以前のブログ投稿でDNSSECの仕組みについて詳しく説明しました。簡単な復習です。 DNSSECは、ルートゾーンから個々のドメイン名まで信頼の連鎖を構築します。ルートゾーンは、署名された各TLDのDelegation Signer（DS）レコードを保持しており、それはそのTLDのDNSKEYのフィンガープリントです。 .alを検証するリゾルバは、.alのネームサーバによって提供されるDNSKEYがルートのDSレコードと一致するかどうかを確認します。一致する場合、リゾルバは.alのネームサーバからのDNS応答が本物であると信頼します。同じパターンが一段下でも繰り返されます：.alは署名された子ゾーンのDSレコードを保持しており、それぞれに一致するDNSKEYがあります。この連鎖のどこかに、もはや存在しないキーを指すDSレコードのようなブレークがあると、それ以下のすべてで検証が失敗します。 インシデント前、ルートゾーンは、以下に示すように、.alネームサーバによって提供されるDNSKEYと一致するDSレコードを保持していました。 約14:15 UTCに、.alオペレータは新しいDNSKEYを公開し、古いものをサービス提供するのを停止しました。ルートゾーンのDSレコードは古いDNSKEY（id=26319）を指したままであったため、.al応答の検証を試みる任意のリゾルバは一致するキーを見つけられず、失敗しました。 約17:00 UTCに、.alオペレータは新しいDNSKEYを削除しましたが、古いものを復元しませんでした。ゾーンにはDNSKEYレコードがまったくなくなりましたが、ルートのDSレコードはid=26319を指したままで、解決は失敗し続けました。 約19:15 UTCに、.alオペレータはルートゾーンからDSレコードを削除しました。DSレコードがないため、リゾルバはもはや.alのDNSSEC検証を期待しなくなり、解決は復元されましたが、TLD全体が署名されなくなりました。 公開時点では、.alは署名されないままです。DSレコードは.alオペレータによってルートゾーンに復元されていません。DSレコードがないため、すべての.alドメインはDNSSEC保護を使用できません。 Negative Trust Anchorが使用される理由 壊れたDNSSEC構成は、特にTLD全体に一度に影響を与える場合、苦痛を伴う可能性があります。.deインシデントのブログでカバーしたように、再帰DNSオペレータはRFC 7646で定義されているNegative Trust Anchor（NTA）をインストールでき、これはリゾルバにゾーンを署名されていないと見なし、検証をバイパスするように指示します。NTAをインストールする前に、.alオペレータに直接連絡を試み、DNS-OARC Mattermostに投稿してコミュニティに警告しました。応答はありませんでした。これは、オペレータの連絡先アドレス自体が.alの下にあったため、アウトエージ中に到達不能であったことも一因です。 私たちは.alにNTAを適用し、インシデント発生から約3時間後の17:15 UTCまでにすべての1.1.1.1ユーザーに展開しました。 トレードオフは.deの場合と同じです：Negative Trust AnchorはDNSSEC検証を一時停止します。これは、その期間中、.alドメインがDNSスプーフィングから保護されなくなったことを意味します。私たちは同じ理由でこれを許容できると判断しました：障害は公に確認されており、すべての検証リゾルバに等しく影響を与えていました。 Negative Trust Anchorは、翌日、.alオペレータがルートゾーンからDSレコードを削除した後、削除されました。DSレコードが存在しないため、リゾルバはもはや.alのDNSSECを期待せず、NTAは不要になりました。 Negative Trust Anchorの問題 Negative Trust Anchorのインストールは、積極的な措置です。ドメインを到達可能に保つためにDNSSEC検証を一時停止し、その期間中応答はもはや暗号学的に検証されないことを受け入れます。ユーザーはSERVFAILの代わりに回答を受け取りますが、それらの回答にはDNSSECの保証はありません。 これをさらに困難にしているのは、これまでDNS応答の何ものもクライアントにこれをシグナルしていなかったことです。NTAの下で提供された応答は、完全に検証された応答と見分けがつかないように見えました。RFC 7646はこのギャップを認識しており、オペレータが現在配置しているNTAを公に開示することを推奨していますが、その開示は帯域外です。.deおよび.alインシデントの両方でステータスページを公開しましたが、ステータスページはユーザーが探しに行く必要があります。アプリケーション、監視ツール、または1.1.1.1にクエリするユーザーは、応答自体からはDNSSEC検証がバイパスされたことを知る方法がありませんでした。 Negative Trust Anchorへの透明性の導入 Extended DNS Error（EDE）コードは、RFC 8914で定義されており、リゾルバがDNS応答（エラーまたは成功した回答のいずれか）とともに追加のコンテキストを含めることを可能にします。Quad9のBabak Farrokhiは、新しいEDEコードを使用して、DNS応答でNegative Trust Anchorの存在をシグナルするインターネットドラフトを提案しました：DNS応答でのNegative Trust Anchorの開示。私たちは共同著者として参加し、1.1.1.1は現在それを実装しています。 .alインシデント中、Negative Trust Anchorがインストールされている間、.al名のクエリはすべて回答と新しいEDEコードの両方を返しました。以下は、それがどのようになったかです。 $ kdig @1.1.1.1 google.al ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 32848 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR ;; EDE: 9 (DNSKEY Missing): 'no SEP matching the DS found for al.' ;; EDE: 33 (Negative Trust Anchor): 'a Negative Trust Anchor has been applied for this query (see RFC 7646)' ;; ANSWER SECTION: google.al. 300 IN A 142.251.142.196 応答は有効な回答を持つNOERRORです：google.alは解決しますが、2つのEDEコードがそれに付随しています。EDE 9（DNSKEY Missing）は、根本的なDNSSEC障害を表面化させます：信頼の連鎖が壊れ、検証が失敗しました。 EDE 33（Negative Trust Anchor）は、1.1.1.1がNegative Trust Anchorを適用し、それでも応答を提供したことをシグナルします。これらを組み合わせることで、クライアントとオペレータは、何が起こったのかを完全に可視化できます。回答は本物ですが、DNSSEC検証されていません。 1.1.1.1は、クエリ自体がDNSSEC検証に失敗したかどうかに関わらず、NTAがアクティブな間に生成されたすべての応答に対してEDE 33を返します。DNSSECをまったく使用しないドメインのクエリでも、アクティブなNTAの下にある場合はEDE 33が付きます。これは意図的です：NTAはゾーン全体をカバーしており、透明性はそれの下で提供されるすべての応答に等しく適用されます。これにより、.deブログで指摘した、1.1.1.1が根本的なDNSSECエラーを表面化させる代わりにEDE 22（No Reachable Authority）を誤って返した問題も解決されます。