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

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レコードは、なりすましに対する強力な耐性を提供するために使用されます。

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

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 ] 。}

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 ]}

早期導入国には、ブラジル( .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」ゾーンとルートが署名されていても、ゾーンを検証するためにトラスト アンカーを展開する必要があります。

条約締結をめぐる政治的な問題は、主にいくつかの中心的な問題に関して、継続的な懸念事項となっている。

• 他国は米国によるインターネット支配を懸念しており、この理由から中央集権的な鍵管理システムを拒否する可能性がある。
• 一部の政府は、DNSSECを利用した暗号鍵配布を禁止しようとするかもしれない。

ルートの下には、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 ]}

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