キャッシュDNSサーバのDNSSEC対応：DNSSEC再入門（3）（2/2 ページ）

» 2011年06月01日 00時00分公開

[阿波連良尚，株式会社日本レジストリサービス（JPRS）]

BIND 9でのトラストアンカー設定方法

　それでは、入手したトラストアンカーを用いた、BIND 9における設定方法について説明する。

　BIND 9でDNSSECに対応するに場合には、BIND 9.7系以降を推奨する。本稿執筆時点でのBIND 9.7系の最新版はBIND 9.7.3-P1、BIND 9.8系の最新版はBIND 9.8.0-P2となっている（5月27日に、セキュリティ上の問題を修正した新しいバージョンがリリースされた）。古いバージョンのBIND 9には、いくつかのセキュリティホールが発見されており、最新版にバージョンアップすることをお勧めしたい。

　BIND 9.8系では、配布物にはじめからルートゾーンのトラストアンカーが含まれている。このため、下記の行をnamed.confのoptionsステートメント内に追加するだけで、DNSSECの検証が有効となる。

dnssec-validation auto;

BIND 9.8系の設定

　なお、ソースコードをダウンロードして自分でコンパイルを行う場合、署名やハッシュ値などで、ソースパッケージが真正なものであると確認しておくとよい。

　BIND 9.7系では、DNSSECの検証を行う設定はデフォルトで有効になっているが、手動でトラストアンカー（DNSKEYレコード形式）を設定する必要がある。トラストアンカーを設定するには、managed-keysステートメントを用いる。下記のとおり、「. initial-key」の後ろに、入手したroot-anchors.keyの「257 3 8」以降を続けて記述する。公開鍵の部分は「"」で囲み、行末に「;」を付け加える。

managed-keys {

        . initial-key 257 3 8 "AwEAAag【中略】Uk1ihz0=";

  }

BIND 9.7系のトラストアンカーの設定

　managed-keysステートメントを用いてトラストアンカーを設定すると、namedの起動時にトラストアンカーが設定ディレクトリ内のファイルとして保存される。そして、トラストアンカーの更新があった場合、そのファイルに新しいトラストアンカーが自動的に保存される。詳しくは、BIND 9に付属のマニュアルを参照していただきたい。

　それでは、設定を行ったキャッシュDNSサーバに対してクエリを行い、実際にDNSSECの検証が行われているか確認してみよう。

　今回は、digコマンドを用いて確認を行う。

$ dig +dnssec jprs.jp @192.0.2.1【キャッシュDNSサーバのIPアドレス】

digコマンドによる確認

　このコマンドは、キャッシュDNSサーバに対して、DNSSEC要求を有効にしてjprs.jpを問い合わせるものである。jprs.jpはDNSSECに対応しているため、実行結果として、名前解決の結果に加えて検証結果が表示される。

; <<>> DiG 9.7.3 <<>> +dnssec jprs.jp

  ;; global options: +cmd

  ;; Got answer:

  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19744

  ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 11


;; OPT PSEUDOSECTION:

  ; EDNS: version: 0, flags: do; udp: 4096

  ;; QUESTION SECTION:

  ;jprs.jp.                       IN      A


;; ANSWER SECTION:

  【略】

DNSSECの検証が成功した場合の実行結果

　注目していただきたいのは、先頭付近にある「flags:」で始まる行である。この行には、応答がどのような意味を持つのかが記述されている。

　「ad」というフラグは、DNSSECの検証が成功したことを意味する。つまり、その情報はゾーンの管理者が登録した正しいものであり、通信路で改ざんされていないことが検証できている。jprs.jp以外にも、「www.isc.org」や「www.verisignlabs.com」などがDNSSECに対応しており、検証が可能となっているので試してみてほしい。

　もしトラストアンカーの設定に失敗していた場合は、以下のような出力となる。

; <<>> DiG 9.7.3 <<>> +dnssec www.example.jp

  ;; global options: +cmd

  ;; Got answer:

  ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 22732

  ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1


;; OPT PSEUDOSECTION:

  ; EDNS: version: 0, flags: do; udp: 4096

  ;; QUESTION SECTION:

  ;www.example.jp.                       IN      A

  【略】

DNSSECの検証が失敗した場合の実行結果

　出力中の「status:」で始まる行に注目してほしい。キャッシュDNSサーバは、検証に失敗した場合には、DNSサーバで不具合が発生したことを示す「SERVFAIL」というステータスを返す。そして、名前解決の結果を得ることはできない。ユーザーからは、名前解決ができなかったように見える。

　なお、DSレコードが上位のゾーンに登録されていないゾーンについては、DNSSECの検証をキャッシュDNSサーバで有効にしていても、これまでどおり名前解決の結果を得ることができる。ただし、DNSSECによる検証は行われないため、「ad」フラグはセットされない。

　digコマンドの例では、明示的にクライアントがDNSSECによる検証を要求した。しかし、スタブリゾルバが明示的に検証を要求しなくても、キャッシュDNSサーバは署名の検証を行ってもよいとされている。このため、スタブリゾルバのDNSSEC対応にかかわらず、キャッシュDNSサーバで署名の検証を行う場合があることに注意していただきたい。

トラストアンカーの更新

　ルートゾーンのトラストアンカーは、セキュリティ強度を維持するために定期的に更新される。DNSSECにおける署名鍵の更新方法はいくつか存在するが、ルートゾーンのKSKに関しては、古い鍵と新しい鍵の両方でDNSSECの検証を行える状態が一定期間続く方式が採用される予定である。

　トラストアンカーが更新された場合、古い鍵による検証が行えなくなる前に、新しい鍵をキャッシュDNSサーバに設定しなければならない。運用上の手間を減らすため、RFC 5011（注2）によってトラストアンカーを自動的に更新する方法が規定されている。

　キャッシュDNSサーバとして広く利用されているBIND 9やUnboundはRFC 5011に対応しており、適切に設定を行うことで、トラストアンカーは自動的に更新される。これを利用すれば、キャッシュDNSサーバの管理者がルートゾーンの鍵更新スケジュールを気にする必要はない。BIND 9では前述したmanaged-keysステートメントを使用することで、自動更新が有効になる。

注2：RFC 5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors(http://www.ietf.org/rfc/rfc5011.txt)

日本語訳(http://jprs.jp/tech/material/rfc/RFC5011-ja.txt)

キャッシュDNSサーバ運用時の留意点

　最後に、DNSSECの検証を行うキャッシュDNSサーバを運用するにあたり、気を付けておきたいポイントを紹介する。

時刻の同期

　近年はNTPによる時刻同期が普及しているため、サーバの多くでは時刻が正確な状態にあるだろう。しかし、NTPクライアントの設定ミスや通信の問題により、キャッシュDNSサーバの時刻が不正確になっていることも考えられる。

　DNSSECの署名には有効期間が指定されており、有効期間外の署名は無効なものとして扱われる。このため、キャッシュDNSサーバの時刻が大幅にずれていると、署名の検証に失敗し、名前解決が一切できない状態になってしまう可能性がある。キャッシュDNSサーバの時刻が合っているか、また時刻同期が正常に動いているか、確認していただきたい。

DNSの通信

　DNSの通信というとUDP（User Datagram Protocol）が連想されるが、DNSの規格であるRFC 1035（注3）では、TCP（Transmission Control Protocol）による通信も規定されている。

　IPv6の普及やDNSSECによる署名の付加により、DNSのパケットサイズは増大する傾向にある。DNSにおいては、UDPによる通信の場合、メッセージサイズが512オクテットまでに制限されている。このため、メッセージサイズが大きくなった場合にはTCPによる通信に切り替える（フォールバックする）こともある。キャッシュDNSサーバからのTCP 53番ポートへの通信について、通信経路上のファイアウォールで遮断されていないか、確認していただきたい。

　また、UDPにおけるメッセージサイズの制限を緩和する「EDNS0（注4）」という規格があり、DNSSECの対応においてEDNS0のサポートが必須となっている。UDPにおけるメッセージサイズの制限を緩和することにより、TCPフォールバックの発生を抑えることができる。

　しかし、一部の古いネットワーク機器では、512オクテットよりも大きなDNSパケットの扱いに問題がある。通信経路上のネットワーク機器について、EDNS0による大きなサイズのDNSパケットに対応しているか、確認していただきたい。

キャッシュDNSサーバのリソース

　DNSSECの検証を行う場合、使用するメモリやCPU、ネットワーク帯域幅が増大する。具体的には、DNSレコードに署名が付加されるため、キャッシュに使用されるメモリや通信に使用される帯域幅が増大する。また、署名の検証を行うためCPU使用率も増大する。

　もっとも、ISPで運用しているような大規模なキャッシュDNSサーバでない限り、DNSSECの検証による負荷の増大はあまり気にする必要はない。日々の運用業務の一環としてキャッシュDNSサーバの負荷を監視し、問題があった場合すぐに対処することが重要である。もしキャッシュDNSサーバの動作がスムーズでないと感じるようであれば、不足しているリソースの調査と必要に応じたリソースの追加を検討していただきたい。

注3：RFC 1035: DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION(http://www.ietf.org/rfc/rfc1035.txt)

注4：RFC 2671: Extension Mechanisms for DNS (EDNS0)(http://www.ietf.org/rfc/rfc2671.txt)

日本語訳(http://rfc-jp.nic.ad.jp/rfc-jp/RFC2671-JP.txt)

　今回は、DNSSECに対応したキャッシュDNSサーバの構築と運用について解説した。次回は、権威DNSサーバで管理するゾーンをDNSSECで署名する方法について説明する。