どさにっきクラウド 〜2009年6月上旬〜

by やまや
<< = >>

2009年6月8日(月)

無題

_ おひさしぶり。いきてるよ。

ゾーン外 CNAME

_ えーと、DNS にこういうレコード↓

hoge.example.com.  IN  CNAME  fuga.example.net.
が置いてあるとする。んで、example.net のゾーンはよその DNS で管理してると。

_ んで、dig でこのレコードについて問い合わせをしてみる。

% dig @ns.example.com hoge.example.com
BIND9 のこの結果が、なんかおかしい。

_ answer section はちゃんと答が返ってきてる。が、なぜか、authority section が

;; AUTHORITY SECTION:
.                       3600000 IN      NS      A.ROOT-SERVERS.NET.
.                       3600000 IN      NS      B.ROOT-SERVERS.NET.
(以下略)
とルートサーバが権威を持ってるよ、という答を返してくる。example.com のゾーンは自分自身で持ってるんだから、example.com の正しい NS (=自分自身)を知ってるはずなのに。CNAME が指してる先が fuga.example.net ではなくて fuga.example.com のように自前のゾーン内ならちゃんとそういう答が返ってくるのに。なんで?

_ さらに、同じ BIND9 で

zone "." { type hint; file "/dev/null"; };
としてルートサーバのヒント情報を潰して (*1)同じ問い合わせをしてみると、SERVFAIL でエラーになってしまう。なんで?

_ 実は、上の dig の問い合わせは間違ってる。

つーことで、これを直してやりなおしてみる。
% dig @ns.example.com hoge.example.com CNAME
→ authority section で「正しい NS」が返ってくる。CNAME +norec でも同様。ANY も同じ。
% dig @ns.example.com hoge.example.com +norec
→ authority section でルートサーバが返ってくる。ルートヒントが空でも authority が空になるだけでエラーにはならない。

_ 実際に問い合わせてみないと CNAME なのか A なのか(それともまた別のタイプなのか)はわからんので CNAME に対して A を聞かれることは多々あるけど、コンテンツサーバに対して再帰検索されることはないので、実運用ではとりあえずエラーを返すようなことない。依然としてルートサーバの情報が混じってきちゃうけど、こいつは(たぶん)無視されるなのでそれほど気にしなくていい。以上、BIND 9.3 と 9.4 で確認。

_ これが NSD だと、A を聞いても +norec じゃなくても、BIND9 で CNAME と明示して問い合わせたときと同じように、エラーになることなく authority section に正しい NS がセットされた答が返ってくる。これが正しい姿なんじゃないかと思うんだが……。BIND はどうしてあんな答を返すんだろ? CNAME の指してる先が自前管理かそうでないかで挙動が変わるというのがさっぱりわけわからん。


(*1): コンテンツサーバは自分自身が知ってること以外は答えないので、ルートサーバを知っている必要はない。 JPRS でもオススメしてる設定。コンテンツサーバ専業の NSD や tinydns (djbdns) はそもそもルートヒントを設定することができない。

<< = >>
やまや