Debian 6 (Squeeze)で運用しているDTIのVPSサーバーはDNSサーバーとしても動いています。
今回はこの DNS - bind9 9.7.3 をDNSSEC対応にしてみました。
別途、課題の項目に掲載していますが、DNSSECに対応するだけでは不十分で、実用にするためにはDSレコードの公開が必要です。これにはドメインを登録しているRegistarがDNSSECに対応する必要があるので、国内ではほぼJPRS系列のJPDirectがサポートしている.jpドメインのみではないかなと思われます。
ドメイン毎の対応状況
今回の作業の目的は、サーバーが応答として返した検索結果が正しい事をクライアント側が検証できる環境を作る事です。
メールサーバーはSPF - Sender Policy Frameworkに対応させたので、今回の作業は、この補強の意味あいが強いです。
とはいえ、目的の.netドメインはルートサーバー側がDSレコードに対応しているのみで、ISCのDLVには未対応です。
この状況自体は何も問題がなくて、むしろ後発ならDSレコード方式にのみ対応しているのは正しいのですが、ここら辺の意味と対応状況が分かるように下調べをする事が必要です。
とはいえ日本語の情報も充実してきているので、DNSSECについて解説ページを一通り読めば問題なく作業に入れると思います。
参考文献
今回の作業は全面的にConfiguring DNSSEC On BIND9 (9.7.3) On Debian Squeeze/Ubuntu 11.10に依っています。
その他にはIANAやISCのドキュメントも読んでいますが、作業自体にはこれだけで良いと思います。
作業中に気がついた事
導入しておくべきパッケージ
dnssec-toolsパッケージが必要な事は当然ですが、署名を行なうzonesignerはPerlスクリプトで組まれているので、なくても動きますが、libcrypt-openssl-random-perlパッケージもほぼ必須です。
bind9の他にこの2つのパッケージを導入することは忘れないでください。
zonesignerコマンドの引数
手順の中でzonesignerコマンドを実行するところがありますが、適宜ゾーン名などのを変更する必要があります。
この引数に指定されているpri.example.orgはzoneファイル名で、/etc/bind以下に存在するファイル名を指定します。実際には次のようなコマンドラインになるはずです。
$ cd /etc/bind
$ sudo zonesigner -genkeys -usensec3 -zone example.org pri.example.org
"-zone"オプションに指定しているゾーン名が、pri.example.orgファイルにあるzoneエントリ名と一致する事を確認してください。
pri.example.orgというゾーンファイルの名称
Debian系のディストリビューションでは、ゾーンを記述するファイル名は、通常はdb.で始まるファイル名を使用します。
pri.example.orgという名前をみて、最初の説明をちゃんと覚えておかないと、何のことやら迷ってしまうかもしれないので注意しましょう。
DNSエントリの修正方法
作業の流れは従来の無署名なzoneファイル(記事中での pri.example.org)を編集して、その内容に対して従来の鍵を使って新しい .signed ゾーンファイルを生成します。
2回目以降に-genkeysオプションを付けると、失敗するので注意しましょう。
$ sudo zonesigner -zone example.org pri.example.org
スレーブサーバーをBIND9 9.8系で構成する
基本的に9.8系はDNSSECに対応しているので、dnssec-validation auto;を含めるだけで対応できます。
スレーブサーバー側は他のサーバーからの問い合わせに対して、正しく署名された返答を行なわなければいけないわけですが、
シリアル値の更新について
良いのかどうか、zonesignerは無署名のpri.example.orgファイルのシリアル値を1つづつ更新してくれます。
編集する時に気を使う必要はないのですが、日付+シリアルという典型的な管理方法を行なっている組織だと、予定していたシリアル値より1つ多い数字が使われてしまう事で、台帳情報と噛み合わないといった混乱を招くかもしれません。
センダリDNSサーバーについて
これまでは、お名前.comに登録しているドメインだったこともあり、セカンダリDNSサーバーサービスを利用していました。
この方式は、ほぼ何もセキュリティのない状態でIPアドレスだけをキーにゾーン転送を受け付け、他のサーバーからの問い合わせに答えてくれる、原始的なDNSサーバーサービスが提供されるだけでした。
今回はDNSSECに対応した事でセカンダリサーバーを、さくらのVPSで使用しているサーバーに構築しました。
前年ながらお名前.comのセカンダリDNSサービスはエントリから削除しています。
もう少し様子をみますが、最終的にはメールとDNSの機能はDTIの490円プランで2台を大阪と東京に配置して、プライマリー、セカンダリーという構成になるでしょう。
DNSSECに対応させたプライマリ、セカンダリサーバーの設定を検証する
DSレコードの追加を申請する前に、手元のUbuntu 10.04 LTSでbind9を動かして、DNSSECが動くかどうか検証します。
基本的な考え方
手元のbind9にはDNSSECに変更したドメインに対するリクエストをフォワードして、DNSSECリクエストを解釈するために必要な鍵情報を追加します。
named.conf.localファイルから抜粋
zone "example.org" {
type forward;
forward only;
forwarders { 183.1xx.165.1xx; };
}; Ubuntu 10.04 LTS上の/etc/bind/named.conf.optionsの下半分くらいは以下のような内容になっています。
named.conf.optionsファイルから抜粋
...
listen-on-v6 { internals; };
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
};
include "/etc/bind/bind.keys";
managed-keys {
example.org. initial-key 257 3 8 "AwEAAbjthg82WErIMm+gcsOeNlI6j7/9VuihQtYVnt9dOFWeddfZxlbv VIFKklxBLMmBt4Z5GULTDKg+2BA6hGq3UGTHJMg1cpYTZtUBF4R1LnxL 2KB15rBFtU8b3C8OtrpGsEI/VUWeii5IPopFU04QMDCQkXBiulwHbG6Z cynlvYeaUC94CVabjTPpO95BysAZqBrxQsWyokMWwMtX6V0+uYlzGIU2 OJazpYkWsIrAfpY2dRL15pugx4gCWMZwdsrfiHZSS7nlDCaDbAgsTS5t QiU4zy2YQ7vst7U4Zmh0+WbfHefeyVByCdiQaF2UmVsmnTxuEtu1Y3SS ClmDzq2/wW8=";
}; このmanaged-keys行に加える内容は3つ生成されたキーファイルの中で、先頭に"a key-signing key"と書かれているKSKファイルの内容です。
キーファイルの内容はexample.org. IN DNSKEY 257 3 8 ...で始まっているので、これをexample.org. initial-key 257 3 8 "...に変更して行の最後に";を忘れずに追加します。
Ubuntu 10.04 LTSでのdig +dnssecコマンド固有の修正
明日(4/26)から12.04 LTSが出るので、どうでも良いんですが、bind9周りが古すぎるので、修正が必要です。
一番肝心な/etc/bind/bind.keysの内容が古く、ISCのDLVに対応した1エントリしかないのでDebina6サーバー側からコピーしてきました。"dlv.isc.org"で始まるエントリの他に. initial-key 257 3 8 で始まるエントリが含まれているはずです。
/etc/bind/bind.keysファイルを最新にしたら、ローカルのbind9を再起動します。
$ /etc/init.d/bind9 restart
digコマンドによる検証
成功するとflags行に"ad"が追加されます。
$ dig +dnssec www.yadiary.net @localhost
出力結果
; <<>> DiG 9.7.0-P1 <<>> +dnssec sakura.yadiary.net @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24794
;; <em>flags: qr rd ra ad</em>; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;sakura.yadiary.net. IN A
;; ANSWER SECTION:
sakura.yadiary.net. 1800 IN A 49.212.135.212
sakura.yadiary.net. 1800 IN RRSIG A 8 3 1800 20120525032448 20120425032448 61503 yadiary.net. k+rxyPboH5QMm+vU/bPU3NH6crnjyefv5Ns5Oq4a2jyfVB4N8zhiO21H FupjuoRvyQaScgjy1jVe6PaZtnhpmbb837IEpl5Xm4u+WnullBtyBshV fszUKq5fFhdkkueMEmm0KWXuOLqajRBO2Mzr13xxWfGj2pAxkz2hybkb OcY=
;; AUTHORITY SECTION:
yadiary.net. 1800 IN NS sakura.yadiary.net.
yadiary.net. 1800 IN NS wwwdti.yadiary.net.
yadiary.net. 1800 IN RRSIG NS 8 2 1800 20120525032448 20120425032448 61503 yadiary.net. hrV/CTOqW9cO5PSnlgg5/cDjkqtIHExQ37nrptaxK0wkls4tdvz6yPDt wBOW3dgdwX5A+Nl0Cd9Vg4oyPei0J5s3lg5eXAXfpW9JNOPwYiyQzmT7 BYYg52EOEzDQfRlQzi0hSkNI2uhcolUwRQFS7Z7MK8yACE5l5yFbJwK5 cbg=
DNSSECに対応したDNSサーバーを公開する最後の課題
最後の最後で問題があって、DNSサーバーをDNSSECに対応させても、実際にはドメインを登録しているレジストラがマスター、スレーブのDNSサーバー情報に加えて、DSレコード情報の登録・公開にも対応している必要があります。
TLD毎の対応状況はICANNが公開していますが、これに掲載されているからといって必ずDNSSECに対応できるわけではありません。
どのRegistarが、どのドメインのDSレコードをメンテナンスできるかはICANNが別途まとめています。
例えばJPRSが運営する.jpドメインは、ほぼ全てがDNSSECに対応可能となっていて、DSレコードの登録受け付けと処理方法が案内されています。
4/19付け更新のICANNの情報にもJPRSは載っていないわけですから、国内で.net/.com/.org等に対応しているRegistarがないとは限りませんが、この状況だとGoDaddy辺りにトランスファーしようかなと思ってしまうわけです。
とりあえず今回はDNSSECに対応はしましたが、自分のドメインを管理しているRegistarがDSレコードの公開に対応するまでは、このまま放置する事になってしまいます。
国内でDNSSECが普及するとしたら、.jpドメインが積極的に対応していく以外にはないでしょうね。
しょうがないのでDLVに登録してみた
dlv.isc.orgにKSKファイルの内容を登録してみました。
最初にKSKファイルの内容を登録すると、DNSにTXTレコードを追加するように促されるので、その通りにエントリを追加します。
ここがポイントですが、自動的にはre-checkは行なわれないので、dlv.isc.orgの"Managed Zones"から状況を確認して"details" → "details" と2ページほど先に進むと、Last Verification Statusという欄があるので、そのrequest re-checkリンクをクリックします。
これでDNS
DLVレコードのチェック方法
処理が進むと、DLVレコードが example.org.dlv.isc.org といった domain name + ".dlv.isc.org" に追加されます。
$ dig dlv example.org.dlv.isc.org などとすると、検索できます。
これを手元から利用可能にするには、bind9のdnssec-lookaside行を修正します。
bind9 9.7用の設定
options { ...
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside . trust-anchor dlv.isc.org.;
}; この状態で手元から $ dig +dnssec example.org のように実行すると、flagsにadが追加され、検証された事がわかります。
Ubuntu 10.04 LTSやDebian6のbind9をデフォルトで運用している限りはDNSSECは有効にならないので、キャッシュ用DNSサーバーでは設定変更が必要になります。
手元のキャッシュDNSサーバーをすべて変更して、FirefoxのDNSSEC Validator Addonを使ったところ無事に検証できました。
さいごに
駆け足でしたがVPSサーバーを2台使う事にしたので、DNSSECに対応させました。
ちなみにDNSのmaster/slave構成の間はTSIGを使ってAXFRされるデータの認証を行なっています。
TSIGは暗号化ではなく認証のみを提供する、簡単に実装できる仕組みですが、別の機会に説明したいと思います。
ただDNSSECを導入するのであれば、マスタ・スレーブ間のデータコピーは確実に行なう必要があり、これはDNSSECではサポートされない点に注意してください。DNSSECはあくまでも各レコードの内容について署名をするだけです。
