権威DNSサーバのDNSSEC対応：DNSSEC再入門（4）（1/4 ページ）

インターネットの重要な基盤技術の1つであるDNSに対して新たな攻撃手法が公開され、その安全性が脅かされている。DNSにセキュリティ機能を提供するための技術であり、普及が進んでいるDNSSECについて、仕組みと運用方法を紹介する。（編集部）

[坂口智哉，株式会社日本レジストリサービス（JPRS）]

古くから検討されてきたDNSSEC

　近年注目を集めているDNSSECだが、実はその検討は1993年ごろから始まっている。また、最初の標準としてRFC 2065が発行されたのは1997年のことである。

　それから継続して検討が進められ、現在のDNSSECの技術仕様は、2005年に発行されたRFC 4033、RFC 4034、RFC 4035（注1）がベースとなっている。これに加え、第3回でも触れたキャッシュDNSサーバにおけるトラストアンカーの自動更新の仕様を定めたRFC 5011が2007年に、またゾーンの列挙を困難にするためのNSEC3拡張を定めたRFC 5155が2008年に発行され、ようやく実際にDNSSECが運用できる環境が整ったといったところだ。

　このように古くから検討が進められてきたDNSSECだが、こうした標準化への動き以外にも、最近になってDNSSECの運用を補助するツールが登場し、DNSSECの導入に向けた環境が整ってきている。

　今回は、このような運用を補助するツールの使用方法も交えながら、権威DNSサーバのDNSSEC対応について紹介する。

注1：RFC 4033: DNS Security Introduction and Requirements(http://www.ietf.org/rfc/rfc4033.txt)

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

RFC 4034: Resource Records for the DNS Security Extensions(http://www.ietf.org/rfc/rfc4034.txt)

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

RFC 4035: Protocol Modifications for the DNS Security Extensions(http://www.ietf.org/rfc/rfc4035.txt)

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

DNSSECにおける権威DNSサーバの役割

　DNSSECにおいて権威DNSサーバに求められる役割は4つある。

【1】自ゾーンのKSK公開鍵／ZSK公開鍵を公開する

　第2回で紹介した通りDNSSECでは、信頼の連鎖を構築するための鍵であるKey Signing Key（KSK）と、ゾーン署名用の鍵であるZone Signing Key（ZSK）の2種類の鍵対が使われており、権威DNSサーバではそれぞれの鍵対のうち公開鍵を、ゾーンの中でDNSKEYレコードという形で公開する。バリデータがこのDNSKEYレコードを参照して、署名の検証を行う。KSK、ZSKともに、セキュリティ強度を一定に保つために、定期的な更新が必要である。

【2】下位ゾーンのKSK公開鍵のダイジェストを公開する

　上位ゾーンと下位ゾーンとの信頼の連鎖を構築するために、上位ゾーンを管理する権威DNSサーバでは、DSレコードという形で下位ゾーンのKSK公開鍵のダイジェストを公開する。バリデータは上位ゾーンに登録されたDSレコードと下位ゾーンに登録されたDNSKEYレコードを照合して、信頼の連鎖を確認する。そのため下位ゾーンのKSK公開鍵が更新された場合は、当然ながら上位ゾーンに登録されたDSレコードも更新する必要がある。

【3】署名付きの応答を返す

　自ゾーンの各レコードに署名を付加し、DNSSECに対応したクエリに対し、対応するレコードに加え、RRSIGレコードと呼ばれる署名を付加した応答を返す。署名についてもセキュリティ強度を一定に保つため、定期的に更新する必要がある。

【4】不在証明を返す

　DNSSECにおいて、クエリに対して対応するレコードがなかった場合は、「存在しない」ということを証明しなければならない。DNSSECでは、このような不在証明を提供するものとして、NSECやNSEC3と呼ばれる仕組みを実装している。詳細は省くが、NSECやNSEC3により、その名前の「存在する前後の名前」を返すことで、そのレコードが存在しないことを証明する。

　第3回で紹介した、DNSSECにおけるキャッシュDNSサーバの役割と比べると、権威DNSサーバではその運用において設定すべき内容が多いことが分かる。それだけ、DNSSECに対応した権威DNSサーバは運用者の能力が試されるものであるといえる。

DNSSECの運用設計

　それでは、実際にDNSSECに対応した権威DNSサーバを構築するにはどうすればよいのだろうか。先ほども述べた通り、DNSSECにおいて権威DNSサーバの役割は多く、構築するに当たっての準備として、いくつか決めておかなければならないことがある。

　ここでは、事前に決めておかなければならない代表的な4つの項目を挙げる。これらは現在の環境や社内の運用ルールなどにも左右されるものなので、各自の環境に合った設計をしていただきたい。

　なお以後は、DNSサーバソフトウェア「BIND」の、2011年12月時点の最新版9.8.1-P1を使用するという前提で説明する。

SOAシリアル番号の組織内における運用ルール

　1点目は、SOAシリアル番号の運用ルールについてである。SOAシリアル番号は、そのゾーンに更新があるときに値を増加させ、更新があったことを知らせるための識別子である。

　DNSSECでは、定期的に署名情報の更新を行うため、その都度SOAシリアル番号を増加させる必要がある。BINDでは、ゾーンへ署名を付加する際に、SOAシリアル番号を自動的に更新するか否かを選択できるよう実装されている。表1はBINDに付属する署名ツールで指定できるSOAシリアル番号の表記方法である。SOAシリアル番号の更新し忘れを防ぐためにも、自動化しておくとよいだろう。

　ただし、unixtime表記を用いた場合、既存のSOAシリアル番号の付加ルールとは異なる場合が多いだろう。この場合、DNSSEC導入時にSOAシリアル番号をリセットする必要が生じる可能性があることに注意していただきたい。

表記方法	説明
keep	・SOAシリアル番号は変更しない ・既存のSOAシリアル番号付加ルールを変更せず運用できる ・再署名を行うたびにSOAシリアル番号も手動で更新する必要がある
increment	・RFC 1982の演算に従ってSOAシリアル番号を自動で増加させる ・既存のSOAシリアル番号付加ルールを変更せず運用できる ・署名済みのゾーンファイルそのものをマスターとして運用していく必要がある
unixtime	・署名時の時間（UNIXTIME）をSOAシリアル番号として使用する ・既存のSOAシリアル番号付加ルールを「YYYYMMDDxx」などの形で運用している場合は変更が必要となる ・署名のたびに自動的に更新されるため、SOAシリアル番号の更新忘れによる署名の期限切れが発生しなくなる
表1　BINDにおけるSOAシリアル番号の表記設定

鍵のアルゴリズムと鍵長

　2点目に、鍵のアルゴリズムや鍵長をどうするかである。

　鍵のアルゴリズムについては、特別な理由がない限りは、ルートサーバなどでも採用されているRSASHA256を使うのが望ましいだろう。

　また鍵長であるが、一般にZSKは署名する対象が多く、また頻繁に検証されるため、鍵長は短くするほうがよい。一方のKSKは署名対象が少なく、セキュリティ強度を優先して鍵長を長くするほうがよいとされている。

署名の有効期間

　3点目に、署名の有効期間をどう設計するかである。またこれに関連して、再署名の間隔をどうするかも考えなければならない。

　署名の有効期間はRRSIGレコードに記載され、キャッシュDNSサーバでは有効期間を過ぎたものは無効なものとして扱われる。キャッシュDNSサーバ上でキャッシュされる期間も考慮すると、「1日」など有効期間が短すぎてはならないし、逆に「1年間」のように長すぎてもセキュリティ強度が低下する（BIND 9に付属するツールでは、有効期限を指定しない場合、デフォルトで30日となる）。

　安全かつ確実に運用をしていくためには、ある程度の有効期間を持たせた上で定期的な再署名を実施するとよいだろう。