DNS HOWTO
Nicolai Langfeldt janl@linpro.no
Version 2.2.1, 18 July 1999
中野武雄 nakano@apm.seikei.ac.jp
v2.2.1j3, 12 August 1999
短い時間で DNS 管理者になる方法。
______________________________________________________________________
目次
1. 前書き
1.1 法的なこと
1.2 謝辞とヘルプ募集
1.3 献辞
2. はじめに
3. キャッシュ専用のネームサーバ
3.1 named を起動する
3.2 改善するには
3.3 おめでとう
4. 単純なドメイン
4.1 でもまず最初に退屈な理論
4.2 自分のドメインを作る
4.3 逆引きゾーン
4.4 気をつけること
4.5 なぜ逆引きが動作しないのか
4.5.1 逆引きゾーンが代理されない
4.5.2 クラスレス (classless) のサブネットをもらった場合
5. 実際のドメインの例
5.1 /etc/named.conf (または /var/named/named.conf)
5.2 /var/named/root.hints
5.3 /var/named/zone/127.0.0
5.4 /var/named/zone/land-5.com
5.5 /var/named/zone/206.6.177
6. メンテナンス
7. バージョン 4 からバージョン 8 に更新する
8. Q & A
9. より熟練した DNS 管理者になるために
______________________________________________________________________
1. 前書き
Keywords: DNS, bind, bind-4, bind-8, named, dialup, ppp, slip, isdn,
Internet, domain, name, hosts, resolving, caching.
この文書は Linux Documentation Project の一部です。 (訳注: 翻訳版は
Japanese FAQ Project の一部です)
1.1. 法的なこと
(C)opyright 1995-1999 Nicolai Langfeldt. Do not modify without
amending copyright, distribute freely but retain copyright message.
この文書の著作権は (C)opyright 1995-1999 Nicolai Langfeldt にありま
す。この文書を修正する場合は著作権表示にもその旨明記して下さい。著作宣
言を変更しなければ自由に再配布することができます。
訳注：翻訳は中野武雄が行いました。(C)opyright 1998-1999 Takeo Nakano
1.2. 謝辞とヘルプ募集
本文書のドラフト版を苦労して読んでいただき、たくさんの有益な提案をして
くださった Arnt Gulbrandsen に感謝します。また電子メールで提案や情報を
送ってくれたたくさんの方々にも感謝します。
この文書はまだ完成したものではありません。この文書をより良い物にするた
めに、問題点や成功例などについて筆者にメールを送って下さい。コメント・
質問、現金などは janl@math.uio.no まで。メールを送り、返信を希望する場
合には、返信先のアドレスが正しいか、またちゃんと機能しているかどうかを
確認して下さるようにお願いします。またメールする前には必ず ``Q & A''
のセクションを読んでください。なお、私が読めるのはノルウェー語と英語に
限られます。
この HOWTO 文書を翻訳する場合は私に知らせて下さい。どの言語に私の名前
が載ったかを知りたいですし、またこの HOWTO 文書の更新をお知らせできま
すから。
訳注: この文書の v1.0 は、横田邦彦さんと藤原輝嘉さんとが翻訳されまし
た。中野が v2.1.1 にあわせて更新し、以降の管理を行っています。更新の際
には、ご意見をいただいた藤原さん・遠藤さん・花高さん・水原さん、校正を
してくださった長谷川さん・武井さんをはじめ、 JF-ML の皆さんにお世話に
なりました。
翻訳に関するコメントは nakano@apm.seikei.ac.jp までお願いします。 DNS
に関する日本語での質問先としては linux-users メーリングリスト
や
fj.os.linux.networking, fj.net.ip.dns などが適当でしょう。
1.3. 献辞
この HOWTO 文書を Anne Line Norheim Langfeldt に捧げる。といっても彼女
がこの文書を読むことは無いだろうけど。そういった類の女の子じゃないから
なあ。
2. はじめに
この文書は何であって何ではないか。
DNS とは Domain Name System のことです。DNS はネットワークに存在するす
べてのマシンの名前を IP 番号に変換します。 DNS は名前からアドレスへの
マップ、アドレスから名前へのマップなどを行います。この HOWTO 文書で
は、 Linux システムを用いてこのようなマッピングを定義する方法について
記述します。ここでの「マッピング」とは、単に二つのものを結びつけること
です。この場合なら ftp.linux.org といったようなマシンの名前と、そのマ
シンの IP 番号 (IP アドレス) である 199.249.150.4 のような値を結びつけ
ることになります。
初心者 (あなた ;-) にとって DNS は、ネットワーク管理のなかでもわかりに
くい部分の一つです。この HOWTO では、いくつかの事柄を多少なりともわか
るようにしたいと思っています。簡単な DNS ネームサーバを設定する方法も
説明します。まずキャッシュ専用のサーバからはじめて、あるドメインに対す
るプライマリ DNS サーバを設定していきます。もっと複雑な設定を行なう場
合には、この文書の ``Q & A'' の章を参照してください。そこにも書いてい
なかったら、もっとちゃんとした文献を読む必要があるでしょう。「ちゃんと
した文献」については、 ``より熟練した管理者になるために'' の章で説明し
ます。
DNS についての作業を始める前に、あなたのマシンを設定して、 telnet での
出入りやネットへの各種接続ができるようにしておいてください。特に
telnet 127.0.0.1 で、現在のマシン自身にログインできるようにしてくださ
い (今すぐテスト!)。また /etc/nsswitch.conf (あるいは
/etc/host.conf)、 /etc/resolv.conf、 /etc/hosts などのファイルに対し
て、正しい設定をしておいてください。これらの機能についてはこの文書では
説明しません。以上の一揃いが準備できていない場合は、 NET-3-HOWTO や
PPP-HOWTO を読んで、ちゃんと設定しておいてください。
この文書で「あなたのマシン」と書いてあった場合、それは DNS を動作させ
ようとしているマシンを指すものとします。他にもネットワークにつながって
いるあなたのマシンはあるでしょうけど、それのことではありません。
あなたのマシンが所属しているネットワークには、名前引きをブロックするよ
うな防火壁 (ファイアウォール) は存在しないものとします。ファイアウォー
ル内部にいる場合には特別な設定が必要になります。 ``Q & A'' の章を見て
ください。
UNIX システムでの名前引きのサービスは named と呼ばれるプログラムによっ
て実現されます。これは Internet Software Consortium の Paul Vixie 氏が
管理している ``bind'' パッケージに含まれるプログラムです。 named はほ
とんどの Linux のパッケージにも含まれていて、 /usr/sbin/named としてイ
ンストールされています。もし named がすでにあれば、それを使えばいいで
しょう。もし無い場合には Linux の ftp サイトからバイナリを入手するか、
最新のソースを から入手し
ましょう。この HOWTO では bind の version 8 を対象にしています。 bind
4 を対象にした古いバージョンの HOWTO は
にありますので、 bind 4 を使ってい
る人はこちらを参照してください。 named の man ページ (最後の方にある
FILES セクション) に named.conf に関する記述があれば、あなたの使ってい
るのは bind 8 です。逆に named.boot に関する記述があれば bind 4 です。
セキュリティに気を使わなければならない人は、 bind 4 を使っているなら
bind 8 にアップグレードするべきでしょう。
DNS はネットワーク全体に広がるデータベースです。データの登録は慎重に行
ないましょう。変な内容を登録すると、あなたも他の人達も迷惑します。真面
目にちゃんと運用すれば、 DNS は恩恵をもたらしてくれるはずです。 DNS の
使い方、管理の仕方、デバッグのやりかたを学び、良い管理者になってくださ
い。設定ミスでネットワークを落としたりすることがないようにしましょう
ね。
この文書には、ちょっとだけごまかしているところが何か所かあります (でも
それらの部分も、うそをついているわけじゃありません)。これは話をわかり
やすくするためです。書いてあることを信じてくれれば、とりあえずうまく行
くはずです。多分ね ;-)
ヒント:私が変更するように指示したファイルがすでに存在していたら、これ
らのバックアップを取っておきましょう。作業の結果がうまくいかなかった場
合に、元の動いている状態に戻すことができるようにするためです。
3. キャッシュ専用のネームサーバ
DNS 設定の最初の一歩。ダイアルアップのユーザにはとっても便利です。
キャッシュ専用のネームサーバとは、名前引きの結果を記憶 (キャッシュ) し
ておき、次回の問い合わせの時にその記憶を使って答えるものです。次回から
の問い合わせに対する応答は (特に遅い回線を使っている場合には) 非常に速
くなります。
まず最初に /etc/named.conf というファイルが必要です。 named は起動する
とまずこのファイルを読み込みます。現在のところは、以下のような簡単なも
のでよいでしょう。
______________________________________________________________________
// Config file for caching only name server
options {
directory "/var/named";
// Uncommenting this might help if you have to go through a
// firewall and things are not working out:
// query-source port 53;
};
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};
______________________________________________________________________
directory の行は、 named が参照するファイルの置き場所を指定するもので
す。これ以降の全てのファイル名はここからの相対パスとなります。すなわち
ディレクトリ pz は /var/named 以下にあり、フルパスで表記すれば
/var/named/pz ということになります。 /var/named は Linux Filesystem
Standard に準拠した正しいディレクトリ名です。
/var/named/root.hints というファイルの名前はここで付けられています。
/var/named/root.hints ファイルの内容は以下のようにしておきます。 (この
文書の電子版からこのファイルをカットアンドペーストする場合は、実際の
ファイルでは先頭にスペースが入ってはいけないことに注意してください。言
い換えると、全ての行が空白以外の文字ではじまっていなければいけません。
文書処理ソフトによっては、行の最初にスペースを入れてしまうことがあるの
で、ちょっと困ることがあります。その場合は先頭のスペースを取り除いて
使ってください)
______________________________________________________________________
;
; There might be opening comments here if you already have this file.
; If not don't worry.
;
. 6D IN NS G.ROOT-SERVERS.NET.
. 6D IN NS J.ROOT-SERVERS.NET.
. 6D IN NS K.ROOT-SERVERS.NET.
. 6D IN NS L.ROOT-SERVERS.NET.
. 6D IN NS M.ROOT-SERVERS.NET.
. 6D IN NS A.ROOT-SERVERS.NET.
. 6D IN NS H.ROOT-SERVERS.NET.
. 6D IN NS B.ROOT-SERVERS.NET.
. 6D IN NS C.ROOT-SERVERS.NET.
. 6D IN NS D.ROOT-SERVERS.NET.
. 6D IN NS E.ROOT-SERVERS.NET.
. 6D IN NS I.ROOT-SERVERS.NET.
. 6D IN NS F.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4
J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10
K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129
L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12
M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33
A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4
H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53
B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107
C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12
D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90
E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10
I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17
F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241
______________________________________________________________________
このファイルには世界中のルートネームサーバを記述します。これは時間とと
もに変化していくので、それに対応して更新させる必要があります。更新方法
は ``メンテナンス'' の章を見てください。
named.conf の次のセクションは最後の zone です。この利用法については後
の章で述べるつもりですので、今のところは以下のような内容のファイルを
pz サブディレクトリに 127.0.0 という名前で作っておいてください。 (ここ
でもカットアンドペーストするときには先頭のスペースを取り除くようにして
ください)
______________________________________________________________________
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
1 ; Serial
8H ; Refresh
2H ; Retry
1W ; Expire
1D) ; Minimum TTL
NS ns.linux.bogus.
1 PTR localhost.
______________________________________________________________________
次に、以下のような内容の /etc/resolv.confが必要です。
______________________________________________________________________
search subdomain.your-domain.edu your-domain.edu
nameserver 127.0.0.1
______________________________________________________________________
`search' で始まっている行は、問い合わせされたホストを探すドメインを指
定します。`nameserver'で始まる行は、ネームサーバのアドレスを指定するも
のです。今は自分のマシンでネームサーバを動かすので、ローカルホストを指
定します。 (注: named はこのファイルを参照しません。参照するのはレゾル
バです。)
このファイルの意味を説明しましょう。クライアントが foo の名前引きを行
うと、まず最初に foo.subdomain.your-domain.edu を調べ、次に foo.your-
domain.edu を試し、最後に foo を調べます。また sunsite.unc.edu の名前
引きを行うと、 sunsite.unc.edu.your-domain.edu、 sunsite.unc.edu.your-
domain.edu、 sunsite.unc.edu の順に調べます。 search 行にあまり多くの
ドメインを書くと、全てを調べるのに時間がかかるようになるので、ほどほど
にしておくのが良いでしょう。
この例ではあなたのマシンが subdomain.your-domain.edu にあるとしていま
すので、あなたのマシンの名前はおそらく your-machine.subdomain.your-
domain.edu となっているでしょう。なお search 行にはあなたの TLD (Top
Level Domain, この場合は `edu') を含めるべきではありません。頻繁に接続
するような特定のドメインがあれば、以下のように search 行にそのドメイン
を加えてもいいでしょう。 (先頭にスペースがあったら取り去るのを忘れない
ように。)
______________________________________________________________________
search subdomain.your-domain.edu your-domain.edu other-domain.com
______________________________________________________________________
もちろん実際には本当のドメイン名を書く必要があります。ドメイン名の最後
にはピリオドを書かないことに注意してください。これは重要なポイントで
す。ドメイン名の最後にはピリオドを書かないことに注意してください。
次に /etc/nsswitch.conf または /etc/host.conf のいずれかを変更します。
どちらを変更するかは使っている libc のバージョンに依存します。すでに
nsswitch.conf があるような場合はそちらを変更しましょう。なければ
host.conf を変更しましょう。
/etc/nsswitch.conf
これは大きなファイルで、いろいろな種類のデータに対して、それぞれどの
ファイルから、あるいはどのデータベースから取得するかを指定するもので
す。通常はためになるコメントが先頭に書かれています。読んでおくといいで
しょう。読み終わったら、 `hosts:' で始まる行を見つけてください。以下の
ようなものです。
______________________________________________________________________
hosts: files dns
______________________________________________________________________
(先頭のスペースに注意ですよ、いいですか？もうこれ以降は言いませんから
ね。)
`hosts:' で始まる行がない場合は、上の例を追加してください。この指定を
すると、プログラムはまず /etc/hosts ファイルを見て、次に resolv.conf
にしたがって DNS をチェックしにいくようになります。
/etc/host.conf
おそらく何行かあるうちの一行が order ではじまっており、以下のように
なっているでしょう。
______________________________________________________________________
order hosts,bind
______________________________________________________________________
`order' の行が無い場合には追加してください。この指定をすると、名前引き
ルーチンは最初に /etc/hostsを参照し、次にネームサーバ (resolv.conf で
127.0.0.1 と指定しましたね) に問い合わせるようになります。
3.1. named を起動する
これらの準備がすんだら、named を立ち上げましょう。ダイアルアップ接続を
している人は、まず先に接続してください。 `ndc start' と入力してリター
ンを押してください。オプションは指定しません。うまくいかない場合は
`/usr/sbin/ndc start' としてみましょう。これもうまくいかない場合は ``Q
& A'' の章を見て下さい。 named を動かしている最中に syslog のメッセー
ジファイル (普通は /var/adm/messages ですが /var/log ディレクトリに
あったり syslog のようなファイル名かもしれません) を見ると (tail -f
/var/adm/messages とします) 、以下のような出力が表示されるはずです:
(\ で終わっている行は、次の行に続いていることを表します)
Feb 15 01:26:17 roke named[6091]: starting. named 8.1.1 Sat Feb 14 \
00:18:20 MET 1998 ^Ijanl@roke.uio.no:/var/tmp/bind-8.1.1/src/bin/named
Feb 15 01:26:17 roke named[6091]: cache zone "" (IN) loaded (serial 0)
Feb 15 01:26:17 roke named[6091]: master zone "0.0.127.in-addr.arpa" \
(IN) loaded (serial 1)
Feb 15 01:26:17 roke named[6091]: listening [127.0.0.1].53 (lo)
Feb 15 01:26:17 roke named[6091]: listening [129.240.230.92].53 (ippp0)
Feb 15 01:26:17 roke named[6091]: Forwarding source address is [0.0.0.0].1040
Feb 15 01:26:17 roke named[6092]: Ready to answer queries.
エラーに関する出力があった場合は、何か間違えているのでしょう。 named
はその間違っているファイルを名指ししてくれるはずです (named.conf か
root.hints のどちらかだと思います :-)。 named を kill して、named 関係
のファイルを再確認しましょう。
さて、ここまで行ってきた設定を試してみましょう。 nslookup を起動して、
ここまでの作業を確認してみましょう。
$ nslookup
Default Server: localhost
Address: 127.0.0.1
>
と表示されれば、うまく動いているはずです (だといいですね)。何か他の表
示が出たら、やり直して全部再チェックです。 named.conf を変更したら、そ
のたびに ndc restart コマンドで named を再起動する必要があります。
では問い合わせをしてみましょう。あなたの近くにあるマシンの名前を引いて
みましょう。私の近く (Oslo 大学) には pat.uio.noというマシンがありま
す。
> pat.uio.no
Server: localhost
Address: 127.0.0.1
Name: pat.uio.no
Address: 129.240.130.16
nslookup はあなたのマシンで動いている named に、 pat.uio.no を探すよう
依頼します。すると named は root.hints ファイルに書かれているネームサ
ーバの一つに接続して、問い合わせをします。 /etc/resolv.conf に書かれて
いるドメイン全てについて調べる必要があるかもしれないので、結果が得られ
るまでに少々時間がかかることがあります。
ここでもう一度同じ問い合わせを行うと、次のような結果になるでしょう。
> pat.uio.no
Server: localhost
Address: 127.0.0.1
Non-authoritative answer:
Name: pat.uio.no
Address: 129.240.2.50
今度は 'Non-authoritative answer:'という行があることに注目してくださ
い。この行からわかることは、今回 named はネットワーク経由で調べたので
はなく、この情報はすでにキャッシュに入っている、ということです。でも
キャッシュの情報はもしかすると古いことがあるかもしれません。ですから、
この `Non-authorative answer:'という結果には、 (ほんのわずかですが) 危
険があることを知っておいてください。あるホストに対して 2 回問い合わせ
をして、 nslookup が二度目にこの結果を出した場合には、 named は情報を
キャッシュしていて、かつそのキャッシュが正しく動作していることになりま
す。 `exit' コマンドを入力して、 `nslookup' を終了しましょう。
3.2. 改善するには
学術機関や ISP (Internet Service Provider) などの、上手に組織化された
大きなネットワークでは、ネットワークのプロ達は DNS サーバに「フォワー
ダ (forwarder)」と呼ばれる階層を設けていることがあるかもしれません。こ
れには内部のネットワーク負荷や外部にあるサーバの負荷を下げる効果がある
のです。自分がそのようなネットワークの一部にいるのかどうかを知るのはそ
れほど簡単ではありませんが、それは別に気にする必要はありません。むしろ
ここで注目すべきなのは、接続しているプロバイダの DNS サーバを「フォワ
ーダ」として利用すると、問い合わせの反応を速くでき、ネットワークへの負
荷を下げることができるという点です。モデムを使っている場合は、この効果
はかなり大きいです。ここで例として、お使いのネットワークプロバイダには
利用を推奨している二つのネームサーバがあるとします。それぞれの IP 番号
を 10.0.0.1 と 10.1.0.1 としましょう。このような場合には、お手元の
named.conf ファイルの最初のセクション、 ``options'' という名前がついて
いる部分に以下の行を挿入して下さい。
______________________________________________________________________
forward first;
forwarders {
10.0.0.1;
10.1.0.1;
};
______________________________________________________________________
ダイアルアップマシンにも forwarders を使ったちょっと嬉しいトリックがあ
ります。 ``Q & A'' の章に書いてあります。
ネームサーバを再起動して、 nslookup でテストしてください。うまくいって
いると思います。
3.3. おめでとう
さて、今やあなたはキャッシュ動作をする named の設定方法を知ったわけで
す。ビールでもミルクでも、お好きなもので乾杯しましょう。
4. 単純な ドメイン
あなた自身のドメインの設定方法
4.1. でもまず最初に退屈な理論
このセクションを実際に始める前に、DNS の動作に関する理論を少々と、実際
の動作例を紹介しておきます。きっと役に立ちますから、ぜひ読みましょう。
読みたくなくても、少なくとも流し読みくらいはしておいてください。
named.conf ファイルの設定に関する部分まできたら流し読みはストップで
す。
DNS は階層的なツリー構造のシステムです。その頂点は `.' と記述され、
「ルート (root)」と発音されます。 '.' の下にはたくさんの Top Level
Domain (TLD) があります。 ORG, COM, EDU, NET などが有名ですが、他にも
たくさんあります。木の場合と同じように、このツリー構造は根を持ち、枝分
かれします。計算機科学の知識がある人には、 DNS は検索ツリーに見えるで
しょう。またそこには節点 (node)、端点 (leaf node)、枝 (edge) があるこ
とも見て取れるでしょう。
マシンの検索を行うとき、問い合わせはトップから始まる階層に対して再帰的
に行われます。あなたがホスト prep.ai.mit.edu のアドレスを問い合わせる
と、あなたのドメインのネームサーバは、まず edu を担当するネームサーバ
を見つけなければなりません。このときあなたのネームサーバは . のサーバ
に対して問い合わせを行います (あなたのネームサーバは . サーバをすでに
知っています。これが root.hints ファイルの役割です)。すると . のサーバ
は edu のサーバの一覧を返してくれます。
$ nslookup
Default Server: localhost
Address: 127.0.0.1
ルートサーバに問い合わせをしてみましょう。
> server c.root-servers.net.
Default Server: c.root-servers.net
Address: 192.33.4.12
問い合わせのタイプ (Query type) を NS (name server records) にします。
> set q=ns
edu に付いて尋ねてみましょう。
> edu.
ここで最後についている '.' には重要な意味があります。これによって
nslookup に、現在問い合わせを行っている edu が '.' の直下にあることを
伝えているのです (前で指定した search ドメインを無視することになり、検
索がいくらか速くなります)。
edu nameserver = A.ROOT-SERVERS.NET
edu nameserver = H.ROOT-SERVERS.NET
edu nameserver = B.ROOT-SERVERS.NET
edu nameserver = C.ROOT-SERVERS.NET
edu nameserver = D.ROOT-SERVERS.NET
edu nameserver = E.ROOT-SERVERS.NET
edu nameserver = I.ROOT-SERVERS.NET
edu nameserver = F.ROOT-SERVERS.NET
edu nameserver = G.ROOT-SERVERS.NET
A.ROOT-SERVERS.NET internet address = 198.41.0.4
H.ROOT-SERVERS.NET internet address = 128.63.2.53
B.ROOT-SERVERS.NET internet address = 128.9.0.107
C.ROOT-SERVERS.NET internet address = 192.33.4.12
D.ROOT-SERVERS.NET internet address = 128.8.10.90
E.ROOT-SERVERS.NET internet address = 192.203.230.10
I.ROOT-SERVERS.NET internet address = 192.36.148.17
F.ROOT-SERVERS.NET internet address = 192.5.5.241
G.ROOT-SERVERS.NET internet address = 192.112.36.4
これによって、*.ROOT-SERVERS.NET の各サーバが EDU. をサービスしている
ことがわかるので、いずれかに問い合わせをすれば良いことがわかります。そ
のまま引き続いて C に尋ねることにしましょう。さて、次にはドメイン名の
次の階層 mit.edu. を担当するサーバを調べます:
> mit.edu.
Server: c.root-servers.net
Address: 192.33.4.12
Non-authoritative answer:
mit.edu nameserver = W20NS.mit.edu
mit.edu nameserver = BITSY.mit.edu
mit.edu nameserver = STRAWB.mit.edu
Authoritative answers can be found from:
W20NS.mit.edu internet address = 18.70.0.160
BITSY.mit.edu internet address = 18.72.0.3
STRAWB.mit.edu internet address = 18.71.0.151
strawb, w20ns, bitsy が mit のサービスを行っていることがわかりました。
この中から一つを選んで、もう一つ上のレベルのサービス ai.mit.edu につい
ての問い合わせを行いましょう。
> server W20NS.mit.edu.
ホスト名は大文字でも小文字でも関係ないのですが、ここで私は画面からカッ
ト・アンド・ペーストを行ったため、この例における入力の大文字・小文字は
nslookup の出力結果と同じになっています。
Server: W20NS.mit.edu
Address: 18.70.0.160
> ai.mit.edu.
Server: W20NS.mit.edu
Address: 18.70.0.160
Non-authoritative answer:
ai.mit.edu nameserver = ALPHA-BITS.AI.MIT.EDU
ai.mit.edu nameserver = GRAPE-NUTS.AI.MIT.EDU
ai.mit.edu nameserver = TRIX.AI.MIT.EDU
ai.mit.edu nameserver = MUESLI.AI.MIT.EDU
ai.mit.edu nameserver = LIFE.AI.MIT.EDU
ai.mit.edu nameserver = BEET-CHEX.AI.MIT.EDU
ai.mit.edu nameserver = MINI-WHEATS.AI.MIT.EDU
ai.mit.edu nameserver = COUNT-CHOCULA.AI.MIT.EDU
ai.mit.edu nameserver = MINTAKA.LCS.MIT.EDU
Authoritative answers can be found from:
AI.MIT.EDU nameserver = ALPHA-BITS.AI.MIT.EDU
AI.MIT.EDU nameserver = GRAPE-NUTS.AI.MIT.EDU
AI.MIT.EDU nameserver = TRIX.AI.MIT.EDU
AI.MIT.EDU nameserver = MUESLI.AI.MIT.EDU
AI.MIT.EDU nameserver = LIFE.AI.MIT.EDU
AI.MIT.EDU nameserver = BEET-CHEX.AI.MIT.EDU
AI.MIT.EDU nameserver = MINI-WHEATS.AI.MIT.EDU
AI.MIT.EDU nameserver = COUNT-CHOCULA.AI.MIT.EDU
AI.MIT.EDU nameserver = MINTAKA.LCS.MIT.EDU
ALPHA-BITS.AI.MIT.EDU internet address = 128.52.32.5
GRAPE-NUTS.AI.MIT.EDU internet address = 128.52.36.4
TRIX.AI.MIT.EDU internet address = 128.52.37.6
MUESLI.AI.MIT.EDU internet address = 128.52.39.7
LIFE.AI.MIT.EDU internet address = 128.52.32.80
BEET-CHEX.AI.MIT.EDU internet address = 128.52.32.22
MINI-WHEATS.AI.MIT.EDU internet address = 128.52.54.11
COUNT-CHOCULA.AI.MIT.EDU internet address = 128.52.38.22
MINTAKA.LCS.MIT.EDU internet address = 18.26.0.36
なるほど、 muesli.ai.mit.edu が ai.mit.edu のネームサーバの一つである
ことがわかりました。
> server MUESLI.AI.MIT.EDU
Default Server: MUESLI.AI.MIT.EDU
Address: 128.52.39.7
ここで、問い合わせのタイプを変更します。見つかったネームサーバ muesli
が prep.ai.mit.edu について知っていることを全部教えてもらうことにしま
しょう。
> set q=any
> prep.ai.mit.edu.
Server: MUESLI.AI.MIT.EDU
Address: 128.52.39.7
prep.ai.mit.edu CPU = dec/decstation-5000.25 OS = unix
prep.ai.mit.edu
inet address = 18.159.0.42, protocol = tcp
ftp telnet smtp finger
prep.ai.mit.edu preference = 1, mail exchanger = gnu-life.ai.mit.edu
prep.ai.mit.edu internet address = 18.159.0.42
ai.mit.edu nameserver = beet-chex.ai.mit.edu
ai.mit.edu nameserver = alpha-bits.ai.mit.edu
ai.mit.edu nameserver = mini-wheats.ai.mit.edu
ai.mit.edu nameserver = trix.ai.mit.edu
ai.mit.edu nameserver = muesli.ai.mit.edu
ai.mit.edu nameserver = count-chocula.ai.mit.edu
ai.mit.edu nameserver = mintaka.lcs.mit.edu
ai.mit.edu nameserver = life.ai.mit.edu
gnu-life.ai.mit.edu internet address = 128.52.32.60
beet-chex.ai.mit.edu internet address = 128.52.32.22
alpha-bits.ai.mit.edu internet address = 128.52.32.5
mini-wheats.ai.mit.edu internet address = 128.52.54.11
trix.ai.mit.edu internet address = 128.52.37.6
muesli.ai.mit.edu internet address = 128.52.39.7
count-chocula.ai.mit.edu internet address = 128.52.38.22
mintaka.lcs.mit.edu internet address = 18.26.0.36
life.ai.mit.edu internet address = 128.52.32.80
というわけで、 . から始めて、ドメイン名の階層を下りながら各階層におけ
るネームサーバを次々と見つけていくことができました。これら他所にあるサ
ーバを使う代わりにあなたの自前の DNS サーバを使っていた場合には、あな
たのサーバはもちろん調べた情報を全てキャッシュしてくれますから、しばら
くの間は他所への問い合わせを行う必要はなくなります。
ツリーとのアナロジーでいうと、名前の ``.'' は枝分かれのポイントに対応
します。そして ``.'' に挟まれた部分はツリー中でのそれぞれの枝の名前に
なります。
私たちは欲しい名前 (prep.ai.mit.edu) を取得しながらツリーを登っていっ
たわけです。まず最初に根 (.) を見つけ、そこで次に登るべき枝 (この場合
は edu) を探しました。見つかったところで、名前のそこまでの部分について
知っているサーバに接続しなおしました (つまり「枝を登り」ました)。次に
edu の枝の上にある mit の枝 (名前をくっつけると mit.edu) を探し、そし
て mit.edu のことを知っているサーバに切り替えました。次の枝 ai.mit.edu
でも同じことを行い、またサーバを切り替えました。そしてとうとう正しいサ
ーバ、正しい枝分かれポイントに到達したわけです。最後の部分は
prep.ai.mit.edu を見つけることでした。簡単でしたね。計算機科学では、
prep の部分はツリーの 端点 (leaf) と呼ぶのが普通です。
いままでほとんど触れませんでしたが、同じくらい非常に重要なドメインとし
て in-addr.arpa があります。これは「普通の」ドメインのようにネストもし
ます。 in-addr.arpa によって、アドレスがわかっている場合にホスト名を得
ることができるようになります。ここで重要なのは、 IP 番号は in-
addr.arpa ドメインでは逆順に記述されることです。あるマシンのアドレス
192.128.52.43 がわかっていた場合、 named は 先程の prep.ai.mit.edu の
例と同じように動作します: 最初に arpa. のサーバを見つけます。次に in-
addr.arpa. のサーバ、 192.in-addr.arpa. のサーバ、 128.192.in-
addr.arpa. のサーバ、 52.128.192.in-addr.arpa. のサーバを見つけます。
そして必要な 43.52.128.192.in-addr.arpa. に対応するレコードを見つけま
す。賢いでしょ？ (でしょ？) ただし番号の逆転には、慣れるまで何年かかか
るかもしれませんけどね。
ここでちょっとウソをつきました。 DNS は今まで書いてきた通り全くそのま
まに動作するわけではありません。でもほぼこの通りと思っていただいてかま
いません。
4.2. 自分のドメインを作る
さて、私たちのドメインを定義しましょう。ドメイン linux.bogus を作り、
そこに私たちのマシンを定義しましょう。ここでは完全に架空のドメイン名を
使って、間違っても外部の人に迷惑がかからないようにしましょう。
始める前にもう一点。ホスト名に使える文字には制限があります。英語のアル
ファベット a-z、数字 0-9、および '-' (ダッシュ) 文字だけが使えます。守
るようにしてください。大文字小文字は DNS では区別されません。したがっ
て pat.uio.no と Pat.UiO.No とはまったく同じように解釈されます。
実はこの章で最初に行うべき部分はすでに記述済みです。 named.conf には以
下のような行がありますよね。
______________________________________________________________________
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};
______________________________________________________________________
このファイルではドメイン名の最後に `.' を付けていない点に注意してくだ
さい。上記の内容から、これから私たちはゾーン 0.0.127.in-addr.arpa を定
義すること、そしてこの named がそのゾーンのマスターサーバになること、
またその内容がファイル pz/127.0.0 に保存されることなどがわかります。こ
のファイルはすでに設定済みで、以下のような内容のはずです。
______________________________________________________________________
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
1 ; Serial
8H ; Refresh
2H ; Retry
1W ; Expire
1D) ; Minimum TTL
NS ns.linux.bogus.
1 PTR localhost.
______________________________________________________________________
先程の named.conf の場合とは対照的に、このファイル中ではすべてのドメイ
ン名の最後に `.' があることに注意してください。ゾーンファイルを
$ORIGIN 命令から開始することを好む人たちもいるようですが、これは不要で
す。ゾーンファイルの origin (このゾーンが属する DNS の階層) は
named.conf のゾーンセクションで指定されます。この場合は 0.0.127.in-
addr.arpa です。
この「ゾーンファイル」には三つの「リソースレコード (resource record:
RR)」が含まれています。 SOA RR, NS RR, PTR RR です。 SOA は Start Of
Authority の省略です。 `@' は特別な記号で、 origin を意味します。この
ファイルの `domain' カラムは 0.0.127.in-addr.arpa ですから、最初の行の
実際の意味は以下と同じになります。
0.0.127.in-addr.arpa. IN SOA ...
NS は Name Server RR の略です。この行の先頭には `@' がありません。これ
は暗黙のうちにすでに指定されたことになっています。直前の行が `@' では
じまっていたからです。多少タイプの量が節約できますね。したがって NS の
行は以下のようにも記述できることになります。
0.0.127.in-addr.arpa. IN NS ns.linux.bogus
この行は DNS に、どのマシンがこのドメイン 0.0.127.in-addr.arpa のネー
ムサーバであるかを教えます。 ns.linux.bogus というわけですね。 `ns' と
いうのはネームサーバに良く用いられる名前ですが、これは web サーバに
www.something という名前が付けられるのと似たような事情からです。実際に
はどんな名前を用いてもかまいません。
最後に、 PTR レコードは、このサブネット 0.0.127.in-addr.arpa のアドレ
ス 1 にあるホスト、すなわち 127.0.0.1 が localhost という名前であるこ
とを示しています。
SOA レコードはどんなゾーンファイルでも先頭に置かれます。また各ゾーン
ファイルにつき一つ書きます。このレコードはゾーンの説明です。どこから得
られるのか (linux.bogusというマシン)、内容に関する責任者は誰か
(hostmaster@linux.bogus: ここにはあなたの電子メールアドレスを入れま
しょう)、ゾーンファイルのバージョンはいくつか (serial: 1)、その他
キャッシュやセカンダリ DNS サーバなどに関連した内容などを書きます。残
りのフィールドの refresh, retry, expire, minimum については、この
HOWTO の値をそのまま使えば特に問題ないでしょう。
さて、ここで named を再起動して (コマンドは ndc restart です)、
nslookup コマンドを使って今までの設定の確認を行いましょう。
$ nslookup
Default Server: localhost
Address: 127.0.0.1
> 127.0.0.1
Server: localhost
Address: 127.0.0.1
Name: localhost
Address: 127.0.0.1
なんとか 127.0.0.1 から localhost が得られました。いい感じですね。では
メインのお仕事である linux.bogus ドメインのために、 named.conf に新し
い `zone' セクションを書きましょう。
______________________________________________________________________
zone "linux.bogus" {
notify no;
type master;
file "pz/linux.bogus";
};
______________________________________________________________________
ここでも named.conf ファイルに記述するドメイン名の最後には `.' が付い
ていないことに着目。
linux.bogus ゾーンファイルには、まったく架空のデータを置くことにしま
しょう。
______________________________________________________________________
;
; Zone file for linux.bogus
;
; The full zone file
;
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, todays date + todays serial #
8H ; refresh, seconds
2H ; retry, seconds
1W ; expire, seconds
1D ) ; minimum, seconds
;
NS ns ; Inet Address of name server
MX 10 mail.linux.bogus ; Primary Mail Exchanger
MX 20 mail.friend.bogus. ; Secondary Mail Exchanger
;
localhost A 127.0.0.1
ns A 192.168.196.2
mail A 192.168.196.4
______________________________________________________________________
SOA レコードについては二つの点に注意する必要があります。
ns.linux.bogus は A レコードを持った実際のマシンでなければなりません。
CNAME レコードのマシンを SOA レコードのマシンとして記述することは許さ
れていません。名前は `ns' でなくても、正しいホスト名であればかまいませ
ん。次に hostmaster.linux.bogus は hostmaster@linux.bogus と読み替えて
ください。これはメールエイリアスかメールボックスで、この DNS をメンテ
ナンスしている人が頻繁にチェックしているところでなければなりません。こ
のドメインに関するメールは、ここで記述されたアドレスに送ることになって
います。名前は `hostmaster' でなくあなたの e-mail アドレスでもかまいま
せん。でも `hostmaster' でももちろんちゃんと動くはずです。
このファイルには新しいタイプの RR があります。 MX (Mail eXchanger) RR
です。これはメールシステムに対して someone@linux.bogus 宛メールの送り
先を伝えるもので、 mail.linux.bogus または mail.friend.bogus がこれに
なります。マシンの名前の前に書かれた数値は MX RR の優先度を示します。
最低の数値 (10) を持つホストに対して優先的にメールが送られます。この配
送に失敗すると、より大きな数値を持つホストに配送が行われます。すなわち
ここでは優先度 20 を持つ mail.friend.bogus です。
ndc restart を実行して named を再起動しましょう。ここまでの設定を
nslookup で確認しましょう。
$ nslookup
> set q=any
> linux.bogus
Server: localhost
Address: 127.0.0.1
linux.bogus
origin = ns.linux.bogus
mail addr = hostmaster.linux.bogus
serial = 199802151
refresh = 28800 (8 hours)
retry = 7200 (2 hours)
expire = 604800 (7 days)
minimum ttl = 86400 (1 day)
linux.bogus nameserver = ns.linux.bogus
linux.bogus preference = 10, mail exchanger = mail.linux.bogus.linux.bogus
linux.bogus preference = 20, mail exchanger = mail.friend.bogus
linux.bogus nameserver = ns.linux.bogus
ns.linux.bogus internet address = 192.168.196.2
mail.linux.bogus internet address = 192.168.196.4
よく見ると、バグがあることがわかると思います。
linux.bogus preference = 10, mail exchanger = mail.linux.bogus.linux.bogus
というのはおかしいですね。これは、
linux.bogus preference = 10, mail exchanger = mail.linux.bogus
でなければなりません。
読者の学習効果を慮って :-)、ここで私はわざと間違えました。ゾーンファイ
ルを見ると、以下の行
MX 10 mail.linux.bogus ; Primary Mail Exchanger
にはピリオドがないことがわかります。あるいは余計に 'linux.bogus' を書
いてしまっている、とも言えます。ゾーンファイルに書かれたホスト名の最後
にピリオドがない場合には、 origin が最後に加えられます。つまり
linux.bogus.linux.bogus と二重になってしまうのです。ですから、
______________________________________________________________________
MX 10 mail.linux.bogus. ; Primary Mail Exchanger
______________________________________________________________________
とするか、
______________________________________________________________________
MX 10 mail ; Primary Mail Exchanger
______________________________________________________________________
とするべきです。私は後者が好きです。タイプ量が少ないですからね。 bind
の専門家にはこの書式に反対する人もいます (賛成する人もいます)。ゾーン
ファイルでは、ドメインは全て書き下して `.' で終えるか、全く書かないか
どちらかにします。後者ではデフォルトで origin が付属します。
強調しておきます。 named.conf ファイルでは、ドメイン名の後に `.' を付
けてはいけません。 `.' が多すぎたり少なすぎたりしたおかげで、どれだけ
多くの物事や人々が混乱したか、きっとあなたには想像もつかないでしょう。
と言うことで、この点を押さえて新たなゾーンファイルを書きましょう。少々
新しい情報も加わっていますが、以下のようになります。
______________________________________________________________________
;
; Zone file for linux.bogus
;
; The full zone file
;
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, todays date + todays serial #
8H ; refresh, seconds
2H ; retry, seconds
1W ; expire, seconds
1D ) ; minimum, seconds
;
TXT "Linux.Bogus, your DNS consultants"
NS ns ; Inet Address of name server
NS ns.friend.bogus.
MX 10 mail ; Primary Mail Exchanger
MX 20 mail.friend.bogus. ; Secondary Mail Exchanger
localhost A 127.0.0.1
gw A 192.168.196.1
HINFO "Cisco" "IOS"
TXT "The router"
ns A 192.168.196.2
MX 10 mail
MX 20 mail.friend.bogus.
HINFO "Pentium" "Linux 2.0"
www CNAME ns
donald A 192.168.196.3
MX 10 mail
MX 20 mail.friend.bogus.
HINFO "i486" "Linux 2.0"
TXT "DEK"
mail A 192.168.196.4
MX 10 mail
MX 20 mail.friend.bogus.
HINFO "386sx" "Linux 1.2"
ftp A 192.168.196.5
MX 10 mail
MX 20 mail.friend.bogus.
HINFO "P6" "Linux 2.1.86"
______________________________________________________________________
ここでいくつか新しいリソースレコードが登場します。 HINFO (Host
INFOmation) には二つのデータが付属します。それぞれを "" で括っておくの
が良い習慣です。最初のデータはマシンのハードウェアか CPU を示し、二番
目のデータはソフトウェアか OS を示します。 `ns' という名前のホストは
Pentium CPU を搭載し、 Linux 2.0 が動いています。 CNAME (Canonical
NAME) は一つのマシンに複数の名前を付けるやり方です。 www は ns の別名
になります。
CNAME レコードの利用については、多少議論の余地があります。でも以下のル
ールを守っておけば大丈夫でしょう。 MX, CNAME, SOA の各レコードでは
CNAME レコードを参照してはいけません。これらは A レコードだけを参照す
べきなのです。したがって
______________________________________________________________________
foobar CNAME www ; NO!
______________________________________________________________________
という指定はすべきではなく、
______________________________________________________________________
foobar CNAME ns ; Yes!
______________________________________________________________________
という指定が正しいものとなります。
また CNAME はメールアドレスとして正しいものではないと思っていた方が安
全です。つまり上記の設定では webmaster@www.linux.bogus は不正なものな
のです。あなたのところではうまく動くかもしれませんが、このルールを守る
べきだと主張するメール管理者はかなりたくさんいるのです。これを避けるに
はかわりに A レコード (あるいは MX などでもいいでしょう) を用いること
です。
______________________________________________________________________
www A 192.168.196.2
______________________________________________________________________
bind の上級魔術師達の中には、 CNAME はどんな場合にも用いるべきではない
と言っている人たちが相当数います。でも理由に関する議論はこの HOWTO の
範囲を越えています。
ですがご覧の通り、この HOWTO や多くのサイトでは、このルールは守られて
いません。
ndc reload を実行して新しいデータベースをロードしましょう。すると
named がファイルを読み込み直します。
$ nslookup
Default Server: localhost
Address: 127.0.0.1
> ls -d linux.bogus
これはレコードをすべて表示せよ、という意味です。結果は以下のようになる
でしょう。
[localhost]
$ORIGIN linux.bogus.
@ 1D IN SOA ns hostmaster (
199802151 ; serial
8H ; refresh
2H ; retry
1W ; expiry
1D ) ; minimum
1D IN NS ns
1D IN NS ns.friend.bogus.
1D IN TXT "Linux.Bogus, your DNS consultants"
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
gw 1D IN A 192.168.196.1
1D IN HINFO "Cisco" "IOS"
1D IN TXT "The router"
mail 1D IN A 192.168.196.4
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
1D IN HINFO "386sx" "Linux 1.0.9"
localhost 1D IN A 127.0.0.1
www 1D IN CNAME ns
donald 1D IN A 192.168.196.3
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
1D IN HINFO "i486" "Linux 1.2"
1D IN TXT "DEK"
ftp 1D IN A 192.168.196.5
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
1D IN HINFO "P6" "Linux 1.3.59"
ns 1D IN A 192.168.196.2
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
1D IN HINFO "Pentium" "Linux 1.2"
うまくいっていますね。ご覧の通り、ゾーンファイルそのものととても似てい
ます。 www だけについても調べてみましょう。
> set q=any
> www.linux.bogus.
Server: localhost
Address: 127.0.0.1
www.linux.bogus canonical name = ns.linux.bogus
linux.bogus nameserver = ns.linux.bogus
linux.bogus nameserver = ns.friend.bogus
ns.linux.bogus internet address = 192.168.196.2
つまり www.linux.bogus の本当の名前は ns.linux.bogus なわけです。そし
て named が ns について持っている情報も示してくれています。あなたがプ
ログラムなら、この情報で接続できるはずです。
さて、ここまでで半分来たことになります。
4.3. 逆引きゾーン
今やプログラムは、 linux.bogus にある名前を実際に接続すべきアドレスに
変換することができるようになったわけです。でも逆引きのゾーンも必要で
す。これは DNS でアドレスを名前に変換できるようにするためのものです。
この名前はさまざまな種類のたくさんのサーバ (FTP, IRC, WWW などなど) に
おいて、あなたとの通信を認めるか、また認めた場合、どの程度の優先性を付
与するかなどの判断に用いられます。インターネットにあるサービスすべてに
アクセスするためには、逆引きのゾーンが必要になります。
以下を named.conf に記述してください。
______________________________________________________________________
zone "196.168.192.in-addr.arpa" {
notify no;
type master;
file "pz/192.168.196";
};
______________________________________________________________________
これは 0.0.127.in-addr.arpa とまったく同じです。ファイルの中身も同じよ
うになります。
______________________________________________________________________
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; Serial, todays date + todays serial
8H ; Refresh
2H ; Retry
1W ; Expire
1D) ; Minimum TTL
NS ns.linux.bogus.
1 PTR gw.linux.bogus.
2 PTR ns.linux.bogus.
3 PTR donald.linux.bogus.
4 PTR mail.linux.bogus.
5 PTR ftp.linux.bogus.
______________________________________________________________________
ここで named を再起動 (ndc restart) して、再び nslookup で調べてみま
しょう。
______________________________________________________________________
> 192.168.196.4
Server: localhost
Address: 127.0.0.1
Name: mail.linux.bogus
Address: 192.168.196.4
______________________________________________________________________
うん、良さそうですね。全体もダンプして調べてみましょう。
______________________________________________________________________
> ls -d 196.168.192.in-addr.arpa
[localhost]
$ORIGIN 196.168.192.in-addr.arpa.
@ 1D IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial
8H ; refresh
2H ; retry
1W ; expiry
1D ) ; minimum
1D IN NS ns.linux.bogus.
1 1D IN PTR gw.linux.bogus.
2 1D IN PTR ns.linux.bogus.
3 1D IN PTR donald.linux.bogus.
4 1D IN PTR mail.linux.bogus.
5 1D IN PTR ftp.linux.bogus.
@ 1D IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial
8H ; refresh
2H ; retry
1W ; expiry
1D ) ; minimum
______________________________________________________________________
よさそうですね！このような出力にならなかった場合は、 syslog にエラー
メッセージが出ていないか見てみましょう。やり方はこの章の一番最初で説明
しましたね。
4.4. 気をつけること
ここでいくつか付け加えておくことがあります。上記で用いた IP 番号は
'private net' のうちの一つのブロックから取ってきたものです。つまりこれ
らの IP 番号はインターネットでパブリックに用いることはできません。です
からこの HOWTO で例として表示しても安全なわけです。次の点は notify no;
の行です。これは named に対して、「ゾーンファイルのどれかが更新されて
も、それをセカンダリ (スレーブ) サーバに伝えない」という指示をすること
になります。 bind-8 の named は、ゾーンファイルの NS レコードにリスト
されている他のサーバに、ゾーンの更新を知らせることができます。これは通
常は便利な機能ですが、プライベートな実験ではこの機能は off にしておき
ましょう。この実験によってインターネットに迷惑をかけたくはないでしょ
う？
そしてもちろん、このドメインは架空のいいかげんなもので、使われているア
ドレスも同じく架空のものです。現実の世界で用いられている本物の例は、次
の章を見て下さい。
4.5. なぜ逆引きが動作しないのか
名前引きのシステムには、ちょっとした「できの悪い部分」がいくつかありま
す。通常これらが表に出てくることはありませんが、逆引きゾーンの設定では
良くお目にかかることがあります。ここから以降を読み進める前には、あなた
のマシンが「あなたのネームサーバ」から逆引きできることを確認してくださ
い。できない場合は戻ってやり直してからにしてください。
ここでは、逆引きを外部ネットワークから見た場合に生じやすい二つの問題点
について議論します。
4.5.1. 逆引きゾーンが代理されない
サービスプロバイダからネットワークアドレス空間とドメインネームをもらう
ときには、通常そのドメインネームは代理 (delegation) されます。代理とは
橋渡しの役目をする NS レコードのことで、あるネームサーバから別のネーム
サーバを取得するときに用います。先に ``退屈な理論'' の節で説明しまし
た。読んでます、よね？逆引きゾーンが動作していない場合は、今すぐ戻って
読むこと。
逆引きゾーンにも代理が必要です。例えば 192.168.196 のネットワークを
linux.bogus ドメインと一緒にプロバイダからもらったとしたら、プロバイダ
には NS レコードを正引きゾーンだけでなく逆引きゾーンにも加えてもらう必
要があります。 in-addr.arpa からあなたのネットワークまでの繋がりを辿っ
ていくと、おそらくどこかで鎖の輪が切れていることでしょう。多分接続して
いるサービスプロバイダで。「切れている輪」が見付かったら、サービスプロ
バイダに連絡してエラーを修正してもらいましょう。
4.5.2. クラスレス (classless) のサブネットをもらった場合
これはやや高度な話題になります。しかしクラスレスのサブネットは最近非常
に良く使われるようになってきたので、中規模以上の会社に所属していない人
はおそらく身近にあるでしょう。
最近のインターネットをなんとか維持できているのは、実はクラスレスサブ
ネットのおかげなのです。数年前に IP 番号の枯渇についてちょっとした騒ぎ
になったことがありました。その時 IETF (Internet Engineering Task
Force: インターネットがちゃんと動いているのは彼らのおかげなのです) の
賢い人たちは、彼らの頭脳を集めてこの問題を解決したのでした。ただし相応
の対価をもって。その対価とは、``C'' 未満のサブネットを使わなければなら
ないこと、そして動作しなくなるものが出てくること、です。このあたりに関
する説明と、その扱い方に関しては、 Ask Mr. DNS
にある優れた解説を見てくだ
さい。
読みました？ここでは説明しませんから、ちゃんと読んでくださいね。
この問題の半分は、接続先の ISP が Mr. DNS に書いてあったテクニックを理
解していなければならない、というところにあります。小さな ISP では、こ
れを知らずに動かしているところもあるでしょう。その場合は、あなたが彼ら
にがまん強く教えてあげなければいけません。それに、まずあなたが理解しな
いといけませんね ;-) 理解してくれたら、きっとちゃんとした逆引きゾーン
を設定してくれるでしょう。 nslookup を使って正しいかどうか確かめましょ
う。
問題の残り半分は、あなたがテクニックを理解しなければならない、というと
ころです。自信がなければ、もう一度読みにいきましょう。そして Mr. DNS
の説明にしたがって、自分のクラスレス逆引きゾーンを設定しましょう。
実はここにはもう一つトラップが待ち構えています。古いレゾルバは、名前解
決のチェーンの中に置かれたこの CNAME トリックの部分をたどることができ
ず、あなたのマシンの逆引きに失敗してしまうことがあります。この結果、そ
のレゾルバは正しくないアクセスクラスを返したり、アクセスを拒否したり、
とにかくそんなようなことになります。この問題に引っかかってしまったら、
(私の知るかぎりでは) 接続先の ISP に頼むしかありません。トリックを使っ
たクラスレスゾーンファイルに、 CNAME の代わりにあなたの PTR レコードを
直接書き込んでもらうことになります。
ISP によっては別の解法を提供していることもあります。たとえば Web ベー
スの form によって逆引きのマップを入力できるようになっているとか、似た
ような全自動型登録システムなどです。
5. 実際のドメインの例
実際に用いられているゾーンファイルの例
チュートリアルの例だけでなく実際に動作している例を載せて欲しい、という
意見があったので、この章を設けました。
この例は LAND-5 の David Bullock の許可の下に用いています。これらの
ファイルは、 1996 年 9 月 24 日現在のものを、私が bind 8 の制限と拡張
にあわせて編集したものです。したがってここでの記述は、実際に LAND-5 の
ネームサーバに問い合わせを行った結果とは多少異なります。
5.1. /etc/named.conf (または /var/named/named.conf)
マスターゾーンセクションとして、必須の逆引きゾーンが二つ書かれていま
す。 127.0.0 のネットと LAND-5 のサブネットである 206.6.177 です。
LAND-5 の正引きゾーンである land-5.com もプライマリとして指定されてい
ます。ゾーンファイルは本 HOWTO のこれまでの例で用いていた pz ではな
く、 zone というディレクトリに収められていることにも注意してください。
______________________________________________________________________
// Boot file for LAND-5 name server
options {
directory "/var/named";
};
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "zone/127.0.0";
};
zone "land-5.com" {
type master;
file "zone/land-5.com";
};
zone "177.6.206.in-addr.arpa" {
type master;
file "zone/206.6.177";
};
______________________________________________________________________
このファイルをあなたの named.conf ファイルに用いるときには、必ず
``notify no;'' を land-5 の二つの zone セクションに追加して、事故が起
こらないようにしてください。
5.2. /var/named/root.hints
このファイルは動的に変化するものですから、このリストは古いです。 dig
を使って新しく作ったものを使いましょう。やり方は次のセクションで説明し
ています。
______________________________________________________________________
; <<>> DiG 8.1 <<>> @A.ROOT-SERVERS.NET.
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
;; QUERY SECTION:
;; ., type = NS, class = IN
;; ANSWER SECTION:
. 6D IN NS G.ROOT-SERVERS.NET.
. 6D IN NS J.ROOT-SERVERS.NET.
. 6D IN NS K.ROOT-SERVERS.NET.
. 6D IN NS L.ROOT-SERVERS.NET.
. 6D IN NS M.ROOT-SERVERS.NET.
. 6D IN NS A.ROOT-SERVERS.NET.
. 6D IN NS H.ROOT-SERVERS.NET.
. 6D IN NS B.ROOT-SERVERS.NET.
. 6D IN NS C.ROOT-SERVERS.NET.
. 6D IN NS D.ROOT-SERVERS.NET.
. 6D IN NS E.ROOT-SERVERS.NET.
. 6D IN NS I.ROOT-SERVERS.NET.
. 6D IN NS F.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4
J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10
K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129
L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12
M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33
A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4
H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53
B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107
C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12
D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90
E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10
I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17
F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241
;; Total query time: 215 msec
;; FROM: roke.uio.no to SERVER: A.ROOT-SERVERS.NET. 198.41.0.4
;; WHEN: Sun Feb 15 01:22:51 1998
;; MSG SIZE sent: 17 rcvd: 436
______________________________________________________________________
5.3. /var/named/zone/127.0.0
非常にシンプルなものです。まず絶対に必要な SOA レコード、そして
127.0.0.1 を localhost にマップするレコードです。これらは両方とも必須
です。逆にこれ以上のものは置くべきではありません。このファイルは、使っ
ているネームサーバか hostmaster のメールアドレスが変更されない限り、更
新する必要はおそらくないでしょう。
______________________________________________________________________
@ IN SOA land-5.com. root.land-5.com. (
199609203 ; Serial
28800 ; Refresh
7200 ; Retry
604800 ; Expire
86400) ; Minimum TTL
NS land-5.com.
1 PTR localhost.
______________________________________________________________________
5.4. /var/named/zone/land-5.com
まず必須である SOA レコードと、同じく必須の NS レコードがあります。セ
カンダリのネームサーバが ns2.psi.net に用意されていることもわかります
ね。これは望ましい設定です。必ずサイトの外にバックアップのセカンダリネ
ームサーバを置くべきです。マスターのホストは land-5 で、このホストは同
時に各種のインターネットサービスを提供していることもわかります。これに
は CNAME (A レコードでなく) が用いられています。
SOA レコードからわかるように、このゾーンファイルは land-5.com を
origin にしており、連絡担当者は root@land-5.com です。 hostmaster も担
当者のアドレスとして良く用いられます。シリアル番号は yyyymmdd 形式で、
その日のうちのシリアル番号が追加されています。これはきっと 1996 年 9
月 20 日の第 6 版なのでしょう。シリアル番号は必ず増加しなければならな
いことを思い出してください。ここには当日中のシリアル番号として一桁しか
使うことができません。したがって 9 回変更を行ったら、次の変更を行うに
は翌日まで待たなければなりません。二桁使う方が良いかもしれませんね。
______________________________________________________________________
@ IN SOA land-5.com. root.land-5.com. (
199609206 ; serial, todays date + todays serial #
8H ; refresh, seconds
2H ; retry, seconds
1W ; expire, seconds
1D ) ; minimum, seconds
NS land-5.com.
NS ns2.psi.net.
MX 10 land-5.com. ; Primary Mail Exchanger
TXT "LAND-5 Corporation"
localhost A 127.0.0.1
router A 206.6.177.1
land-5.com. A 206.6.177.2
ns A 206.6.177.3
www A 207.159.141.192
ftp CNAME land-5.com.
mail CNAME land-5.com.
news CNAME land-5.com.
funn A 206.6.177.2
;
; Workstations
;
ws-177200 A 206.6.177.200
MX 10 land-5.com. ; Primary Mail Host
ws-177201 A 206.6.177.201
MX 10 land-5.com. ; Primary Mail Host
ws-177202 A 206.6.177.202
MX 10 land-5.com. ; Primary Mail Host
ws-177203 A 206.6.177.203
MX 10 land-5.com. ; Primary Mail Host
ws-177204 A 206.6.177.204
MX 10 land-5.com. ; Primary Mail Host
ws-177205 A 206.6.177.205
MX 10 land-5.com. ; Primary Mail Host
; {Many repetitive definitions deleted - SNIP}
ws-177250 A 206.6.177.250
MX 10 land-5.com. ; Primary Mail Host
ws-177251 A 206.6.177.251
MX 10 land-5.com. ; Primary Mail Host
ws-177252 A 206.6.177.252
MX 10 land-5.com. ; Primary Mail Host
ws-177253 A 206.6.177.253
MX 10 land-5.com. ; Primary Mail Host
ws-177254 A 206.6.177.254
MX 10 land-5.com. ; Primary Mail Host
______________________________________________________________________
land-5 のネームサーバを試してみればわかりますが、本当のホスト名は
ws_number となっています。最近の版の bind 4 の named では、ホスト名に
用いることのできる文字が制限されるようになりました。したがってこの名前
は bind-8 では絶対に動作しませんから、この HOWTO に掲載する際には '_'
(underline) を '-' (dash) で置き換えました。
もう一つ気がつきましたか？各ワークステーションには固別の名前は付いてお
らず、プレフィックスに IP 番号の最後の二つが付いた形式になっています。
このような命名方法を用いればメンテナンスはとても楽になりますが、やや人
間との相性は悪いので、顧客をイライラさせる結果になってしまうかもしれま
せん。
funn.land-5.com も land-5.com のエイリアスになっていますが、これは
CNAME レコードではなく A レコードを用いています。先に述べたように、こ
れは良い方針です。
5.5. /var/named/zone/206.6.177
このファイルについては後でコメントします。
______________________________________________________________________
@ IN SOA land-5.com. root.land-5.com. (
199609206 ; Serial
28800 ; Refresh
7200 ; Retry
604800 ; Expire
86400) ; Minimum TTL
NS land-5.com.
NS ns2.psi.net.
;
; Servers
;
1 PTR router.land-5.com.
2 PTR land-5.com.
2 PTR funn.land-5.com.
;
; Workstations
;
200 PTR ws-177200.land-5.com.
201 PTR ws-177201.land-5.com.
202 PTR ws-177202.land-5.com.
203 PTR ws-177203.land-5.com.
204 PTR ws-177204.land-5.com.
205 PTR ws-177205.land-5.com.
; {Many repetitive definitions deleted - SNIP}
250 PTR ws-177250.land-5.com.
251 PTR ws-177251.land-5.com.
252 PTR ws-177252.land-5.com.
253 PTR ws-177253.land-5.com.
254 PTR ws-177254.land-5.com.
______________________________________________________________________
逆引きのゾーンは、設定の中でも多くの悲劇を引き起こす部分と言えます。こ
れはマシンの IP 番号がわかっている場合に、ホスト名を取得するために用い
られます。例えば、あなたが立てている IRC サーバが IRC クライアントから
接続されたとしましょう。しかしあなたの IRC サーバではノルウェー語が使
われているので、ノルウェーと他のスカンジナビアの国々以外からの接続はさ
せたくないとします。クライアントから接続されると、 C ライブラリによっ
て接続してきたマシンの IP 番号を知ることができます。なぜならクライアン
トの IP 番号は、ネットワークを運ばれてきた IP パケットのそれぞれに書き
込まれているからです。ここで gethostbyaddr という関数を呼べば、 IP 番
号からホストの名前を引くことができます。 gethostbyaddr は DNS サーバに
尋ね、 DNS サーバは DNS からそのマシンを探します。接続してきたクライア
ントは ws-177200.land-5.com だったとしてみましょう。 C ライブラリが
IRC サーバに渡す IP 番号は 206.6.177.200 となります。したがって名前を
引くためには 200.177.6.206.in-addr.arpa を見つける必要があります。 DNS
サーバはまず arpa. のサーバに問い合わせをし、 in-addr.arpa. のサーバを
教えてもらいます。続いて 206, 6 を順次逆に辿って、最後に Land-5 のゾー
ンである 177.6.206.in-addr.arpa ゾーンを発見します。最後にサーバは、そ
こから 200.177.6.206.in-addr.arpa に対する答えを入手します。 ``PTR
ws-177200.land-5.com'' レコードから、 206.6.177.200 は
ws-177200.land-5.com であることがわかります。なお以上の説明には、
prep.ai.mit.edu の名前引きの部分と同じように少々フィクションが入ってい
ます。
IRC サーバの例に戻りましょう。 IRC サーバはスカンジナビアの国々から、
つまり *.no, *.se, *.dk からしか接続を受け付けません。
ws-177200.land-5.com は明らかに以上のどれにもマッチしませんから、サー
バは接続を拒否します。 206.2.177.200 に対する逆引きマップがそもそも
in-addr.arpa ゾーンに存在しなければ、サーバは決して名前を見つけること
ができませんから、 206.2.177.200 そのものを *.no, *.se, *.dk と比較し
ます。もちろんマッチするわけがありません。
逆引きマップが重要なのはサーバだけだ、という人や、そもそも逆引きマップ
なんて全然大事じゃないんだ、なんていう人がいるかもしれません。これは間
違いです。多くの ftp, news, IRC サーバでは逆引きのできないマシンからの
接続を拒否します (WWW サーバにさえ拒否するものもあります)。ですからマ
シン名の逆引きマップは実のところは必須なのです。
6. メンテナンス
動作を維持するために
named には、ただ走らせる以外にも一つ保守作業があります。 root.hints
ファイルを最新の状態に保つ作業です。一番簡単なのは dig を使うやり方で
す。まず引き数なしで dig を動かすと、現在サーバで使っている root.hints
の内容が表示されます。次にリストされているルートサーバのいずれかに対し
て dig @rootserver のように問い合わせを行います。出力結果は root.hints
の内容にとっても似ていることでしょう。この結果を dig @e.root-
servers.net . ns > root.cache.new のように保存して、古い root.hints と
置き換えます。
キャッシュファイルを入れ替えた後には named の再実行をお忘れなく。
Al Longyear がスクリプトを送ってくれました。自動的に root.hints を更新
してくれるものです。これを月に一度起動する crontab のエントリをインス
トールすれば、後は全部おまかせです。スクリプトでは、メールがちゃんと動
作していて、メールエイリアスとして `hostmaster' が定義されていることを
前提としています。あなたの設定にあわせてハックする必要があります。
______________________________________________________________________
#!/bin/sh
#
# Update the nameserver cache information file once per month.
# This is run automatically by a cron entry.
#
# Original by Al Longyear
# Updated for bind 8 by Nicolai Langfeldt
# Miscelanious error-conditions reported by David A. Ranch
# Ping test suggested by Martin Foster
#
(
echo "To: hostmaster "
echo "From: system "
echo "Subject: Automatic update of the root.hints file"
echo
PATH=/sbin:/usr/sbin:/bin:/usr/bin:
export PATH
cd /var/named
# Are we online? Ping a server at your ISP
case `ping -qnc 1 some.machine.net` in
*'100% packet loss'*)
echo "The network is DOWN. root.hints NOT updated"
echo
exit 0
;;
esac
dig @e.root-servers.net . ns >root.hints.new 2>&1
case `cat root.hints.new` in
*NOERROR*)
# It worked
:;;
*)
echo "The root.hints file update has FAILED."
echo "This is the dig output reported:"
echo
cat root.hints.new
exit 0
;;
esac
echo "The root.hints file has been updated to contain the following
information:"
echo
cat root.hints.new
chown root.root root.hints.new
chmod 444 root.hints.new
rm -f root.hints.old
mv root.hints root.hints.old
mv root.hints.new root.hints
ndc restart
echo
echo "The nameserver has been restarted to ensure that the update is complete."
echo "The previous root.hints file is now called
/var/named/root.hints.old."
) 2>&1 | /usr/lib/sendmail -t
exit 0
______________________________________________________________________
root.hints は Internic から ftp でも入手できる、と言うことをすでにご存
じの方もいるかもしれません。ですが root.hints の更新に ftp は使わない
ようにしてください。上記の方法のほうが、ずっと「ネット (と Internic)
に優しい」のです。
7. バージョン 4 からバージョン 8 に更新する
この章はもともと David E. Smith (dave@bureau42.ml.org) が書いた、 bind
8 の利用に関する章でした。新しい章の名前に対応するように、少々編集しま
した。
実はあまりたいしたことはありません。 named.boot の代わりに named.conf
を用いることを除けば、すべてまったく同じです。 bind8 には perl スクリ
プトが付属してきて、古いスタイルのファイルを新しいものに変換してくれま
す。以下、キャッシュ専用のネームサーバに対する (古い形式の) named.boot
を示します。
______________________________________________________________________
directory /var/named
cache . root.hints
primary 0.0.127.IN-ADDR.ARPA 127.0.0.zone
primary localhost localhost.zone
______________________________________________________________________
bind8/src/bin/named ディレクトリで、コマンドラインから以下のように入力
します (ソース配布を仮定しています。バイナリパッケージには、このスクリ
プトは入っていないかもしれません。その場合どこから入手すればいいかは
ちょっとわかりません -ed.)。
______________________________________________________________________
./named-bootconf.pl < named.boot > named.conf
______________________________________________________________________
以下のような named.conf ができるはずです。
______________________________________________________________________
// generated by named-bootconf.pl
options {
directory "/var/named";
};
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "127.0.0.zone";
};
zone "localhost" {
type master;
file "localhost.zone";
};
______________________________________________________________________
これは named.boot ファイルでの動作をすべて受け継いでいるはずです。ただ
し bind8 で新たに拡張された設定オプションをすべて追加するわけではあり
ません。以下に、同じ動作をするが多少効率的になっている named.conf の完
全な例を示します。
______________________________________________________________________
// This is a configuration file for named (from BIND 8.1 or later).
// It would normally be installed as /etc/named.conf.
// The only change made from the `stock' named.conf (aside from this
// comment :) is that the directory line was uncommented, since I
// already had the zone files in /var/named.
options {
directory "/var/named";
datasize 20M;
};
zone "localhost" IN {
type master;
file "localhost.zone";
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "127.0.0.zone";
};
zone "." IN {
type hint;
file "root.hints";
};
______________________________________________________________________
bind 8 ディストリビューションの bind8/src/bin/named/test ディレクトリ
に、これと同じものがゾーンファイルの雛形と一緒に置かれています。ほとん
どの人はこれをコピーするだけですぐに使えるはずです。
ゾーンファイルと root.hints ファイルの書式はまったく同じです。これらを
更新するコマンドも同じです。
8. Q & A
私にメールする前に、まずこの章を読んでください。
1. 私の named では named.boot ファイルが必要と言われます
読んでいる HOWTO が間違っています。この HOWTO の古い版では bind 4
のことを扱っていますので、そちらを読んでください。
にあります。
2. ファイアウォールの中で DNS を使うには？
ヒント。 forward only;
___________________________________________________________________
query-source port 53;
___________________________________________________________________
が named.conf ファイルの ``options'' の部分に必要になるでしょう。
``キャッシュ専用のネームサーバ'' の節にある例でちょっと触れましたね。
3. DNS によって、あるサービスに対するアドレスを順繰りにまわす (round-
robin する) にはどうすれば良いですか？つまり例えば www.busy.site に
対する負荷を分散させるようにするにはどうすれば良いでしょうか。
www.busy.site に対する A レコードを複数用意して、 4.9.3 以降の bind
を用いましょう。 bind は回答を round-robin してくれます。古い版の
bind では、これは動作しません。
4. (クローズな) イントラネットで DNS を使いたいのです。どうすれば良い
ですか？
root.hints ファイルを使わないようにして、ゾーンファイルだけを使いま
しょう。 hint ファイルをいちいち更新する必要もないわけです。
5. セカンダリ (スレーブ) のネームサーバを設定するには？
プライマリ (マスタ) のサーバが、アドレス 127.0.0.1 だったとして、以
下のような行をセカンダリの named.conf に記述します。
___________________________________________________________________
zone "linux.bogus" {
type slave;
file "sz/linux.bogus";
masters { 127.0.0.1; };
};
___________________________________________________________________
zone 情報を取ってこれるマスタサーバが他にもある場合は、 masters リスト
に `;' (セミコロン) で区切って追加することもできます。
6. net から切断されているときにも bind を動作させておきたいんですが
これに関連した記事を 4 つ紹介しましょう。
o bind 8 に特化したやり方を Adam L Rice が電子メールで教えてくれまし
た。ダイアルアップのマシンで DNS を手間をかけずに動作させる方法で
す。
私は、最近のバージョンの BIND では、この [ファイルを切り替える, -ed]
がもう不必要であることに気がつきました。 "forwarders" 指定の他に
"forward" 指定が可能になっていて、後者で前者の使われ方を制御できる
ようになっていたんです。デフォルトの設定は "forward first" で、
最初にそれぞれの forwarders に問い合わせを行い、失敗した場合に
はじめて自分自身で聞き込み調査を始めます。これがラインが切れている
時に gethostbyname() にやたらと時間がかかってしまう、おなじみの
振る舞いです。しかし "forward only" を設定しておくと、 BIND は
forwarders から反応が帰ってこないとすぐにあきらめます。したがって
gethostbyname() も速やかに帰ってくることになります。ですから
巧みな技を使って /etc のファイルを切り替え、サーバを再起動する
必要はないのです。
私の場合では、以下の行を named.conf ファイルの options { }
セクションに追加するだけでした。
forward only;
forwarders { 193.133.58.5; };
とってもうまく動作してます。この方法のただ一つの欠点は、非常に
洗練された DNS ソフトウェアを、キャッシュ動作だけしかしない
単機能なソフトにしてしまう、ということです。ただ DNS キャッシュ
だけをするソフトがあれば私は実はそっちを使いたいんですけど、
Linux ではそのようなソフトはないみたいですね。
o 以下の記事は Ian Clard からもらったメールです。
彼のやり方を説明してくれています。
IP マスカレードをさせている手元のマシンで named を走らせています。
root.hints ファイルを二つ用意します。一つは root.hints.real で、
本物の root サーバの名前が書かれています。もう一つは
root.hints.fake で、その内容は...
----
; root.hints.fake
; this file contains no information
----
です。切断するときには root.hints.fake ファイルを root.hints に
コピーして named を再起動します。
接続するときには root.hints.real ファイルを root.hints にコピー
して named を再起動します。
これらは ip-down と ip-up でそれぞれ自動実行させています。
オフラインの時にドメイン名に対する問い合わせを行うと、 named は
それらに付いて知りませんから、以下のようなエントリを messages に
出力します。
Jan 28 20:10:11 hazchem named[10147]: No root nameserver for class IN
これは気にしなくてもかまいません。
私のところではこれで全く問題なく動作しています。ネットから切断
されているときは、ローカルマシンのネームサーバを外部のドメイン名に
対するタイムアウトの待ち時間なしで使えますし、接続されているとき
には外部のドメインに対する問い合わせを普通に行うことができています。
o 切断されている時間の長いマシンにおいて、 bind が NFS やポートマッパ
とどのように相互作用するのかに関する情報もいただきました。 Karl-Max
Wanger からです。
インターネットに対してモデム経由でたまにしか接続しないマシンには、
私はすべて named を走らせていました。ネームサーバはキャッシュと
してのみ動作し、 authority をもつ zone は保有せず、すべてを
root.cache ファイルに書かれたネームサーバに問い合わせに行く設定に
していました。 Slackware の流儀に従い、named は nfsd や mountd の
前に起動していました。
マシンのうちの一つ (Libretto 30 notebook) で、問題が起こりました。
私のローカルな LAN につながっている他のマシンから、そのマシンを
mount できなくなってしまうのです (ごくたまにできる時もありますが)。
これは接続形式に依存せず、 PLIP でも PCMCIA のイーサネットカードでも、
シリアル経由の PPP でも同じように起こりました。
しばらく実験と考察を行った後、以下のような結論に達しました。
nfsd と mountd が起動時に portmapper に対して行った登録動作
(私はこれらのデーモンを、通常通りブート時にスタートしていました)
を、 named はめちゃめちゃにしてしまうのです。 named の起動を
nfsd と mountd のあとに行うようにしたところ、この問題は完全に
解決しました。
ブートの順序をこのように変更することによる不利はまったくありません
から、潜在的な問題を避けるために、このようにすることをすべての
皆さんにお薦めしたいと思います。
o 最後に。この件に関する HOWTO 情報が Ask Mr. DNS
にあります。これは
bind 4 を対象にしていますので、内容を適宜 bind 8 向けに読み替える必
要があります。
7. キャッシュネームサーバはどこにキャッシュを保存しているの？キャッ
シュのサイズは制御できますか？
キャッシュはすべてメモリに保管されています。ディスクに書き込まれる
ことはまったくありません。 named を kill すると、キャッシュも失われ
ます。キャッシュをコントロールする方法はありません。 named のキャッ
シュ管理は単純なルールに従っているからです。キャッシュそのものも、
あるいはキャッシュのサイズも、どんな理由があれコントロールすること
はできません。この点を「修正」したければ named をハックしても良いで
しょう。おすすめはできませんが。
8. named は再起動されるときにキャッシュを保存してくれますか？保存する
ようにできますか？
いいえ、 named は終了時にキャッシュを保存しません。つまり named を
kill して再起動するたびに、キャッシュはゼロから再構成されます。
キャッシュをファイルに保存するように named に指示する方法はないので
す。この点を「修正」したければ named をハックしても良いでしょう。お
すすめはできませんが。
9. ドメインを手に入れるにはどうすればいいですか？私は (例えば) linux-
rules.net というドメインを立ち上げたいのですが、このドメインを割り
当ててもらうにはどうすればいいのでしょうか。
ネットワークサービスプロバイダに連絡してみれば、おそらく助けてもら
えるでしょう。なお世界のほとんどの地域では、ドメインの入手にはお金
が必要であるはずですので念のため。
9. より熟練した DNS 管理者になるために
文献とツール
しっかりした文献もちゃんと存在していて、オンラインのものと印刷されてい
るものとがそれぞれあります。即席 DNS 管理者が熟練した DNS 管理者になる
ためのステップを踏むには、この中のいくつかを読むことが必要です。印刷さ
れた書籍としては、 DNS and BIND ( C. Liu and P. Albitz, O'Reilly &
Associates, Sebastopol, CA, ISBN 0-937175-82-X) がスタンダードです。私
も読みました。非常にすぐれた本です。 bind 4 ベースなのが残念ですが、本
質的な問題ではないでしょう。 TCP/IP Network Administration (Craig
Hunt, O'Reilly..., ISBN 0-937175-82-X) にも DNS の章があります。良い
DNS (やその他の) 管理者になるためには Zen and the Art of Motorcycle
Maintenance (Robert M. Prisig :-), ISBN 0688052304) も必須でしょう。他
にもまだあるかもしれません。
訳注: 最初の二冊には訳本もあります。それぞれ DNS & BIND 第3版 (オライ
リー・ジャパン, ISBN4-900900-91-5)、 TCP/IP ネットワーク管理 (オーム
社, ISBN4-900718-01-7) です。なお DNS & BIND の 3版では bind 8 が対象
となっています。
オンラインでは DNS Resources Directory や
でいろいろ見つかります。 FAQ、リファレ
ンスマニュアル (BOG; Bind Operations Guide)、にも論文やプロトコル定義
や DNS の実装ハックもあります。上記や、以下に示す RFC のほとんど
は、bind の配布の中に含まれています。私はこのあたりをしっかり読んでい
ません。ですので、習熟した DNS 管理者ではありません。一方 Arnt
Gulbrandsen は BOG をすでに読んでおり、それに夢中になっています :-)。
ニュースグループ comp.protocols.tcp-ip.domains では DNS の議論をしてい
ます。また DNS に関する RFC もたくさん存在しています。中でも重要なもの
を以下に挙げておきます。
RFC 2052
A. Gulbrandsen, P. Vixie, A DNS RR for specifying the location
of services (DNS SRV), October 1996
RFC 1918
Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear,
Address Allocation for Private Internets, 02/29/1996.
RFC 1912
D. Barr, Common DNS Operational and Configuration Errors,
02/28/1996.
RFC 1912 Errors
B. Barr Errors in RFC 1912, this is available at
RFC 1713
A. Romao, Tools for DNS debugging, 11/03/1994.
RFC 1712
C. Farrell, M. Schulze, S. Pleitner, D. Baldoni, DNS Encoding of
Geographical Location, 11/01/1994.
RFC 1183
R. Ullmann, P. Mockapetris, L. Mamakos, C. Everhart, New DNS RR
Definitions, 10/08/1990.
RFC 1035
P. Mockapetris, Domain names - implementation and specification,
11/01/1987.
RFC 1034
P. Mockapetris, Domain names - concepts and facilities,
11/01/1987.
RFC 1033
M. Lottor, Domain administrators operations guide, 11/01/1987.
RFC 1032
M. Stahl, Domain administrators guide, 11/01/1987.
RFC 974
C. Partridge, Mail routing and the domain system, 01/01/1986.