2 min. 読む

DNSSEC：定義、仕組み、そして重要な理由

ドメインネームシステムDNSは、インターネットの電話帳の役割を果たし、人間が読める名前をIPアドレスに変換する作業を1日に何十億回も行っています。DNSデータベースは、IPアドレスやドメインエイリアスなどの重要なDNSレコードを保存しており、サイバー脅威の標的となっている。しかし、この重要なインフラは、1980年代にセキュリティが組み込まれずに設計されました。従来のDNSの検証は、応答に対して同じIPアドレスを一致させることに依存していましたが、IPアドレスはなりすますことができるため、これは安全ではありません。DNSSECは、この根本的なギャップを修正するために存在し、もともと純粋に信頼だけで運用されていたシステムに暗号検証を追加しています。

DNSSECの概要

Domain Name System Security Extensions、通称DNSSECは、DNS Security Extensionsの略で、DNSデータに暗号署名を追加するIETFプロトコル仕様のセットです。これらの署名により、DNSリゾルバは、受信した情報が実際に権威あるソースから来たものであり、途中で改ざんされていないことを確認できます。

DNSSECが解決する中核的な問題は簡単です。DNSSECがないと、攻撃者は偽のDNS応答をリゾルバのキャッシュに注入することができます。 DNSキャッシュポイズニングとして知られるこの攻撃は、ユーザーが知らないうちに悪意のあるサイトにリダイレクトします。DNSSECは、なりすましやデータの改ざんを防ぐために、データの発信元認証を可能にし、デジタル署名によってDNSレコードの完全性を確保し、公開鍵暗号を使用し、慎重なDNSゾーン鍵管理を要求することで、これを防止します。

インターネット技術タスクフォース（IETF）は、2000年代初頭にRFC 4033、4034、および4035を含む一連のRFCを通じてDNSSECを標準化しました。2010年7月、ICANNがDNSルートゾーンに署名し、グローバルなトラストアンカーが確立され、世界中で実用的なDNSSECの展開が可能になりました。

DNSSECが何を行い、何を行わないかを理解することが重要です。DNSSECはDNSデータを認証し、A、AAAA、MX、およびTXTレコードが本物であり、変更されていないことを確認します。しかし、DNSクエリや応答を暗号化するものではありません。あなたのDNSトラフィックは、それを観察できる誰にでも見えるままです。暗号化のためには、DNS over TLSや DNS over HTTPSのような補完的なプロトコルが必要です。

DNSSECはまた、DNSインフラに対するすべての攻撃を防ぐわけではありません。大規模なDDoS攻撃は、署名に関係なく、依然としてDNSサーバーを圧倒する可能性があります。また、DNSSECは、ユーザーが偶然説得力のあるように見える正規に登録されたフィッシング・ドメインを訪問することを阻止することはできません。

DNSSECの実装は、鍵管理と信頼の連鎖の確立が必要なため、複雑になる可能性があります。 DNSSECの導入を成功させるには、親ゾーンとチェーン内の全ゾーンも署名する 必要がある。

今日、ほとんどのトップレベルドメインはDNSSECをサポートしています。ICANNのデータによると、1,400以上のTLDが署名されています。しかし、セカンドレベルドメインの採用状況は異なります。.comゾーンの約1～2%のみがDNSSECを有効にしています。一方、.nl（オランダ）や.se（スウェーデン）のような国別コードTLDは、強制的なポリシーにより署名率が90%を超えています。

なぜ気にする必要があるのでしょうか？DNSSECがなければ、組織が行うすべてのDNSクエリが無言の操作にさらされる可能性があるからです。 リゾルバのキャッシュを汚染した攻撃者は、従業員を認証情報収集サイトにリダイレクトしたり、電子メール配信を傍受したりすることができる。

DNSとDNSSECの適合性

DNSSECを深く掘り下げる前に、今日のドメインネームシステムの仕組みを簡単に復習しておきましょう。ブラウザにURLを入力すると、コンピュータのスタブリゾルバが再帰的DNSリゾルバに連絡します。多くの場合、インターネットサービスプロバイダ、企業ネットワーク、またはGoogleの8.8.8.8や Cloudflareの1.1.1.1のようなパブリックサービスによって提供されます。DNSリゾルバは、効率的で正確な解決を保証するために、正しいIPアドレスを取得するためにサーバのチェーンをたどることによってDNSクエリを処理します。

www.example.com。再帰DNSリゾルバはまず、13の論理ルートDNSネームサーバーの1つに問い合わせ、.comに関する情報を求める。ルートサーバーはベリサインが運営する.com TLDサーバーへの照会で応答する。次に、リゾルバはexample.comについて.comサーバーに問い合わせ、example.comの権威ネームサーバーへの再照会を受ける。最後に、リゾルバはその権威サーバーに問い合わせ、www.example.com のIPアドレスを含む実際のAレコードを取得します。

この階層システムの中で、リソースレコード、権威ネームサーバー、ゾーン署名キーなど、さまざまなDNSコンポーネントが連携して、各DNSゾーンを管理、制御、保護します。

このエレガントで階層的なシステムは、1987年にRFC1034と1035で定義された。問題は古典的なDNSプロトコルは強力な認証なしで設計された。 応答は主に送信元IPアドレスと16ビットのトランザクションIDを照合することで検証されたが、攻撃者はこのシステムを悪用することを学んだ。

2008年のカミンスキー脆弱性は、この設計がいかに脆弱であるかを証明した。セキュリティ研究者のダン・カミンスキーは、攻撃者が単一のクエリウィンドウの間に推測のフラッディングを行うことで、高い確率で偽の応答をリゾルバキャッシュに注入できることを示しました。この開示により、業界全体で緊急パッチが適用され、世界中でDNSSECの導入が大幅に加速されました。

DNSSECは、コアのクエリ/レスポンスモデルを変更することなく、既存のDNSをラップする拡張レイヤーとして統合されます。 未署名のゾーンは、検証を行わないリゾルバでは正常に動作し続ける。検証を行うリゾルバは署名付きゾーンに対して追加の暗号チェックを行うだけである。 この後方互換性は、DNSネームスペース全体で段階的に採用していく上で極めて重要であった。

相互接続されたノードを持つグローバルネットワークを描いた抽象的な画像に、DNSデータの保護を象徴するセキュリティシールドを重ねたもの。この視覚的表現は、DNSスプーフィングやキャッシュポイズニングなどの脅威から保護するためのDNSセキュリティとDNSSEC検証の重要性を強調しています。

コアDNSSECの概念とレコードタイプ

DNSSECは、検証可能な信頼の連鎖を作成するために連携するいくつかの新しいDNSリソースレコードタイプを導入します。 これらの記録とその関係を理解することは、サインゾーンを扱う者にとって不可欠である。

DNSSECの基本単位はリソースレコードセット（RRSet）である。 これは同じ名前、タイプ、およびクラスを共有するDNSレコードのグループ化である。個々のレコードに署名するのではなく、DNSSECはRRSet全体に署名する。 このアプローチはアトミックな完全性を保証する。つまり、すべてのレコードの署名を無効にすることなく、セットの中の1つのレコードを改ざんすることはできない。

RRSIGレコードはRRSetをカバーするデジタル署名を含む。 ゾーンの秘密鍵を使って作成される各リソースレコード署名には、署名者名、有効期間、 使用アルゴリズムなどのメタデータが含まれる。リゾルバはRRsetデータのハッシュを再計算し、暗号署名と照合することで、 これらの署名を検証する。

DNSKEYレコードは署名の検証に使用される公開鍵を公開する。 これらのレコードはゾーンの頂点(example.comのような)に表示され、 キーの役割を示すフラグを含む。 フラグ値256はゾーン署名鍵を、257は鍵署名鍵を示す。

DSレコード(委任署名レコード)は、親ゾーンと子ゾーン間のリンクを作成する。DSレコードは親ゾーンに格納され、子ゾーンの公開鍵の暗号ハッシュを含む。例えば、example.comのDSレコードは .comゾーンに格納され、リゾルバはexample.comのDNSKEYレコードが真正であることを検証できる。各ゾーンの公開鍵は親ゾーンの秘密鍵によって署名され、これはDNSSECにおける 信頼の連鎖を確立するために不可欠である。このプロセスにより、信頼が親ゾーンから子ゾーンへと確実に受け継がれ、安全で 検証可能な階層が形成される。

NSECとNSEC3レコードは、認証された存在拒否を可能にする。 DNSクエリが存在しない名前を要求した場合、これらのレコードはその名前が本当に存在しないことを証明し、攻撃者が存在しない名前を実在すると主張することを防ぐ。NSECは既存の名前をソート順に連鎖させるが、NSEC3は暗号的にハッシュ化したレコード名を使用し、ゾーンの内容を簡単に列挙できないようにする。

CDSとCDNSKEYレコードは自動鍵管理をサポートする。 これらにより、子ゾーンは更新されたDSまたはDNSKEY情報を親ゾーンに通知することができ、従来レジストラとの間で必要であった手作業による調整を減らすことができる。

ゾーン署名鍵（ZSK）と鍵署名鍵（KSK）の分離は、特に注意を要する。 ZSKは通常のゾーンデータ(A、AAAA、MXレコード)に署名し、KSKは DNSKEY RRset自体にのみ署名する。 この分離により、オペレーターは、より安定したKSKとそれに関連する親ゾーンのDSレコードを変更しないまま、ZSKを頻繁に回転させることができる。

ネームシステムのセキュリティ拡張

ネームシステムセキュリティ拡張（NSSE）は、ドメインネームシステム（DNS）のセキュリティを強化するために設計されたプロトコルと標準の包括的なセットです。NSSEの中心はDNSSECであり、デジタル署名と公開鍵暗号を使用してDNSデータを認証し、その完全性を保証します。これらのシステムセキュリティ拡張の主な目的は、DNSスプーフィングやDNSキャッシュポイズニング（DNSデータを操作し、ユーザーを不正サイトにリダイレクトさせる攻撃）などの脅威を防御することです。

ネームシステムのセキュリティ拡張機能を活用することで、ドメイン所有者は、ドメインに関連付けられたDNSデータがインターネット上を移動する際に、真正かつ変更されていないことを保証することができます。これは公開鍵基盤の使用によって達成され、各署名済みゾーンはDNSレコードのデジタル署名を検証するためにリゾルバが使用する公開鍵を公開します。その結果、ユーザーとアプリケーションは、ドメインネームシステムから受け取る情報が正当であることを信頼することができ、ユーザーの信頼を維持し、さまざまなサイバー脅威から保護することができます。

DNSSEC検証のエンドツーエンドの仕組み

DNSSECの検証はDNS解決の経路に従い、トラストアンカーと呼ばれる 既知の出発点から検証を構築する。ほとんどのリゾルバにとって、このアンカーはルートゾーンの KSKであり、IANAとリゾルバのソフトウェア更新を通じて配布される。検証型再帰検索リゾルバーが署名付きドメインの問い合わせを処理する際、DNS階層の各段階で暗号検証を実行する。リゾルバーはルートDNSKEYを既に信頼している。そのキーを使用して、ルートゾーンの RRSIGがTLD(例えば.com)のDSレコードをカバーしていることを検証する。次に.comのDNSKEYを取得し、DSハッシュと一致することを検証する。このプロセスはターゲットドメインまで続く。

完全に署名された環境でwww.example.com。リゾルバは検証する：

  • ルートのDNSKEY（信頼できるアンカー）が.comのDSレコードに署名する。
  • .comのDNSKEYはDSハッシュと一致し、example.comのDSレコードに署名する。
  • example.comのDNSKEYはそのDSと一致し、wwwのAレコードに署名する。

これにより、ルートから要求されたDNSレコードまで、切れ目のない信頼の連鎖が形成される。 無効な署名、期限切れのRRSIG、DS/DNSKEYハッシュの失敗など、不一致があれば チェーンは切断される。

dnssec-failed.orgのような、ICANNが意図的に誤った設定をしたテストドメインを使って、検証の失敗を観察することができる。検証リゾルバはこのドメインに対してSERVFAILを返し、アクセスを完全にブロックする。検証不能なリゾルバの背後にいるユーザー（まだ世界的に約70％）にとっては、ドメインは正常に解決される。

DNSSECは、HTTPやSMTPのようなアプリケーションプロトコルを変更しません。単に、アプリケーションが受信するIPアドレスとその他のDNSデータが 本物であり、変更されていないことを保証するだけです。DNSSECは、DNSクエリ応答が正当なサーバーを指すことを保証するだけです。

認証された存在拒否の場合、NSECまたはNSEC3レコードは、問い合わせた 名前またはタイプが存在しないことを証明する。リゾルバーは、ゾーンに存在する名前を示す暗号署名された証明を受け取ることで、 問い合わせられた名前が現れるであろうギャップを確認することができる。

DNSSECリソースレコードの実際

DNSSECに関連する主要なDNSレコードタイプについて、より実際的な詳細を見てみよう。

RRSIGレコードはゾーンの秘密鍵(通常レコードではZSK)を使用して生成される。各署名は、署名アルゴリズム(ECDSAP256SHA256など)、署名された名前の ラベル数、元のTTL、開始/終了タイムスタンプを指定する。これらのタイムスタンプは非常に重要である。リゾルバは有効期限外の署名を拒絶する。ゾーン管理者は、検証の失敗を避けるために、有効期限が切れる前に レコードを破棄しなければならない。

DNSKEYレコードはゾーンの頂点に出現し、ロールオーバー期間中は複数の鍵を 含む可能性がある。257はSEP(Secure Entry Point)ビットが設定されたKSKを示し、256はZSKを示す。鍵タグは鍵データから計算される16ビットの識別子であり、リゾルバーが DNSKEYレコードと対応するDSレコードを迅速に照合するのに役立つ。

親ゾーンのDSレコードには、子ゾーンのKSKのハッシュが含まれる。典型的なDSレコードは、鍵タグ、アルゴリズム番号、ダイジェストタイプ(通常は SHA-256)、ダイジェストそのものを含む。 DNSSECの検証中に、リゾルバは子のDNSKEYを取得し、ハッシュを計算し、比較する。不一致はBOGUSステータスを生成し、検証失敗の原因となる。

NSECレコードはゾーンの名前を正規のソート順で連鎖する。各NSECは次に存在する名前を指し、その名前に存在するレコードタイプを列挙 する。 これは非存在を証明するが、ゾーンの内容を “ゾーンウォーキング “にさらす ことになる。

NSEC3はゾーン・ウォーキングに対処するため、名前をハッシュ化し、ソルトと反復回数を設定した上でチェーン化する。これは些細な列挙を防ぐものではあるが、決意のある攻撃者はオフラインでも 予測可能な名前をクラックすることができる。opt-outフラグは、署名されていないサブドメインが多数存在する大規模な ゾーンに対して有効である。

CDSとCDNSKEYレコードはDSとDNSKEYの書式を反映するが、子ゾーン自体に 公開される。親ゾーンの運用者は、これらのレコードをポーリングして委任署名者レコードを 自動的に更新し、鍵のロールオーバーとDNSSECの初期導入を合理化することができる。

DNSレコードのグループ化

DNSSEC実装の基本的な側面は、DNSレコードをリソースレコードセット（RRSet）にグループ化することである。 RRSetは、ゾーン内で同じ名前とタイプを共有するDNSレコードの集まりである。 個々のレコードに署名する代わりに、DNSSECは単一のRRSIGレコードでRRSet全体に署名する。 このアプローチにより、DNSデータの署名と検証のプロセスが合理化され、ドメイン所有者と検証リゾルバの両方にとってより効率的になる。

DNSレコードをRRSetにグループ化することで、DNSSECの実装が簡素化されるだけでなく、DNSインフラの管理性も向上します。RRSet内のレコードに変更が加えられると、セット全体が再署名され、関連するすべてのDNSデータの完全性と真正性が維持されます。ドメイン所有者にとっては、署名管理の複雑さが軽減され、DNSレコードの改ざんや不正な変更に対する防御がより強固になります。結局のところ、DNSレコードのグループ化は、最新のDNSインフラのスケーラビリティとセキュリティをサポートするベストプラクティスです。

ゾーン署名鍵、署名モード、鍵管理

DDNSSECの鍵管理の中心は、2つの異なる役割である。 ゾーン署名鍵(ZSK)は、ゾーンデータ-A、AAAA、MX、TXT、その他通常のレコードの 日常的な署名を処理する。鍵署名鍵(KSK)は、より限定された、しかし重要な機能を果たす。

運営者がこれらの役割を分けるのには、それなりの理由がある。ZSK秘密鍵は頻繁に使用され、暴露リスクが高いため、30〜90日ごとにローテートする ことで、漏洩による潜在的な損害を限定する。KSKはめったに変更されないが、年1回またはそれ以下である。なぜなら、ローテーションのたびに親ゾーンの DSレコードを更新する必要があり、通常はレジストラの調整が必要になるからである。

DNSSECの実装には3つの主要な署名モードが存在する：

  • オフライン署名：ゾーンはエアギャップされたマシンまたはHSM上で署名され、署名されたゾーン・ ファイルが権威サーバに転送される。運用上の利便性よりもセキュリティが優先される静的ゾーンに最適。
  • 集中型オンライン署名：専用の署名サービスが署名されていない更新を受信し、権威DNSサーバーに配信する前に署名する。動的更新のサポートとセキュリティのバランスをとる。
  • オンザフライ署名：権威サーバーは、DNSリクエストが到着するとリアルタイムでDNSSEC署名を生成します。非常に動的なゾーンに適していますが、サーバーが侵害された場合、キーの暴露リスクが高まります。

鍵のロールオーバーには、信頼の連鎖を断ち切らないよう、慎重なタイミングが要求される。 新しい鍵をDNSKEY RRsetに追加し、キャッシュが期限切れになるのを待ち (通常2回のTTL期間)、古い鍵を破棄する。 KSKのロールオーバーでは、古いKSKを削除する前に、新しいDSを親ゾーンに伝搬させ なければならない。

2018年のルートKSKのロールオーバーは、その危険性を示している。大規模な準備にもかかわらず、約0.3%のリゾルバがトラストアンカーの更新に失敗し、一時的なSERVFAIL応答が発生した。単一のゾーンの場合、このようなエラーは些細なものに見えるかもしれないが、影響を受けたユーザーにとっては実質的にドメインをオフラインにすることになる。

委任署名者

委任署名者(DS)レコードはDNSSECの信頼の連鎖の要であり、DNS階層内の 子ゾーンと親ゾーンのセキュリティを結びつける。DSレコードには、子ゾーンの鍵署名鍵(KSK)を暗号ハッシュ化したものが含まれ、 親ゾーンで公開される。これにより、再帰検索リゾルバーは子ゾーンが提示する DNSKEYレコードが本物であり、改竄されていないことを確認できる。

この接続を確立することで、DSレコードはドメイン所有者が親ゾーンから自身のDNSデータまで信頼を拡大することを可能にし、解決プロセスのすべてのステップが検証されることを保証します。このメカニズムは、攻撃者がチェーンのどの時点でも不正なDNSデータを注入することを防ぐため、DNSインフラ全体の完全性を維持するために不可欠です。ドメイン所有者にとって、委任署名レコードを適切に設定することは、DNSSECを導入し、DNSベースの攻撃からドメインを保護するための重要なステップです。

DNSSECの利点と限界

DNSSECの主な価値は、DNSキャッシュポイズニングとDNSスプーフィング攻撃に対する防御です。レスポンスの信頼性を暗号的に証明することで、攻撃者がユーザーをフィッシングサイトに無言でリダイレクトしたり、偽のMXレコードを通じて電子メールを傍受したりすることを防ぎます。 2008年のKaminsky脆弱性は、このような攻撃がいかに壊滅的な被害をもたらすかを実証しました。DNSSECは、署名付きゾーンに対してこのような攻撃を根本的に無効にしています。

基本的な保護にとどまらず、DNSSECは高度なセキュリティアプリケーションを可能にする。 DANE（DNS-Based Authentication of Named Entities）により、ドメイン所有者は、TLSAレコードを使用してDNSで直接TLS証明書情報を公開できる。これにより、従来の認証局のみに依存することなく、SMTPサーバーまたはWebサービスの証明書を検証できます。このようなアプリケーションには、認証されたDNSデータが必要であり、まさにDNSSECが提供するものです。

限界を理解することも同様に重要だ：

  • 機密性はない：DNSSECは認証はするが暗号化はしない。DNSクエリとDNSクエリ応答は観測者から見えるままである。 暗号化には、DNS over TLSまたはDNS over HTTPSが必要です。
  • DDoS保護なし：DNSSECは、DNSインフラに対するボリュメトリック攻撃を阻止することはできません。実際、より大きな署名付き応答は、増幅攻撃を悪化させる可能性があります。
  • 合法的に見える脅威からの保護がない：DNSSECは、タイポスクワッティングや、正規に登録され適切に署名されたドメイン名を詐称するユーザーを防ぐことはできません。

パフォーマンスに関する考慮事項には、DNSレスポンスが著しく大きくなることが含まれます-シグネチャは RRSetあたりおよそ500バイト追加されます。これは時にTCPフォールバックを引き起こし（待ち時間を追加）、帯域幅の消費を増加させます。DNSSECを備えたオープンリゾルバは、プレーンDNSと比較して、リフレクション攻撃を50倍以上のファクターで増幅する可能性があります。

このようなトレードオフにもかかわらず、ICANNやNISTを含むセキュリティ機関は、価値の高いドメインにDNSSECを推奨しています。オーバーヘッドは実際にありますが、DNSスプーフィングが深刻な攻撃を可能にする可能性がある公衆向けサービスでは、保護は複雑さを正当化します。

リスク、課題、そして普及が進まない理由

DNSSECは運用上のリスクをもたらし、それが採用のためらいの原因となっている。 有効期限切れの署名、DS/DNSKEYの不一致、無効な署名チェーンなどの設定ミスは、検証失敗の原因となる。 有効なリゾルバの背後にいる約30%のユーザーにとって、設定ミスのゾーンは単に機能しなくなるだけである。 クエリはSERVFAILを返す。

いくつかの障壁がDNSSECの導入を遅らせている：

  • 複数当事者の調整：署名には、ドメイン所有者、レジストラ、DNSホスティングプロバイダ間の調整が必要です。DSレコードは親ゾーンに到達するためにレジストラシステムを経由しなければなりません。
  • 専門知識のギャップ：多くの組織はDNSSECの経験が不足しています。設定ミスによる機能停止を恐れて、着手しない。
  • レガシーインフラストラクチャ：一部の企業環境には、DNSSECの検証を完全にサポートしていないリゾルバやアプライアンスが含まれており、互換性の問題が生じています。

採用の統計は、不均一な進捗を明らかにしている。ルートDNSゾーンは2010年以来署名されており、現在1,400以上のTLDがDNSSECをサポートしている。しかし、セカンドレベルの採用は大きく異なります。.nlゾーンは、レジストリのインセンティブと強制的なポリシーによって、95%の署名を超えています。対照的に、.comは1.5%程度で、数百万のドメインが未署名のままです。

リゾルバ側では、APNICの測定によると、DNSリゾルバの約30%がグローバルでDNSSEC検証を実施しており、2018年の約10%から増加している。進展は続いているが、ほとんどのエンドユーザーはまだ検証されていないDNS応答を受け取っている。

DNSSECはまた、検証の失敗以外のセキュリティ上の考慮点も提示している。 署名された応答が大きいと、権威サーバーはDNS増幅攻撃にとって魅力的な存在となる。オペレーターは、知らず知らずのうちに攻撃インフラになることを避けるために、応答速度制限を実装し、リゾルバ設定のベストプラクティスに従わなければならない。

主要な組織は、より広範な採用を提唱し続けています。ICANNはデプロイメントガイドを発行し、各国のサイバーセキュリティ機関は政府機関や重要インフラのドメインにDNSSECを推奨するようになっています。予測によると、CDS/CDNSKEYによる自動化によって運用上の摩擦が減るため、セカンドレベルの採用は2030年までに50%に達する可能性がある。

実世界での運用DNSルートゾーン署名式とトラストアンカー

DNSルートゾーンはDNSSECアーキテクチャの中でユニークな位置を占める。DSレコードを提供する親ゾーンがないため、ルートのKSKは 究極のトラストアンカーとしてアウトオブバンドで信頼されなければならない。すべてのDNSSECの信頼の連鎖はここから始まる。

ICANNは年に4～6回、米国と欧州の安全な施設でルート署名式を実施している。これらのセレモニーでは、並外れた手続き管理が行われる：ハードウェアセキュリティモジュール（HSM）にはルート秘密鍵が格納され、複数の暗号担当者がスマートカードとPINを同時に使用する場合にのみアクセスできる。ハードウェア・セキュリティ・モジュール（HSM）には、複数の暗号担当者が同時にスマートカードとPINを使用する場合にのみアクセスできるルート秘密鍵が格納されている。

2010年7月の最初のルートゾーン署名は、DNSSECの理論から実用的なグローバル展開への移行を示すものでした。 2018年のKSKロールオーバーは、2010年のKSKをKSK-2016に置き換えたもので、基本的なトラスト・アンカーを更新するシステムの能力が試された。 広範な働きかけにもかかわらず、約0.2％のリゾルバーが、古いソフトウェアや設定に起因する問題を経験した。今後のロールオーバーは2020年代半ばに予定されている。

再帰的リゾルバは、ソフトウェア配布またはIANAが管理する自動更新プロトコルを 通じてルートトラストアンカーを取得する。 最新のリゾルバー・ソフトウェアは通常、現在のアンカーと更新をフェッチするメカニズムを含み、鍵が変更されても信頼の連鎖が損なわれないようにしている。

これらの儀式は精巧に見えるかもしれないが、正当な保証を提供するものである。ルートゾーンの完全性はDNSSECをグローバルに支えるものであり、文書化され、監査可能なプロセスは、この重要なインフラが適切な厳格さを持って運用されているという信頼を築くものです。

この画像は、重要なDNSデータを保護し、DNSSEC検証のようなシステムセキュリティ拡張を保証するように設計された高度なセキュリティインフラを示す、整理されたサーバーラックで満たされた安全なデータセンターを描いています。この環境は、DNSクエリを保護し、ドメインネームシステムの完全性を維持することの重要性を強調しています。

ドメインにDNSSECを導入する

お客様のドメインでDNSSECを有効にする準備はできましたか？ このプロセスには、検証から継続的なメンテナンスまで、いくつかの段階がある。

確認する前提条件

  • お客様のTLDはDNSSECをサポートしています（ICANNの導入リソースをご確認ください）。
  • レジストラはDSレコードの提出を受け付けます。
  • お使いのDNSホスティングプロバイダーは、ゾーン署名とDNSKEY管理をサポートしています。

Cloudflareや AWS Route 53のような多くのマネージドDNSプロバイダーは、自動的に署名を処理します。自己管理ゾーンの場合は、権威サーバーソフトウェアと互換性のある署名ツールが必要です。

典型的な配備ステップ：

  1. ZSKとKSKのペアを生成する（またはプロバイダ管理署名を有効にする）
  2. DNSゾーンに署名し、DNSSEC署名をローカルで検証する
  3. DNSKEYレコードを公開する(自動DS管理のためにCDS/CDNSKEYを公開することもできる)
  4. レジストラのインターフェイスからDSレコードを提出する
  5. 伝播時間を確保し、完全なチェーンを検証する。

検証も同様に重要である。組織が再帰リゾルバを運用する場合、DNSSEC検証を有効にする（例えば、BINDのdnssec-validation yes ）。既知のドメインに対するテスト：適切に署名されたサイトはAD（認証済みデータ）フラグを返し、dnssec-failed.orgはSERVFAILを返すはずである。

運営のベストプラクティス：

  • 署名の有効期限を監視する：RRSIGの有効期限は通常30日。有効期限が切れる前に署名の辞任を自動化する。
  • キーのロールオーバーをテストする：本番運用の前に、ステージング環境でロールオーバー手順を練習する。
  • アラートを実装する：リゾルバでのDNSSEC検証失敗の監視を設定します。
  • 手順を文書化する：明確なランブックは、インシデントや予定されたロールオーバーの際のパニックを防ぐ。

正確なインターフェイスはレジストラとプロバイダによって異なるため、特定のボタンクリックを覚えるよりも、基本的なタスクを理解することに集中してください。目標は、停止を引き起こすことなくDNSSECを展開することです-慎重な準備とテストにより、それは達成可能です。

DNSSECのベストプラクティス

DNSSECの導入を成功させるには、単に署名を有効にするだけでなく、継続的な細部への注意と業界のベストプラクティスの遵守が必要です。ドメイン所有者は、鍵の漏洩リスクを最小限に抑えるために、定期的な鍵のローテーションを優先し、すべての秘密鍵が安全に保管されるようにする必要がある。理想的には、ハードウェアセキュリティモジュールやその他の保護された環境を使用することである。

DNSSEC検証の継続的な監視は不可欠です。これには、署名の有効期限を追跡し、失効する前にレコードを速やかに破棄することが含まれます。DNSインフラのすべてのコンポーネント（認証サーバー、再帰リゾルバ、およびレジストラインターフェース）がDNSSECの実装と検証を完全にサポートしていることを確認することも重要です。

テストはもうひとつの重要なステップだ。 ドメイン所有者は、検証の成功シナリオと失敗シナリオの両方をシミュレートするツールやテストドメインを使用して、DNSデータが正しく署名され、検証されていることを日常的にチェックすべきである。 これらのベストプラクティスに従うことで、ドメイン所有者は回復力のあるDNSインフラストラクチャを維持し、DNSベースの攻撃からユーザーを保護し、ドメインネームシステムの継続的な完全性と信頼性を確保することができます。

結論と次のステップ

DNSSECは、DNSが1980年代に設計されて以来存在する脆弱性に対処するため、ドメインネームシステムを、電子署名と 階層的な信頼の連鎖による 暗号検証を備えた、信頼されるすべてのアーキテクチャから変換します。保護メカニズムであるRRSIG署名、DNSKEY/DS連携、NSEC/NSEC3による認証拒否は、DNSキャッシュポイズニングやDNSスプーフィング攻撃を防ぎ、そうでなければユーザーを無言でリダイレクトさせることができる。不正なDNSデータを含む既存のDNSレコードに対して、検証リゾルバは単に操作されたDNSデータを完全に拒否する。

運用の複雑さにもかかわらず、DNSSECは2010年のルート署名以来、大きく成熟しています。広範なTLDのサポート、CDS/CDNSKEYによる自動化の改善、リゾルバの検証率の向上はすべて、その勢いを示している。主要なセキュリティ組織は、なりすましによって深刻な被害が発生する可能性のあるドメインに対してDNSSECを推奨しています。

DNSインフラの責任者にとっては、次のステップが現実的である：

  • 現在署名されているドメインとゾーンのインベントリ
  • 重要な一般向けサービスから段階的にDNSSECの導入を計画する。
  • 可能であれば、内部リゾルバでDNSSEC検証を有効にする。
  • DNSSEC障害の監視とインシデント対応手順の確立

さらなる学習リソースには、中核となるDNSSEC RFC（4033、4034、4035）、ICANNや地域ネットワーク情報センターからの展開ガイド、ベリサインのDNSSECアナライザーのようなテストツールがあります。理解から行動への道筋はこれまで以上に明確であり、セキュリティ上のメリットは投資を正当化するものです。