ドメインネームシステムのセキュリティ拡張

ドメインネーム システム セキュリティ拡張( DNSSEC ) は、インターネット プロトコル( IP )ネットワークのドメイン ネーム システム( DNS )で交換されるデータを保護するための、インターネット技術タスク フォース( IETF )による拡張仕様のスイートです。このプロトコルは、データの暗号化認証、認証された不在拒否、およびデータの整合性を提供しますが、可用性や機密性は提供しません。

ドメイン ネーム システムの元の設計には、セキュリティ機能は含まれていませんでした。スケーラブルな分散システムとしてのみ考え出されました。ドメイン ネーム システム セキュリティ拡張機能 (DNSSEC) は、下位互換性を維持しながらセキュリティを追加しようとします。2004年のRFC  3833 には、DNS に対する既知の脅威の一部と、DNSSEC でのその解決策が文書化されています。

DNSSECは、 DNSキャッシュポイズニングによって作成されたものなど、偽造または操作されたDNSデータを受け入れることからDNSを使用するアプリケーションを保護するために設計されました。DNSSECで保護されたゾーンからのすべての応答はデジタル署名されています。^[1]デジタル署名をチェックすることで、DNSリゾルバは、情報がゾーン所有者によって公開され、権威DNSサーバーで提供されている情報と同一であるかどうか（つまり、変更されておらず完全であるかどうか）を確認できます。 IP アドレスの保護は多くのユーザーにとって差し迫った懸念事項ですが、DNSSEC は、テキスト レコード (TXT) やメール交換レコード (MX) など、DNS で公開されるすべてのデータを保護できます。また、証明書レコード ( CERT レコード、RFC  4398)、SSHフィンガープリント ( SSHFP、RFC  4255)、IPSec公開鍵 (IPSECKEY、RFC  4025)、TLSトラスト アンカー ( TLSA、RFC 6698)、暗号化クライアント Hello (ECH ^{[2] [3]の SVCB/HTTPS レコード)} など、DNS に保存されている暗号化証明書への参照を公開する他のセキュリティ システムをブートストラップするために使用できます。

DNSSEC はデータの機密性を提供しません。特に、すべての DNSSEC 応答は認証されますが、暗号化されません。DNSSEC はDoS攻撃を直接的に防ぐわけではありませんが、間接的にいくらかの利点を提供します (署名チェックにより、信頼できない可能性のある当事者を利用できるため)。^{[引用が必要]}

DNS サーバー間で送信される大量のデータ ( DNS ゾーン転送など) を保護するには、他の標準 (DNSSEC 以外) が使用されます。RFC  4367 に記載されているように、一部のユーザーや開発者は、会社の共通名に「.com」を付け加えたものが常にドメイン名であると想定するなど、DNS 名について誤った想定をしています。DNSSEC では誤った想定から保護することはできません。データが本当にドメイン所有者からのものであるか、またはドメイン所有者から入手できないかを認証することしかできません。^{[引用が必要]}

DNSSEC 仕様 ( DNSSEC-bisと呼ばれる) では、現在の DNSSEC プロトコルが詳細に説明されています。RFC  4033、RFC  4034、およびRFC  4035 を参照してください。これらの新しい RFC の公開 (2005 年 3 月) により、以前の RFC であるRFC 2535 は廃止されました。DNSSEC を指定する RFCの 完全なセットは、 BCP 237 でもあるRFC 9364 にまとめられています。

DNSのセキュリティ確保はインターネット全体のセキュリティ確保にとって極めて重要であると広く信じられています^[4]が、DNSSECの導入はいくつかの困難によって妨げられています（2010年1月22日現在^[update]）。

• インターネットの規模に合わせて拡張できる下位互換性のある標準を設計する必要性
• 必要に応じて「ゾーン列挙」を防止する
• さまざまなDNSサーバーとリゾルバ（クライアント）にわたるDNSSEC実装の展開
• トップレベルドメインのルートキーを誰が所有すべきかについて実装者の間で意見の相違がある
• DNSSECとDNSSECの導入の複雑さを克服する

DNSSEC は、公開鍵暗号化を使用して DNS ルックアップのレコードにデジタル署名することで機能します。正しい DNSKEY レコードは、信頼できる第三者であるDNS ルート ゾーンの検証済み公開鍵のセットから始まる信頼チェーンによって認証されます。ドメイン所有者は独自の鍵を生成し、ドメイン名レジストラの DNS コントロール パネルを使用して鍵をアップロードします。レジストラは、secDNS 経由で鍵をゾーン オペレータ (.com の場合は Verisign など) にプッシュし、ゾーン オペレータは鍵に署名して DNS に公開します。

DNS は、いくつかのリソース レコードを使用して実装されます。DNSSEC を実装するために、いくつかの新しいDNS レコード タイプが作成または DNSSEC で使用できるように調整されました。

RRSIG (リソースレコード署名)

レコード セットの DNSSEC 署名が含まれます。DNS リゾルバーは、DNSKEY レコードに保存されている公開キーを使用して署名を検証します。

DNSキー

DNS リゾルバが RRSIG レコード内の DNSSEC 署名を検証するために使用する公開キーが含まれます。

DS (委任署名者)

委任されたゾーンの名前を保持します。サブ委任されたゾーンの DNSKEY レコードを参照します。DS レコードは、委任する NS レコードとともに親ゾーンに配置されます。

NSEC (次のセキュアレコード)

ゾーン内の次のレコード名へのリンクが含まれ、レコード名に対して存在するレコード タイプが一覧表示されます。DNS リゾルバは、DNSSEC 検証の一環として、NSEC レコードを使用してレコード名とタイプが存在しないことを確認します。

NSEC3 (次世代セキュアレコードバージョン3)

ゾーン内の次のレコード名へのリンク (ハッシュ化された名前のソート順) が含まれており、NSEC3 レコード自身の名前の最初のラベルのハッシュ値でカバーされる名前に対して存在するレコード タイプが一覧表示されます。これらのレコードは、DNSSEC 検証の一部として、リゾルバがレコード名とタイプが存在しないことを確認するために使用できます。NSEC3 レコードは NSEC レコードに似ていますが、NSEC3 は暗号化されたハッシュ化されたレコード名を使用して、ゾーン内のレコード名の列挙を回避します。

NSEC3PARAM (次のセキュア レコード バージョン 3 パラメータ)

権威 DNS サーバーはこのレコードを使用して、存在しない名前/タイプに対する DNSSEC 要求への応答に含める NSEC3 レコードを計算および決定します。

DNSSEC を使用すると、DNS ルックアップに対する各応答には、要求されたレコード タイプに加えて、RRSIG DNS レコードが含まれます。RRSIG レコードは、応答DNSリソース レコード セットのデジタル署名です。デジタル署名は、DNSKEY レコードで見つかった正しい公開キーを検索することによって検証されます。NSEC レコードと NSEC3 レコードは、リソース レコード (RR) が存在しないことを示す暗号証拠を提供するために使用されます。DS レコードは、信頼チェーンを使用したルックアップ手順での DNSKEY の認証に使用されます。NSEC レコードと NSEC3 レコードは、なりすましに対する強力な耐性のために使用されます。

DNSSECは拡張性を考慮して設計されており、既存のアルゴリズムに対する攻撃が発見された場合、RFC 8624で説明されているように、下位互換性のある方法で新しいアルゴリズムを導入することができます 。次の表は、2019年6月現在、最も頻繁に使用されている、または使用されていたセキュリティアルゴリズムを定義しています。^[5]

セキュリティ対応の DNSリゾルバは、DNS ルックアップの結果から、問い合わせ先のドメインの権威ネーム サーバがDNSSEC をサポートしているかどうか、受信した応答が安全かどうか、何らかのエラーがあるかどうかを判断できます。ルックアップ手順は、多くのISP が提供しているような再帰ネーム サーバと、主流のオペレーティング システムにデフォルトで含まれているようなスタブリゾルバでは異なります。Microsoft Windows はスタブリゾルバを使用しており、特に Windows Server 2008 R2 と Windows 7 は検証は行いませんが DNSSEC 対応のスタブリゾルバを使用しています。^{[6] [7]}

信頼チェーンモデルを使用すると、親ドメイン ( DNS ゾーン)の委任署名者 (DS) レコードを使用してサブドメインの DNSKEY レコードを検証できます。その後、サブドメインに他の DS レコードを含めて、さらにサブドメインを検証できます。ISP ネーム サーバーなどの再帰リゾルバが、ドメイン "www.example.com "の IP アドレス ( A レコードおよび/またはAAAA レコード)を取得したいとします。

1. このプロセスは、セキュリティ対応リゾルバが DNS クエリに「DO」(「DNSSEC OK」) フラグ ビットを設定すると開始されます。DO ビットは、DNS の拡張メカニズム (EDNS)、RFC  6891 で定義されている拡張フラグ ビットにあるため、すべての DNSSEC トランザクションは EDNS をサポートする必要があります。DNSSEC トランザクションに必要な、はるかに大きなパケット サイズを可能にするためにも、EDNS サポートが必要です。
2. リゾルバが通常の DNS ルックアップ プロセスで回答を受信すると、回答が正しいかどうかを確認します。理想的には、セキュリティ対応リゾルバは、DNS ルートの DS レコードと DNSKEY レコードの検証から開始します。次に、ルートにあるトップレベル ドメイン「com」の DS レコードを使用して、「com」ゾーンの DNSKEY レコードを検証します。そこから、「com」ゾーンのサブドメイン「example.com」の DS レコードがあるかどうかを確認し、ある場合は、DS レコードを使用して「example.com」ゾーンにある DNSKEY レコードを検証します。最後に、「www.example.com」の A レコードの回答にある RRSIG レコードを検証します。

上記の例にはいくつか例外があります。

まず、「example.com」が DNSSEC をサポートしていない場合、応答には RRSIG レコードがなく、「com」ゾーンには「example.com」の DS レコードがありません。「example.com」の DS レコードがあるのに応答に RRSIG レコードがない場合は、何かが間違っており、中間者攻撃が行われ、DNSSEC 情報が削除され、A レコードが変更されている可能性があります。または、途中でセキュリティに気付かないネーム サーバーが壊れ、クエリから DO フラグ ビットが削除されたり、応答から RRSIG レコードが削除されたりする可能性があります。または、構成エラーである可能性もあります。

次に、「www.example.com」という名前のドメイン名が存在しない可能性があります。この場合、応答で RRSIG レコードを返す代わりに、NSEC レコードまたは NSEC3 レコードのいずれかが返されます。これらは、リゾルバがドメイン名が存在しないことを証明できるようにする「次のセキュア」レコードです。NSEC/NSEC3 レコードには RRSIG レコードがあり、上記のように検証できます。

最後に、「example.com」ゾーンは DNSSEC を実装しているが、「com」ゾーンまたはルート ゾーンは実装しておらず、別の方法で検証する必要がある「セキュリティの孤島」が作成されている可能性があります。2010 年 7 月 15 日現在^[update]、ルートへの DNSSEC の展開は完了しています。^[8] .com ドメインは有効なセキュリティ キーで署名され、安全な委任は 2011 年 4 月 1 日にルート ゾーンに追加されました。^[9]

スタブリゾルバは、「再帰クエリモードを使用して DNS 解決の作業のほとんどを再帰ネームサーバーにオフロードする最小限の DNS リゾルバ」です。^[10]スタブリゾルバは、要求を再帰ネームサーバーに転送し、応答の認証データ (AD) ビットを「再帰ネームサーバーが応答の回答セクションと権限セクションのすべてのデータの署名を検証できたかどうかを確認するためのヒント」として使用します。^[11] Microsoft Windows はスタブリゾルバを使用しており、特に Windows Server 2008 R2 と Windows 7 は検証は行いませんが AD ビットを認識するスタブリゾルバを使用しています。^{[6] [7]}

検証スタブリゾルバは、クエリメッセージにチェック無効（CD）ビットを設定することで、独自の署名検証を実行することもできます。^[11]検証スタブリゾルバは、CDビットを使用して独自の再帰認証を実行します。このような検証スタブリゾルバを使用すると、インターネットサービスプロバイダーまたはそれらへの接続が信頼されていない場合でも、DNSSECを実装しているドメインに対してクライアントにエンドツーエンドのDNSセキュリティが提供されます。

非検証スタブリゾルバは、ユーザーのインターネットサービスプロバイダーやパブリック再帰ネームサーバーによって制御される外部DNSSEC検証サービス、およびDNS over TLSなどの方法を使用して、スタブリゾルバとネームサーバー間の通信チャネルに依存する必要があります。^{[11] [12]}

DNS の回答が正しいことを証明するには、DNS 以外のソースから正しいキーまたは DS レコードを少なくとも 1 つ知る必要があります。これらの開始点はトラスト アンカーと呼ばれ、通常はオペレーティング システムまたは他の信頼できるソースから取得されます。DNSSEC が最初に設計されたとき、必要なトラスト アンカーはDNS ルートのみであると考えられていました。ルート アンカーは 2010 年 7 月 15 日に初めて公開されました。^[13]

認証チェーンは、対象のドメインの権威ネーム サーバーへの信頼アンカーから始まる、リンクされた一連の DS レコードと DNSKEY レコードです。完全な認証チェーンがないと、DNS ルックアップへの回答を安全に認証できません。

リプレイ攻撃を制限するために、キャッシュ用の通常の DNS TTL 値だけでなく、署名の有効性を制限するための RRSIG レコード内の追加のタイムスタンプがあります。レコードが送信された時点に相対的な TTL 値とは異なり、タイムスタンプは絶対的です。つまり、セキュリティ対応のすべての DNS リゾルバーは、数分以内など、かなり厳密に同期されたクロックを備えている必要があります。

これらのタイムスタンプは、ゾーンを定期的に再署名してセカンダリ サーバーに再配布する必要があることを意味します。そうしないと、検証リゾルバーによって署名が拒否されます。

DNSSEC には、DNSKEY レコードと他のソースの両方に保存され、信頼アンカーを形成するさまざまなキーが含まれます。

交換キーを可能にするには、キー ロールオーバースキームが必要です。通常、これにはまず、既存の古いキーに加えて、新しい DNSKEY レコードに新しいキーを展開することが含まれます。次に、有効期限値によって古いキーのキャッシュが期限切れになったと想定しても問題ない場合、これらの新しいキーを使用できます。最後に、古いキーを使用したレコードのキャッシュが期限切れになったと想定しても問題ない場合、古い DNSKEY レコードを削除できます。このプロセスは、ルートなどの信頼アンカーへのキーなどではより複雑になり、オペレーティング システムの更新が必要になる場合があります。

DNSKEY レコード内のキーは 2 つの異なる目的に使用でき、通常はそれぞれに異なる DNSKEY レコードが使用されます。まず、他のレコードに署名するために使用されるゾーン署名キー(ZSK) を含む他の DNSKEY レコードに署名するために使用されるキー署名キー(KSK) があります。ZSK は特定のDNS ゾーンによって完全に制御および使用されるため、より簡単に、より頻繁に切り替えることができます。その結果、ZSK は KSK よりもはるかに短くても、RRSIG/DNSKEY レコードのサイズを縮小しながら、同じレベルの保護を提供できます。

新しい KSK が作成されると、DS レコードを親ゾーンに転送して公開する必要があります。DS レコードは、レコードのサイズを小さく保つために、完全なキーではなく KSK のメッセージ ダイジェストを使用します。これは、 .comドメインなどの非常に大きいゾーンに役立ちます。親ゾーンで DS キーを更新する手順も、DNSKEY レコードを親ゾーンに配置する必要があった以前の DNSSEC バージョンよりも簡単です。

密接に関連する原則は、アルゴリズムロールオーバーです。これは、ゾーンを1つの署名アルゴリズムから別の署名アルゴリズムに移行することを意味します。この良い例は、アルゴリズム8（RSA / SHA-256）からアルゴリズム13（ECDSA / SHA-256）への移行です。.at、.br、.cz、.ch、.fr、.ie、.nl ^[14]、. phなど、いくつかのccTLDはすでに移行しています。Verisignは、 2023年後半に.com、.net、.eduをアルゴリズム13に移行しました。 ^{[15] [16]}ルートドメインのアルゴリズム8からアルゴリズム13への移行は、現在2024年初頭の時点で計画されています。^[17]

DNSベースの名前付きエンティティの認証（DANE）は、^{インターネットアプリケーションがDNSSECに基づいて}TLS、DTLS、SMTP、S/MIMEを使用して暗号化された安全な通信を確立できるようにするプロトコルと技術を開発することを目的としたIETFワーキンググループ[18]です。

新しいプロトコルにより、公開鍵インフラストラクチャに基づく従来のモデルにさらなる保証と制約が加わります。また、ドメイン所有者は、サードパーティの証明機関に頼ることなく、自分自身で証明書を発行できるようになります。

DNSSECステープル証明書のサポートはGoogle Chrome 14で有効化されましたが^[19] 、後に削除されました。^[20] Mozilla Firefoxではアドオンによってサポートが提供されていましたが^[21]、ネイティブサポートは現在誰かが作業を開始するのを待っています。^[22]

DNSは極めて重要かつ基本的なインターネットサービスですが、1990年にスティーブ・ベロビンがDNSに重大なセキュリティ上の欠陥を発見しました。DNSのセキュリティ確保に向けた研究が始まり、1995年に彼の論文が公開されると飛躍的に進歩しました。 ^[23] 最初のRFC 2065は1997年にIETFによって公開され、その仕様を実装する最初の試みは1999年にIETF RFC 2535として改訂された（そして完全に機能すると考えられた）仕様につながりました。RFC 2535に基づいてDNSSECを展開する計画が立てられました。

残念ながら、IETF RFC 2535 仕様は、インターネット全体に拡張する際に非常に重大な問題を抱えていました。2001 年までに、この仕様は大規模ネットワークには使用できないことが明らかになりました。通常の操作では、DNS サーバーは親と同期しなくなることがよくあります。これは通常問題にはなりませんが、DNSSEC が有効になっている場合、この同期されていないデータによって、深刻な自己生成型サービス拒否が発生する可能性があります。元の DNSSEC では、子のキー変更を実行するために、複雑な 6 メッセージ プロトコルと大量のデータ転送が必要でした (DNS 子ゾーンは、すべてのデータを親に送信し、親に各レコードに署名してもらい、その署名を子に送り返して、子が SIG レコードに格納する必要がありました)。また、公開キーの変更によって不合理な影響が生じる可能性がありました。たとえば、「.com」ゾーンが公開キーを変更すると、2,200 万件のレコードを送信する必要があります (すべての子のすべての署名を更新する必要があるため)。したがって、RFC 2535 で定義されている DNSSEC はインターネットに拡張できませんでした。

IETF は DNSSEC を根本的に変更しました。これは、 RFC 2535 の元の DNSSEC アプローチと区別するために、必要に応じてDNSSEC-bisと呼ばれます。この新しいバージョンでは、「委任署名者 (DS) リソース レコード」を使用して、親ゾーンと子ゾーン間の委任ポイントで追加の間接レベルを提供します。新しいアプローチでは、子のマスター公開キーが変更されると、子のレコードごとに 6 つのメッセージがあるのではなく、1 つの簡単なメッセージがあります。つまり、子は新しい公開キーを親に送信します (もちろん、署名されています)。親は、子ごとに 1 つのマスター公開キーを保存するだけです。これははるかに実用的です。つまり、親と子の間で大量のデータが交換されるのではなく、親にプッシュされるデータはわずかです。これは、クライアントがキーを検証するときに少し多くの作業を行う必要があることを意味します。より具体的には、DNS ゾーンの KEY RRset を検証するには、RFC 2535 で必要な 1 つの署名検証操作ではなく、2 つの署名検証操作が必要です (他の種類の RRset で検証される署名の数には影響しません)。ほとんどの人は、DNSSEC の導入がより現実的になるため、これは小さな代償だと考えています。新しいバージョンは RFC4033-4035 で公開されています。

2024年1月、仕様を遵守するすべてのDNSSECリゾルバーに対する「KeyTrap」サービス拒否攻撃が発表されました。DNSSEC仕様（RFC4033-4035）では、リゾルバーが上流から署名されたパケットを受信すると、すべての署名で正しい「タグ」を持つすべてのキーを試し、いずれかの組み合わせが正常に検証されるまで試す必要があると規定されています。同じ「タグ」を持つ多くのキーとその「タグ」に対応する多くの署名をパケットに入れることで、研究者はリゾルバーを200万倍遅くすることができます。これに対応して、リゾルバーは検証エラー、キータグの衝突、ハッシュ計算の量に制限を設け始めました。^[24]

ドメインが存在しないことを暗号的に証明するには、存在しないドメインのすべてのクエリに対する応答に署名する必要があります。これは、キーをオンラインで利用できるようにしておくオンライン署名サーバーでは問題になりません。ただし、DNSSEC は、ゾーン署名キーをコールド ストレージに保管できるように、オフライン コンピューターを使用してレコードに署名するように設計されています。これは、存在しないドメインのクエリに対する応答を認証しようとするときに問題になります。すべてのホスト名クエリに対する応答を事前に生成することは不可能だからです。

当初の解決策は、ゾーン内のすべてのドメインのペアに対して NSEC レコードを作成することでした。したがって、クライアントが存在しない でレコードを照会した場合、サーバーはと のk.example.com間に何も存在しないことを示す NSEC レコードで応答します。ただし、これは実際のドメインの存在を明らかにするため、従来の認証されていない NXDOMAIN エラーよりも多くのゾーン情報が漏洩します。 a.example.comz.example.com

NSEC3 レコード (RFC 5155) は、名前を直接リストするのではなくハッシュする代替手段として作成されました。時間の経過とともに、GPU と専用ハードウェアを使用したハッシュの進歩により、オフライン辞書攻撃を使用して NSEC3 応答を安価にブルートフォース攻撃できるようになりました。NSEC5 は、ゾーンの変更に使用できる秘密鍵を保持せずに、権威サーバーが NSEC 応答に署名できるようにするために提案されました。したがって、NSEC5KEY を盗むと、ゾーンをより簡単に列挙できるようになります。^[25]

プロトコルの乱雑な進化と下位互換性を維持したいという要望により、オンライン DNSSEC 署名サーバーは、存在の否定を直接認証する代わりに「白々しい嘘」を返します。RFC 4470 で概説されている手法では、要求されたドメインを語彙的に囲むドメインのペアを含む NSEC レコードが返されます。たとえば、 の要求は、 (架空の) ドメインと のk.example.com間に何も存在しないことを証明する NSEC レコードになります。これは NSEC3 レコードでも可能です。^[26]j.example.coml.example.com

CloudFlare は、応答サイズの 3 分の 1 で同じ結果を達成する 2 つの代替アプローチを開拓しました。^[27]最初のアプローチは、「白い嘘」アプローチのバリエーションで、「黒い嘘」と呼ばれ、一般的な DNS クライアントの動作を利用して、存在しないことをより簡潔に示します。^[28] 2 番目のアプローチは、「レコードは存在するが、要求されたレコード タイプは存在しない」ことを証明することを選択し、これを「DNS ショットガン」と呼びます。^{[29] [27]}

インターネットは重要なインフラですが、その運用は根本的に安全でないDNSに依存しています。そのため、DNSを安全にする強い動機があり、DNSSECの導入は一般的にその取り組みの重要な部分であると考えられています。たとえば、米国のサイバースペースの安全を確保するための国家戦略では、 DNSを安全にする必要性を明確に認識しています。^[30] DNSSECを大規模に導入することで、電子メールアドレスの安全な鍵配布など、他の多くのセキュリティ問題も解決できます。

大規模ネットワークでの DNSSEC の導入も困難です。Ozment 氏と Schechter 氏は、DNSSEC (およびその他のテクノロジ) には「ブートストラップ問題」があると指摘しています。つまり、通常、ユーザーはすぐにメリットが得られる場合にのみテクノロジを導入しますが、コストを上回るメリットをユーザーが得るまでに最低限の導入レベルが必要な場合( DNSSEC の場合も同様)、導入は困難です。DNSSEC は DNS 階層のどのレベルでも導入できますが、他の多くの人が採用したくなる前に、ゾーンで広く利用できるようにする必要があります。DNS サーバーは、DNSSEC をサポートするソフトウェアで更新する必要があり、DNSSEC データを作成して DNS ゾーン データに追加する必要があります。TCP/IP を使用するクライアントは、DNSSEC の機能を使用する前に、DNS リゾルバ (クライアント) を更新する必要があります。さらに、DNSSEC の使用を開始する前に、リゾルバは信頼できる公開キーを少なくとも 1 つ持っているか、取得する方法を持っている必要があります。

DNSSEC の実装は、一部の DNS サーバーにかなりの負荷をかける可能性があります。一般的な DNSSEC 署名付き応答は、デフォルトの UDP サイズである 512 バイトよりもはるかに大きくなります。理論上は、複数の IP フラグメントでこれを処理できますが、この分野の多くの「ミドルボックス」はこれを正しく処理しません。このため、代わりに TCP が使用されます。しかし、現在の TCP 実装の多くは、TCP 接続ごとに大量のデータを格納します。負荷の高いサーバーは、大量の (おそらく偽の) DNSSEC 要求に応答しようとするだけでリソースを使い果たす可能性があります。TCP Cookie Transactionsなどの一部のプロトコル拡張は、この負荷を軽減するために開発されました。^[31]これらの課題に対処するために、DNSSEC を展開するための多大な努力が続けられています。これは、インターネットが多くの組織にとって非常に重要だからです。

早期導入国としては、ブラジル( .br )、ブルガリア( .bg )、チェコ共和国( .cz )、ナミビア( .na ) ^[32] プエルトリコ( .pr )、スウェーデン( .se ) が挙げられ、これらの国は国コードトップレベルドメインに DNSSEC を使用しています。^[33] RIPE NCC は、インターネット番号割り当て機関(IANA)から委任されたすべての逆引き参照レコード (in-addr.arpa) に署名しています。 ^[34] ARINも逆引きゾーンに署名しています。^[35] 2007 年 2 月、TDC はスウェーデンの ISP として初めて、この機能を顧客に提供し始めました。^[36]

IANAは2007年6月からサンプルの署名済みルートを公開テストしてきました。ルートの実稼働署名前のこの期間中、いくつかの代替トラストアンカーもありました。IKS Jenaは2006年1月19日に1つを導入し、^[37]インターネットシステムコンソーシアムは同年3月27日に別のトラストアンカーを導入し、^[38] ICANN自身も2009年2月17日に3つ目のトラストアンカーを発表しました。^[39]

2009年6月2日、Public Interest Registryの.orgゾーンのレジストリサービスプロバイダーであるAfiliasが.org TLDに署名しました。^[40] AfiliasとPIRは2008年9月26日にも、強力な協力関係にある大手レジストラ（「友人や家族」）が関与する第1フェーズが「2009年初頭」からドメインに署名できるようになると詳細を発表しました。^[41] 2010年6月23日、13のレジストラが.ORGドメインのDNSSECレコードを提供するとリストされました。^[42]

VeriSign は、NSEC3 実験の目的で、.com および .net ドメインが自分で登録できるようにするパイロット プロジェクトを実行しました。2009 年 2 月 24 日、同社は 24 か月以内にすべてのトップレベル ドメイン (.com、.net など) に DNSSEC を導入すると発表しました。^[43]また、同年 11 月 16 日には、実装の技術的側面による遅延の後、.com および .net ドメインは 2011 年第 1 四半期までに署名される予定であると述べました。^[44]この目標は予定通りに達成され^[45]、Verisign の DNSSEC 担当副社長である Matt Larson は、DNSSEC の推進における役割が認められ、InfoWorld の 2011 年テクノロジー リーダーシップ賞を受賞しました。^{[46] [47]}

DNSSEC は、2010 年 7 月 15 日に初めてルート レベルで導入されました。^[48]これにより、ルート トラスト アンカーを使用して、ルートからの完全な信頼チェーンを持つ任意の DNSSEC ゾーンを検証できるため、DNSSEC リゾルバーの導入が大幅に簡素化されると予想されます。信頼チェーンは、検証するために中断することなく信頼できるルートまで遡る必要があるため、上位のゾーンのいずれかが安全でない場合は、安全なゾーンに対してトラスト アンカーを構成する必要があります。たとえば、ゾーン「signed.example.org」は安全であるが、「example.org」ゾーンは安全でない場合、「.org」ゾーンとルートが署名されているとしても、ゾーンを検証するためにトラスト アンカーを導入する必要があります。

ルートの署名をめぐる政治的な問題は、主にいくつかの中心的な問題に関して継続的な懸念となっています。

• 他の国々は、米国によるインターネットの管理を懸念しており、この理由から集中化されたキー設定を拒否する可能性があります。
• 一部の政府は、DNSSEC を利用した暗号化キーの配布を禁止しようとする可能性があります。

2008年9月、ICANNとVeriSignはそれぞれ実装提案を発表し^[49]、10月には国家電気通信情報局（NTIA）が一般からの意見を求めた^[50] 。寄せられた意見が最終的な導入計画の設計に影響を与えたかどうかは不明である。

2009年6月3日、アメリカ国立標準技術研究所（NIST）は、ICANN、 VeriSign、NTIAと協力して、2009年末までにルートに署名する計画を発表しました。 ^[51]

2009 年 10 月 6 日、第 59 回RIPE会議において、ICANN と VeriSign はルートゾーン内で DNSSEC を展開するための計画された展開タイムラインを発表しました。^[52]会議では、2009 年 12 月 1 日から 1 か月に 1 つのルートネームサーバーに段階的に展開され、2010 年 7 月 1 日に最後のルートネームサーバーが DNSSEC 署名ゾーンを提供し、ルートゾーンは RSA/SHA256 DNSKEY で署名されることが発表されました。^[52]段階的な展開期間中、ルートゾーンはダミーキーを使用する意図的に検証不可能なルートゾーン(DURZ) を提供し、最終的な DNSKEY レコードは 2010 年 7 月 1 日まで配布されません。 ^[53]これは、ゾーンの使用を署名するために使用されたキーが意図的に検証不可能であることを意味します。

.orgトップレベルドメインは2010年6月にDNSSECで署名され、その後2010年後半と2011年に.com、.net、.eduが続きました。 ^{[54] [55]}国コードトップレベルドメインは2010年5月から鍵を預けることができるようになりました。^[56] 2011年11月現在、トップレベルドメインの25%以上がDNSSECで署名されています。^{[57] [update]}

2010 年 1 月 25 日、L (ell) ルート サーバーは、意図的に検証不可能なルート ゾーン(DURZ) の提供を開始しました。このゾーンは、RFC 5702で定義されているRSAアルゴリズムを使用して作成されたSHA-2 (SHA-256) ハッシュの署名を使用します 。2010 年 5 月の時点で、13 台のルート サーバーすべてが DURZ の提供を開始しました。^[53] 2010 年 7 月 15 日、最初のルート完全実稼働 DNSSEC ルート ゾーンが署名され、SOA シリアル番号 2010071501 が付与されました。ルート トラスト アンカーは IANA から入手できます。^[48]

ルートの下には、DNSSEC を完全に導入するために署名する必要があるトップレベル ドメインの大規模なセットがあります。インターネット トップレベル ドメインのリストには、既存のトップレベル ドメインのうち、どのドメインが署名され、ルートにリンクされているかに関する詳細が記載されています。

2006 年 3 月、インターネット システム コンソーシアムはDNSSEC ルックアサイド検証レジストリを導入しました。^[58] DLV は、ルート トラスト アンカーがない場合でも DNSSEC をより簡単に導入できるようにすることを目的としていました。当時は、検証者が DNS の署名済みサブツリーに対応する多数のトラスト アンカーを維持する必要があると考えられていました。^[59] DLV の目的は、検証者がトラスト アンカー リポジトリの管理作業を信頼できる第三者にオフロードできるようにすることでした。DLV レジストリは、各検証者が独自のリストを維持する作業を繰り返す代わりに、トラスト アンカーの中央リストを維持しました。

DLVを使用するには、 BINDやUnboundなどのDLVゾーンのトラストアンカーが設定された、DLVをサポートするバリデータが必要でした。このゾーンにはDLVレコードが含まれていました。^[60]これらはDSレコードとまったく同じ形式でしたが、委任されたサブゾーンを参照する代わりに、DNSツリー内の他のゾーンを参照しました。バリデータは、ルートからチェックしようとしているRRsetまでの信頼チェーンを見つけられなかった場合、代わりの信頼チェーンを提供できるDLVレコードを検索しました。^[61]

署名されていないトップレベルドメインや DNSSEC 委任をサポートしていないレジストラなどの信頼チェーンのギャップにより、下位レベルのドメインの管理者は DLV を使用して、DLV を使用するように構成されたリゾルバによって DNS データを検証できるようになりました。これにより、レジストラと TLD レジストリに DNSSEC を適切にサポートするプレッシャーが軽減され、DNSSEC の導入が妨げられた可能性があります。また、DLV は DNSSEC 検証のアクターとコードパスを追加することで複雑さを増しました。

ISCは2017年にDLVレジストリを廃止しました。^[62] DLVサポートはBIND 9.12で非推奨となり、BIND 9.16では完全に削除されました。^[63] Unboundバージョン1.5.4（2015年7月）では、設定例とマニュアルページでDLVが廃止されたとマークされていました。^[64] Knot ResolverとPowerDNS RecursorはDLVを実装しませんでした。

2020年3月、IETFはRFC 8749を公開し 、DLVを標準として廃止し、RFC 4432とRFC 5074を「歴史的」ステータスに移行しました。^[65]

米国国土安全保障省(DHS)の科学技術局は、「DNSSEC 導入イニシアチブ」を後援しています。このイニシアチブは、「多くの国や公的機関、民間機関が関与するグローバルな協力活動の一環として、インターネットの命名イン​​フラストラクチャのセキュリティを向上させるセキュリティ対策をすべての部門が自主的に採用すること」を奨励しています。DHS は、DNSSEC を成熟させ、米国連邦政府内に導入するための取り組みにも資金を提供しています。

2007 年 3 月 30 日、米国国土安全保障省が「DNS ルート ゾーンに署名するための鍵を米国政府に確実に管理させる」ことを提案したと報告された^[66]。しかし、会議室には米国政府関係者は誰もおらず、記事のきっかけとなったコメントは別の関係者によってなされた。DHS は後に^{[67] [68]、}米国政府がそのような提案をしたという誤った結論に飛びついたと考える理由について次のようにコメントしている。「米国国土安全保障省は DNSSec を実装するための技術計画の開発に資金提供しており、昨年 10 月にはその最初の草案を多数の国際専門家に配布してコメントを求めた。草案では、ルート ゾーン キーの所有者、つまり「オペレーター」となる可能性のある人物について一連の選択肢が提示されており、基本的には政府機関か請負業者に絞られる。「この文書のどこにも、ルート キー オペレーターの身元に関する提案は記載されていない」と、国土安全保障省のサイバー セキュリティ研究開発マネージャーであるモーガン氏は述べた。

米国国立標準技術研究所(NIST) は、2006 年 5 月 16 日に NIST 特別刊行物 800-81 セキュア ドメイン ネーム システム (DNS) 導入ガイドを発行し、DNSSEC の導入方法に関するガイダンスを示しました。NIST は、この導入ガイドを参照して、NIST SP800-53-R1 で新しい DNSSEC 連邦情報セキュリティ管理法 (FISMA) 要件を発表する予定でした。米国の政府機関は、NIST SP800-53-R1 の最終発行から 1 年以内にこれらの新しい FISMA 要件を満たす必要がありました。^[69] ただし、その時点では NSEC3 は完成していませんでした。NIST は分割ドメインの使用を提案していましたが、これは可能だとはわかっていますが、正しく導入するのが難しく、前述のセキュリティ上の弱点があります。

2008 年 8 月 22 日、行政管理予算局 (OMB) は、米国連邦政府機関に .gov サイト全体に DNSSEC を導入することを要求する覚書を発表しました。.gov ルートは 2009 年 1 月までに署名され、.gov の下にあるすべてのサブドメインは 2009 年 12 月までに署名される必要があります。^[70] この覚書は .gov サイトに焦点を当てていますが、米国国防情報システム局は、.mil (米国軍) ドメインでも OMB DNSSEC 要件を満たすつもりであると述べています。NetworkWorld の Carolyn Duffy Marsan は、DNSSEC が「古典的な鶏と卵のジレンマに悩まされているため、広く導入されていません... OMB の命令により、卵が割れているようです」と述べています。^[71]

いくつかのISPはDNSSEC検証DNS再帰リゾルバの導入を開始している。コムキャストは米国で最初にDNSSECを導入した大手ISPとなり、2010年10月18日にその意向を発表し^{[72] [73]}、2012年1月11日に導入を完了した。^[74]

APNICの調査によると、DNSSEC検証を実行するDNSリゾルバのみを使用するクライアントの割合は、2013年5月に8.3%に上昇しました。^{[75]これらのクライアントの約半数は}、GoogleのパブリックDNSリゾルバを使用していました。

2015年9月、Verisignは無料のパブリックDNSリゾルバサービスを発表しました^[76]。プレスリリースでは言及されていませんが、DNSSEC検証も実行します。

2016年の初めまでに、APNICの監視では、DNSSEC検証を実行するDNSリゾルバのみを使用するクライアントの割合が約15％に増加したことが示されました。^[77]

Googleのパブリック再帰DNSサーバーは2013年5月6日にDNSSEC検証を有効にしました。^[78]

最も人気のある DNS 管理ソフトウェアである BIND は、バージョン 9.5 以降、デフォルトで DNSSEC サポートを有効にします。

Quad9パブリック再帰DNSは、 2016年5月11日の設立以来、メインの9.9.9.9アドレスでDNSSEC検証を実行しています。Quad9は、主にデバッグ用にDNSSEC検証を実行しない代替サービスも提供しています。^[79]

2023年9月、マイクロソフトはSMTP通信中の証明書の信頼性を検証するためにDNSSEC（ DANE経由）を利用すると発表した。 ^[80]

ジェフ・ハットソンはDNSSECの導入を断念すべきだと主張している。^[81]

• RFC  2535 ドメインネームシステムセキュリティ拡張
• RFC  3225 リゾルバの DNSSEC サポートを示す
• RFC  3226 DNSSEC および IPv6 A6 対応サーバー/リゾルバーのメッセージ サイズ要件
• RFC  3833 ドメインネームシステムの脅威分析
• RFC  4033 DNS セキュリティの概要と要件 ( DNSSEC-bis )
• RFC  4034 DNS セキュリティ拡張のリソース レコード ( DNSSEC-bis )
• RFC  4035 DNS セキュリティ拡張のプロトコル変更 ( DNSSEC-bis )
• RFC  4398 ドメインネームシステム (DNS) での証明書の保存
• RFC  4431 DNSSEC ルックアサイド検証 (DLV) DNS リソース レコード
• RFC  4470 NSEC レコードと DNSSEC オンライン署名を最低限カバー
• RFC  4509 DNSSEC 委任署名者 (DS) リソース レコード (RR) での SHA-256 の使用
• RFC  4641 DNSSEC 運用プラクティス
• RFC  4955 DNS セキュリティ (DNSSEC) 実験
• RFC  5011 DNS セキュリティ (DNSSEC) トラスト アンカーの自動更新
• RFC  5155 DNSSEC ハッシュ認証による存在拒否
• RFC  5702 DNSSEC の DNSKEY および RRSIG リソース レコードにおける RSA を使用した SHA-2 アルゴリズムの使用
• RFC  6014 DNSSEC の暗号化アルゴリズム識別子の割り当て
• RFC  6605 DNSSEC 用楕円曲線デジタル署名アルゴリズム (DSA)
• RFC  6725 DNS セキュリティ (DNSSEC) DNSKEY アルゴリズム IANA レジストリの更新
• RFC  6781 DNSSEC 運用プラクティス、バージョン 2
• RFC  6840 DNS セキュリティ (DNSSEC) の明確化と実装に関する注意事項
• RFC  6975 DNS セキュリティ拡張 (DNSSEC) におけるシグナリング暗号化アルゴリズムの理解
• RFC  7129 DNS における認証された存在拒否
• RFC  7344 DNSSEC 委任信頼維持の自動化
• RFC  7583 DNSSEC キーロールオーバーのタイミングに関する考慮事項
• RFC  8078 CDS/CDNSKEY 経由で親から DS レコードを管理する
• RFC  8080 DNSSEC 向け Edwards-Curve デジタル セキュリティ アルゴリズム (EdDSA)
• RFC  8198 DNSSEC 検証済みキャッシュの積極的な使用
• RFC  8624 DNSSEC アルゴリズム実装要件と使用ガイダンス
• RFC  8749 DNSSEC ルックアサイド検証 (DLV) を歴史的ステータスに移行
• RFC  9077 NSEC および NSEC3: TTL と積極的な使用
• RFC  9157 DNSSEC に関する IANA の考慮事項の改訂
• RFC  9276 NSEC3パラメータ設定のガイダンス
• RFC  9364 ( BCP 237) DNS セキュリティ拡張

DNSSEC を導入するには、サーバー側とクライアント側にソフトウェアが必要です。DNSSEC をサポートするツールには次のようなものがあります。

• Windows 7およびWindows Server 2008 R2には、再帰ネーム サーバーによる安全な応答と安全でない応答を区別できる「セキュリティ対応」スタブリゾルバーが含まれています。Windows Server 2012 DNSSEC は、Active Directory 統合ゾーンによる安全な動的更新と互換性があり、Active Directory による他のサーバーへのアンカー キーの複製も可能です。^{[82] [83]}
• 最も人気のある DNS ネーム サーバーであるBIND ( digを含む) には、新しいDNSSEC-bis (DS レコード) プロトコルと NSEC3 レコードのサポートが組み込まれています。
• Unbound は、 DNSSEC の概念に基づいて設計されるようにゼロから作成された DNS ネーム サーバーです。
• DNS ASP 用のGPL DNS 管理ソフトウェアであるmysqlBind が、DNSSEC をサポートするようになりました。
• OpenDNSSEC は、PKCS#11 を使用してハードウェア セキュリティ モジュールとインターフェイスする専用の DNSSEC 署名ツールです。
• Knot DNS はバージョン 1.4.0 で自動 DNSSEC 署名のサポートを追加しました。
• PowerDNS は、バージョン 3.0 以降、事前署名モードとライブ署名モードで DNSSEC を完全にサポートしています。
• DNSSECとは何か、そしてなぜ長期間にわたって実装することが重要なのか? — インターネット コミュニティとオランダ政府の取り組みをチェック

• DNS暗号化
• DNSカーブ
• DNS の拡張メカニズム (EDNS)
• TSIG
• リソース公開鍵基盤 (RPKI)

• H. Yang、E. Osterweil、D. Massey、S. Lu、L. Zhang (2010 年 4 月 8 日)。「インターネット規模のシステムへの暗号化の導入: DNSSEC のケース スタディ」。IEEE Transactions on Dependable and Secure Computing。8 ( 5 )。pp. 656–669。CiteSeerX 10.1.1.158.1984。doi : 10.1109 /TDSC.2010.10。S2CID 14887477  。 

• DNSSEC – DNSSEC 情報サイト: DNSSEC.net
• DNSEXT DNS 拡張IETF ワーキング グループ
• DNSSEC ツール プロジェクト