bindからnsdへ

前記事にて、DNSのキャッシュサーバをbindからunboundへ移行した訳ですが、DNSのコンテンツサーバも
bindから移行することにしました。nsdってやつ。
bindのzoneファイルがそのまま使えるってのはありがたいですね。
※コンテンツサーバというネーミングはどうもしっくりこない。

portsからインストールしてもいいんだが、dnsとかwebとか緊急のパッチが必要なときには、portsだときついので、自前でインストールします。

% tar zxvf nsd-3.2.13.tar.gz
% cd nsd-3.2.13
% ./configure --prefix=/usr/local/nsd
% make
# make install

※DNSSECとかまだやりません。

起動スクリプトだけ、手抜きでいつものごとくportsでもってきます。
/usr/local/etc/rc.d/nsdに配置して、パスの設定だけ編集して、
/etc/rc.confに

nsd_enable="YES"

/var/db/nsdにchrootされるようにしているので、ここに今まで利用していたゾーンファイルを
置いて

/usr/local/nsd/sbin/nsdc rebuild

でDB化してくれます。
/usr/local/etc/rc.d/nsdスクリプトを見ると、reload時もちゃんと、事前にrebuildしてくれてます。
zoneファイルを書き換えて、reloadしてやればいいだけですね。

nsdcというコマンドでいろいろできるようです。

特別なことは何もしてないので、主にzoneの記述をしてやるだけで、ほぼ変更なしです。
IPv6の設定は有効にしています。

以下、/usr/local/nsd/etc/nsd.confの一部

server:
	ip-address: 192.168.0.XXX
	ip-address: 2001:470:24:XXX::YYY
	ip4-only: no
	ip6-only: no
略
zone:
	name: "pman.biz"
	zonefile: "db.pman.biz"
        provide-xfr: 192.168.0.0/24 NOKEY
        provide-xfr: 2001:470:24:XXX::/64 NOKEY
zone:
	name: "XXX.24.470.2001.ip6.arpa"
	zonefile: "db.2001.470.24.XXX.ip6.arpa"
zone:
	name: "YYY.470.2001.ip6.arpa"
	zonefile: "db.2001.470.YYY.ip6.arpa"
略

(*) provide-xfrでゾーン転送をLANから可能に設定。

 

unbound::stub-zone

自宅LAN内のクライアントPC達へ名前解決を行う再起問い合わせ可能なキャッシュサーバをbindからunboundへリプレイスしました。
このblogのサーバはNATさせているので、自宅内のクライアントからアクセスするためには、192.168.0.xxxのプライベートアドレスを返してあげる必要があります。
今までは、bindのviewを使って記載していました。
unboundでも同様なことができそうなので、loca-dataを使って、unbound.confを変更しました。

local-data: "lol.pman.biz IN A 192.168.0.xxx"

上記を追加してうまく名前解決ができるようになりました。しかし、local-dataでoverwriteしていないホスト名は全く返ってきません。。。
local-dataに記載のないものは、通常の名前解決を実施するはず。
つまり、

local-zone: "pman.biz" transparent

は、暗黙のルールであるはず。。

こんなところではまって、いろいろ調べてたのですが、原因はunboundの問題ではなかった。。
他のホストはlol.pman.bizにmactchしないので、通常の問い合わせをunboundが実施。。
通常の問い合わせを実施するので、pman.bizのネームサーバに問い合わせする訳だが、よく考えると、このネームサーバはインターネットから見るとグローバルアドレスな訳…

unboundとnsd(コンテンツサーバ)は同一サーバで動作させているので、グローバルアドレスに問い合わせに
いくためには、NATをしているfirewall(vyatta)を経由することになる。。。
ヘアピンNATの設定はしていないので、通信できる訳がないことに気づいた。

forwarderか何かを使って回避できないかとunboundを調べていると、stub-zoneという記述を発見。
これが今回はあっていそうなので、利用します。

stub-zone: 
  name: pman.biz
  stub-addr: 192.168.0.xxx (nsdが動作しているLAN内のプライベートIP)

これで、local-dataにマッチしないpman.bizに属する他のホストは、stub-zoneの設定に従い名前解決できました。

自宅内LANから他のホストのアドレスの名前解決ができて何がうれしいかって?
名前が解決できてもヘアピンNATでないので、実際にはアクセスできないので、不要なのですが、応答がないやNXDOMAINなどではトラブルシュートの際にあせってしまうので、マッチしないものは、適切なDNS zoneから名前解決しているという事実が得られるだけありがたい。ってなだけです。

ひとつ問題。
IPv6のアドレスは自宅内でもグローバルで割り当てているので、local-dataでoverwriteする必要は全くないのですが、IPv4のホストはlocal-dataでoverwriteしているのでIPv6も同じようにと思って設定したのですが、これはダメでした。。。

何がダメかというと、local-dataそのものの動作は問題ないのですが、local-dataでマッチしないIPv6のホストを引くと、stub-zoneで設定したDNSへ問い合わせしてくれず、無応答のまま。。

ってな訳で、IPv6のAAAAは、local-dataをoverwriteせずに、stub-zoneへ問い合わせることにしました。
原因の追求はしていません。
stub-addrで、IPv6のアドレスも定義してやればいいのかな〜。。。これで動作してもなんかしっくりこない。
transport prtocolはv4でもいいだろ!って感じになるので。