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

 

unboundとcacti

先日、unboundをインストールしたので、ついでにcactiでもデータ取得を行ってみました。
unboundのソースに付属しています。contribディレクトリ内にunbound_cacti.tar.gzファイルがあるのでこれを使います。
展開して、README.txtとscriptととなるunbound_cactiを見ながら設定します。

unboundの統計情報は、unbound-controlを使用して実施されます。
unbound-controlを利用するためunbound用の証明書を作成します。これは、unbound-control-setupコマンドで作成できます。以下4つの鍵および証明書が出力されます。

unbound_server.pem
unbound_server.key
unbound_control.pem
unbound_control.key

次にunbound.confを変更

server:   extended-statistics: yes
          statistics-cumulative: no
          statistics-interval: 0

remote-control:
  control-enable: yes
  control-interface: 127.0.0.1
  control-interface: ::1
  server-key-file: "/PATH/unbound_server.key"
  server-cert-file: "/PATH/unbound_server.pem"
  control-key-file: "/PATH/unbound_control.key"
  control-cert-file: "/PATH/unbound_control.pem"

snmpd.confに以下を追加。

extend  .1.3.6.1.3.1983.1.1 cache_hits /bin/cat /usr/local/etc/unbound/statistics/cache_hits
extend  .1.3.6.1.3.1983.1.2 memory_usage /bin/cat /usr/local/etc/unbound/statistics/memory_usage
extend  .1.3.6.1.3.1983.1.3 queues_by_type /bin/cat /usr/local/etc/unbound/statistics/queues_by_type
extend  .1.3.6.1.3.1983.1.4 answers_to_queries /bin/cat /usr/local/etc/unbound/statistics/answers_to_queries
extend  .1.3.6.1.3.1983.1.5 histogram /bin/cat /usr/local/etc/unbound/statistics/histogram
extend  .1.3.6.1.3.1983.1.6 queues_by_flags /bin/cat /usr/local/etc/unbound/statistics/queues_by_flags
extend  .1.3.6.1.3.1983.1.7 requestlist /bin/cat /usr/local/etc/unbound/statistics/requestlist

cronに下記を設定

*/5 * * * * /PATH/unbound_cacti

実際にunbound_cactiスクリプトを実行し、statisticsディレクトリにデータが書き込まれているか確認し、
最後にsnmpwalkで値が取得できるか確認します。

ここまできたら、後はcactiにテンプレートをimportします。テンプレートファイルは、
unbound-cacti/Host template (all in one)/ ディレクトリにあるcacti_host_template_unbound_dns.xmlになります。
cactiからConsole->Import Templatesを選択し、上記ファイルをimportします。テンプレート名は適当に設定。
あとは、deviceを作成し、host templateで先ほど名付けたテンプレート名”Unbound DNS”を選択してgraphを作成するだけになります。
数日間動作させて問題なく動作しているようです。

こんな感じでグラフ化されます。