Loading article…
ドメインネームシステムセキュリティ拡張（DNSSEC ）は、インターネットプロトコル（IP）ネットワークのドメインネームシステム（DNS）で交換されるデータを保護するために、インターネット技術タスクフォース（IETF）によって策定された一連の拡張仕様です。このプロトコルは、データの暗号化認証、存在の認証による否認、およびデータの完全性を提供しますが、可用性や機密性は提供しません。2026年現在、DNSSECの導入状況はまちまちです。
ドメインネームシステム（DNS）の当初の設計には、セキュリティ機能は含まれていませんでした。これは、拡張性の高い分散システムとしてのみ構想されたものでした。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）、暗号化クライアントハロー（ECH用のSVCB/HTTPSレコード[ 2 ] [ 3 ] ）など、DNSに保存されている暗号化証明書への参照を公開する他のセキュリティシステムをブートストラップするために使用できます。
DNSSECはデータの機密性を保証するものではありません。特に、すべてのDNSSEC応答は認証されますが、暗号化はされません。DNSSECはDoS攻撃を直接的に防ぐものではありませんが、間接的には一定の利点があります（署名チェックによって、信頼できない可能性のある相手も利用できるようになるため）。
DNSSEC以外の標準規格は、DNSサーバー間で送信される大量のデータ（ DNSゾーン転送など）を保護するために使用されます。RFC 4367に記載されているように、一部のユーザーや開発者は、DNS名について誤った思い込みをすることがあります。例えば、企業の共通名に「.com」を付けたものが常にドメイン名であると想定するなどです。DNSSECは、このような誤った思い込みを防ぐことはできません。DNSSECができるのは、データがドメイン所有者から提供されたものか、あるいは所有者から提供されていないかを認証することだけです。
DNSSEC仕様（DNSSEC-bisと呼ばれる）は、現在のDNSSECプロトコルを詳細に記述しています。RFC 4033、RFC 4034、RFC 4035を参照してください。これらの新しいRFCの公開（2005年3月）により、以前のRFCであるRFC 2535は廃止されました。DNSSECを規定するRFCの全セットは、 RFC 9364 （ BCP 237でもある）にまとめられています。
DNSのセキュリティ確保はインターネット全体のセキュリティ確保に極めて重要であると広く信じられているが[ 4 ] 、特にDNSSECの展開は妨げられてきた（ 2010年1月22日現在）。 いくつかの困難によって：
2026年3月現在、DNSSECは国別コードトップレベルドメインの83（45%）でのみ運用されています。[ 5 ] ICANNは2014年に新しい汎用トップレベルドメインにDNSSECを義務付けました。[ 6 ]すべての下位レベルドメインがDNSSECを使用しているわけではありません。Verisignは、.netセカンドレベルドメインで約5%、. comで約4%の採用率を報告しました。[ 7 ]セカンドレベルドメインの採用率は、 .nl（オランダ）、. cz（チェコ共和国）、. no（ノルウェー）、. se（スウェーデン）、. nu（ニウエ、かつては「new」のように聞こえた）で50%を超えています。[ 8 ] 2023年現在、google.com、amazon.com、microsoft.comなどの主要ドメインは署名されていません。[ 9 ]
DNSSECは、公開鍵暗号方式を使用してDNSルックアップ用のレコードにデジタル署名することで機能します。正しいDNSKEYレコードは、信頼できる第三者であるDNSルートゾーンの検証済み公開鍵セットから始まる信頼の連鎖によって認証されます。ドメイン所有者は独自の鍵を生成し、ドメイン名登録機関のDNSコントロールパネルを使用してアップロードします。登録機関は、secDNSを介してゾーンオペレーター（.comの場合はVerisignなど）に鍵を送信し、ゾーンオペレーターが署名してDNSに公開します。
DNSは複数のリソースレコードを使用して実装されます。DNSSECを実装するために、いくつかの新しいDNSレコードタイプが作成またはDNSSECで使用するように変更されました。
DNSSECを使用する場合、DNSルックアップに対する各応答には、要求されたレコードタイプに加えて、RRSIG DNSレコードが含まれます。RRSIGレコードは、応答DNSリソースレコードセットのデジタル署名です。デジタル署名は、DNSKEYレコードに含まれる正しい公開鍵を見つけることで検証されます。NSECレコードとNSEC3レコードは、リソースレコード（RR）が存在しないことを暗号学的に証明するために使用されます。DSレコードは、信頼の連鎖を使用してルックアップ手順でDNSKEYを認証するために使用されます。NSECレコードとNSEC3レコードは、なりすましに対する強力な耐性を提供するために使用されます。
DNSSECは拡張可能になるように設計されており、既存のアルゴリズムに対する攻撃が発見された場合、RFC 8624で説明されているように、後方互換性のある方法で新しいアルゴリズムを導入できます。次の表は、2019年6月時点で最もよく使用されている、または使用されていたセキュリティアルゴリズムを定義しています。[ 10 ]
セキュリティ対応の DNSリゾルバは、DNS ルックアップの結果から、クエリ対象のドメインの権威ネーム サーバーがDNSSEC をサポートしているかどうか、受信した応答が安全かどうか、何らかのエラーがあるかどうかを判断できます。ルックアップ手順は、多くのISPのネーム サーバーなどの再帰ネーム サーバーと、主流のオペレーティングシステムにデフォルトで含まれているスタブリゾルバで異なります。Microsoft Windows はスタブリゾルバを使用しており、特に Windows Server 2008 R2 と Windows 7 は、検証は行わないが DNSSEC 対応のスタブリゾルバを使用しています。[ 11 ] [ 12 ]
信頼の連鎖モデルを使用すると、親ドメイン ( DNS ゾーン) の委任署名者 (DS) レコードを使用してサブドメインの DNSKEY レコードを検証でき、さらにそのサブドメインには他の DS レコードを含めてさらにサブドメインを検証できます。たとえば、ISP ネーム サーバーなどの再帰リゾルバがドメイン "www. example.com " の IP アドレス ( A レコードおよび/またはAAAA レコード)を取得したいとします。
上記の例にはいくつかの例外がある。
まず、「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日現在 DNSSECのルートへの展開が完了しました。[ 13 ] .comドメインは有効なセキュリティキーで署名され、セキュア委任が2011年4月1日にルートゾーンに追加されました。[ 14 ]
スタブリゾルバは、「再帰クエリモードを使用して、DNS解決の作業の大部分を再帰ネームサーバーにオフロードする最小限のDNSリゾルバ」です。[ 15 ]スタブリゾルバは、リクエストを再帰ネームサーバーに転送し、応答の認証データ（AD）ビットを「応答のAnswerセクションとAuthorityセクションのすべてのデータの署名を再帰ネームサーバーが検証できたかどうかを調べるためのヒント」として使用します。[ 16 ] Microsoft Windowsはスタブリゾルバを使用しており、特にWindows Server 2008 R2とWindows 7は、検証は行わないがADビットを認識するスタブリゾルバを使用しています。[ 11 ] [ 12 ]
検証スタブ・リゾルバは、クエリ・メッセージ内のチェック無効（CD）ビットを設定することで、独自の署名検証を実行することもできます。[ 16 ]検証スタブ・リゾルバは、CDビットを使用して独自の再帰認証を実行します。このような検証スタブ・リゾルバを使用すると、インターネット・サービス・プロバイダやそれらへの接続が信頼できない場合でも、DNSSECを実装するドメインに対してクライアントにエンドツーエンドのDNSセキュリティが提供されます。
検証を行わないスタブリゾルバは、ユーザーのインターネットサービスプロバイダやパブリック再帰ネームサーバーによって制御される外部の DNSSEC 検証サービス、およびDNS over TLSなどの方法を使用して、自身とそれらのネームサーバー間の通信チャネルに依存する必要があります。[ 16 ] [ 17 ]
DNS の応答が正しいことを証明するには、DNS 以外のソースから正しいキーまたは DS レコードを少なくとも 1 つ知る必要があります。これらの開始点はトラスト アンカーと呼ばれ、通常はオペレーティングシステムまたは他の信頼できるソースから取得されます。DNSSEC が最初に設計されたとき、必要なトラスト アンカーはDNS ルートのみであると考えられていました。ルート アンカーは 2010 年 7 月 15 日に初めて公開されました。[ 18 ]
認証チェーンとは、対象ドメインの権威ネームサーバーへの信頼アンカーから始まる、リンクされた一連のDSレコードとDNSKEYレコードのことです。完全な認証チェーンがなければ、DNSルックアップの応答を安全に認証することはできません。
リプレイ攻撃を制限するために、キャッシュ用の通常のDNS TTL値だけでなく、RRSIGレコードには署名の有効期間を制限するための追加のタイムスタンプが設けられています。レコードが送信された時刻を基準とするTTL値とは異なり、タイムスタンプは絶対値です。つまり、セキュリティを意識したすべてのDNSリゾルバは、数分以内といった非常に正確な時刻同期を維持する必要があります。
これらのタイムスタンプは、ゾーンが定期的に再署名され、セカンダリサーバーに再配布される必要があることを意味しており、そうしないと検証リゾルバによって署名が拒否されます。
DNSSECでは、DNSKEYレコードに保存される鍵と、信頼アンカーを形成するための他のソースから取得される鍵など、さまざまな鍵が使用されます。
鍵の交換を可能にするには、鍵のロールオーバー方式が必要です。通常、この方式では、まず既存の古い鍵に加えて、新しい DNSKEY レコードに新しい鍵をロールアウトします。次に、有効期限が切れて古い鍵のキャッシュが不要になったと判断できるようになった時点で、これらの新しい鍵を使用できます。最後に、古い鍵を使用したレコードのキャッシュが不要になったと判断できるようになった時点で、古い DNSKEY レコードを削除できます。ルートなどの信頼アンカーへの鍵など、このプロセスはより複雑になり、オペレーティングシステムのアップデートが必要になる場合があります。
DNSKEYレコード内のキーは2つの異なる用途に使用でき、通常はそれぞれに異なるDNSKEYレコードが使用されます。まず、ゾーン署名キー（ZSK）を含む他のDNSKEYレコードに署名するために使用されるキー署名キー（KSK）があります。ZSKは他のレコードに署名するために使用されます。ZSKは特定のDNSゾーンによって完全に制御および使用されるため、より簡単かつ頻繁に切り替えることができます。その結果、ZSKはKSKよりもはるかに短くても、同じレベルの保護を提供し、RRSIG/DNSKEYレコードのサイズを削減できます。
新しいKSKが作成されると、DSレコードを親ゾーンに転送して公開する必要があります。DSレコードは、レコードのサイズを小さく保つために、完全なキーではなくKSKのメッセージダイジェストを使用します。これは、 .comドメインのような非常に大きなゾーンに役立ちます。また、親ゾーンでDSキーを更新する手順は、DNSKEYレコードを親ゾーンに配置する必要があった以前のDNSSECバージョンよりも簡単です。
密接に関連する原則として、アルゴリズムロールオーバーがあります。これは、ゾーンをある署名アルゴリズムから別のアルゴリズムに移行することを意味します。その良い例としては、アルゴリズム 8 (RSA/SHA-256) からアルゴリズム 13 (ECDSA/SHA-256) への移行が挙げられます。.at、.br、.cz、.ch、.fr、.ie、.nl [ 19 ]、.ph など、いくつかの ccTLD が既に移行しています。Verisignは2023年後半に.com 、 .net 、 .eduをアルゴリズム13に移行しました。[ 20 ] [ 21 ]ルートドメインのアルゴリズム 8 からアルゴリズム 13 への移行は、2024 年初頭現在計画中です。[ 22 ]
DNSベースの名前付きエンティティ認証（DANE）はIETFワーキンググループ[ 23 ]であり、DNSSECに基づいてTLS、DTLS、SMTP、S/MIMEとの暗号化された安全な通信をインターネットアプリケーションが確立できるようにするプロトコルと技術を開発することを目標としています。
新しいプロトコルは、公開鍵基盤に基づく従来のモデルに対して、さらなる保証と制約を可能にする。また、ドメイン所有者が第三者認証局を参照することなく、自ら証明書を主張することも可能になる。
DNSSEC ステープルド証明書のサポートはGoogle Chrome 14で有効になりましたが[ 24 ] 、後に削除されました[ 25 ] 。Mozilla Firefoxでは、 Firefox 56 まではアドオン[ 26 ]でサポートが提供されていましたが、ネイティブサポートが提案されたものの、最終的には却下されました[ 27 ] 。
DNSはインターネットの重要かつ基本的なサービスですが、1990年にスティーブ・ベロビンが深刻なセキュリティ上の欠陥を発見しました。そのセキュリティに関する研究が始まり、1995年に彼の論文が公開されると劇的に進展しました。[ 28 ] 最初のRFC 2065は1997年にIETFによって公開され、その仕様を実装する最初の試みにより、1999年にIETF RFC 2535として改訂された（そして完全に機能すると考えられた）仕様が生まれました。RFC 2535に基づいてDNSSECを展開する計画が立てられました。
残念ながら、IETF RFC 2535 仕様はインターネット全体に拡張する際に非常に大きな問題を抱えていました。2001 年までに、この仕様が大規模ネットワークでは使用できないことが明らかになりました。通常の運用では、DNS サーバーは親サーバーと同期がずれることがよくあります。これは通常問題ではありませんが、DNSSEC が有効になっている場合、この同期ずれデータは深刻な自己生成型サービス拒否攻撃を引き起こす可能性があります。元の DNSSEC では、子サーバーの鍵変更を実行するために複雑な 6 つのメッセージ プロトコルと大量のデータ転送が必要でした (DNS 子ゾーンはすべてのデータを親サーバーに送信し、親サーバーに各レコードに署名してもらい、その後、子サーバーが SIG レコードに保存するために署名を子サーバーに送り返す必要がありました)。また、公開鍵の変更は不合理な影響を与える可能性がありました。たとえば、「.com」ゾーンが公開鍵を変更した場合、2200 万件のレコードを送信する必要があります (すべての子サーバーのすべての署名を更新する必要があるため)。したがって、RFC 2535で定義されているDNSSECは、インターネット規模に拡張することができませんでした。
IETFはDNSSECを根本的に変更しました。これは、 RFC 2535の元のDNSSEC方式と区別するために、必要に応じてDNSSEC-bisと呼ばれます。この新しいバージョンでは、「委任署名者（DS）リソースレコード」を使用して、親ゾーンと子ゾーン間の委任ポイントで追加の間接レベルを提供します。新しい方式では、子のマスター公開鍵が変更されると、子の各レコードごとに6つのメッセージではなく、1つのシンプルなメッセージになります。子は新しい公開鍵を親に送信します（もちろん署名付きです）。親は各子に対して1つのマスター公開鍵を保存するだけで済みます。これははるかに実用的です。つまり、親と子の間で大量のデータが交換されるのではなく、親にプッシュされるデータは少量になります。ただし、これはクライアントが鍵を検証する際に少し多くの作業が必要になることを意味します。具体的には、DNSゾーンのKEY RRセットを検証するには、RFC 2535で要求される1つの署名検証操作ではなく、2つの署名検証操作が必要になります（他のタイプのRRセットで検証される署名の数には影響はありません）。これはDNSSECの導入をより実用的にするため、ほとんどの人は小さな代償だと考えている。新バージョンはRFC4033-4035で公開されている。
2024 年 1 月、仕様に準拠したすべての DNSSEC リゾルバに対して「KeyTrap」サービス拒否攻撃が発表されました。DNSSEC 仕様 (RFC4033-4035) では、リゾルバはアップストリームから署名付きパケットを受信すると、正しい「タグ」を持つすべてのキーをすべての署名に対して試行し、いずれかの組み合わせが正常に検証されるまで試行する必要があると規定されています。研究者らは、同じ「タグ」を持つ多数のキーと、その「タグ」に対応する多数の署名をパケットに含めることで、リゾルバの速度を 200 倍低下させることができます。これに対応して、リゾルバは検証エラー、キー タグの衝突、ハッシュ計算の量に制限を設けるようになりました。[ 29 ]
ドメインの不在を暗号的に証明するには、存在しないドメインに対するすべてのクエリへの応答に署名する必要があります。これは、鍵をオンラインで保持するオンライン署名サーバーにとっては問題ありません。しかし、DNSSECは、ゾーン署名鍵をコールドストレージに保管できるように、オフラインのコンピュータを使用してレコードに署名することを前提として設計されています。これは、考えられるすべてのホスト名クエリに対する応答を事前に生成することが不可能なため、存在しないドメインに対するクエリへの応答を認証しようとする場合に問題となります。
当初の解決策は、ゾーン内のすべてのドメインペアに対してNSECレコードを作成することでした。つまり、クライアントが存在しないドメインに対してレコードを照会した場合、サーバーはととk.example.comの間に何も存在しないことを示すNSECレコードで応答します。しかし、これは実際のドメインの存在を露呈するため、従来の認証されていないNXDOMAINエラーよりもゾーンに関する情報を多く漏洩します。a.example.comz.example.com
NSEC3 レコード (RFC 5155) は、名前を直接リストするのではなくハッシュ化する代替手段として作成されました。時間の経過とともに、GPU や専用ハードウェアを使用したハッシュ化の進歩により、オフライン辞書攻撃を使用して NSEC3 レスポンスを安価に総当たり攻撃することが可能になりました。NSEC5 は、権威サーバーがゾーンを変更するために使用できる秘密鍵を保持することなく NSEC レスポンスに署名できるようにするために提案されました。したがって、NSEC5KEY を盗むと、ゾーンをより簡単に列挙できるようになるだけです。[ 30 ]
プロトコルの複雑な進化と後方互換性の維持という要望から、オンラインの DNSSEC 署名サーバーは、存在の否定を直接認証する代わりに「白い嘘」を返します。RFC 4470 で概説されている手法では、要求されたドメインを語彙的に囲むドメインのペアを含む NSEC レコードが返されます。たとえば、 の要求は、 (架空の) ドメインとk.example.comの間に何も存在しないことを証明する NSEC レコードになります。これは NSEC3 レコードでも可能です。[ 31 ]j.example.coml.example.com
Cloudflare は、応答サイズの 3 分の 1 で同じ結果を達成できる 2 つの代替アプローチを先駆的に開発しました。[ 32 ] 1 つ目は、「白い嘘」アプローチのバリエーションである「黒い嘘」と呼ばれ、一般的な DNS クライアントの動作を利用して、存在しないことをより簡潔に表現します。[ 33 ] 2 つ目のアプローチでは、「レコードは存在するが、要求されたレコード タイプは存在しない」ことを証明することを選択し、これを「DNS ショットガン」と呼んでいます。[ 34 ] [ 32 ]
インターネットは重要なインフラですが、その運用は根本的に安全でない DNS に依存しています。そのため、DNS を安全にする強い動機があり、DNSSEC の導入は一般的にその取り組みの重要な部分と考えられています。たとえば、米国のサイバースペースを安全にするための国家戦略では、DNS を安全にする必要性が具体的に示されています。[ 35 ] 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 トランザクションなどのプロトコル拡張機能が、この負荷を軽減するために開発されています。[ 36 ]これらの課題に対処するため、インターネットは多くの組織にとって非常に重要であるため、DNSSEC の展開に多大な努力が続けられています。
早期導入国には、ブラジル( .br )、ブルガリア( .bg )、チェコ共和国( .cz )、ナミビア( .na ) [ 37 ] 、プエルトリコ( .pr )、スウェーデン( .se ) があり、これらの国は国別コードトップレベルドメインに DNSSEC を使用しています。[ 38 ] RIPE NCC は、インターネット割り当て番号機関(IANA)から委任されたすべての逆引きレコード (in-addr.arpa) に署名しています。 [ 39 ] ARINも逆引きゾーンに署名しています。[ 40 ] 2007 年 2 月、TDC は、この機能を顧客に提供し始めた最初のスウェーデンの ISP になりました。[ 41 ]
IANAは2007年6月から署名済みのルート証明書のサンプルを公開テストしていました。ルート証明書の本番署名に先立つこの期間には、いくつかの代替トラストアンカーも存在しました。IKS Jenaは2006年1月19日に1つを導入し[ 42 ] 、インターネットシステムコンソーシアムは同年3月27日に別のものを導入し[ 43 ] 、 ICANN自身も2009年2月17日に3つ目を発表しました[ 44 ]。
2009年6月2日、Public Interest Registryの.orgゾーンのレジストリサービスプロバイダーであるAfiliasが.org TLDに署名した。[ 45 ] AfiliasとPIRは2008年9月26日に、最初のフェーズでは、強い協力関係にある大手レジストラ（「友人や家族」）が「2009年初頭」からドメインに署名できるようになると詳細を述べた。[ 46 ] 2010年6月23日には、13のレジストラが.ORGドメインのDNSSECレコードを提供しているとリストされた。[ 47 ]
VeriSign は、NSEC3 実験のために .com および .net ドメインが登録できるようにするパイロット プロジェクトを実施しました。2009 年 2 月 24 日、同社はすべてのトップレベル ドメイン (.com、.net など) に 24 か月以内に DNSSEC を展開すると発表しました[ 48 ]。同年 11 月 16 日、実装の技術的な側面による遅延の後、.com および .net ドメインは 2011 年の第 1 四半期までに署名されると述べました[ 49 ] 。この目標は予定通りに達成され[ 50 ]、Verisign の DNSSEC 担当副社長である Matt Larson 氏は、DNSSEC の推進における役割により InfoWorld の 2011 年テクノロジー リーダーシップ賞を受賞しました[ 51 ] [ 52 ] 。
DNSSEC は、2010 年 7 月 15 日に初めてルート レベルで展開されました。[ 53 ]ルート トラスト アンカーを使用して、ルートから完全な信頼チェーンを持つすべての DNSSEC ゾーンを検証できるため、DNSSEC リゾルバの展開が大幅に簡素化されると予想されます。検証するには信頼チェーンを中断することなく信頼できるルートまでたどる必要があるため、上位のゾーンのいずれかが安全でない場合は、安全なゾーンに対してトラスト アンカーを構成する必要があります。たとえば、「signed.example.org」ゾーンが安全だが「example.org」ゾーンが安全でない場合、「.org」ゾーンとルートが署名されていても、ゾーンを検証するためにトラスト アンカーを展開する必要があります。
条約締結をめぐる政治的な問題は、主にいくつかの中心的な問題に関して、継続的な懸念事項となっている。
2008年9月、ICANNとVeriSignはそれぞれ実装提案を発表し[ 54 ]、10月には米国電気通信情報局（NTIA）が一般からの意見を募った[ 55 ] 。寄せられた意見が最終的な展開計画の設計に影響を与えたかどうかは不明である。
2009年6月3日、米国国立標準技術研究所（NIST）は、ICANN、 VeriSign、NTIAと共同で、2009年末までにルート署名を行う計画を発表した。 [ 56 ]
2009 年 10 月 6 日、第 59 回RIPE会議で、ICANN と VeriSign はルート ゾーン内に DNSSEC を展開するための計画された展開タイムラインを発表しました。[ 57 ]会議では、2009 年 12 月 1 日を起点として、毎月 1 つのルート ネーム サーバーに段階的に展開し、2010 年 7 月 1 日に最終的なルート ネーム サーバーが DNSSEC 署名付きゾーンを提供し、ルート ゾーンは RSA/SHA256 DNSKEY で署名されることが発表されました。[ 57 ]段階的な展開期間中、ルート ゾーンはダミー キーを使用する意図的に検証不可能なルート ゾーン(DURZ) を提供し、最終的な DNSKEY レコードは 2010 年 7 月 1 日まで配布されません。[ 58 ]これは、ゾーンの使用に署名するために使用されたキーが意図的に検証不可能であることを意味します。この展開の理由は、DNSSEC リソース レコードを要求するクエリに対するより大きな応答によって引き起こされるトラフィック パターンの変化を監視するためでした。
.orgトップレベルドメインは 2010 年 6 月に DNSSEC で署名され、その後 2010 年と 2011 年に.com、.net、.eduが続きました。[ 59 ] [ 60 ]国別コードトップレベルドメインは2010 年 5 月より鍵を預け入れることができました。[ 61 ] 2011 年11 月現在 トップレベルドメインの25%以上がDNSSECで署名されている。[ 62 ]
2010 年 1 月 25 日、L (ell) ルート サーバーが、意図的に検証不可能なルート ゾーン(DURZ) の提供を開始しました。このゾーンは、RFC 5702で定義されているRSAアルゴリズムを使用して作成されたSHA-2 (SHA-256) ハッシュの署名を使用します。2010 年 5 月現在、13 台のルート サーバーすべてが DURZ の提供を開始しました。[ 58 ] 2010 年 7 月 15 日、最初の完全な本番 DNSSEC ルート ゾーンが、SOA シリアル 2010071501 で署名されました。ルート トラスト アンカーはIANA から入手できます。[ 53 ]
ルートの下には、DNSSECを完全に展開するために署名が必要な多数のトップレベルドメインが存在します。インターネットのトップレベルドメイン一覧には、既存のトップレベルドメインのうち、どれが署名され、ルートにリンクされているかの詳細が記載されています。
2006 年 3 月、インターネット システム コンソーシアムはDNSSEC ルックアサイド検証レジストリを導入しました。[ 63 ] DLV は、ルート トラスト アンカーがない状況で DNSSEC をより簡単に展開できるようにすることを目的としていました。当時、バリデーターは DNS の署名付きサブツリーに対応する多数のトラスト アンカーを維持する必要があると想定されていました。[ 64 ] DLV の目的は、バリデーターがトラスト アンカー リポジトリの管理作業を信頼できる第三者にオフロードできるようにすることでした。DLV レジストリは、各バリデーターが独自のリストを維持する作業を繰り返す代わりに、トラスト アンカーの中央リストを維持しました。
DLV を使用するには、 DLV ゾーンの信頼アンカーで構成された、 BINDやUnboundなどの DLV をサポートするバリデータが必要でした。このゾーンには DLV レコードが含まれていました。 [ 65 ]これらのレコードは DS レコードとまったく同じ形式でしたが、委任されたサブゾーンを参照する代わりに、DNS ツリー内の別のゾーンを参照していました。バリデーターがルートからチェックしようとしている RRset への信頼チェーンを見つけられなかった場合、代替の信頼チェーンを提供できる DLV レコードを検索しました。[ 66 ]
署名のないトップレベルドメインやDNSSEC委任をサポートしていないレジストラなど、信頼関係にギャップがあったため、下位レベルドメインの管理者はDLVを使用して、DLVを使用するように構成されたリゾルバによってDNSデータを検証させることができました。これは、レジストラやTLDレジストリがDNSSECを適切にサポートする必要性を軽減することで、DNSSECの展開を妨げた可能性があります。また、DLVはDNSSEC検証のためのアクターとコードパスを増やすことで、複雑さを増しました。
ISC は 2017 年に DLV レジストリを廃止しました。[ 67 ] DLV のサポートは BIND 9.12 で非推奨となり、BIND 9.16 では完全に削除されました。[ 68 ] Unbound バージョン 1.5.4 (2015 年 7 月) では、サンプル構成とマニュアル ページで DLV が廃止されたとマークされました。[ 69 ] Knot Resolver と PowerDNS Recursor は DLV を実装していません。
2020年3月、IETFはRFC 8749を公開し、DLVを標準規格から外し、RFC 4432とRFC 5074を「歴史的」ステータスに移行した。[ 70 ]
米国国土安全保障省（DHS）の科学技術局は、「DNSSEC導入イニシアチブ」を後援しています。このイニシアチブは、「多くの国や官民の組織が参加するグローバルな協力体制の一環として、インターネットの命名インフラストラクチャのセキュリティを向上させるためのセキュリティ対策を、あらゆる分野が自主的に採用すること」を奨励するものです。DHSはまた、DNSSECを成熟させ、米国連邦政府内で導入するための取り組みにも資金を提供しています。
2007年3月30日、米国国土安全保障省が「DNSルートゾーンに署名するための鍵を米国政府が確実に管理する」ことを提案したと報じられた[ 71 ] 。しかし、その会議室には米国政府関係者は出席しておらず、記事の発端となった発言は別の人物によるものだった。国土安全保障省は後に、米国政府がそのような提案をしたという誤った結論に飛びついた理由について次のようにコメントした[ 72 ] [ 73 ]。「米国国土安全保障省はDNSSecを実装するための技術計画の開発に資金を提供しており、昨年10月にその初期草案を多数の国際的な専門家に配布して意見を求めた。草案では、ルートゾーン鍵の保有者、つまり「オペレーター」となる可能性のある人物について一連の選択肢が示されており、基本的には政府機関か請負業者に絞られる。「この文書のどこにも、ルート鍵オペレーターの身元に関する提案はしていない」と、国土安全保障省のサイバーセキュリティ研究開発マネージャーであるモーガン氏は述べた。
米国国立標準技術研究所（NIST）は、DNSSECの展開方法に関するガイダンスを記載したNIST特別刊行物800-81セキュアドメインネームシステム（DNS）展開ガイドを2006年5月16日に発行しました。NISTは、この展開ガイドを参照するNIST SP800-53-R1で、新しいDNSSEC連邦情報セキュリティ管理法（FISMA）要件をリリースする予定でした。米国の機関は、NIST SP800-53-R1の最終発行から1年以内に、これらの新しいFISMA要件を満たす必要がありました。[ 74 ] しかし、当時NSEC3は完成していませんでした。NISTは、分割ドメインの使用を提案していましたが、これは可能であることは知られていますが、正しく展開するのが難しく、上記のセキュリティ上の弱点があります。
2008年8月22日、行政管理予算局（OMB）は、米国連邦政府機関に対し、.govサイト全体にDNSSECを導入するよう求める覚書を発表した。.govルートは2009年1月までに署名されなければならず、.gov配下のすべてのサブドメインは2009年12月までに署名されなければならない。[ 75 ] この覚書は.govサイトに焦点を当てているが、米国国防情報システム局は、.mil（米軍）ドメインでもOMBのDNSSEC要件を満たす意向であると述べている。NetworkWorldのキャロリン・ダフィー・マーサンは、DNSSECは「鶏と卵のジレンマに陥っているため広く普及していないが、OMBの義務化により、卵が割れ始めているようだ」と述べている。[ 76 ]
いくつかのISPがDNSSEC検証DNS再帰リゾルバの導入を開始した。Comcastは米国で最初にこれを行った大手ISPとなり、2010年10月18日にその意向を発表し[ 77 ] [ 78 ]、2012年1月11日に導入を完了した[ 79 ] 。
APNICの調査によると、DNSSEC検証を実行するDNSリゾルバのみを使用するクライアントの割合は、2013年5月に8.3%に上昇した。[ 80 ]これらのクライアントの約半数は、 GoogleのパブリックDNSリゾルバを使用していた。
2015年9月、Verisignは無料の公開DNSリゾルバサービスを発表しました[ 81 ]。プレスリリースでは言及されていませんが、DNSSEC検証も実行します。
APNICのモニタリングによると、2016年初頭までに、DNSSEC検証を実行するDNSリゾルバのみを使用するクライアントの割合は約15%に増加した。[ 82 ]
Googleの公開再帰DNSサーバーは、2013年5月6日にDNSSEC検証を有効にした。[ 83 ]
最も人気のあるDNS管理ソフトウェアであるBINDは、バージョン9.5以降、デフォルトでDNSSECをサポートしています。
Quad9パブリック再帰 DNS は、2016 年 5 月 11 日に設立されて以来、メインの 9.9.9.9 アドレスで DNSSEC 検証を実行しています。Quad9 は、主にデバッグのために、DNSSEC 検証を実行しない代替サービスも提供しています。[ 84 ]
2023年9月、マイクロソフトは、SMTP通信中に証明書の真正性を検証するためにDNSSEC（ DANE経由）を利用すると発表した。 [ 85 ]
ジェフ・ヒューストンは、DNSSECの導入を断念すべきだと主張している。[ 86 ] 2016年、メールプロバイダーのFastmailは、当時発生した多数のDNSSEC関連の障害に言及し、DNSSECを導入する予定はないとブログ記事を公開した。[ 87 ]
インターネットインフラ企業Cloudflareは、DNSSECの創設者の1人を雇い、社内での実装を支援してもらうなど、より肯定的な反応を示している。[ 88 ]ドメインレジストリSpaceship（ Namecheap [ 89 ]が所有するブランド）は、ネームサーバーをホストしているサポート対象ドメインに対してDNSSECを自動的に有効にする。[ 90 ] 2025年、オランダのレジストリSIDNは、DNSSECは他のインターネットプロトコルと比較して複雑であるという主張に反論した。[ 91 ]
unbound-host)DNSSECの導入には、サーバー側とクライアント側の両方にソフトウェアが必要です。DNSSECをサポートするツールには、以下のようなものがあります。
DNSクライアントはスタブリゾルバです...
Server 2008 R2 および Windows® 7 の DNS クライアントは、検証を行わないセキュリティ対応のスタブリゾルバです。
スタブ リゾルバは、定義上、再帰クエリ モードを使用して DNS 解決の作業の大部分を再帰ネーム サーバーにオフロードする最小限の DNS リゾルバです。以前のRFCでは、 ロバート・ブレイデン（1989年10月）によって、より以前の定義が示されていました。ブレイデン、R.（編）。RFC 1123 - インターネットホストの要件 - アプリケーションとサポート。IETF（インターネット技術タスクフォース）。p. 74。doi ：10.17487/RFC1123。 「スタブリゾルバ」は
再帰ネームサーバーのサービスに依存します[...]
{{cite web}}: CS1 maint: url-status (リンク){{cite web}}: CS1 maint: url-status (リンク)