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でもいいだろ!って感じになるので。

 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

*