DNSSECを使用してDNSを保護するためのガイド

インターネットは、あらゆる人や物を繋ぐグローバルネットワークです。人々はソーシャルネットワークでプロフィールを共有し、企業は電子商取引を行い、コンテンツ制作者は作品をオンラインで公開するなど、様々な活動が行われています。このネットワークはイノベーションを促進し、広範な情報共有を可能にし、ビジネスを容易にしてきました。しかし残念ながら、悪意のある組織が様々なプラットフォームの脆弱性を悪用し、評判を傷つけたり、被害者を騙したりする機会も生み出しています。 

ドメインネームシステム（DNS）はグローバルインターネットの主要コンポーネントの一つですが、インターネットが今よりずっと小規模で、主に専門家によって利用され、セキュリティ上の懸念がほとんどなかった数十年前の設計です。もちろん、現在では世界は大きく様変わりしており、DNSは不可欠な存在であるため、常に脅威の標的となっています。DNSへの攻撃は、ほぼすべてのインターネット活動を妨害する可能性があるからです。大規模なDDoS攻撃からDNSサーバーの乗っ取り、DNSレコードの改ざんまで、悪意のある攻撃者は常に脅威であり、システム管理者は常に警戒しておく必要があります。

DNSプロトコルの標準化を担うインターネット技術タスクフォース（IETF）は、DNSのセキュリティと安定性の向上に継続的に取り組んできました。その重要な機能強化の一つが、デジタル署名を用いた認証と検証をDNSに追加するDNSセキュリティ拡張機能（DNSSEC）です。 

主要概念の要約

なぜDNSSECなのか？	DNSは、なりすまし攻撃や中間者攻撃の格好の標的です。DNSSECは、これらの脅威から保護するのに役立ちます。
DNSSECはどのように機能するのですか？	DNSSECは、公開鍵暗号と信頼の連鎖を利用して、DNS応答の真正性と有効性を確立することで機能します。
DNSSEC検証の設定方法	DNSSECの実装には、権威サーバーにおけるゾーンの署名と、リゾルバにおける信頼性の検証機能の有効化が必要です。
DNSSEC検証	オンラインツールやコマンドラインツールを使用して、DNSSECが正しく実装されていることを確認してください。
グローバルなDNSSEC実装	DNSSECは、gTLDやccTLDを含め、世界中で導入が進められており、DNS全体の安定性と安全性にとって不可欠です。
DNSSECに関連する課題	DNSSECは、DNSゾーントラバーサルやより深刻なDDoS攻撃など、いくつかのセキュリティ上の問題を抱えている。

なぜDNSSECなのか？

初期インターネットにおけるDNS

WhatsAppメッセージの送信、YouTube動画の視聴、Instagramストーリーの投稿、検索エンジンでの検索など、インターネット上で行うあらゆる通信要求は、DNS解決要求から始まります。お使いのコンピュータやスマートフォンがリモートサーバーとの通信を開始すると、ドメインネームシステム（DNS）がリモートシステムのホスト名に対応するIPアドレスを提供します。 

DNSは、インターネットが黎明期にあった1980年代初頭に標準化されました。当時はシステムやネットワークの数が比較的少なく、ほとんどが信頼できる組織に属しており、セキュリティよりも通信の容易さが重視されていました。そのため、DNSはシンプルな仕組みになっていました。コンピュータはDNSリゾルバにIPアドレスを要求し、その応答が正規のソースから送信されたものか、あるいは返された情報が改ざんされていないかを確認することなく、無条件に受け入れるというものでした。

DNSスプーフィングとキャッシュポイズニング攻撃 

インターネットの普及が進み、接続されるシステムが増えるにつれ、悪意のある攻撃者は様々なシステムやアプリケーションの脆弱性を探し出し、悪用しようと絶えず試みてきました。基本的なDNSシステムにも、なりすましやキャッシュポイズニングなど、複数の脆弱性が存在します。

スプーフィングとは、DNSクエリに対する正当な応答を偽の応答に置き換える仕組みです。キャッシュポイズニングとは、悪意のある攻撃者がDNSリゾルバのDNSキャッシュを改ざんし、悪意のあるウェブサイトのアドレスを返すように仕向ける行為です。 

中間者攻撃（MITM攻撃）を行う攻撃者は、正規の権威DNSサーバーのアドレスを偽装することでDNSクエリを傍受できます。攻撃者はDNS応答を不正なウェブサイトを指すように変更します。その結果、DNSリゾルバのキャッシュが誤った情報で汚染されます。非常に大規模で有名な組織でさえも、この攻撃の被害に遭う可能性があります。 ターゲットにされている.

Facebookの認証情報や、さらに深刻な銀行口座情報などを盗もうとする悪意のある存在を想像してみてください。攻撃者はウェブサイトの偽物を作成し、DNSリゾルバのキャッシュを改ざんします。Facebookや銀行のウェブサイトにログインしようとすると、DNSリゾルバは偽造されたIPアドレスを返します。すると、あなたのブラウザは知らず知らずのうちに悪意のあるウェブサイトに接続し、そこで認証情報を入力すると、攻撃者がその情報を盗み取ります。

DNSセキュリティ拡張機能（DNSSEC）の必要性

上述の脆弱性から、悪意のある主体がDNSクエリ応答を改ざんしていないことを保証するために、認証および検証メカニズムを組み込むことでDNSを改善する必要性が明らかになった。この要件を認識し、2005年にDNSセキュリティ拡張機能（DNSSEC）スイートが標準化され、ドメインネームシステムにデータ発信元認証とデータ整合性保護が追加された。

DNSSECはどのように機能するのですか？

DNSSECは、公開鍵／秘密鍵暗号方式を用いて、データが正当なゾーンから送信されたものであること、および応答が転送中に改ざんされていないことを認証します。 

DNSは階層構造のシステムであり、ルートゾーンから始まり、トップレベルドメイン（TLD）を経て、最終的に特定のドメインの権威DNSサーバーへと続きます。この階層構造では、信頼の連鎖を構築する必要があります。子ゾーンが暗号署名付きの応答を返すと、親ゾーン（TLD）は子ゾーンの鍵の署名を自身の鍵で検証しなければなりません。同様に、TLDゾーンの鍵も検証が必要であり、これはルートゾーンが行います。ルートゾーンは階層構造の最上位に位置するため、それ自体が信頼のアンカーとなります。 

信頼の連鎖とDNSSEC検証を含むDNS階層の詳細については、以降のセクションでさらに詳しく説明します（ゾーントラバーサルの例も含まれています）。

DNSSECのリソースレコード

DNSSECは、デジタル署名をリソースレコードセット（RRセット）に関連付けます。RRセットは、同じ名前のDNSレコードをグループ化してセットにします。たとえば、次の3つ AAAA 記録 www.example.com 単一のRRセットにまとめられます。

www.example.com	IN	AAAA		fd15:9203:bbb4:64b2::100
www.example.com	IN	AAAA		fd15:9203:5802:ea4a::100
www.example.com	IN	AAAA		fd15:9203:6854:64b2::100

DNSSEC規格では、署名および署名検証のために以下のレコードタイプが規定されています。

• DNSKEY リソースレコードは公開鍵を保存するために使用されます。これらの鍵は非対称です。公開鍵はDNSレコードに保存され、秘密鍵は署名に使用され、公開されません。
• RRSIG (リソースレコード署名)は、DNSリソースレコードセットのデジタル署名を保存します。 
• NSEC/NSEC3 （次のセキュアレコード）は、存在しないレコードに対して署名付きの回答を返すための認証メカニズムを提供します。
• DS （委任署名者）は、親ゾーンに保存されている DNSKEY レコードのハッシュです。
• CDS/CDNSKEY （子DS / 子DNSKEY）レコードは、親ゾーンとのDSおよびDNSKEYレコードの自動更新に使用されます。

ゾーン署名キー、キー署名キー、および委任署名者

前述の通り、信頼の連鎖を確立する必要があります。ルートゾーンはTLDを検証し、TLDは登録されたドメインを検証します。ゾーンに署名が行われると、その署名を検証するための鍵レコードがTLDに保存されます。 

暗号化においては、鍵を可能な限り頻繁にローテーションすることが推奨されています。このガイドラインに従ってドメイン署名鍵をローテーションする必要がありますが、鍵をローテーションするたびにTLDの検証レコードも更新しなければならない場合、プロセスが非常に煩雑になります。

このプロセスを簡素化するために、キー署名キー（KSK）とゾーン署名キー（ZSK）の2種類のキーが導入されます。KSKはZSKに署名するために使用され、ZSKはゾーンレコードに署名するために使用されます。親ゾーンでは、実際のキーの代わりに、委任署名者レコードと呼ばれるKSKのフィンガープリントを暗号学的ハッシュ関数を使用して保存します。これにより、親ゾーンのレコードサイズを小さく保つことができます。権威DNS管理者は、親TLDのDSレコードを更新することなく、必要に応じてZSKをローテーションできます。

DNSSEC検証プロセスと信頼の連鎖

DNSSEC検証によるDNS解決の仕組みを復習し、信頼の連鎖を完成させましょう。ほとんどのDNSリゾルバは、ルートゾーンの公開鍵（トラストアンカーと呼ばれる）で構成されています。このトラストアンカーにより、リゾルバはルートゾーンが提供するレコードを暗黙的に信頼します。信頼の連鎖はこの鍵から始まるため、ルート鍵のセキュリティは非常に重要です。ルート鍵の署名プロセスの詳細は、 ICANNの発表.

下の図を参照すると、クライアントが DNSSEC 対応リゾルバ (1) を使用してドメイン example.com のクエリを開始するとします。リゾルバはルート DNS サーバー (2) にアクセスし、そこから .com TLD サーバーと .com TLD ゾーンの DS レコード (3) を取得します。DS レコードが返されると、リゾルバは .com ゾーンが DNSSEC で保護されていることを認識します。 

次に、リゾルバはTLDサーバー（4）に問い合わせ、example.comの権威ネームサーバーとDSレコード（5）を取得します。リゾルバはTLDゾーンのKSKをハッシュ化し、ルートゾーン（6）から受信したDSレコードと比較します。ハッシュがDSレコードと一致する場合、リゾルバはTLDゾーンから提供されたレコードが信頼できると判断します。 

リゾルバは権威ネームサーバー（7）にクエリを送信し、レコードとDNSKEY（8）を受信します。リゾルバは権威ネームサーバーから提供されたKSKをハッシュ化し、ハッシュがTLD（9）から提供されたDSレコードと一致する場合、example.comのゾーンレコードは信頼できると判断されます。その後、DNSリゾルバは検証済みのレコードをクライアント（10）に返します。

DNSSEC検証の設定方法

世界中でDNSSECの導入は自動的に行われるものではなく、現状ではDNSSEC検証を有効にするには手動の手順が必要です。インターネットサービスプロバイダや、独自のDNSリゾルバを導入・管理する企業は、再帰型DNSサーバーでDNSSEC検証を有効にする必要があります。 

ドメイン所有者として、DNSSECをサポートするドメインレジストラを選択する必要があります。レジストラは、DSレコードの署名と更新、および親TLDへのDSレコードの提供ができる必要があります。ドメインのDNSSECを無効にする場合、またはDNSSECに対応していないレジストラに移行する場合は、まず親TLDからDSレコードを削除し、キャッシュされたレコードの有効期限（TTL値に基づく）が切れるまで待ってから、次の手順に進む必要があります。

ホスティングに関しては、DNSSECをサポートするDNSホスティングプロバイダーを選択できます。あるいは、独自のDNSインフラストラクチャを構築し、権威DNSサーバーでDNSSEC署名を有効にすることもできます（後述）。

DNSSEC対応の再帰型DNSサーバーは、上記で説明した信頼チェーンを使用して、リモートサーバーからの各クエリの検証を実行します。リゾルバは、公開鍵暗号を使用して、応答が正当であることを検証します。 

長年にわたり、ほぼすべてのDNSリゾルバがDNSSEC検証をサポートしています。この検証を有効にするには、通常、数行の設定変更を行うだけの簡単な手順です。検証を有効にすると、リゾルバは改ざんされたデータを受信することからエンドユーザーを保護し、検証チェックが失敗した場合はSERVFAILステータスを返します。ただし、この保護機能はDNSSECで保護されているドメインにのみ適用される点にご注意ください。

BIND DNS再帰サーバーの設定

ISC BINDリゾルバでDNSSEC検証を有効にするには、オプション設定ファイルを編集します（/etc/bind/named.options）そして、次の行が設定されていることを確認してください。最近の BIND リリースでは、このオプションはデフォルトで有効になっています。古い BIND バージョン (9.11 まで) では、これを明示的に行う必要があります。

options {
	. . . .
	. . . .
	dnssec-validation auto;
	. . . .
	. . . .
};

PowerDNS権威サーバー構成

DNSSECキーの設定と生成、およびゾーンレコードへの署名は複雑になる場合があります。PowerDNS権威DNSには、管理オーバーヘッドを軽減し、シンプルなコマンドラインインターフェイスでゾーンに署名できるようにするサポートが含まれていますが、 秘密管理 ツールの使用が推奨されます。前提条件として、PowerDNS で構成されたバックエンドで DNSSEC 処理を有効にする必要があります。たとえば、メインの PowerDNS 構成ファイルで次のオプションを構成します (/etc/powerdns/pdns.confSQLiteバックエンドを使用する場合は、以下のようになります。

. . . .
. . . .
# Enable Sqlite3 backend
launch=gsqlite3
# Path to Sqlite3 DB file
gsqlite3-database=/var/lib/powerdns/pdns.sqlite3
# Enable DNSSEC processing
gsqlite3-dnssec
. . . .
. . . .

DNSSECを使用してゾーンを保護するには、次のコマンドラインを使用します。

$ sudo pdnsutil secure-zone example.com

PowerDNSはデフォルトではNSECを使用してNXDOMAINクエリに対する応答を返します。これをNSEC3に変換するには、以下のコマンドラインを使用してください。

$ sudo pdnsutil set-nsec3 example.com '1 0 0 -'

セカンダリDNSサーバーが新しいキーまたは更新されたキーで更新されていることを確認し、SOAシリアル番号をインクリメントしてください。

$ sudo pdnsutil increase-serial example.com

ドメインレジストラでDSレコードを設定する

ゾーンのDNSSECを有効にした後、親ドメインまたはTLDにそのゾーンのDSレコードを更新する必要があります。以下のコマンドを実行すると、ハッシュの生成に使用されたハッシュ、アルゴリズム、およびダイジェストタイプが表示されます。

$ sudo pdnsutil show-zone example.com
. . .
Zone has hashed NSEC3 semantics, configuration: 1 0 0 -
keys: 
ID = 2 (CSK), flags = 257, tag = 30717, algo = 13, bits = 256	  Active	 Published  ( ECDSAP256SHA256 ) 
. . .
DS = example.com. IN DS 30717 13 2 13dd5 .......... 61f91bda8 ; ( SHA256 digest )

上記出力から以下の情報をドメイン登録業者に安全に提供する必要があります。

Domain:   	example.com
Algorithm:	ECDSA
Digest Type:	SHA256
Digest:		13dd5 .......... 61f91bda8
keyTag:		30717

これであなたのドメインは example.com DNSSECによって保護されており、リゾルバは信頼の連鎖を通じて提供された情報の身元を検証できます。 

DNSSEC検証

ゾーンに対するDNSSECの適切な実装は、エンドユーザーが検証済みの応答を受け取ることを保証します。DNSSECの実装が不適切だと、エンドユーザーがドメインレコードを取得できなくなり、結果としてドメインがインターネット上で表示されなくなる可能性があります。 

オンライン認証ツール

インターネット協会 公開する DNSSECのテストと実装のためのツール一覧。Verisignはオンラインツールを提供しています。 DNSSECアナライザー 指定されたドメインの信頼チェーンをテストします。このツールは、ルートDNSからゾーンの権威DNSサーバーまでのDNSSEC検証チェックを実行し、テスト中に検出された問題点をハイライト表示します。

出典： https://dnssec-debugger.verisignlabs.com/verisign.com

別のオンラインツールは DNSVizこれは、ルートからゾーンまで、DNSSEC検証とDNS解決を視覚的に分析します。

コマンドライン検証

ドメインの DNSSEC ステータスは、以下の方法でもテストできます。 dig コマンドラインユーティリティは、以下からダウンロードできます。 ISCウェブサイト インストールされていない場合は、DNSSEC対応のリゾルバにクエリを実行し、+dnssecオプションを追加して、キーを複数行に表示（+multiline）することで、DNSSECレコードとステータスを確認できます。

$ dig verisign.com @1.1.1.1 +dnssec +multiline

; <<>> DiG 9.18.12-0ubuntu0.22.04.2-Ubuntu <<>> verisign.com @1.1.1.1 +dnssec +multiline
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63981
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;verisign.com.		IN A

;; ANSWER SECTION:
verisign.com.		60 IN A	69.58.187.40
verisign.com.		60 IN A	72.13.63.40
verisign.com.		60 IN RRSIG A 8 2 60 (
				202309192318 202308202318 17355 verisign.com.
				ob16wft/jzpDZeZbeAJMBF1hX7jhtfwqj4G1RQkJkKVN

上記の出力では、 ad フラグは、ドメインがすべての DNSSEC 検証プロセスを通過したことを示します。dig ユーティリティの後継は デルブこのツールはdigと同様の動作をしますが、DNSSECチェーンの検証にBIND DNSサーバーと同じコードを使用するため、DNSSECの実装に関する理解がより優れています。DNSSECの実装が成功した場合、このツールは「完全に検証済み」というレポートを返します。

$ delv verisign.com @1.1.1.1 +multi +rtrace
;; fetch: verisign.com/A
;; fetch: verisign.com/DNSKEY
;; fetch: verisign.com/DS
;; fetch: com/DNSKEY
;; fetch: com/DS
;; fetch: ./DNSKEY
; fully validated
verisign.com.		60 IN A	72.13.63.40
verisign.com.		60 IN A	209.131.162.45
verisign.com.		60 IN RRSIG A 8 2 60 (
				202312022319 202311022319 41998 verisign.com.
				AFBYZG/6VHvIYNdZaKBWzKnGEpgqICF9onlqjOLPmT8T

DNSSEC実装のテストに関する詳細は、以下から入手できます。 BINDのドキュメント.

グローバルなDNSSEC実装

より安全なインターネットを確保するためには、世界中のすべてのドメインで適切なDNSSECの実装が重要です。しかし、現在のDNSSECの普及は、いくつかの理由から遅れています。 

• 技術スタッフには適切な研修が必要です。
• DNSSECの実装ミスは、ドメインがインターネット上から消滅する原因となる可能性がある。
• DNSSECレコードを保存することでゾーンサイズが大幅に大きくなり、DNS応答のサイズも大きくなるため、ドメインレジストリおよびレジストラはハードウェアとソフトウェアのアップグレードを必要とします。 
• 他のすべての組織もDNSSECを導入しない限り、個々の組織はDNSSECのメリットを十分に享受することはできません。

TLDとDNSゾーンの統計情報

汎用トップレベルドメイン（gTLD）はすべて、またほとんどの国別コードトップレベルドメイン（ccTLD）もDNSSECを導入しています。インターネットソサエティは、各TLDにおけるDNSSECの実装状況を追跡し、グラフや統計情報を提供しています。

出典： https://www.internetsociety.org/deploy360/dnssec/maps/

Verisignは、DNSSECによって保護されている.comドメインと.netドメインのスコアボードを公開しています。現在の統計によると、DSレコードを持つ.comドメインの5%以上、.netドメインの約4.5%がTLDで公開されています。

グローバルリゾルバ統計

アジア太平洋ネットワーク情報センター（APNIC）は、リゾルバからのDNSトラフィックを追跡し、 公開する 世界におけるDNSSEC検証の実施率を示します。地域、国、ネットワークごとにDNSSEC検証を実施している状況の統計情報を提供します。現在、世界中のDNSリゾルバの30%以上がDNSSEC検証を実施しています。

下図は、国別のDNSSEC検証率を示しています。緑色の部分が多いほどDNSSECトラフィックの割合が高く、赤色の部分が多いほど割合が低いことを意味します。

DNSSECに関連する課題

NSECを使用したDNSゾーントラバーサル

存在しないレコードを照会すると、DNSサーバーはNXDOMAINステータスの空のレコードを返します。空の応答では、そのレコードの正当性を検証することはできません。DNSSECは、次のセキュアレコード（NSEC）を使用してこの問題を解決します。NSECで署名されたゾーンは、DNSSECのソート基準に従って、次の有効なレコードを返します。 

これにより、空のレコードの場合でも署名付き応答を返すという問題が解決されます。しかし、別の脆弱性が生じます。悪意のある攻撃者がすべてのNSECレコードを走査することで、ゾーン内のすべてのDNSレコードを公開できてしまうのです。この問題は、すべての有効なレコードのハッシュを作成するNSEC3を使用することで解決できます。これにより、存在しないレコードに対するクエリの応答が隠蔽されます。

DNSリフレクション/増幅攻撃

DNSは一般的に、TCPよりもシンプルで高速なプロトコルであるUDPをクエリに使用します。しかし、UDPの欠点はステートレスであることであり、UDPを使用して通信する場合、潜在的な被害者のIPアドレスを偽装することが非常に容易です。この脆弱性は、DNSリフレクション/増幅技術を用いたDDoS攻撃を生成するために悪用されます。DNS応答の一般的なサイズは50～60バイトです。 

DNSSECで署名されたゾーンでは、応答サイズが512バイト以上に増加する可能性があり、そのようなゾーンを使用したDDoS攻撃の影響ははるかに大きくなります。

DNS応答の遅延

DNSSEC実装におけるもう一つの課題は、DNS解決時間が大幅に増加することです。DNSSEC検証プロセスでは、信頼チェーンを検証するための追加手順が必要となります。1ミリ秒たりとも無駄にできない現代社会において、これは一部の組織がドメインにDNSSECを実装しない理由の一つとなっています。 APNICのブログ記事 この課題について、より詳細に解説しています。

主要概念の要約

DNSはグローバルインターネットにおいて最も重要な構成要素の一つであり、悪意のある攻撃者による標的となることが少なくありません。DNSSECは、初期のDNS標準には欠けていた検証メカニズムを追加することで、より安全なインターネットを実現します。 

DNSSECでは、ルートサーバーからTLDサーバー、そして権威サーバーへと続く信頼の連鎖を確立する必要があります。また、DNSリゾルバがDNSSEC検証を有効にしていることも必要です。リゾルバは、DNS応答が正当な送信元から送信されたものであり、転送中に改ざんされていないことを検証できます。 

DNSSECの導入は、その複雑さやその他の理由から、ゆっくりと進んでいます。しかし、適切な技術知識と適切なツールの使用により、DNSSECの導入を成功させることは可能です。