自宅サーバにBINDを導入して，LAN内から使用する(内向き)DNSを設定する

１．はじめに

自宅内ネットワーク(LAN)からインターネットに接続する場合，ブロードバンドルータなどのDHCPサーバを使っていないと，各マシン毎にDNSの設定が必要になる．

これは通常，プロバイダのDNSを参照する設定になるのだが，自宅内ネットワーク内にLANから使用する専用のDNS(内向きDNS)を立てることにより，その設定を簡略化する．

また，そのDNSでの応答キャッシュにより，DNS問い合わせの性能が改善することも狙う．

↑

環境

何やら古くさいが，以下の環境．
  • bind-devel-9.2.1-0.71.1.i386.rpm
  • bind-9.2.1-0.71.1.i386.rpm
  • bind-utils-9.2.1-0.71.1
  • rp-pppoe-2.6-5
  • ppp-2.4.0-2

後ろ2個のPPP関係は直接DNSの話には関係ないが，PPPoEで接続したときにBINDの設定を動的に変えるという小細工が出てくるので，一応．

↑

構成図

今回DNSを動かすのは，ルータ兼用のカモランドサーバである．

bind1.png

LAN内のPCからのDNSリクエストはここに集約することで，キャッシュ効果も狙う．

↑

２．BINDの設定

別に外に対して何かゾーンの情報を提供するというわけではなく，問い合わせは全部プロバイダのDNSに丸投げするので，至ってシンプル．

↑

/etc/named.conf

options {
	directory "/var/named";
	recursion yes;

	listen-on {192.168.0.254;};
	allow-query {localhost; 192.168.0.0/24;};

	forwarders {210.?.?.?;};
};

zone "." {
	type hint;
	file "named.root";
};

zone "localhost" {
	type master;
	file "localhost.zone";
};

zone "0.0.127.in-addr.arpa" {
	type master;
	file "localhost.rev";
};

recursion yes
LAN内のマシンからリゾルバの参照先として設定するため，再帰検索を受け付けることが必須．それでyes．デフォルトでyesらしいが，一応明示しておく．

listen-on {192.168.0.254;}
このDNSマシンはルータの役割も兼ねているので，ネットワークカードが2枚刺さっているのだが，LAN側でしかLISTENしないように設定する(192.168.0.254というのは，LAN側のネットワークカードに割り当てているIPアドレス)．これにより，インターネット側からは問い合わせできなくなる．

allow-query {localhost; 192.168.0.0/24;}
前述のlisten-onで大丈夫なはずだが，念のためここでもLAN内からしか問い合わせできないように制限する．192.168.0.0/24は，うちのLANのネットワークアドレス．

forwarders {210.?.?.?;}
もちろん本当に?とか書くわけではなく，実際にはプロバイダのDNSのIPアドレスをforwardersで指定する．これが無いとルートサーバに検索に行くことになるが，それは性能的，マナー的に凶悪だ．

で，このプロバイダのDNSはIPアドレスが公開されていればそれを記述すれば良いが，そうでない場合は，ADSL等でPPPoE接続したときに自動取得された設定を記述することになる．

これは通常，PPPoE接続時に /etc/resolve.confに自動反映されるのでそれを見て書けばよいが，特に公開されているものではない場合，いつIPアドレスが変わるか判らないという問題がある．(そうコロコロ変えられても困りますが)

この話は後述．

↑

ルートDNSの設定

ルートDNSの情報ファイルをダウンロードしてきて配置する． 

 $ wget ftp://ftp.nic.ad.jp/internet/rs.internic.net/domain/named.root
 # cp named.root /var/named/named.root

↑

/var/named/localhost.zone (localhost用正引きファイル)

$TTL 1D

@       IN		SOA	ns.kamoland.com. kamoland.gmail.com. ( ; DNS機のホスト名と管理者メルアド(@→.)
        2007032201
        3H
        1H
        1W
        1D )
		IN      NS      ns.kamoland.com.
localhost.		IN      A       127.0.0.1

↑

/var/named/localhost.rev (localhost用逆引きファイル)

$TTL    1D

@       IN		SOA	ns.kamoland.com. kamoland.gmail.com. (
        2003072501
        3H
        1H
        1W
        1D )
		IN      NS      ns.kamoland.com.
1		IN      PTR     localhost.

いくら問い合わせは外部(プロバイダのDNS)に丸投げするとは言え，localhostだけは各DNSの責任で解決できるようにしておかなくてはならないようだ．

↑

３．BINDの起動

BINDを起動する． 

 # service named start

起動したっぽいので， 

 # service named status

を叩いてみると， 

number of zones: 4
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
server is up and running
何やら動いているようだ．後はsyslog(/var/log/messages)にも何か出るので確認する．

↑

４．BINDの動作テスト

↑

localhostの正引き，逆引き

$ host localhost
localhost has address 127.0.0.1

$ host 127.0.0.1
1.0.0.127.in-addr.arpa domain name pointer localhost.
OKだ．

↑

外のホストの正引き，逆引き

$ host www.google.co.jp
www.google.co.jp is an alias for www.google.com.
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 66.102.7.99
www.l.google.com has address 66.102.7.104
www.l.google.com has address 66.102.7.147

$ host 66.102.7.99
99.7.102.66.in-addr.arpa domain name pointer mc-in-f99.google.com.
OK． 今度は，使うDNSとして自分を明示して試してみる． 
$ host www.google.co.jp 192.168.0.254
Using domain server:
Name: 192.168.0.254
Address: 192.168.0.254#53
Aliases:

www.google.co.jp is an alias for www.google.com.
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 66.102.7.104
www.l.google.com has address 66.102.7.147
www.l.google.com has address 66.102.7.99

$ host 66.102.7.99 192.168.0.254
Using domain server:
Name: 192.168.0.254
Address: 192.168.0.254#53
Aliases:

99.7.102.66.in-addr.arpa domain name pointer mc-in-f99.google.com.
うまくいったようだ．

↑

５．PPPoEとの連動 (お勧めできない作業)

既に書いたように，プロバイダDNSのIPアドレスは，コロコロ変えられては困るもののいつか変わる可能性を否定できない．

それで今回は，PPPoEの接続を行ったタイミングで，最新情報で更新するという方法を使っている．

pppoeで接続後のresolve.confには，プロバイダのDNSのアドレスが設定されているので，これを /etc/named.confのforwardersパラメータに反映して，namedを再起動するという方針だ．

↑

/etc/ppp/ip-up.local に追加

# 2007.03.24 for named
NSLIST=`cat /etc/resolv.conf |awk '/nameserver/{print $2}'|sed -e 's/$/;/g'`
NSJOIN=''
for NS in $NSLIST; do
	NSJOIN=$NSJOIN$NS' '
done
\cp /etc/named.conf /etc/named.conf.bak
cat /etc/named.conf.bak |sed -e "s/forwarders.*$/forwarders {$NSJOIN};/" > /etc/named.conf
ip-up.localは，ppp接続時の最後にrootで実行されるスクリプト．(詳しくはpppdのmanページ参照)

やっていることはといえば，resolv.confをスキャンしてnameserver行の内容を抽出し，それをnamed.confのforwarders行に埋め込むという泥臭い作業．

↑

連動のテスト

以下のようにして，実際にPPPoEを切断，再接続してみる 

 # service pppoe stop


 # service pppoe start

named.confが正しく更新されていて，bindの再起動をsyslogで確認できればOK．

まぁ実際には，プロバイダもDNSのIPアドレスはそう変えないだろうから，この章の内容はやらなくても良いはず． というか，DNS移行期間が設けられる可能性を考えると，むしろPPPoEでの値で上書きされると困るかも知れないので， この連動については人にはあまりお勧めできません．

© 2024 KMIソフトウェア