次世代のセキュリティ拡張DNSSECをBIND 9で実現：実用 BIND 9で作るDNSサーバ（13）（1/3 ページ）

現在、標準化作業が進行中のDNSSEC。その仕組みとBIND 9での実現方法を解説する。後半では、スプリットDNSの設定方法を紹介。（編集局）

[鶴長鎮一，＠IT]

　今回は、DNSのセキュリティ拡張である「DNSSEC」とスプリットDNSを実現する「VIEW」について解説します。DNSSECは、まだ標準化の議論が活発に行われている最中です。そのためBIND 9では実装が不完全なものもあります。

ゾーン情報の信頼性を保証するDNSSEC

　第9回で、ゾーン情報が改ざんされる危険を回避する手段としてDNSSEC（DNS Security Extension：DNSセキュリティ拡張）を紹介しました。現在、DNSSECはIETFのDNSEXT（DNS Extensions）ワーキンググループで標準化の作業が進められており、ゾーン情報の信頼性を保証する手段として広く普及することが期待されています。

参考：
▼IETF
　http://www.ietf.org/
▼DNSEXT（DNS Extensions）ワーキンググループ
　http://www.ietf.org/html.charters/dnsext-charter.html

DNSSECの仕組み

　DNSSECで大きな役割を担うのが、RSAなどの公開鍵暗号法によるメッセージへの署名です。

　ゾーン情報の信頼性を確保する方法としては、ゾーン情報そのものを暗号化して改ざんを防ぐ手段も考えられます。しかし、それではDNS応答のたびに暗号の解読コストが発生し、効率が大きく低下します。

　そこでより手ごろな手段として、ハッシュ関数を組み合わせるのです。ハッシュ関数でゾーン情報のハッシュ値を求め、そのハッシュ値を公開鍵暗号方式で暗号化したものを署名としてゾーン情報に添付します。ゾーン情報と比べてハッシュ値はごく小さなデータであるため、解読に掛かるコストも少なくなります。ゾーン情報を受け取った側は、受信したゾーン情報のハッシュ値を計算し、さらに署名を解読して送信時のゾーン情報のハッシュ値を求めます。ゾーン情報が改ざんされたものでなければ、両ハッシュ値が一致するというわけです。

図1　DNSSECの仕組み

　秘密鍵で暗号化したデータは、その秘密鍵と対をなす公開鍵でしか復号できません。また、公開鍵を用いて暗号化しても、同一の暗号文を作成したり秘密鍵を複製することはできません。これら公開鍵暗号方式の利点により、DNSゾーンサーバから送信されるメッセージの信頼性が保証されます。

公開鍵自身の署名（RFC 2535方式）

　公開鍵そのものが改ざんされる可能性を考えてみましょう。公開鍵が改ざんされても、秘密鍵が変わっていなければ署名の機能は果たされます。しかし、DNSサーバが乗っ取られて、秘密鍵・公開鍵ともに差し替えられてしまえばゾーン情報の改ざんは侵入者の思いのままです。

　そこで、作成した鍵を第三者に承認してもらう必要があります。ベリサインなどの専門のCA機関を利用することも考えられますが、RFC 2535方式のDNSSECでは上位ゾーンのDNSサーバを利用する方法が提案されています。

図2　RFC 2535方式による鍵ペアの作成と署名

　example.jpドメイン管理者が作成した公開鍵を基に、上位ゾーンであるjpドメイン管理者がjpドメインの秘密鍵を使って署名を作成し、それをexample.jpドメイン管理者に送り返します。example.jpドメイン管理者は、自身の公開鍵の署名としてjpゾーンの管理者から送られた署名を利用します。

　example.jpドメインの問い合わせを行う際は、ドメインツリーの経路に従いjpドメインを参照します。その際にjpドメインのゾーン情報の検証を行い、同時にjpドメインが利用している公開鍵を入手できるというわけです。

セキュリティルートとNULL鍵

　ここで疑問が残ります。example.jpドメインのゾーン情報の検証に、jpドメインが利用している公開鍵を使用しました。同じく、jpドメインの検証を行うために.（ルート）ドメインの公開鍵を使用します。では、.（ルート）ドメインの検証はどの鍵で行うのでしょうか？

　ドメインツリーを利用する以上、その根（ルート）に帰結することは必至です。そこで、.（ルート）ゾーンを検証する鍵はマスター鍵として、あらかじめ配布されたものをDNS問い合わせを行う全サーバに登録しておく必要があります。

図3　ドメインツリーと鍵ペア

処理1
　　「.（ルート）ゾーンの公開鍵＋その公開鍵の署名」から、.（ルート）ゾーンの公開鍵を検証。検証の際は、あらかじめ登録されている信頼済み鍵を使用。正規のものであれば、その公開鍵を使って「jpのNSレコード＋その署名」を検証
処理2
　　「jpゾーンの公開鍵＋その公開鍵の署名」から、jpゾーンの公開鍵を検証。検証の際は、処理1で得た.（ルート）ゾーンの公開鍵を使用。正規のものであれば、その公開鍵を使って「example.jpのNSレコード＋その署名」を検証
処理3
　　「example.jpゾーンの公開鍵＋その公開鍵の署名」から、example.jpゾーンの公開鍵を検証。検証の際は、処理2で得たjpゾーンの公開鍵を使用。正規のものであれば、その公開鍵を使って「www.example.jpのAレコード＋その署名」を検証
注：第6回第6回図2も参照。

　では、.（ルート）ゾーンがDNSSECに対応していなければ、自身のゾーン情報にDNSSECを実装することは無意味でしょうか？

　不特定多数のDNSクライアントまでサービス対象とする場合は、.（ルート）ゾーンのみならず、ドメインツリー経路上すべてのドメインでのDNSSEC対応が必須になります。もちろん、DNSクライアント自身もDNSSEC対応の問い合わせができる必要があります。

　しかし、サービス対象を特定のDNSクライアントに限るなら、これらの条件は必須ではありません。その特定のDNSクライアントに、ドメインツリー経路途中のDNSサーバが持っている公開鍵を信頼済み鍵として登録することで、そのDNSサーバを頂点とする新しいセキュリティルートを確保することができます。逆に、経路の途中からDNSSECを無効にするためにNULL鍵と呼ばれる値を上位ゾーンに登録することで、署名付きゾーン情報が得られないことを明示することもできます。

RFC 2535方式の問題とDS方式の採用

　RFC 2535方式は公開鍵の署名を上位ゾーンに依頼し、上位ゾーンから送り返される公開鍵署名をゾーン情報に登録する必要があります。そこで、上位のゾーン情報に下位ゾーンの公開鍵の署名を登録するDS（Delegation Signer）方式が検討されています。

　DS方式では、NSレコードなどの資源レコードの1つとしてDSレコードを設け、これに下位ゾーンの公開鍵のハッシュ値と鍵idを登録します。下位ゾーンの管理者は、公開鍵署名が上位ゾーンから送り返されるのを待たずに、いままでNSレコードにDNSサーバを登録してもらっていた要領でDSレコードの登録を上位ゾーンに依頼できます。

　鍵の作成は2年に1回というわけにはいかず、少なくとも数カ月に1度は実施する必要があります。公開鍵暗号法は完全に安全というわけではなく、第三者による解読には天文学的な時間を要するということが鍵の安全を保証しているにすぎません。長い時間をかければ解読される危険が大きくなるため、鍵の更新は頻繁に行う必要があります。一方で、手間を軽減するに越したことはありません（注）。

注：仮に1つのドメインが年に4回キーの更新を行ったと仮定すると、jpやcomなどのTLD管理者の手間は相当なものになります。

　DS方式では、公開鍵を署名する新しい鍵のペアを用います。署名を2段階にすることで、ゾーン情報に署名を行う鍵は頻繁に更新し、その鍵の署名に必要な鍵はある程度長い期間同一のまま使用できます。ゾーン情報の署名に用いる鍵をZSK（Zone Signing Key）、ZSKに署名を行う鍵をKSK（Key Signing Key）と呼びます。

図4　DS方式による鍵ペアの作成と署名

　DS方式を採用することで、NULL鍵は必要なくなります。DSレコードがなければ、そのゾーンはDNSSECで保護されていないことが分かり、DNSSEC問い合わせをする必要がなくなるからです。これは、ドメインツリー上の全ドメインで一斉にDNSSECに対応する必要性をなくし、jpやcomなどのTLDでDNSSECを導入しやすくします。

参考：
▼RFC 3658
　http://www.ietf.org/rfc/rfc3658.txt