- DNSSECは、DNSにデジタル署名と信頼の連鎖を追加することで、応答の真正性と完全性を保証します。
- 実用的なセキュリティには、署名付きゾーン、リゾルバ検証、およびKSKとZSKキーの適切な管理が必要です。
- DNSSECはクエリを暗号化したり、DoS攻撃を防いだりするものではありません。E-DNSSECなどの提案では、DNSトラフィックの機密性も確保しようとしています。
インターネットは、私たちがほとんど意識することのない、しかしブラウザを開くたびに必ず存在する、いくつかの重要な構成要素の上に成り立っています。その中でも最も重要なものの1つがドメインネームシステム（DNS）です。DNSSECやローカルネットワークのセキュリティについて語る時、私たちは実際には、不正なリダイレクト、なりすまし、その他の深刻な攻撃を防ぐために、この基盤を強化することを意味しているのです。
以前は、すべてが正常に動作することだけを優先していましたが、今日ではそれでは不十分であることがわかっています。DNSは80年代に大規模なサイバー攻撃を考慮せずに誕生しましたが、現在では名前解決だけでなく、各応答の正当性と完全性を検証する必要があります。そこでDNSSECが登場し、さらに最近では、機密性も追加することを目的としたE-DNSSECのような提案が出てきています。これは、ローカルネットワークや企業ネットワークのセキュリティを懸念している場合に重要な要素となります。
DNSとは何か、そしてなぜセキュリティにとってそれほど重要なのか？
ドメインネームシステム（DNS ）は、インターネットの電話帳のようなものです。覚えやすい名前（www.example.comなど）を、コンピュータが理解できる数値のIPアドレス（例えば、192.168.2.15やIPv6アドレスなど）に変換します。この仕組みがなければ、名前の代わりに数字を記憶しなければならず、それは全く非現実的です。
このインフラストラクチャは、ツリー構造の分散データベースとして構成されており、最上位にルートゾーン、その下にトップレベルドメイン（.es、.com、.orgなどのTLD）、さらにその下にドメインとサブドメインが配置されています。このデータベースの各部分は「ゾーン」と呼ばれ、1つ以上の権威ネームサーバーでホストされ、各ドメインの「公式」情報を公開します。
コンピュータ、携帯電話、その他のデバイスがウェブサイトにアクセスしようとすると、まずオペレーティングシステムの一部であるスタブリゾルバに問い合わせを行います。このリゾルバは、その問い合わせを再帰型DNSサーバー（通常はインターネットサービスプロバイダ、会社、またはGoogle Public DNS、OpenDNS、Quad9などのパブリックサーバー）に送信します。再帰型サーバーは、正しいIPアドレスが見つかるまで、複数の権威サーバーに問い合わせて回答を検索します。
再帰型リゾルバは、受信した応答をキャッシュすることで、後続のクエリの処理速度を向上させます。これは非常に効率的ですが、同時に攻撃者が「DNSキャッシュを汚染」して偽のデータを挿入する余地も生み出します。その結果、ユーザーが気づかないうちに、後続の多くのリクエストがこの改ざんされた情報で解決されてしまう可能性があります。
最大の問題は、DNSの本来の設計では、応答の正当性を検証する確実な方法がないことです。リゾルバは基本的に、応答がクエリしたIPアドレスと同じIPアドレスから来ているかどうかを確認しますが、その送信元IPアドレスは比較的簡単に偽装できます。これにより、例えば銀行のウェブサイトを模倣した不正サイトへの、気づかれないうちにリダイレクト攻撃が行われる可能性があります。
従来のDNSのセキュリティ上の限界
DNSプロトコルは、セキュリティが主要な懸念事項ではなかった時代に作成されました。そのため、現在ではDNSクエリとレスポンスは暗号化されずに平文で送信され、追加の保護なしにレコードデータが改ざんされる可能性があることが分かっています。
これにより、 DNSキャッシュポイズニングや中間者攻撃など、いくつかの種類の攻撃が可能になります。どちらの場合も、攻撃者は途中で偽の応答を挿入し、ブラウザに表示されるドメイン名は正当なままなので、ユーザーは何も異常に気づかないまま、攻撃者の支配下にあるウェブサイトにアクセスさせられます。
銀行のウェブサイトにアクセスしたと想像してみてください。コンピュータは再帰サーバーから銀行のドメインIPアドレスを要求しますが、攻撃者はサーバーを騙して、自身が管理する同一のウェブサイトのIPアドレスを含む偽の応答を受け入れさせてしまいます。ユーザーはすべてが正常だと思い込んで認証情報を入力しますが、サイバー犯罪者はそれを平文で受け取り、後で本物のサイトで使用します。
RFC 2845で定義されているトランザクション署名（TSIG）などのメカニズムは、DNSサーバー間の特定の操作（例えば、マスターサーバーとスレーブサーバー間のゾーン転送や動的更新）を保護するために用いられます。TSIGは、秘密鍵を共有する2台のマシンが、相手の身元と転送中のメッセージの完全性を検証することを可能にします。
しかし、TSIGの適用範囲は非常に限定的です。DNSデータの「真の」発信元を認証するものではなく、特定の2つのサーバー間のやり取りが改ざんされていないことを保証するだけです。ゾーン内の元の情報がサーバーに到達する前に既に侵害または改ざんされていた場合、TSIGはそれを検出できません。したがって、ゾーン転送にはよく使用されますが、公開されたDNSデータの真正性という根本的な問題は解決されません。
DNSSECとは何ですか？また、セキュリティにどのような貢献をしますか？
これらの弱点に対処するため、ドメインネームシステムセキュリティ拡張機能（DNSSEC）が開発されました。DNSSECは従来のDNSに取って代わるものではなく、受信したデータが正当であり、改ざんされていないことを検証できるセキュリティ層を追加するものです。
DNSSECは公開鍵暗号（非対称暗号）に基づいています。各DNSゾーンには鍵ペアがあり、秘密鍵は秘密に保持され、公開鍵はDNSサーバー自体で公開されます。ゾーンの所有者は秘密鍵を使用してそのゾーン内のレコードにデジタル署名を行い、公開鍵はその署名を検証するために使用されます。
再帰サーバーがDNSSECを使用してドメインに問い合わせを行う際、通常の情報（例えば、ドメイン名に関連付けられたIPアドレス）に加えて、検証に必要なデジタル署名と公開鍵も受信します。再帰サーバーは、公開鍵に対して署名を検証します。検証が成功すれば、データは署名後変更されていない真正なデータであるとみなされます。
検証が失敗した場合、リゾルバは何らかの問題が発生した（例えば、なりすましや転送中の改ざんなど）ことを認識し、クライアントにエラーコード（通常はSERVFAIL ）を返します。このようにして、ユーザーは潜在的に悪意のあるデータを受け取ることはありませんが、ユーザーから見ると、ページが「読み込まれない」かエラーが表示されるだけです。
DNSSECは、既存のDNS階層を活用する信頼の連鎖という概念も導入しています。ルートゾーンはトップレベルドメイン（.es、.comなど）の鍵に署名し、これらのトップレベルドメインはさらにその子ドメインの鍵に署名するというように連鎖していくため、ルートゾーンの公開鍵という単一の信頼点を用いて、どのドメインも検証できるようになります。
KSKおよびZSKの鍵、記録、信頼の連鎖
セキュリティをより効果的に管理するために、DNSSECは鍵署名鍵（KSK）とゾーン署名鍵（ZSK）という2種類の鍵を使用します。技術的には（暗号学的には）同じものですが、システム内での機能は異なります。
ZSKキーは、ゾーン内のすべてのリソースレコード（A、AAAA、MXなど）に署名するために使用されます。このキーが漏洩するとゾーン内のすべてのレコードに影響するため、リスクを最小限に抑えるために通常は頻繁にローテーションされます。一方、KSKは主にゾーンキー（ZSK）自体に署名するために使用され、そのハッシュは親ゾーンのDS（委任署名者）レコードとして公開されます。
役割分担のおかげで、ZSKの変更はより簡単になります。新しいZSKを生成し、KSKで署名し、ゾーンのDNSKEYレコードに公開するだけで、リゾルバが情報を更新します。DSは同じKSKを指し続けるため、親ゾーンを変更する必要はなく、KSKはより長く安定した状態を保ちます。
DNSSECは、データ署名と検証をサポートするために設計された、いくつかの種類の特定のレコードをDNSプロトコルに追加します。中でも重要なのは、DNSKEY、RRSIG、DS、NSEC/NSEC3、およびNSEC3PARAMです。これらを使用することで、クエリの基本的な動作を変更することなく認証ロジックを構築できます。
DNSKEYレコードには、署名の検証に必要なゾーンの公開鍵が格納されます。RRSIGレコードには、特定のレコードセット（「リソースレコードセット」）に関連付けられたデジタル署名が含まれます。DSレコードは、子ゾーンのDNSKEYのハッシュ値であり、親ゾーンに公開され、信頼チェーンのリンクとして機能します。
NSECおよびNSEC3レコードは、認証された存在否定を提供するために使用されます。つまり、ドメイン名またはレコードが存在しないことを暗号学的に証明し、実際には存在するものが存在しないことを示す偽の応答を紛れ込ませようとする攻撃（またはその逆）を防ぎます。
信頼の連鎖とDNSSEC応答の検証
DNSSECにおけるいわゆる信頼チェーンは、ルートゾーンから検証対象のドメインまで、DNSKEYレコードとDSレコードをリンクさせることで構築されます。その出発点はルートゾーンの公開鍵であり、これは信頼のアンカーとして機能し、通常は再帰リゾルバに直接設定されます。
例えば、mywebsite.es のようなドメインを検証する場合、論理的なプロセスは次のようになります。リゾルバは、.es キーに署名するルートの公開鍵を信頼します。.es ゾーンは、mywebsite.es KSK キーに対応する DS レコードを公開します。.es キーを使用してその DS を検証することで、リゾルバは mywebsite.es DNSKEY を信頼し、そこからすべてのレコードの RRSIG を検証できます。
チェーン内のいずれかの箇所で有効な署名が欠落している場合、またはDS（データ署名）が本来あるべき場所に存在しない場合、信頼の連鎖は途切れます。その場合、検証を実行する再帰サーバーはデータを安全とはみなさず、その構成に応じて、要求されたレコードを返さないか、応答を無効としてマークします。
この階層構造は、DNSSECを真に効果的に機能させるには、自分のゾーンだけに署名するだけでは不十分であることを意味します。親ゾーン（例えば、.es）とルートゾーンにも署名し、DNSレコードを正しく公開する必要があります。現在、DNSルートゾーン、ほぼすべての汎用トップレベルドメイン（gTLD）、および多くの国別コードトップレベルドメイン（ccTLD）は既に署名されています。
DNSSEC検証が有効になっている再帰サーバーが、署名が一致しない、またはリンクが欠落していることを検出すると、通常、クライアントへの応答にはRCODE SERVFAILエラーコードが付加されます。これはエンドユーザーにとっては混乱を招く可能性があります（「ウェブサイトが動作していない」）が、セキュリティの観点からは、改ざんされる可能性のあるデータに対する保護措置です。
DNSSECには、データ発信元認証という2つの重要な機能も導入されています。これは、レコードが実際に想定されるゾーンから送信されたものであることを検証する機能です。また、整合性保護という機能もあり、ゾーン所有者が秘密鍵で署名して以来、情報が変更されていないことを保証します。
DNSSECによって軽減される攻撃とTLS/HTTPSとの関係
DNSSECを実装することで、いくつかの一般的な脅威から保護することができます。まず、DNS応答のなりすましが極めて困難になります。攻撃者はゾーンの秘密鍵を知らずに有効な署名を生成する必要があるため、鍵が適切に管理されていれば暗号学的に不可能です。
さらに、DNSSECは、署名検証に失敗した改ざんされた応答の受け入れを防止することで、再帰型サーバーにおけるキャッシュポイズニングのリスクを低減します。また、DNSトラフィックに対する中間者攻撃（MITM攻撃）も困難にします。MITM攻撃では、攻撃者は転送中の応答を改ざんしますが、DNSSECは応答の検証に失敗した応答をリゾルバが破棄します。
しかし、DNSSECが何をしないのかを理解することが重要です。これらの拡張機能は、クエリやレスポンスの内容を暗号化するようには設計されていません。DNSSECを使用しても、他の補完的な技術（DoT、DoH、E-DNSSECタイプのソリューションなど）を使用しない限り、すべてのDNSトラフィックは平文で送信されます。DNSSECは、受信したものが本物であり、改ざんされていないことを保証することに重点を置いており、要求内容を隠すことに重点を置いていません。
これは、 TLSやHTTPSといったプロトコルとは明らかに異なる点です。HTTPSはブラウザとウェブサーバー間の通信を暗号化して第三者による傍受や改ざんを防ぎますが、DNSSECは単にDNSデータに署名することでなりすましを検出します。サイトはHTTPSのみ、またはDNSSECのみで構成できますが、両方を組み合わせることで、なりすましやスパイ行為に対するより包括的な保護が実現します。
ICANNやIETFといった組織は、レジストリ、レジストラ、ISP、ネットワーク事業者によるDNSSECの普及を長年にわたり推進してきました。その目的は、より多くのゾーンが署名され、より多くのリゾルバがそれらを積極的に検証することで、一般ユーザーが特別な操作をすることなく、これらの暗号化による保証の恩恵を受けられるようにすることです。
.esドメインにおけるDNSSECと所有者の義務
スペインの場合、Red.esが管理する「.es」ドメイン部門は、.es国別コードに基づくDNSサービスの品質とセキュリティを向上させるため、長年にわたり追加の技術と手順を導入してきました。これらの対策の中には、IETFの仕様に準拠したDNSSECセキュリティプロトコルの実装が含まれています。
.esドメインは、.ESトップレベルゾーンへの署名とDNSルートからの認証取得を担当し、グローバルな信頼チェーンに組み込まれます。つまり、.esドメインを所有していれば、このインフラストラクチャを活用してDNSSECで自身のドメインを保護できるということです。
ドメイン所有者としてDNSSECを有効にする一般的な手順は、権威DNSサーバーが署名済みゾーンを公開するようにすることです。通常、これにはゾーンの公開鍵を生成し、レコードに署名し、DNS鍵を公開し、鍵マテリアル（またはDSレコード自体）をレジストリまたはレジストラに送信して、親ゾーンに対応するDSレコードを作成してもらうことが含まれます。
実際には、多くのDNSホスティングプロバイダーやレジストラは、DNSSECを有効にするための比較的簡単なオプションを提供しており、コントロールパネルでチェックボックスをオンにするだけで済む場合もあります。ただし、プロバイダーやサービスレベルによっては、この機能に少額の年間費用がかかる場合があります。
ゾーンに署名が行われ、ドメインネームシステム（DNS）が正常に公開されると、ドメインはDNSSEC信頼チェーンの一部となります。それ以降、DNSSEC検証が有効になっているリゾルバは、ドメインのDNS解決を暗号的に検証できるようになり、ユーザーの信頼度が高まり、なりすまし攻撃のリスクが軽減されます。
ローカルネットワーク上のDNSSEC：ユーザー側検証
エンドユーザーやローカルネットワークのセキュリティを懸念する企業にとって、重要な疑問は「DNSSECのメリットを享受するには何が必要か？」ということです。幸いなことに、再帰型DNSサーバー（コンピュータが使用するサーバー）がDNSSECを検証していれば、各コンピュータで個別に設定する必要はありません。
これを行うには、 DNSプロバイダ（ISP、パブリックリゾルバ、または組織の内部DNS）が、DNSSEC検証が有効で適切に構成された再帰サーバーを備えていることが必要です。事実上、最新のリゾルバはすべて何年も前からDNSSECをサポートしており、有効にするには通常、設定ファイルを少し変更してルートトラストアンカーを追加するだけで済みます。
検証が有効になると、ローカルネットワーク上のコンピュータが署名付きドメインにクエリを実行すると、再帰リゾルバは応答を返す前にすべての署名と信頼チェーンを検証します。一致しない箇所があればレコードは返されず、ユーザーにはエラーが表示されるため、不正な可能性のあるサイトへの接続を効果的に防止できます。
ドメインがDNSSECで保護されているかどうかを確認するには、DNSSEC Analyzerなどのオンラインツールやその他の検証ユーティリティが利用できます。ドメインを入力すると、RRSIG（暗号署名）、DNSKEY（公開鍵）、DS（親ゾーン内のDNSKEYのハッシュ）などのレコードが表示されます。ツールがレコードに関連付けられたデジタル署名がないと表示した場合、そのドメインは「署名なし」または「安全でない」とみなされます。
この確認の結果、ドメインまたはローカルネットワークで使用しているDNSサーバーがDNSSECを活用していないことが判明した場合は、サービスプロバイダーまたはISPに連絡して有効化を依頼することをお勧めします。もしこのオプションが提供されていない場合は、DNSSEC検証をサポートするプロバイダーへの切り替えを検討する良い機会かもしれません。そうすることで、自社と顧客双方のセキュリティレベルを向上させることができます。
DNSSECの限界：プライバシーおよびその他の側面
DNSSECには多くの利点があるものの、すべてのDNSセキュリティ問題に対する万能薬ではありません。重要な問題点の一つは、クエリの機密性を確保できないことです。DNSSECを使用しても、DNSパケットは平文で送信されるため、トラフィックにアクセスできる人（例えば、セキュリティ対策が施されていない公共Wi-Fiネットワークなど）は、どのドメインがクエリされているかを知ることができます。
また、アクセス制御機能やサービス拒否攻撃（DoS攻撃やDDoS攻撃）に対する具体的な防御機能もありません。実際、署名、鍵、追加レコードなどのデータを追加することでDNS応答のサイズが大きくなり、インフラストラクチャが適切に構成および保護されていない場合、増幅攻撃に悪用される可能性があります。
一方、DNSSECには運用上の複雑さが伴います。鍵ペアの管理、ZSKとKSKのローテーション、親ゾーンにおけるDSの公開調整、そして信頼関係を断ち切るような不一致がないことを確認する必要があります。これらの手順に誤りがあると、ドメインの検証が正しく行われなくなり、サービス停止のように見える事態が発生する可能性があります。
DNSSECプロセス自体には、検証の実行方法や報告方法に影響を与える制御ビット（クエリのCDビットやレスポンスのADビットなど）がメッセージに含まれています。安全でない環境でこれらのビットを操作できる攻撃者は、再帰リゾルバが提供する保護を低下させようとする可能性があります。そのため、DNSSECを使用するリゾルバとクライアント間の通信は、安全なチャネルを介して行うことを推奨します。
これらの制約はあるものの、DNSSECはDNSの信頼性と完全性を強化する上で不可欠な要素であり続けています。しかし、さらに一歩進んでクエリの機密性も保証するためには、他の技術と組み合わせるか、より高度なソリューションへと進化していく必要があります。
E-DNSSEC：認証と暗号化されたDNSを目指して
DNSSECが抱えるプライバシー上のギャップに対処するため、E-DNSSEC（暗号化DNSSEC）という概念が提案されている。このアプローチの根底にある考え方は、DNSSECクエリに暗号化を追加することで、認証と署名に加えて、インターネット上やローカルネットワークを経由する際に第三者による傍受からも保護するというものである。
E-DNSSECの目的は、DNSSECの特性（認証性と完全性）と、DNSSECクライアントとDNSSECサーバー間のクエリの機密性を確保する暗号化メカニズムを組み合わせることです。これにより、DNSサービスの全体的なセキュリティが向上し、外部の傍受者がどのドメイン名が解決されているかを知ることができなくなります。
概念的なプロセスとしては、再帰サーバー上でクエリを分析し、暗号化してから権威サーバーに送信し、その後DNSSECを使用して通常どおり復号化して処理するという手順が取られます。応答は、署名と暗号化を施した状態で再帰サーバーまたはクライアントに返送され、プロセス全体を通して機密性が維持されます。
この組み合わせにより、DNSメッセージは解決プロセスの最初から最後まで安全に保護されます。DNSSECによって認証と完全性が確保され、追加の暗号化によって不正アクセスから保護されます。ローカルネットワークや企業ネットワークの環境では、このようなアプローチを他の境界セキュリティソリューションと統合することができます。
今日、E-DNSSECのような提案は、DNS over TLS（DoT）やDNS over HTTPS（DoH）といった技術と並んで、 DNSのプライバシーを強化するためのより広範な取り組みの一環です。その根底にある方向性は明確です。未来のDNSは、真正性と機密性の両方を備えていなければならず、単に名前を迅速に解決するだけでは不十分です。セキュリティも確保されなければなりません。
高度なサイバー攻撃、なりすまし、および基本的なインフラストラクチャを標的とした脅威がますます増加している環境において、DNSSECの導入は、あらゆる重要なドメインにとって既に重要なセキュリティ要件となっており、E-DNSSECなどの暗号化ソリューションへの移行は、ローカルネットワークを含むネットワークの保護をさらに強化するための論理的な次のステップとして浮上しています。
従来のDNSからDNSSEC、そしてE-DNSSECのような暗号化ソリューションに至るまで、このエコシステム全体は、DNSセキュリティがオプションではなく、インターネットアーキテクチャとあらゆる最新のローカルエリアネットワークの中核を成す要素であることを示しています。検証機能を持つリゾルバ、署名付きゾーン、適切に維持された信頼チェーン、そして将来的にはクエリ用の暗号化チャネルを備えることで、脆弱なネットワークと、現在および将来の課題に対応できるインフラストラクチャとの決定的な違いが生まれます。
