DNSSEC：DNS応答を認証する

2008年、研究者のDan Kaminsky氏は、DNSリゾルバーに対する重大な攻撃を公表しました。この攻撃は、DNS応答に含まれる16ビットのトランザクションIDフィールドが小さいことを悪用するものでした。ランダムなトランザクションIDを含む偽造応答をリゾルバーに大量に送りつけることで、正規の応答が到着する前に、攻撃者が正しいトランザクションIDとの一致に統計的に成功できました。キャッシュが期限切れになるまで、汚染されたキャッシュは、そのリゾルバーを利用するすべてのユーザーを数週間にわたって攻撃者が制御するサーバーへリダイレクトします。

DNSSEC（DNS Security Extensions）は、DNS応答に暗号学的な認証を追加します。DNSSEC署名ゾーン内のすべてのDNSレコードセットには、デジタル署名が付加されます。検証を行うリゾルバーは、レコードを受け入れる前にこれらの署名を確認します。偽造または改変された応答は無効な署名になるため、拒否されます。DNSSECはキャッシュポイズニングや応答偽造から保護しますが、DNSクエリを暗号化するものではありません。

DNSSECでは、ゾーンごとに2種類の鍵からなる階層を使用します。ゾーン署名鍵（ZSK）は、個々のDNSレコードセットに日常的な署名を行うために使用します。鍵署名鍵（KSK）は、ZSKとKSKの公開鍵を含むDNSKEYレコードセットだけに署名します。KSKのハッシュは親ゾーンに登録する必要があり、ローテーションは運用上複雑であるため、ZSKは頻繁（毎月）にローテーションできる一方、KSKの変更頻度は低く（毎年）なります。

署名されたすべてのDNSレコードセット（RRsetと呼ばれます）には、そのRRsetに対する暗号学的署名を含む対応するRRSIGレコードがあります。リゾルバーがDNSレコードを要求すると、応答にはレコードとそのRRSIGの両方が含まれます。リゾルバーは、ゾーンの公開鍵を使用してRRSIGを検証します。署名には、レコードの内容、タイプ、クラス、有効期限が含まれるため、改変だけでなく、過去に有効だった署名のリプレイも防止できます。

DNSSECの信頼の連鎖は、Delegation Signer（DS）レコードを通じて構築されます。ゾーンが子ゾーンに委任されると、親ゾーンは子ゾーンのKSKのハッシュを含むDSレコードを公開します。親ゾーンを信頼するリゾルバーは、子ゾーンのKSKのハッシュがDSレコードと一致することを検証し、子ゾーンの署名への信頼を確立できます。この連鎖はDNSルートゾーンからTLDを経由して個々のドメインゾーンまで続きます。

DNSSEC署名ゾーンはすべて、DNSKEYレコードで署名用の公開鍵を公開します。通常、DNSKEYレコードはZSK用とKSK用の2つあります。KSKの公開鍵のハッシュは親ゾーンにDSレコードとして登録され、ゾーンの信頼を親ゾーンに結び付けます。ルートゾーンのKSKのハッシュは、最終的なトラストアンカーであるRoot Zone Trust Anchorとして、検証を行うリゾルバーにハードコードされています。

DNSSECの検証は、KSKのトラストアンカーがリゾルバーにハードコードされているルートゾーンから始まります。ルートゾーンのDNSKEYを使用してそのRRSIGを検証し、.comなどのTLDに対するDSレコードを認証します。.comゾーンのDNSKEYは、個々のドメインに対するDSレコードのRRSIGを検証します。この暗号学的な検証の連鎖はルートから問い合わせ対象のドメインまで続き、すべてのリンクが認証されていることを保証します。

DNSSEC検証を行うリゾルバーは、応答を受信すると、信頼の連鎖全体を検証します。DNSKEYレコードを取得し、RRSIG署名を検証し、DSレコードをルートアンカーまでたどり、署名の有効期限を確認します。検証に失敗した場合、リゾルバーは偽造されている可能性のあるレコードを返すのではなく、SERVFAILエラーを返します。Cloudflareの1.1.1.1やGoogleの8.8.8.8を含む、主要な公開リゾルバーのほとんどがDNSSEC検証を実行します。

DNSSECはセキュリティ上のメリットがあるにもかかわらず、導入は遅れています。鍵のロールオーバーには、ゾーン運用者と親レジストリの連携が必要です。KSKのロールオーバー中にミスがあると、ゾーン全体にアクセスできなくなる可能性があります。2019年のICANNルートKSKロールオーバーには、何年もの準備が必要でした。署名によってゾーンサイズは大幅に増加します。運用者は、自動化された鍵ローテーションと監視を実装する必要があります。こうした運用上の複雑さから、多くの小規模なドメイン運用者はDNSSECを避けています。

DNSSECがDNSクエリのプライバシーを提供するというのは、よくある誤解です。DNSSECはプライバシーを提供しません。DNSSECは応答を認証するだけであり、クエリと応答は依然としてポート53上を平文のUDPパケットとして送信されます。ネットワークを監視できる人は、問い合わせられたすべてのドメイン名を引き続き確認できます。DNS-over-TLS（DoT）とDNS-over-HTTPS（DoH）は、DNSトラフィックを暗号化することでクエリのプライバシーを提供します。DNSSECとDoH/DoTは相補的なもので、一方は真正性を、もう一方は機密性を提供します。

2024年時点で、DNSルートゾーンと主要TLDの約90パーセントがDNSSECで署名されています。しかし、個々のドメイン名で署名されているのは約20～30パーセントにすぎません。ブラウザーやアプリケーションにおけるDNSSEC検証の採用状況にはばらつきがあります。DNSSECのセキュリティ上のメリットは、DANE（DNS-Based Authentication of Named Entities）と組み合わせたときに最大になります。DANEはDNSSECを使用してTLS証明書のフィンガープリントを公開し、クライアントが認証局（CA）だけに依存せずに証明書を検証できるようにします。

DNSSEC検証を行うリゾルバーは、最初の状態からどのようにしてドメインのDNSレコードへの信頼を確立するのでしょうか。

DNSSECはDNS応答に暗号学的署名を追加し、キャッシュポイズニングと応答偽造を防止します。ZSKはレコードセットに署名し、KSKはDNSKEYレコードに署名します。DSレコードは親ゾーンと子ゾーンの間で信頼を連鎖させます。検証は、ハードコードされたRoot Zone Trust Anchorから始まります。DNSSECはDNSトラフィックを暗号化しません。DoHとDoTがプライバシーを提供する一方、DNSSECは真正性を提供します。鍵のロールオーバーなどの運用上の複雑さが、広範な導入を遅らせています。