NSDとUnboundで社内用DNSサーバを立てた話

Posted by on 2012年10月18日

システム開発部ブログに社内システム管理者が乱入です。
わたなべです。

社内用にDNSサーバを立てる事にしました。
社内にDNSサーバを立てるとこんないいことがあります。

  • DNSの名前解決が速くなる
  • 社内LAN上の他のPCを参照する時にFQDNっぽい書き方が使えてかっこいい
  • VirtualHostで開発環境にWebアプリを作った時に他の人に見てもらうのが簡単

主な目的は一番下です。
名前解決が速くなるなんていうのは体感的にたかが知れてますし
ローカルのドメイン名が使えるのは副産物です。

ある開発者が app1.example.com と app2.example.com という
別のドメインで動くWebアプリを、開発用PCで並行して開発しているとします。

ある程度開発が進み、社内レビューとなりました。
開発中に社内の他の人に見てもらうという事はよくあることですね。

その場合、まず簡単な方法は IPアドレスでアクセスしてもらう、という方法です。
開発用PCのWebサーバに/app1/および/app2/という仮想ディレクトリを置き、

  • http://192.168.1.x/app1/〜
  • http://192.168.1.x/app2/〜

というURLでそれぞれアクセスしてもらう、という方法です。

ですがこれだとURL階層が一段増えてしまいます。
ついうっかりこの認識でプログラムを組んでしまうと、本番環境で不具合を起こしかねません。

他にはポートを変える、という方法もあります。

  • http://192.168.1.x/〜 （こっちでapp1を動かす）
  • http://192.168.1.x:8080/〜 （こっちでapp2を動かす）

一応用は足りますが…

    「アクセスできないよー」
    「うそーん」
    「ほら、サーバが見つかりませんって」
    「ああ、パーソナルファイアウォールが蹴ってた…」

IPアドレス自体を別に持つ、という方法もある事はあります。
PCにIPアドレスを２つ設定し、

  • http://192.168.1.x/〜 （こっちでapp1を動かす）
  • http://192.168.1.y/〜 （こっちでapp2を動かす）

    「おい誰だ俺のIPアドレスにかぶらしたの！」
    「やべっ」

素直にVirtualHostの設定をしました。

  • http://app1.mytest.dom/〜 （こっちでapp1を動かす）
  • http://app2.mytest.dom/〜 （こっちでapp2を動かす）

    「見つからないよ」
    「すいません、hostsに書き足す必要があるんです」
    「なにホスツって」
    「Windowsのsystem32の下にある…ああ、メモ帳は管理者権限で…あれこれ64bitでしたっけ？だったらファイルを開くで…」
    「なにこれこわい」

そこで社内用DNSです。

上の例で言えば、社内用のDNSに

  • app1.mytest.dom → 192.168.1.x
  • app2.mytest.dom → 192.168.1.x

を登録すれば、
開発者も最初からVirtualHost環境で開発しておいて

    「http://app1.mytest.dom/ ，それと同じくapp2見てくださーい」
    「「はーいこれね」」

で済みます。

今回の環境は Ubuntu 12.04 です。
前のいしかわさんのエントリで分かるとおり、システム開発部の開発用ではCentOSを使っていますが
ロゴスウェアの社内システム・ネットワークで使っているLinuxサーバは、基本的にUbuntu Linuxを使用しています。
私の趣味です（笑）

DNSサーバは有名なものはBINDですが、
今回はNSDとUnboundを使ってみる事にしました。
ロゴスウェアにはつくばと東京の２拠点ありまして、VPNで内部ネットワークが接続されているので
権威サーバは一つあれば十分ではあるのですが、
せっかくなのでそれぞれに立ててそれぞれの分を登録し、お互いにゾーン転送させてみます。

NSDとUnbound概念図

NSDとUnbound概念図

同一サーバでNSDとUnboundを動かすにあたって、NSDを10053ポートで動かす事にしました。

sudo apt-get install nsd
sudo apt-get install unbound

nsdは 3.2.9-1，unboundは 1.4.16-1 がインストールされました。

設定ファイルを書き換えます。
/etc/nsd3/nsd.conf

server:
    port: 10053
    zonesdir: "/etc/nsd3/zones"

key:
    name: nsd_key
    algorithm: hmac-sha1
    secret: "xxxxxxxxxxxxxxxxxxxxxxxx"

###master
zone:
    name: "tsukuba.mydomain"
    zonefile: "tsukuba.mydomain.zone"

    notify: 192.168.11.5@10053 nsd_key
    provide-xfr: 192.168.11.5 nsd_key

###slave
zone:
    name: "tokyo.mydomain"
    zonefile: "tokyo.mydomain.zone"

    allow-notify: 192.168.11.5 nsd_key
    request-xfr: 192.168.11.5@10053 nsd_key

ポート番号を10053に変更し、ゾーンファイルの置き場をzonesディレクトリ以下としました。

ちょっとハマった事としては、

  • notifyとrequest-xfrにはポート指定（＠10053）を付ける
  • allow-notifyとprovide-xfrにはポート指定を付けない

という点。
よく考えればそりゃそうです。「知らせる先(notify)」「要求する先(request-xfr)」だったら
その送信先ポート番号が必要で、
「ここからの知らせは受ける(allow-notify)」「ここには提供する(provide-xfr)」に関しては、
どこから来たかのIPアドレスしか分からないですから。送信元ポートなんて適当に変わるものだし。
最初全箇所にポート番号つけてしまってREFUSEDされてしばらく悩んでしまいました。

/etc/unbound/unbound.conf

server:
    interface: 0.0.0.0
    access-control: 127.0.0.0/8 allow
    access-control: 192.168.1.0/24 allow
    access-control: 192.168.11.0/24 allow
    do-not-query-localhost: no

stub-zone:
    name: "tsukuba.mydomain"
    stub-addr: 127.0.0.1@10053

stub-zone:
    name: "tokyo.mydomain"
    stub-addr: 127.0.0.1@10053

forward-zone:
    name: "."
    forward-addr: 192.168.1.1

自ホストおよび社内のIPアドレスからのアクセスを受け、
社内で使用しているドメインについてはスタブゾーンとしてNSDから参照し、
それ以外はルータに対して再問い合わせを投げる、という設定にしました。

ここでハマったのは do-not-query-localhost の設定です。
確かに単純に考えれば自身に対して再問い合わせを投げる事が出来ると
無限ループになってしまう危険性がでてきますが、
今回の設定の場合ポートが異なるので自身への問い合わせにはなりません。
ですが、デフォルトでは localhost だったらポートは何であろうとダメ、という動きになるようで、
これをnoにする事で、NSDからDNS情報が取得出来るようになりました。

The following two tabs change content below.

ロゴスウェア

ロゴスウェア株式会社は、インターネットや情報技術を使って学習に革新的進化をもたらす製品を開発することを目標に、2001年7月に設立されたテクノロジー系ベンチャー企業です。
テクニック

Comments are closed.