2011-02-24 :-(
_ 午後
1300 sleep
_ [DNS][BIND][NetBSD][翻訳]DNS and BIND on NetBSD
NetBSD での DNS と BIND
DNS and BIND on NetBSD
by Hoang Q. Tran
Three advices:
助言が 3 つある
1. Get DNS and BIND book. It's nice to understand how DNS works.
2. DNS needs time to distribute its information.
3. BIND won't load if there is a syntax error.
- DNS and BIND 本を入手せよ。DNS の仕組みを理解するにはよい
- DNS は情報を配布するには時間がかかる
- BIND は{ 設定ファイルを }ロードするときにシンタックスエラーを報告しない
If you have two or more computers, it is recommended to use DNS instead of /etc/hosts. Another obvious advantage is mail routing. With traditional /etc/hosts, there is no easy way to specify backup mail servers for mail delivery. This howto is based on the author's experience with BIND on his favourite NetBSD 1.5.1 and 1.5X boxes.
あなたがもし 2 つかそれ以上のコンピュータを持っているならば、/etc/hosts よりも DNS を使うことをお勧めする。メールルーティングにも優位だ。伝統的な /etc/hosts では、メール配送のためのメールサーバーたちのバックアップを作るのは容易ではない。ここでは、筆者の環境で NetBSD 1.5.1 と 1.5X 系計算機で BIND を使った経験を記す。
- Download BIND
- Setup zone and DNS records
- Secure BIND
- Different DNS servers
- Run DNS for your own domain
- Familiarize with DNS tools
- Reference
- BIND をダウンロードする
- zone と DNS レコードを設定する
- BIND をセキュアにする
- DNS サーバー群の相違
- DNS を自分のドメインで走らせる
- DNS ツールに慣れる
- 参考
Download BIND (BIND をダウンロードする)
NetBSD 1.5.1 comes with BIND 8.2.3 and 8.2.4-REL-NOESW on NetBSD 1.5X. BIND8 is considered to be stable and is used by most root name servers. BIND9 is a complete rewrite with several new features:
NetBSD 1.5.1 では NetBSD 1.5X 用の BIND 8.2.3 と 8.2.4-REL-NOESW が使えるようになった。BIND8 は安定しており、ほとんどのルートネームサーバーで使われている。BIND9 はいくつか実装を書き直したものだ。
DNSSEC (signed zones) TSIG (signed DNS requests) IPv6 support Bitstring Labels DNS Protocol Enhancements IXFR, DDNS, Notify, EDNS0 Views (former split-dns) Multiprocessor Support Improved Portability Architecture
So it is worthwhile to run and play with new features. For the rest of the howto, BIND means BIND version 9.
これらは実際に走らせてみるだけの価値がある機能である。この文書では、 BIND は BIND バージョン 9 を指す。
Since BIND is in the NetBSD packages collection, first, get the packages collection then install BIND. You can skip this part and just download the BIND source from here and just build yourself.
BIND は NetBSD パッケージコレクションに含まれているので、まずはパッケージコレクションを所得し、それから BIND をインストールする。BIND のソースをダウンロードしてビルドするだけならばこの部分は読み飛ばしてよい。
Edit an example supfile in /usr/share/examples/supfiles:
/usr/share/examples/supfiles にある supfile のサンプルを編集する。
# cp /usr/share/examples/supfiles/sup.netbsd.org /etc/ports-supfile
Remove other lines except for the ``current release'' below.
current release の行 以外を削除する。
# $NetBSD: sup.netbsd.org,v 1.4.10.1 2000/08/10 23:15:24 soda Exp $ # # Example supfile for sup.netbsd.org. # current release=pkgsrc host=sup.netbsd.org hostbase=/ftp/pub \ base=/usr prefix=/usr backup use-rel-suffix compress delete
Retrieve the packages collection:
パッケージコレクションを取得。
# cd /usr # sup /etc/ports-supfile ( packages downloading, it will take a while. Maybe now is a good time for an expresso cup... ) ...
Once it is done, build and install BIND9 as:
終わったら BIND9 をビルドしてインストールする。
# cd /usr/pkgsrc/net/BIND9 # make install clean ( BIND9 building, installing and cleaning...Another expresso cup would be nice ) ...
BIND binaries will be installed mostly in /usr/pkg/sbin. It also comes with lwresd and named9 scripts in /usr/pkg/etc/rc.d. Copy named9 to /etc/rc.d and turn on the executable bit with chmod +x.
BIND のバイナリはたいてい /usr/pkg/sbin にインストールされる。lwresd と named9 のスクリプトが /usr/pkg/etc/rc.d に格納される。named9 を /etc/rc.d にコピーし、chmod +x して実行ビットを立てる。
# cp /usr/pkg/etc/rc.d/named9 /etc/rc.d # chmod +x /etc/rc.d/named9
lwresd is the lightweight resident daemon. Not a requirement to get BIND running. Now, enable BIND on startup:
lwresd はライトウェイトの軽量デーモンであり、BIND とは別に動作する。{ システムの } 起動時に BIND を有効にさせる。
# vi /etc/rc.conf.d/named9 and add:
named9=YES named_flags="-c /etc/namedb/named.conf"
This will start BIND as root user in non-chroot compartment. Section 3 of this howto will change how it runs.
これで root ユーザーとして BIND が起動するようになるのだが、chroot 環境ではない。それについてはセクション 3 で扱う。
Setup zone and DNS records (zone と DNS レコードを設定する)
For this howto, assume the following ficticious information:
ここでは架空の環境を設定する。
Domain example.com: (example.com ドメイン)
host1:
IP: 10.0.0.1
Purpose: primary DNS server
primary mail server
primary web server
host2:
IP: 10.0.0.2
Purpose: secondary DNS server
secondary mail server
host3:
IP: 10.0.0.3
Purpose: secondary DNS server
primary ftp server
network: 10.0.0/24
loopback: 127.0.0.1
BIND configuration files for host1 as primary DNS server: (プライマリ DNS サーバーとして host1 を設定する)
Configuration directory (設定ディレクトリ): /etc/namedb
Main configuration file (メイン設定ファイル): named.conf
example.com name-to-address zone (正引きゾーンファイル): db.example
example.com address-to-name zone (逆引きゾーンファイル): db.10.0.0
loopback zone (ループバック): db.127.0.0
root hint zone (ルートヒント): db.cache
/*
* Main configuration file
* /etc/namedb/named.conf
*/
/* Global options */
options {
/* BIND directory */
directory "/etc/namedb";
auth-nxdomain no;
};
/* Local network name-to-address zone file */
zone "example.com" in {
/* This zone is of type primary and will load the zone file
* from local disk.
*/
type master;
file "db.example";
};
/* Local network reverse map zone file */
zone "0.0.10.IN-ADDR.ARPA" in {
/* This zone is of type primary and will load the zone file
* from local disk.
*/
type master;
file "db.10.0.0";
};
/* Loopback reverse map zone file */
zone "0.0.127.IN-ADDR.ARPA" in {
/* This zone is of type primary and will load the zone file
* from local disk.
*/
type master;
file "db.127.0.0";
};
/* Use root servers for non-authoritative domains */
zone "." in {
/* Consult root servers for other domains. */
type hint;
file "db.cache";
};
/*
* example.com name-to-address zone
* /etc/namedb/db.example
*/
$TTL 86400
@ IN SOA host1.example.com. hostmaster.example.com. (
2001081101 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ; minimum negative cache TTL of 1 day
)
;
; Name servers
;
IN NS host1.example.com.
IN NS host2.example.com.
IN NS host3.example.com.
;
; Mail MX RRs
;
example.com. IN MX 0 host1.example.com.
IN MX 10 host2.example.com.
;
; Addresses for the canonical names
;
localhost IN A 127.0.0.1
host1 IN A 10.0.0.1
host2 IN A 10.0.0.2
host3 IN A 10.0.0.3
;
; Aliases
;
www IN CNAME host1.example.com.
mail IN CNAME host2.example.com.
ftp IN CNAME host3.example.com.
/*
* example.com address-to-name zone
* /etc/namedb/db.10.0.0
*/
$TTL 86400
@ IN SOA host1.example.com. hostmaster.example.com. (
2001081101 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ; minimum negative cache TTL of 1 day
)
;
; Name servers
;
IN NS host1.example.com.
IN NS host2.example.com.
IN NS host3.example.com.
;
; Addresses point to canonical name
;
1 IN PTR host1.example.com.
2 IN PTR host2.example.com.
3 IN PTR host3.example.com.
/*
* example.com loopback zone
* /etc/namedb/db.127.0.0
*/
$TTL 86400
@ IN SOA host1.example.com. hostmaster.example.com. (
2001081101 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ; minimum negative cache TTL of 1 day
)
;
; Name servers
;
IN NS host1.example.com.
IN NS host2.example.com.
IN NS host3.example.com.
1.0.0.127.IN-ADDR.ARPA. IN PTR localhost.
For root hint zone, either rename root.hint to db.cache or execute this command to download the latest copy.
ルートヒントゾーンのために root.hint を db.cache に名前変更するか、または以下のコマンドを実行して最新のコピーをダウンロードする。
# dig @a.root-servers.net. . ns > /etc/namedb/db.cache
BIND configuration files for host2 as secondary: (セカンダリとして host2 を設定する)
Configuration directory (設定ディレクトリ): /etc/namedb
Main configuration file (メイン設定ファイル): named.conf
example.com name-to-address zone (正引きゾーンファイル): secondary for host1
example.com address-to-name zone (逆引きゾーンファイル): secondary for host1
loopback zone (ループバック): db.127.0.0
root hint zone (ルートヒント): db.cache
/*
* BIND configuration file for host2
* /etc/namedb/named.conf
*/
/* Global options */
options {
/* BIND directory */
directory "/etc/namedb";
auth-nxdomain no;
};
/* Local network name to address zone file */
zone "example.com" in {
/* This zone is of type secondary and will download the zone file
* from host1.
*/
type slave;
file "db.example";
masters { 10.0.0.1; };
};
/* Local network reverse map zone file */
zone "0.0.10.IN-ADDR.ARPA" in {
/* This zone is of type secondary and will download the zone file
* from host1.
*/
type slave;
file "db.10.0.0";
masters { 10.0.0.1; };
};
/* Loopback reverse map zone file */
zone "0.0.127.IN-ADDR.ARPA" in {
/* This zone is of type primary and will load the zone file from
* local disk.
*/
type master;
file "db.127.0.0";
};
/* Use root servers for non-authoritative domains */
zone "." in {
/* Consult root servers for other domains. */
type hint;
file "db.cache";
};
/*
* example.com loopback zone
* /etc/namedb/db.127.0.0
*/
$TTL 86400
@ IN SOA host1.example.com. hostmaster.example.com. (
2001081101 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ; minimum negative cache TTL of 1 day
)
;
; Name servers
;
IN NS host1.example.com.
IN NS host2.example.com.
IN NS host3.example.com.
1.0.0.127.IN-ADDR.ARPA. IN PTR localhost.
For root hint zone, either rename root.hint to db.cache or execute this command to download the latest copy.
ルートヒントゾーンのために root.hint を db.cache に名前変更するか、または以下のコマンドを実行して最新のコピーをダウンロードする。
# dig @a.root-servers.net. . ns > /etc/namedb/db.cache
BIND configuration files for host3 as slave: (スレーブとして host3 を設定する)
Configuration directory (設定ディレクトリ): /etc/namedb
Main configuration file (メイン設定ファイル): named.conf
example.com name-to-address zone (正引きゾーンファイル): secondary for host1
example.com address-to-name zone (逆引きゾーンファイル): secondary for host1
loopback zone (ループバック): db.127.0.0
root hint zone (ルートヒント): db.cache
From this point on, host3 configuration files are identical to host2. Just repeat the steps for host2.
host3 の設定ファイルは host2 と同じなので host2 の手続きを繰り返す。
Starting BIND: (BIND を起動する)
Before starting BIND on host1, verify that named.conf and zone files are syntatically correct and valid.
host1 で BIND を起動する前に、named.conf とゾーンファイルの構文が正しいかチェックする。
# /usr/pkg/sbin/named-checkconf /etc/namedb/named.conf # /usr/pkg/sbin/named-checkzone example.com /etc/namedb/db.example
At this point, BIND is ready to start:
これで BIND の起動準備ができた。
# /etc/rc.d/named9 start Starting named. #
Check /var/log/messages for the last line for the word "running". e.g.: Aug 6 16:01:00 roseapple /usr/pkg/sbin/named[8203]: running
/var/log/messages に "running" という行があることを確認する。例: Aug 6 16:01:00 roseapple /usr/pkg/sbin/named[8203]: running
Looks like BIND is running on host1. Repeat this step for host2 and host3.
host1 で BIND が起動したら、host2 と host3 でも同様に作業する。
Once all three hosts are up and running, lets put them into use by editing /etc/resolv.conf and add:
3 つのホストで BIND が起動したら、それらのホストの /etc/resolv.conf に以下を追加する。
search example.com nameserver 10.0.0.1 nameserver 10.0.0.2 nameserver 10.0.0.3
Then ping host2, host3 and localhost from host1 to see if name-to-address is working. They should resolve to 10.0.0.2, 10.0.0.3 and 127.0.0.1. Try to ping www.yahoo.com to see if BIND is perusing root hint zone. Finally, to test reverse mapping, use ``host'' and give the IP address of host2, 3 and localhost and the output should look similar to this:
host1 から host2 と host3 と localhost へ向けて ping を打つ。正引き出来ていれば ping が通る。各々 10.0.0.2、10.0.0.3、127.0.0.1 として名前解決されるはずだ。BIND がちゃんとルートヒントゾーンを読んでるか確認するために www.yahoo.com へ ping する。最後に reverse mapping しているか確認するために host コマンドで host2、host3、localhost の IP アドレスが取得でき、以下のように印字されることを確認する。
# host 10.0.0.2 2.0.0.10.IN-ADDR.ARPA domain name pointer host2.example.com
Repeat this on host2 and host3. Both should behave the same as host1. If all goes well, time for a third expresso cup. It is definitely boring doing all these steps. There is a utility called h2n which will convert a working /etc/hosts into configuration files above. However, doing manually is tedious but sure makes your brain smarter.
以上の作業を host2 と host3 で繰り返す。host1 と同じ結果になるはずだ。全てうまくいったらティータイムにしよう。けっこうしんどい作業だからね。これまでの設定ファイルを /etc/hosts へ変換するための h2n というユーティリティがあるので、手作業に飽きたら使ってみるとよい。
Secure BIND (BIND をセキュアにする)
Now that everything is working, there are other considerations to make it more secure.
これで全て動作はしている。もっとセキュアにしてみよう。
Early versions of BIND did not have a good security record. However, BIND is still the best implementation around.
BIND の以前のバージョンはあまり security record ではなかった。{ ググったら「保障記録」と言われたけど何のことだ???? } しかし、もはや BIND は最良の実装になっている。
Obscure BIND version: (BIND のバージョンを隠ぺいする)
Firstly, people have no business in knowing what version of BIND is running. Secondly, according to the Project Honeynet, the two most popular scans from script kiddies on the internet today are BIND version and portmap (rpcbind). So this is another good reason to not give them the easy information they need.
第一に、仕事では BIND のバージョンを気にしているひとは居ない。第二に、ハニーネット { ref. ハニーポット - Wikipedia } によれば、スクリプトキディによる代表的なスキャン方式は 2 つあって、BIND のバージョンチェックと portmap (rpcbind) のチェックだ。よって、連中に余計な情報を与えないようにするには、別の情報を返してやればよい。
In /etc/namedb/named.conf, add a version statement and put whatever you want between double quote.
/etc/namedb/named.conf にバージョンの文を追加し、ダブルクォートでくくる。
options {
directory "/etc/namedb";
version "Expresso cup";
};
Now, use dig to query the version from a remote host and "Expresso cup" should appear instead of real BIND version.
リモートホストから dig を実行すると、本物の BIND バージョンの代わりに "Expresso cup" というバージョンが返ってくる。
# dig @host1.example.com txt chaos version.bind
Restrict zone transfer: (ゾーン転送を制限する)
Zone transfer is intended for secondary nameservers to retrieve any zones for backup purposes. For other nameservers, they should not be able to retrieve any zones and use whatever information to mount attacks. Lets restrict zone transfer to trusted secondary nameservers only.
ゾーン転送は、ゾーン検索のバックアップをセカンダリネームサーバーに任せることである。他のネームサーバーはゾーンを検索させないし、させたらフルボッコされる {mount attacks}。ゾーン転送を許可するのはセカンダリネームサーバーのみだ。
In host1, edit /etc/namedb/db.example:
host1 の /etc/namedb/db.example を編集する。
zone "example.com" in {
type master;
file "db.example";
/* Only host2 and host3 can transfer this zone */
allow-transfer { 10.0.0.2; 10.0.0.3; };
};
In host1, edit /etc/namedb/db.10.0.0:
host1 の /etc/namedb/db.10.0.0 を編集する。
zone "0.0.10.IN-ADDR.ARPA" in {
type master;
file "db.example";
/* Only host2 and host3 can transfer this zone */
allow-transfer { 10.0.0.2; 10.0.0.3; };
};
Restrict zone transfer on any secondary too as attackers will try to zone transfer all authoritative dns servers.
攻撃者への対策としてゾーン転送をセカンダリに制限することにより、権威サーバーへゾーン転送を試みるようになる。
Restrict query: (問合せを制限する)
{ query はクエリ、検索、問合せなどと訳されるようだ。ここでは ipa に倣って「問合せ」にする。むしろ誤訳 満載のこんな怪しい文章よりも 4.2 サーバーサービスのセキュア化 - 4.2.2 BINDのインストールと設定 を読むこと }
Query is similar to mail open relay concept. Only trusted mail clients can relay mails through the mail server. With DNS, only trusted clients can query the server.
問合せは、電子メールのオープンリレーと同じ考えだ。信頼されたクライアントからの電子メールだけをメールサーバーへリレーする。DNS では、信頼されたクライアントからの問合せのみを扱うようにする。
/* Define my network */
acl "example.com-net" {
10.0.0.0/24;
};
In host1, edit /etc/namedb/db.example:
host1 の /etc/namedb/db.example を編集する。
zone "example.com" in {
type master;
file "db.example";
allow-transfer { 10.0.0.2; 10.0.0.3; };
allow-query { example.com-net; };
};
In host1, edit /etc/namedb/db.10.0.0:
host1 の /etc/namedb/db.10.0.0 を編集する。
zone "0.0.10.IN-ADDR.ARPA" in {
type master;
file "db.example";
allow-transfer { 10.0.0.2; 10.0.0.3; };
allow-query { example.com-net; };
};
Restrict recursive query: (再帰問合せを制限する)
Recursive query is a query send to the nameserver for the information which the local nameserver is not authoritative and must ask other nameservers for the answer. The answer is then feed back to the client and the nameserver will cache the information for future requests. Trusted DNS clients use this feature by listing nameservers in /etc/resolv.conf. Even if untrusted clients putting our nameservers in their /etc/resolv.conf and our nameservers to do the work for free, prevent this from happen with allow-recursion below.
再帰問合せは、ローカルネームサーバーから送信された問合せを、さらにネームサーバーへ送信する。権威サーバーではないが、あらゆるネームサーバーからの問い合わせに回答しなければならない{ 誤訳に注意 }。 回答はクライアントへ返され、ネームサーバーは次回の問合せのために情報をキャッシュする。信頼されたクライアントは /etc/resolv.conf に書かれたネームサーバーには使える。しかし、信頼されていないクライアントが /etc/resolv.conf に我々のネームサーバーを書き、ネームサーバーが問合せに無制限に回答させたいのであれば、以下のように書けばよい。{ なんかおかしいな }
Restrict recursive query to only trusted DNS clients:
信頼されたクライアントにのみ再帰問合せを制限する
/* Define my network */
acl "example.com-net" {
10.0.0.0/24;
};
options {
directory "/etc/namedb";
version "Expresso cup";
allow-recursion { "example.com-net"; };
};
Run BIND as non-root user inside chroot jail under NetBSD 1.5.1: ( NetBSD 1.5.1 で jail に chroot して 非 root ユーザーに BIND を実行させる)
Add named account to passwd using vipw:
vipw で named アカウントを追加する。
named:*:14:14::0:0:Named pseudo-user:/var/named:/sbin/nologin
Add named group to /etc/group:
/etc/group に named グループを追加する。
named:*:14:
Populate the chroot compartment:
たいていの chroot は以下のようになる。
# mkdir -p /var/chroot/named # cd /var/chroot/named # mkdir -p dev etc/namedb/cache usr/libexec var/run var/tmp # chmod 775 etc/namedb/cache # chown -R named:named etc/namedb/cache # chmod 775 var/run # chmod 01775 var/tmp # chgrp named var/run var/tmp # mknod dev/null c 2 2 # mknod dev/random c 46 0 # chmod 666 dev/null dev/random # chgrp named /etc/rndc.conf /etc/rndc.key # chmod 640 /etc/rndc.conf /etc/rndc.key # cp -p /etc/rndc.key /var/chroot/named/etc
Edit BIND startup configuration file so that it will run in chroot compartment with a non-priviledged user:
BIND のスタートアップ設定ファイルを編集し、chroot 環境で非特権ユーザーで走らせる。
Modify /etc/rc.conf.d/named9 and add -u named -t /var/chroot/named to named_flags:
/etc/rc.conf.d/named9 の named_flags に -u named -t /var/chroot/named を追加する。
named9=YES named_flags="-c /etc/namedb/named.conf -u named -t /var/chroot/named"
Edit BIND script to point from old location of pid-file to new one:
BIND スクリプトで新しい PID ファイルを参照するようにする。
# vi /etc/rc.d/named9
and change:
これを
pidfile="/var/run/${name}.pid"
to:
こうする
pidfile="/var/chroot/named/var/run/${name}.pid"
Copy BIND configuration files to chroot compartment and set proper permission:
BIND の設定ファイルをパーミッションを保持したまま chroot 環境へコピーする。
# cp -p /etc/namedb/* /var/chroot/named/etc/namedb
Restart BIND to pick up new changes:
BIND を再起動する。
# /etc/rc.d/named9 restart
Run BIND as non-root user inside chroot jail under NetBSD 1.5 current: ( NetBSD 1.5 current で jail に chroot して 非 root ユーザーに BIND を実行させる)
On 1.5X current, the chroot jail compartment is already populated and ready to use. All is needed is to copy the configuration files in /etc/namedb to /var/chroot/named/etc/namedb.
1.5X current では chroot jail 環境はすでに使えるようになっている。/etc/namedb にある設定ファイルを /var/chroot/named/etc/namedb へコピーすればよい。
# cp -p /etc/namedb/* /var/chroot/named/etc/namedb
Edit BIND startup config file so that it will run in chroot compartment with a non-priviledged user:
BIND のスタートアップ設定ファイルを編集し、chroot 環境で非特権ユーザーで走らせる。
Modify /etc/rc.conf.d/named9 and add -t /var/chroot/named and -u named to named_flags:
/etc/rc.conf.d/named9 の named_flags に -t /var/chroot/named と -u named を追加する。
named9=YES named_flags="-c /etc/namedb/named.conf -t /var/chroot/named -u named"
Starting with BIND 9.2.0, it requires /dev/random in chroot, so populate it:
BIND 9.2.0 で chroot するには /dev/random が必要なので以下のようにする。
# mknod /var/chroot/named/dev/random c 46 0
If the nameserver is a slave for any other domains, BIND needs to have write access to that directory. /var/chroot/named/etc/namedb/cache is where BIND will download other domain zones. Modify named.conf accordingly for the backup zones and make sure the file'' statement is referring to cache'' directory. e.g.:
ネームサーバーが他のドメインのスレーブになっている場合、BIND にはディレクトリへの書き込み権限が必要になる。BIND は /var/chroot/named/etc/namedb/cache に他ドメインのゾーンをダウンロードする。named.conf を編集し、ゾーンをバックアップするために file 文で cache ディレクトリを参照するようにする。
/* example.com zone name-to-address */
zone "example.com" in {
type slave;
file "cache/db.example";
masters { 10.0.0.1; };
allow-transfer { none; };
};
Running rndc to manage BIND in chroot environment requires proper permission.
chroot 環境で要求される権限で BIND を動作させるために rndc を走らせる。
Allow group BIND to use rndc in chroot:
chroot で BIND グループに rndc を許可する。
# chgrp named /etc/rndc.conf /etc/rndc.key
Only root and group BIND should know the secret key:
root と BIND グループにのみ秘密鍵を許可する。
# chmod 640 /etc/rndc.conf /etc/rndc.key
Finally, BIND needs to know the secret key when loading:
最後に、BIND が秘密鍵をロードできるようにする。
# cp -p /etc/rndc.key /var/chroot/named/etc
Start BIND in chroot:
chroot で BIND を起動する。
# /etc/rc.d/named9 start
Different DNS servers (他の DNS サーバー)
There are different type of DNS servers each serving a purpose. We have discussed and configured primary/master, secondary/slave. Others are cache only server, forwarding server and stealth server. Lets look at each one of them.
サービスの目的ごとに異なるタイプの DNS サーバーがある。プライマリ/マスターやセカンダリ/スレーブを設定できる。他のサーバーというのは、キャッシュサーバー、転送サーバ、ステルスサーバーだ。各々について見ていく。
Cache only name server: (キャッシュサーバー)
Cache only name server basically caches information that it receives and uses it until the data expires. A cache only server is not authoritative for any zone.
キャッシュサーバーは、基本的には受信した情報をキャッシュし、データの有効期間中は保持する。キャッシュサーバーはゾーンにたいして認証しない。
Here is an example configuration of a cache only server:
キャッシュサーバーの設定の例
/*
* file: /etc/namedb/named.conf
* purpose: cache only name server
*/
acl "example.com.internal" {
192.168.1.0/24;
};
options {
directory "/etc/namedb";
allow-query { "example.com.internal"; };
};
zone "0.0.127.IN-ADDR.ARPA" in {
type master;
file "db.127.0.0";
};
zone "." in {
type hint;
file "db.cache";
};
Stealth server: (ステルスサーバー)
From BIND9 ARM:
BIND9 の ARM { the Administrator's Reference Manual. 管理者向けリファレンスマニュアル } より
A stealth server is a server that answers authoritatively for a zone, but is not listed in that zone.s NS records. Stealth servers can be used as a way to centralize distribution of a zone, without having to edit the zone on a remote nameserver. Where the master file for a zone resides on a stealth server in this way, it is often referred to as a hidden primary'' configuration. Stealth servers can also be a way to keep a local copy of a zone for rapid access to the zone.s records, even if all official'' nameservers for the zone are inaccessible.
ステルスサーバーはゾーンの権威サーバーであるが、 NS レコードには書かない。ステルスサーバーはリモートのネームサーバーのゾーンファイルを編集しなくても、ゾーンの centralize distribution { ?????? } として利用できる。ここではステルスサーバーを「隠しプライマリ」として設定させるために、ステルスサーバーに master ファイルを設置する。正式なネームサーバーにアクセスできない場合は、ステルスサーバーはゾーンレコードに素早くアクセスするためにコピーを保持することも出来る。
Remote name daemon controller: rndc (リモートネームデーモン制御: rndc)
BIND comes with rndc and is a tool to manage a running BIND. To use rndc, an /etc/rndc.conf is required. rndc uses an authenticated link to communicate with the name server. This will reduce the chance of message spoofing the link.
BIND には制御ツール rndc が付属している。rndc を利用するためには /etc/rndc.conf が必要だ。rndc はネームサーバーと通信するために認証を使う。これによりメッセージなりすましをされる危険性を減らす。
Get rndc to work: (rndc を動作させる)
First, generate a shared secret key. The key will be used by rndc and named to authenticate each other.
最初に共有秘密鍵を作成する。rndc と named が認証のために使う。
# dnssec-keygen -a hmac-md5 -b 512 -n HOST int-example
will generate:
このようになる。
Kint-example.+157+23209.key Kint-example.+157+23209.private
the shared secret key is in either file.
共有秘密鍵は以下のようなファイルになる。
# cat Kint-example.+157+23209.key int-example. IN KEY 512 3 157 xCWxMply6q0NFFTIpL4Qf9qpFtg/DSADFSsdsdfgC9jq11QabdM+QHPaaOJG 9yzlnYp U0SWtSY10LXds6twdraoRsOA==
The last long string is the shared secret key, copy and and paste in the secret statement of /etc/rndc.conf. In /etc/rndc.conf, only options and key statements are required.
最後の長文は共有秘密鍵であり、/etc/rndc.conf の secret 文にコピーペーストする。/etc/rndc.conf には options 文と key 文のみが必要である。
/*
* /etc/rndc.conf for example.com
*/
// Key int-example.
key "int-example." {
algorithm "hmac-md5";
secret"vCWxMply6q0NFFTIpL4Qf9qpFtg/Du67g3IgC9jq11QabdM+QHPddOJG 9yzlnYpU
0SWtSY9LXds6twdraoRsOA==";
};
// Default server is localhost and key name is int-example.
options {
default-server localhost;
default-key "int-example.";
};
server localhost {
key "int-example."
};
In /etc/namedb/named.conf, declare the key and controls statement as below to enable the communicating channel.
/etc/namedb/named.conf では、通信チャネルを有効にするために key 文と controls 文を定義する。
// Use shared secret key for TSIG and rndc
key "int-example." {
algorithm hmac-md5;
secret"vCWxMply6q0NFFTIpL4Qf9qpFtg/Du67g3IgC9jq11QabdM+QHPddOJG 9yzlnYpU
0SWtSY9LXds6twdraoRsOA==";
};
// Allow rndc to connect to 127.0.0.1 on port 953
controls {
inet 127.0.0.1 allow { localhost; } keys { "int-example." ;};
};
To test rndc, try reload /etc/namedb/named.conf file with:
rndc をテストする。/etc/namedb/named.conf ファイルをリロードする。
# rndc reload rndc: reload command successful #
View /var/log/messages to see if BIND is reloaded successfully.
/var/log/messages を見ると BIND がリロードに成功したことが分かる。
To view statistics: (統計を眺める)
# rndc stats rndc: stats command successful #
A file /etc/namedb/named.stats is generated for viewing.
/etc/namedb/named.stats ファイルが生成されたことが確認できる。
TSIG: (TSIG)
TSIG stands for transaction signatures and is for server-to-server communication. Useful for dynamic update and zone transfer.
TSIG はサーバーとサーバー間通信におけるトランザクション署名である。動的アップデートとゾーン転送に利用する。
First create a shared secret key for use during zone transfer between master and slave:
最初にマスターとスレーブ間でゾーン転送するときの共有秘密鍵を作成する。
# dnssec-keygen -a hmac-md5 -b 512 -n HOST example-exslave.
Declare the key in /etc/namedb/named.conf:
/etc/namedb/named.conf で key を定義する。
// Use shared secret key for TSIG and rndc
key "muine-secondary." {
algorithm hmac-md5;
secret"4BQV4cc6JbE5wlMlVr/+HdO2G7qzBZOSxsrpyR5QjSMXqPm37ZIHZc8x LcsIG6XE
MLnzGK+H3NC7I4Xeoc70Jw==";
};
For the the zone you want to permit slave to transfer add:
スレーブに転送を許可するならば transfer にスレーブを追加する。
// All zone transfers to those signed with the example-other key
allow-transfer { key example-other. ;};
At this point, if the local name server receives a message signed with this key, it can verify the signature. If the signature succeeds, the response is signed by the same key.
ここで、ローカルのネームサーバーがこの鍵で署名されたメッセージを受信すると、署名を検査する。署名が正しければ、応答は同じ鍵で署名される。
When using shared secret, /etc/namedb/named.conf should not set to world-readable. Transfering key from one server to another using ssh is better than telnet. TSIG requires that the clocks be no more than 5 minutes apart between master-slave because it will timestamp TSIG record to prevent replay attacks. Make sure your clock is synchronize properly.
共有鍵を使う場合、/etc/namedb/named.conf は誰でも読めるようにしないほうがよい。サーバーから別のサーバー鍵を転送する場合は telnet するよりも ssh するほうがよい。TSIG は、マスターとスレーブの間の時差が 5 分未満であることを要求する。TSIG は、リプレイアタックを防ぐためにタイムスタンプを記録するのである。クロックは同期させておこう。
Tell local name server to sign all requests with key if it's the one who initiates the transaction.
ローカルネームサーバーがトランザクションを開始するときに全てのリクエストに鍵で署名する。
// Sign all requests with key example-other when communicating with 10.10.0.0
server 10.10.0.0 {
keys { example-other. ;};
};
Run DNS for your own domain (独自ドメインで DNS を走らせる)
If you're one of those people with a static IP address and a registered domain name, you might want to consider running your own DNS instead of relying on somebody else.
あなたが固定 IP アドレスを持っていて、ドメイン名をレジストラに登録しているならば、自分で DNS を運用してみるとよい。
First, update example.com DNS information at the domain registry where it was registered so that your new DNS will become the authoritative nameserver. Second, arrange with a friend to act as secondary DNS. Alternatively, use free 3rd party like Secondary.com or The Public DNS Service. Read DJB's Third-party DNS service page for some caveats.
最初に、自分の DNS で権威サーバーを持つために、レジストラに登録してある example.com の DNS 情報を更新する。次に、友人にセカンダリ DNS を依頼する。または Secondary.com のようにフリーのサードパーティを使うか、The Public DNS Service を使う。DJB のサードパーティ DNS サービスについての注意ページ { Costs and benefits of third-party DNS service }を読んでおくこと。
The idea is to ask the domain registry to ``delegate'' example.com domain requests to your own DNS server and find a backup for the domain just in case your DNS is unreachable.
これは、example.com ドメインの問合せをレジストラから自分の DNS に委譲し、自分の DNS が不達になったときのためにバックアップさせる、ということをやっている。
Here are what the domain registry required to update their DNS for proper delegation. Note that the information below are ficticious:
レジストラから委譲してもらうために DNS 情報を更新してもらう。たとえばこう。
domain to delegate: example.com
primary dns server for example.com: ns.example.com
ns.example.com IP address: 10.0.0.1
secondary dns server for example.com: ns.other.com
ns.other.com IP address: 172.16.0.1
Here is how it is going to look like in the parent/name registry DNS zone: (親ネームサーバーから DNS ゾーンを委譲してもらうとこうなる)
; ; Delegate example.com to ns.example.com DNS ; Name CLASS TTL TYPE RR Data example.com 86400 IN NS ns.example.com 86400 IN NS ns.other.com ns.example.com 86400 IN A 10.0.0.1 ns.other.com 86400 IN A 10.0.0.2
The last 2 lines are called glue records. Glue record is an A record where the name appears on the right hand side of an NS record.
最後の 2 行はグルーレコードと呼ばれる。グルーレコードは、NS レコードの右側と同じ値を A レコードに記述する。
Setup example.com zone to answer requests from the internet: (example.com ゾーンをインターネットからの問合せに回答するようにする)
/* Global options */
options {
directory "/etc/namedb";
auth-nxdomain no;
recursion no;
};
/* Control logging behaviour */
logging {
category lame-servers { null; };
};
/* example.com zone name-to-address */
zone "example.com" in {
type master;
file "db.example";
allow-transfer { 172.16.0.1; };
};
/* example.com zone address-to-name */
zone "0.0.10.IN-ADDR.ARPA" in {
type master;
file "db.10.0.0";
allow-transfer { 172.16.0.1; };
};
/* loopback zone address-to-name */
zone "0.0.127.IN-ADDR.ARPA" in {
type master;
file "db.127.0.0";
};
/* root hint zone */
zone "." in {
type hint;
file "db.cache";
};
/* example.com zone name-to-address */
;
; Default Time To Live for records with undefined TTLs
;
$TTL 86400
@ IN SOA ns.example.com. hostmaster.example.com. (
2001092401 ; serial
43200 ; refresh after 12 hours
3600 ; retry after 1 hour
1209600 ; expire after 2 weeks
86400 ; minimum negative cache TTL of 1 day
)
;
; Nameservers
;
IN NS ns.example.com.
IN NS ns.other.com.
;
; Mail servers
;
example.com. IN MX 0 ns.example.com.
IN MX 10 ns.other.com.
;
; example.com
;
IN A 10.0.0.1
;
; ns.example.com
;
ns IN A 10.0.0.1
;
; Aliases:
; www.example.com
; ftp.example.com
;
www IN CNAME ns.example.com.
ftp IN CNAME ns.example.com.
/* example.com zone address-to-name */
;
; Default Time To Live for the zone
;
$TTL 86400
@ IN SOA ns.example.com. hostmaster.example.com. (
2001092401 ; serial
43200 ; refresh after 12 hours
3600 ; retry after 1 hour
1209600 ; expire after 2 weeks
86400 ; minimum negative cache TTL of 1 day
)
;
; Nameservers
;
IN NS ns.example.com.
IN NS ns.other.com.
;
; Reverse mapping for ns
;
1 IN PTR ns.example.com.
And the usual loopback zone address-to-name...
あとループバックゾーンの逆引きを追加したり
And the usual root hint zone...
ルートヒントゾーンを追加したり
Setup other.com zone to backup for example.com: (example.com のバックアップとして other.com を設定する)
other.com will be able to transfer db.example and db.10.0.0 from example.com primary dns server. For other.com db.other and db.172.16.0 should have similar entries as example.com's db.example and db.10.0.0 zone files.
other.com は example.com のプライマリ DNS サーバーから db.example と db.10.0.0 を転送してもらう。other.com の db.other と db.172.16.0 は example.com の db.example と db.10.0.0 ゾーンファイルと同じようにする。
/* Global options */
options {
directory "/etc/namedb";
auth-nxdomain no;
recursion no;
};
/* Control logging behaviour */
logging {
category lame-servers { null; };
};
/* example.com zone name-to-address */
zone "example.com" in {
type slave;
file "db.example";
masters { 10.0.0.1; };
allow-transfer { none; };
};
/* example.com zone address-to-name */
zone "0.0.10.IN-ADDR.ARPA" in {
type master;
file "db.10.0.0";
masters { 10.0.0.1; };
allow-transfer { none; };
};
/* other.com zone address-to-name */
zone "0.16.172.IN-ADDR.ARPA" in {
type master;
file "db.172.16.0";
allow-transfer { none; };
};
/* loopback zone address-to-name */
zone "0.0.127.IN-ADDR.ARPA" in {
type master;
file "db.127.0.0";
};
/* root hint zone */
zone "." in {
type hint;
file "db.cache";
};
Familiarize with DNS tools (NS ツールに慣れる)
DNS debugging tools (DNS デバッグツール): host,dig,nslookup,dnswalk,doc
To find out mail exchange for example.com:
example.com の mail exchange を探す
# host -t mx example.com
To find out name server for example.com:
example.com のネームサーバーを探す
# host -t ns example.com
To manually transfer zone example.com:
example.com へ手動でゾーン転送する
# dig @ns.example.com AXFR example.com
Use dnswalk to test example.com:
dnswalk で example.com のテスト
# dnswalk -d example.com.
Use doc to verify that example.com is configured and functioning correctly:
example.com の設定と機能を検証するために doc を使う。
# doc example.com
doc will produce log.example.com. file with all the information needed to verify the correctness of example.com
doc は example.com の検証結果を log.example.com ファイルに保存する。
To find out the authors of BIND:
BIND の著者を探す。
% dig @ns.example.com authors.bind chaos txt
Load balance (round robin): (ロードバランス (ラウンドロビン))
BIND supports load balancing between 2 or more IP addresses. Ping postoffice will
BIND は 2 つ以上の IP アドレスのロードバランスに対応している。postoffice に ping してみる。
; Name TTL CLASS TYPE RR Data
postoffice 300 IN A 10.0.0.2
300 IN A 10.0.0.3
$ ping postoffice PING postoffice.example.com (10.0.0.2): 56 data bytes ... 1 packets transmitted, 1 packets received, 0.0% packet loss $ ping postoffice PING postoffice.example.com (10.0.0.3): 56 data bytes ... 1 packets transmitted, 1 packets received, 0.0% packet loss
The order will be: 10.0.0.2,10.0.0.3 and 10.0.0.3,10.0.0.2 and back to 10.0.0.2,10.0.0.3 and so on.
10.0.0.2、10.0.0.3 という順番が 10.0.0.3、10.0.0.2 になり、10.0.0.2、10.0.0.3 に戻っている。
Reference (参考)
BIND home: http://www.isc.org/products/BIND/
DNS rfc: http://www.example.com/rfc/rfc1035.txt/
DNS and BIND bible: http://www.ora.com/catalog/dns4/
comp.protocols.tcp-ip.domains Frequently Asked Questions http://www.intac.com/~cdp/cptd-faq/
Name Server Operations Guide for BIND http://www.irbs.com/bog-4.9.5/
Read BIND Administrator Reference Manual: http://www.nominum.com/resources/documentation/Bv9ARM.pdf
Mr. DNS questions archive: http://www.acmebw.com/askmrdns/ http://www.menandmice.com/9000/9300_DNS_Corner.html
DNS Resources Directory: http://www.dns.net/dnsrd/
DNS implementation by qmail author: http://cr.yp.to/djbdns.html
Operational guidelines for Root Name Servers. http://www.muine.org/rfc2870.txt
Common DNS Operational and Configuration Errors http://www.muine.org/rfc/rfc1912.txt
Selection and Operation of Secondary DNS Servers http://www.muine.org/rfc/rfc2182.txt
Tools for DNS debugging http://www.muine.org/rfc/rfc1713.txt ftp://ftp.uu.net/.vol/1/ip/dns/
Securing an internet name server http://www.nsiregistry.com/dns/securing_an_internet_name_server.pdf
Running BIND9 in a chroot cage using NetBSD's new startup system http://www.daemonnews.org/200110/named-chroot.html
last update: July 27, 2003
