_ おひさしぶり。いきてるよ。
_ えーと、DNS にこういうレコード↓
が置いてあるとする。んで、example.net のゾーンはよその DNS で管理してると。hoge.example.com. IN CNAME fuga.example.net._ んで、dig でこのレコードについて問い合わせをしてみる。
BIND9 のこの結果が、なんかおかしい。% dig @ns.example.com hoge.example.com_ answer section はちゃんと答が返ってきてる。が、なぜか、authority section が
とルートサーバが権威を持ってるよ、という答を返してくる。example.com のゾーンは自分自身で持ってるんだから、example.com の正しい NS (=自分自身)を知ってるはずなのに。CNAME が指してる先が fuga.example.net ではなくて fuga.example.com のように自前のゾーン内ならちゃんとそういう答が返ってくるのに。なんで?;; AUTHORITY SECTION: . 3600000 IN NS A.ROOT-SERVERS.NET. . 3600000 IN NS B.ROOT-SERVERS.NET. (以下略)_ さらに、同じ BIND9 で
としてルートサーバのヒント情報を潰して (*1)同じ問い合わせをしてみると、SERVFAIL でエラーになってしまう。なんで?zone "." { type hint; file "/dev/null"; };_ 実は、上の dig の問い合わせは間違ってる。
つーことで、これを直してやりなおしてみる。
- タイプを明示してない(CNAME ではなく A を問い合わせてる)
- +norec を指定してない(コンテンツサーバに対して再帰検索を要求してる)
→ authority section で「正しい NS」が返ってくる。CNAME +norec でも同様。ANY も同じ。% dig @ns.example.com hoge.example.com CNAME→ authority section でルートサーバが返ってくる。ルートヒントが空でも authority が空になるだけでエラーにはならない。% dig @ns.example.com hoge.example.com +norec_ 実際に問い合わせてみないと CNAME なのか A なのか(それともまた別のタイプなのか)はわからんので CNAME に対して A を聞かれることは多々あるけど、コンテンツサーバに対して再帰検索されることはないので、実運用ではとりあえずエラーを返すようなことない。依然としてルートサーバの情報が混じってきちゃうけど、こいつは(たぶん)無視されるなのでそれほど気にしなくていい。以上、BIND 9.3 と 9.4 で確認。
_ これが NSD だと、A を聞いても +norec じゃなくても、BIND9 で CNAME と明示して問い合わせたときと同じように、エラーになることなく authority section に正しい NS がセットされた答が返ってくる。これが正しい姿なんじゃないかと思うんだが……。BIND はどうしてあんな答を返すんだろ? CNAME の指してる先が自前管理かそうでないかで挙動が変わるというのがさっぱりわけわからん。
(*1): コンテンツサーバは自分自身が知ってること以外は答えないので、ルートサーバを知っている必要はない。 JPRS でもオススメしてる設定。コンテンツサーバ専業の NSD や tinydns (djbdns) はそもそもルートヒントを設定することができない。