DNSSEC とその仕組み
Domain Name System Security Extensions（DNSSEC）は、インターネットプロトコル（IP）ネットワーク経由で送信されるデータを保護するために DNS レコードに追加される暗号化署名です。DNS の設計者は、プロトコルのセキュリティ対策を組み込まなかったため、攻撃者がレコードを偽造し、不正な Web サイトにユーザーを誘導する機会を見つけることができました。このため、DNS 応答の信頼性と完全性をさらに高めるために、DNSSEC プロトコルが導入されました。
DNSSEC は、既存の DNS レコードに暗号化署名を追加して、セキュリティで保護された DNS を設定することで機能します。署名は、AAAA や MX などの一般的なレコードタイプとともに DNS ネームサーバーに格納されます。次に、要求された DNS レコードに対応する署名をチェックすることで、レコードがその権威ネームサーバーから直接送信されていることを確認できます。これは、レコードがデジタル転送中に汚染されるなどして改ざんされていないことを意味し、これにより、偽のレコードが組み込まれるのを防ぎます。
署名の検証を容易にする
DNSSEC では、署名の検証を容易にするために、状況に応じて、次の DNS レコードタイプのいずれかを追加します。
リソースレコードの署名（RRSIG）： レコードセットの暗号化 DNSSEC 署名が含まれます。
DNSKEY： 公開署名鍵が含まれます。
DS： DNSKEY レコードのハッシュが含まれます。
NSEC および NSEC3： ゾーン内の次のレコード名へのリンクを提供し、レコード名に使用可能なレコードタイプも一覧表示します。
CDNSKEY および CDS： 要求された DS 状態を子ゾーンから親ゾーンに転送し、親ゾーンの DS レコードへの更新を要求します。
ドメインで DNSSEC を有効にすべきか
DNSSEC では、キャッシュポイズニングや応答偽造からドメインを保護します。現在のデジタル環境では、Web サイト所有者のアーキテクチャをエンドツーエンドから保護することが求められており、DNS 攻撃が成功するとブランドの評判が著しく損なわれる可能性があるため、DNSSEC はドメインにとって重要な拡張機能です。DNS 解決は、ユーザーが Web サイトのアプリケーションと対話する前に実行されます。攻撃者が DNS を傍受した場合、Web サイトにアクセスしようとしているユーザーは、本来のサイトではなく、（ユーザーを騙すことを目的とした）偽のサイトに誘導される可能性があります。プロトコルのアグレッシブキャッシュアーキテクチャでは、有害なレコードを迅速に修正することが困難になります。
このため、強力なファイアウォールで Web サイトを強化しても、DNSSEC を使用してサイトの DNS アーキテクチャが十分に保護されなければ、エンドユーザーのデータとテクノロジーはリスクにさらされます。
DNS レコードを RRSet にグループ化する
DNSSEC とドメインの統合は、DNS レコードを名前とレコードタイプ別にリソース・レコード・セット（RRSet）にグループ化することから始まります。DNS 自体は DNS ゾーンに分割されます。ゾーンとは、DNS 所有者の組織全体またはネットワーク管理者によって監視される全体的な DNS 名前空間の一部です。このゾーンにより、権威ネームサーバーなどの DNS コンポーネントを詳細にメンテナンスできます。
各ゾーンは、ゾーン署名鍵（ZSK）と呼ばれる公開鍵と秘密鍵の組み合わせにより署名されます。生成された署名は、ゾーンファイル自体に RRSIG レコードとして公開されます。たとえば、ホスト名「www.dsnsecexample.com」に A レコードと AAAA レコードの両方が含まれている場合、ゾーンファイルは各 IP バージョンに対応する RRSIG レコードをアドバタイズします。
DNS ゾーンを分離することで、攻撃によって万が一 1 つのゾーンが感染しても、隣接するゾーンは保護されます。
リソースレコードの署名
RRSIG レコードでは、RRSet のデジタル DNSSEC 署名を保持します。これらのデジタル署名は、署名済み RRSet にあるデータの認証に使用されます。リゾルバーでは、DNSKEY レコードに格納されている公開鍵を使用して署名を検証できます。
レコードタイプと所有ドメイン名の RRSet は、署名された DNS ゾーン内に格納されます。ドメイン・ネーム・サーバーが ZSK ペアの秘密鍵を使用して、特定のゾーン内の RRSet に署名する場合、RRSIG レコードは各 RRSet のデジタル署名の格納に使用されます。従って、署名されたゾーンには各 RRSet の RRSIG レコードが含まれます。
RRSIG レコードは次のコンポーネントで構成されています。
署名対象タイプ： RRSIG で署名となる DNS レコードタイプ
アルゴリズム： 最終的な署名を生成する暗号化アルゴリズム
ラベル数： オリジナルの RRSIG レコード名のラベル数（ワイルドカードの検証に使用）
オリジナル TTL： 対象となるレコードセットの TTL 値
署名の有効期限： 署名の有効期限が切れる時刻
署名の開始時刻： 署名が最初に作成された時刻
鍵タグ： この RRSIG 署名の検証に使用される DNSKEY レコードを識別する数値
署名者名： この署名の検証に使用される DNSKEY レコードの名前
署名： 送信の検証に使用される暗号化署名
ゾーン署名鍵
ZSK は送信データを認証するための鍵です。ZSK は、鍵署名鍵（KSK）と同じ RRSet の側面であり、この DNSKEY RRSet に署名するための対応する秘密鍵が含まれます。各ゾーンには ZSK ペアがあります。DNSSEC 対応ゾーンは公開 ZSK を DNSKEY レコードとして通知し、リゾルバーが RRSIG 値を認証できるようにします。
DNSSEC 検証では、ZSK と他の DNSSEC 認証鍵が区別されないため、鍵署名鍵と ZSK の両方に 1 つの鍵を使用できます。検証が成功したことは、ゾーン管理者のみが秘密 ZSK にアクセスできるため、DNS レコードが偽造されたり、転送中に操作されたりしていないことを示します。
ZSK はゾーンの署名に使用される秘密鍵に対応し、通常はこの RRSet に署名する秘密鍵に対応する署名公開鍵と同じ RRSet の一部です。
鍵署名鍵
KSK は、DNSKEY レコードのセキュリティ体制をさらに改善するために実装された、計算コストの高い鍵ペアです。これは、ゾーン管理者の管理の負担を軽減するために導入されました。KSK は秘密鍵に対応し、特定のゾーンの他の認証鍵の署名に使用されます。通常、KSK に対応する秘密鍵は ZSK に署名します。ZSK 自体には、DNS ゾーン内で検出された他のデータに署名するための対応する秘密鍵があります。リゾルバーでは、このデジタル署名を、公開 KSK を通知する適切なプレーンテキスト DNSKEY レコードで認証します。
更新頻度が高い ZSK と異なり、KSK とそれに対応する委任署名者レコードは定期的にしか更新されません。このため、セキュリティと運用の観点から理想的なアーキテクチャは、頻繁にローテーションする ZSK を個別の永続的な KSK で自己署名を行うものです。この実装では、DNS ゾーンを潜在的な脅威から保護するだけでなく、継続的な DNSSEC メンテナンスの量を最小限に抑えることができます。
委任署名者レコード
DNSSEC では、公開 DNS リゾルバーを使用した「信頼チェーン」モデルを作成するために、委任署名者（DS）レコードを設定しています。これらのシナリオでは、攻撃者が理論的に DNS 応答を偽装し、ゾーンの完全性を損なう偽造 DNSKEY レコードを返す可能性があります。DS レコードでは、親ゾーンの公開 KSK のフィンガープリントを公開します。
検証中、リゾルバーは親ゾーンの DS レコードが子ゾーンの対応する DNSKEY レコードと一致していることを確認し、子の鍵ペアの正当性を認証します。この信頼チェーンはルートゾーンまで保持され、ほとんどの再帰リゾルバーに組み込まれたトラストアンカーが含まれます。
NSEC および NSEC3
Next Secure（NSEC）レコードを使用すると、特定のゾーン内に名前が存在するかどうかを判断できます。NSEC は、ゾーンにレコードが存在しない場合の問題を解決するために導入されました。これは、「非存在」認証の問題と呼ばれることもあります。攻撃者はこの脆弱性を悪用し、Web サイトのホスト名の NXDOMAIN 応答を偽造してサイトを利用不能にすることができます。
NXDOMAIN は、存在しない名前のクエリーを受信したときに存在するゾーン内の次の正規レコードを示す NSEC レコードと、その名前に表示されるレコードのタイプを含めることで、この欠陥に対処します。
たとえば、「example.com」ゾーンがソートされ、「beta.example.com」が最初のレコードである場合、「alpha.example.com」にクエリーを実行すると、「beta.example.com」を指す NSEC レコードと NXDOMAIN が生成されます。NSEC レコードは、他のレコードと同様に、ZSK によって署名され、対応する RRSIG が含まれます。その結果、NXDOMAIN 応答では、認証済み RRSIG NSEC レコードを有効にする必要があります。
NSEC3 は、ゾーン内の有効なすべてのレコードを一覧表示するために使用されている NSEC レコードの問題に対処するために開発されました。NSEC3 は NSEC と同じように動作しますが、ゾーン内の次のセキュア名はクリアテキストで表示されるのではなく、ハッシュされます。これにより、情報のセキュリティを保護し、ゾーンウォーキングを防ぐことができます。
DNSSEC の操作モード
静的ゾーンのオフライン署名
DNSSEC の操作モードは多くあり、各モードには、DNS ゾーン内のデータをどのように署名するかに関する独自のアプローチがあります。これらのモードのうち、最も一般的なモードの 1 つは、静的ゾーンのオフライン署名です。これにより、外部の脅威から署名システムを強力に保護できます。このオペレーティングモデルは、現在ネットワークに接続されていないマシンで検出された秘密鍵を保持し、DNS ゾーンで検出された情報が頻繁に変更されない場合に有効です。
集約型オンライン署名
集約型オンライン署名は、DNSSEC 操作のもう 1 つの繰り返しモードです。管理者が専用の制限付きアクセス DNS でデータに署名している場合、集中型オンライン署名により、DNS データをすばやく変更してゾーンに公開できます。静的ゾーンのオフライン署名と同様に、集中型オンライン署名では、単一または複製された中央の署名者がすべてのデータ署名を実行します。次に、新たに署名されたデータが権威 DNS サーバーに循環します。
オンザフライ署名
オンザフライのデータ署名は、必要に応じて権威 DNS サーバーがデータに署名できるようにする DNSSEC の操作モードです。このアプローチの問題は、鍵がさまざまなマシン上に存在し、それぞれがインターネットに直接アクセスできる状態になる可能性があることです。これにより、攻撃者が名前空間に外部からアクセスするための手段が増えることになります。鍵配布（送信者が秘密鍵の値を選択して受信者に安全に送信する場合）も、オンザフライ署名によって複雑になり、各ノードのコンピューティング要件が不必要に増加する可能性があります。
DNSSEC を組み込むリスク
DNSSEC はネットワークセキュリティを強化するための重要な方法ですが、意図せず重大な脆弱性を引き起こす可能性があります。DNSSEC では、分散型サービス妨害（DDoS）攻撃のリスクが高まり、その影響が増大する可能性があります。DDoS では、サーバー、サービス、またはネットワークが複数のデバイスからのトラフィックによって一度に中断されます。DNSSEC では、レコードを適切に検証するために追加のフィールドと暗号化情報が必要になるため、DNS クエリー応答の数が増加します。つまり、DNSSEC がなければ、攻撃者が大量の応答を駆使して、ゾーンに対してはるかに多くの攻撃ボリュームを仕掛けることができます。
3 ウェイハンドシェイクが必要
伝送制御プロトコル（TCP）は接続指向プロトコルであるため、低速になり、 3 ウェイハンドシェイクが必要になります。そのため、DNS（および DNSSEC）では User Datagram Protocol（UDP）を使用しています。UDP は高速ですが、リスクの高いプロトコルであり、接続のオープン、維持、終了の要件がなく、宛先への署名済みデータの配信も保証されません。UDP で提供されるのは、チェックサムの形式の最も基本的なエラーチェック機能のみです。ハンドシェイクは必要ないため、送信されたデータが攻撃者に簡単に傍受されます。
UDP スプーフィングは、ターゲットの IP アドレスを UDP ソース IP アドレスとしてリストする有効な UDP 要求パケットを攻撃者が生成するときに実行されます。攻撃者は、スプーフィングされたソース IP を中間サーバーに送信し、その中間サーバーがすべての UDP 応答パケットを送信して、要求パケットよりもはるかに大きい応答を生成します。この応答は、ターゲットの IP アドレスに送信される攻撃トラフィックのレベルを上げるのに十分です。
このような状況では、DNS クエリーの長さも増大し、攻撃の重大度が増幅されます。これらの攻撃が増幅される範囲は、応答サイズと要求サイズの比率で表されます。たとえば、攻撃者が DNS サーバーに 64 バイトの要求を送信すると、3,400 バイトを超える悪意のあるトラフィックが生成され、選択した被害者に送信される可能性があります。
ルート署名セレモニーを理解する
DNS ルート署名セレモニーは、ルート DNS ゾーンの公開鍵情報に署名するために、今後数か月間実行される厳格な手順です。このプロセスにより、共謀者のグループがルート署名鍵を侵害する可能性を 100 万分の 1 未満に抑えることができます。これは、ルート KSK を保護する 2 つの場所のいずれかで実行されます。このプロセスで使用される秘密署名鍵は、DNSSEC で保護されたインターネットのロックを解除するための鍵です。
親のないルート DNS ゾーンの問題を解決する
このセレモニーでは、親のないルート DNS ゾーンの問題が解決されます。つまり、一部の親ゾーンでは完全性を監視できないゾーンが解決されます。これには、セレモニー管理者、内部監視者、認証情報金庫管理者、ハードウェア金庫管理者、3 人の暗号オフィサーなど、少数の参加者が必要です。各メンバーは、インターネットコミュニティのボランティアである暗号オフィサーとは別に、ICANN（Internet Corporation for Assigned Names and Numbers）でもあります。
認証情報金庫にアクセスする
認証情報金庫とハードウェア金庫の 2 つの金庫があります。ルート鍵にアクセスするためには、両方にアクセスする必要があります。認証情報金庫管理者は、認証情報金庫を開けることができますが、セレモニー管理者と暗号オフィサーが保持する 2 つの鍵がそれぞれ必要です。これらのボックスには、ハードウェア金庫内のハードウェア・セキュリティ・モジュールを開けるために必要なオペレーターカードとセキュリティ許可カードが収められています。カードは、不正開封防止袋で包装されたプラスチックケースに納められ、認証情報金庫に保管されます。
ハードウェア金庫を開ける
次に、ハードウェア金庫管理者が安全な部屋に入り、ハードウェア・セキュリティ・モジュールを保管しているハードウェア金庫を開けます。ハードウェア金庫には、バッテリーやハードディスクを搭載していないノートパソコンも保管されています。このノートパソコンは、セキュリティモジュールにコマンドを送信するように設計されています。これは、セレモニーのルート DNS 鍵の署名に使用されるもので、すべての側面が綿密に記録され、後々のためにインターネットにライブストリーミングされます。
暗号オフィサーが携わる
セレモニーが開始されたら、暗号オフィサーがセレモニー管理者にオペレーターカードを渡す必要があります。セレモニー管理者は、DVD からノートパソコンを起動し、セレモニーログが記録されている USB を初期化します。次にセレモニー管理者が 3 枚のオペレーターカードを使用してセキュリティモジュールを有効にし、イーサネットケーブルを介してノートパソコンに接続します。鍵署名リクエストがノートパソコンにロードされ、鍵署名リクエストの PGP ハッシュが計算されて、提供されたハッシュと同一であることが確認されます。この時点で、セレモニー管理者は秘密 KSK を使用して鍵署名リクエストに署名します。秘密 KSK では、デジタル署名のコレクション（RRSIG レコード）が作成されます。
ドメインセキュリティを強化するために、DNSSEC をすぐに実装する
デジタルエコシステムの完全性とブランド全体の評判に恒久的に影響を与えるには、ドメインに対する DNS 攻撃を 1 つだけ成功させれば済みます。DNSSEC 暗号化署名は、キャッシュポイズニングや応答偽造などのサイバー脅威からドメインを保護する DNS 解決プロセスを強化します。最終的には、組織とエンドユーザーのデータとテクノロジーのエンドツーエンドのセキュリティが実現されます。
Akamai の多様な DNS ソリューションを見る
Akamai では、継続的にプラットフォームを拡張し、ドメイン所有者向けの多様な優れた DNS サービスを可能にしています。
ドメインの安定性と耐障害性を Edge DNS サービスが実現します。
データセンター、クラウド展開、CDN の負荷分散を Global Traffic Management が実現します。
アプリケーションを Application Load Balancer（ALB）Cloudlet で大規模に拡張できます。
ネットワーク内のすべてのデバイスによる DNS セキュリティツールのチェックと、DNS リゾルバーのセキュリティツールとしての使用を Secure Internet Access Enterprise が可能にします。
さまざまな DNS リソースへのアクセスが Akamai コミュニティへの参加することで可能になります。
DevOps の専門家の方ならAkamai の 開発者コミュニティをご覧ください。
サポートが必要な場合は 今すぐ Akamai にお問い合わせください。
2021 年 3 月 19 日発行。2022 年 6 月更新
