DNSコンテンツサーバとキャッシュサーバを分ける理由

<< DNS Summer Days 2012 togetterまとめからの感想 | TOP | 共有サーバホスティングでのドメイン・アカウント紐付け方法 >>

2012年09月02日

DNSコンテンツサーバとキャッシュサーバを分ける理由

はじめに言っておくと、だいたいBIND8のせいです。

（少なくとも昔の）BINDは、masterなゾーンが設定されているとき（recurseな）クエリを受けると、自分が権威サーバかチェックすることなく、単にそれを返す。したがってドメイン所有者が転出してしまったあと、ドメイン所有者とDNSサーバ提供事業者（webホスティングとか）の間で意思疎通がなくなって、Lameなmasterゾーンが残っていると、そのDNSをキャッシュとして使っている内側のユーザには古いlameなゾーンの情報が返され続けることなる。
またゾーン管理スクリプトの委任関係のチェックが甘いと、不正な（当然lameな）ゾーンを突っ込まれる可能性もある。これが直ぐDNSのポイズニングにつながるかどうかは、正しく設定されているかによる。

もちろん、DNSキャッシュとコンテンツが同一のマシン・プログラムで動いていても、セキュリティ・ポリシーとして、キャッシュする際には権威があるサーバー（つまり自分になるはず）までルートから必ず確認しに行くように設定できればいい。

ISCのBIND9 http://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.html document view statements あたりを読むと、Bind9で導入された viewを内向きと外向きで切り替え、内向きはキャッシュ動作させ、外＋内向きはコンテンツのみ動作、さらにキャッシュを独立させる（これは少なくとも9.9ではattach-cacheなしがデフォルト）やや面倒な設定をすることでできそうです。

acl local {
192.168.0.0/16;
// このサーバを信頼してくれてる人。お客様は神様です
};

options {/* 全略 */};

view "cache" {
match-recursive-only yes;
// 再帰はキャッシュを通す
// これ設定しないと無限ループするよ！！！

match-clients {127.0.0.1/8; local;};
// 内向きのみ

recursion yes;

include "local.conf";
// RFC規定のhintやローカル関連ゾーンのリスト

include "admin.conf";
// DNSサーバ管理者がメンテしているmaster/slaveゾーンのリスト
// これ信用出来ないならこの鯖意味ないよね

// ここに少しでも不安があるゾーンをincludeしちゃダメ

};

// BINDは+norecurseで探索するのでクエリはこっちに来ます
// forwardするなら同居する意味ないよね

view "userzones" {
match-clients {any;};
// 自分も含めること
recursion no;

include "local.conf";
include "admin.conf";

include "user.conf";
// ユーザーから要求されたmaster/slaveゾーンのリスト
// 管理者がいくらチェックしてても一時的にLAMEってる可能性はある

// ここでattach-cacheはダメ！絶対！
// 今のところattach-cacheはただの参照で階層化してるわけじゃないんです！　BIND9.9doc
};