DNS HOWTO
Nicolai Langfeldt (janl@linpro.no), Jamie Norrish and others
Version 3.1, 2001-01-18
中野武雄 nakano@apm.seikei.ac.jp
v3.1j1, 2001-01-31
短い時間で DNS 管理者になる方法。
______________________________________________________________________
目次
1. 前書き
1.1 法的なこと
1.2 謝辞とヘルプ募集
1.3 献辞
2. はじめに
3. 名前解決とキャッシュを行うネームサーバ
3.1 named を起動する
3.2 レゾルバ
3.3 おめでとう
4. フォワード (forwarding)
5. 単純なドメイン
5.1 でもまず最初に退屈な理論
5.2 自分のドメインを作る
5.3 逆引きゾーン
5.4 気をつけてほしいこと
5.5 なぜ逆引きが動作しないのか
5.5.1 逆引きゾーンが代理されない
5.5.2 クラスレス (classless) のサブネットをもらった場合
5.6 スレーブサーバ
6. 基本的なセキュリティオプション
6.1 ゾーン転送の制限
6.2 不正利用から守る
6.3 named を root 以外で実行する
7. 実際のドメインの例
7.1 /etc/named.conf (または /var/named/named.conf)
7.2 /var/named/root.hints
7.3 /var/named/zone/127.0.0
7.4 /var/named/zone/land-5.com
7.5 /var/named/zone/206.6.177
8. メンテナンス
9. バージョン 4 からバージョン 8 に更新する
10. Q & A
11. より熟練した DNS 管理者になるために
______________________________________________________________________
1. 前書き
Keywords: DNS, BIND, BIND 4, BIND 8, named, dialup, PPP, slip, ISDN,
Internet, domain, name, resolution, hosts, caching.
この文書は Linux Documentation Project の一部です。 (訳注: 翻訳版は
Japanese FAQ Project の一部です)
1.1. 法的なこと
(C)opyright 1995-2001 Nicolai Langfeldt, Jamie Norrish & Co. Do not
modify without amending copyright, distribute freely but retain
copyright message.
この文書の著作権は (C)opyright 1995-2000 Nicolai Langfeldt, Jamie
Norrish & Co. にあります。この文書を修正する場合は著作権表示にもその旨
明記して下さい。著作宣言を変更しなければ自由に再配布することができま
す。
訳注：翻訳は中野武雄が行いました。(C)opyright 1998-2000 Takeo Nakano
1.2. 謝辞とヘルプ募集
本文書のドラフト版を苦労して読んでいただき、たくさんの有益な提案をして
くださった Arnt Gulbrandsen に感謝します。また電子メールで提案や情報を
送ってくれたたくさんの方々にも感謝します。
この文書はまだ完成したものではありません。この文書をより良い物にするた
めに、問題点や成功例などについて筆者にメールを送って下さい。コメント・
質問、現金などは janl@math.uio.no まで。あるいは私の DNS 本を買ってく
ださい。本に関する情報は参考文献を見てください。メールを送り、返信を希
望する場合には、返信先のアドレスが正しいか、またちゃんと機能しているか
どうかを確認して下さるようにお願いします。またメールする前には必ず ``Q
& A'' のセクションを読んでください。なお、私が読めるのはノルウェー語と
英語に限られます。
これは HOWTO 文書です。私は 1995 年から、この文書を LDP の一部として管
理してきました。 2000 年に、私はこのトピックに関する書籍を書きました。
お断りしておきたいのですが、この HOWTO はいろいろな点でその本と似てい
ますけれども、本の売り上げを伸ばすためにこの HOWTO で手抜きをしたよう
なことはありません。でも、本の情報は末尾の参考文献に載せておきました。
この HOWTO の読者は、DNS の理解がいかに難しいものであるかを私に教えて
くださいました。それによってこの本は良いものになりましたし、また一方本
を書くことで、この HOWTO に何が必要なのかを考えさせられることにもなり
ました。この HOWTO がその本を産み、またその本がこの HOWTO の第三版を産
むことになりました。このチャンスを私に下さったことに対して、出版社の
Que に感謝します :-)
訳注: この文書の 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 文書で
は、Unix システムを用いてこのようなマップを定義する方法について記述し
ます。なお Linux に特有なことがらもいくつか含まれています。
ここでの「マップ」とは、単に二つのものを結びつけることです。この場合な
ら ftp.linux.org といったようなマシンの名前と、そのマシンの IP 番号
(IP アドレス) である 199.249.150.4 のような値を結びつけることになりま
す。 DNS には逆向きのマップも含まれます。すなわち、IP 番号からマシンの
名前への変換です。これは「逆引き」といわれています。
初心者 (あなた ;-) にとって DNS は、ネットワーク管理のなかでもわかりに
くい部分の一つです。幸い DNS は実際にはそれほど難しくはありません。こ
の HOWTO では、いくつかの事柄を多少なりともわかるようにしたいと思って
います。簡単な DNS ネームサーバを設定する方法も説明します。まずキャッ
シュ専用のサーバからはじめて、あるドメインに対するプライマリ DNS サー
バを設定していきます。もっと複雑な設定を行なう場合には、この文書の ``Q
& A'' の章を参照してください。そこにも書いていなかったら、もっとちゃん
とした文献を読む必要があるでしょう。「ちゃんとした文献」については、
``より熟練した管理者になるために'' の章で説明します。
DNS についての作業を始める前に、あなたのマシンを設定して、 telnet での
出入りやネットへの各種接続ができるようにしておいてください。特に
telnet 127.0.0.1 で、現在のマシン自身にログインできるようにしてくださ
い (今すぐテスト!)。また /etc/nsswitch.conf (あるいは
/etc/host.conf)、 /etc/resolv.conf、 /etc/hosts などのファイルに対し
て、正しい設定をしておいてください。これらの機能についてはこの文書では
説明しません。以上の準備ができていない場合は、 Networking-HOWTO や
Networking-Overview-HOWTO に説明がありますから、ちゃんと読んで設定して
おいてください。
この文書で「あなたのマシン」と書いてあった場合、それは DNS を動作させ
ようとしているマシンを指すものとします。他にもネットワークにつながって
いるあなたのマシンはあるでしょうけど、それのことではありません。
あなたのマシンが所属しているネットワークには、名前引きをブロックするよ
うな防火壁 (ファイアウォール) は存在しないものとします。ファイアウォー
ル内部にいる場合には特別な設定が必要になります。 ``Q & A'' の章を見て
ください。
UNIX システムでの名前引きのサービスは named と呼ばれるプログラムによっ
て実現されます。これは Internet Software Consortium の ``BIND'' パッケ
ージに含まれるプログラムです。 named は、ほとんどの Linux ディストリ
ビューションに含まれています。たいていは BIND という名前のパッケージに
入っていて、 /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 です。セキュリティに気を使わなければならない人で、 4 を使っ
ている場合は、最新の BIND 8 にアップグレードするべきでしょう。今すぐ
に、です。
(訳注) 最後はちょっと意見の分かれるところかも知れません。例えばソース
レベルでのセキュリティチェックを行っていることで知られる OpenBSD で
は、まだ依然として BIND 4 が現役の named だったりします。
DNS はネットワーク全体に広がるデータベースです。データの登録は慎重に行
ないましょう。変な内容を登録すると、あなたも他の人達も迷惑します。真面
目にちゃんと運用すれば、 DNS は恩恵をもたらしてくれるはずです。 DNS の
使い方、管理の仕方、デバッグのやりかたを学び、良い管理者になってくださ
い。設定ミスでネットを落としたりすることがないようにしましょうね。
注意: 私が変更するように指示したファイルがすでに存在していたら、これら
のバックアップを取っておきましょう。作業の結果がうまくいかなかった場合
に、元の動いている状態に戻すことができるようにするためです。
3. 名前解決とキャッシュを行うネームサーバ
DNS 設定の最初の一歩。ダイアルアップ・ケーブルモデム・ADSL ユーザには
とっても便利です。
Red Hat や、Red Hat に関連したディストリビューションでは、 bind パッケ
ージ・bind-utils パッケージ・ caching-nameserver パッケージをインスト
ールするだけで、この HOWTO の最初のセクションの結果と同じものが得られ
ます。 Debian を使っているなら bind と bind-doc をインストールするだけ
です。もちろんこれらのパッケージをインストールするだけでは、この HOWTO
を読むことによって得られる知識は手に入りません。ですので、まずパッケー
ジをインストールし、そこでインストールされたファイルを調べながら、読み
進んでいくのが良いでしょう。
キャッシュ専用のネームサーバとは、名前引きの結果を記憶しておき、次回の
問い合わせの時にその記憶を使って答えるものです。次回からの問い合わせに
対する応答は (特に遅い回線を使っている場合には) とても速くなります。
まず最初に /etc/named.conf というファイルが必要です (Debian では
/etc/bind/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. But you probably
// need to talk to your firewall admin.
// query-source port 53;
};
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};
______________________________________________________________________
Linux ディストリビューションのパッケージでは、ここで紹介するそれぞれの
ファイルに、別の名前をつけているかもしれません。でも内容は同じはずで
す。
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 M.ROOT-SERVERS.NET.
. 6D IN NS I.ROOT-SERVERS.NET.
. 6D IN NS E.ROOT-SERVERS.NET.
. 6D IN NS D.ROOT-SERVERS.NET.
. 6D IN NS A.ROOT-SERVERS.NET.
. 6D IN NS H.ROOT-SERVERS.NET.
. 6D IN NS C.ROOT-SERVERS.NET.
. 6D IN NS G.ROOT-SERVERS.NET.
. 6D IN NS F.ROOT-SERVERS.NET.
. 6D IN NS B.ROOT-SERVERS.NET.
. 6D IN NS J.ROOT-SERVERS.NET.
. 6D IN NS K.ROOT-SERVERS.NET.
. 6D IN NS L.ROOT-SERVERS.NET.
;
M.ROOT-SERVERS.NET. 6D IN A 202.12.27.33
I.ROOT-SERVERS.NET. 6D IN A 192.36.148.17
E.ROOT-SERVERS.NET. 6D IN A 192.203.230.10
D.ROOT-SERVERS.NET. 6D IN A 128.8.10.90
A.ROOT-SERVERS.NET. 6D IN A 198.41.0.4
H.ROOT-SERVERS.NET. 6D IN A 128.63.2.53
C.ROOT-SERVERS.NET. 6D IN A 192.33.4.12
G.ROOT-SERVERS.NET. 6D IN A 192.112.36.4
F.ROOT-SERVERS.NET. 6D IN A 192.5.5.241
B.ROOT-SERVERS.NET. 6D IN A 128.9.0.107
J.ROOT-SERVERS.NET. 6D IN A 198.41.0.10
K.ROOT-SERVERS.NET. 6D IN A 193.0.14.129
L.ROOT-SERVERS.NET. 6D IN A 198.32.64.12
______________________________________________________________________
このファイルには世界中のルートネームサーバを記述します。これは時間とと
もに変化していくので、ときどき更新する必要があります。更新の方法は
``メンテナンス'' の章を見てください。
named.conf の次のセクションは最後の zone です。この利用法については後
の章で述べるつもりですので、今のところは以下のような内容のファイルを
pz サブディレクトリに 127.0.0 という名前で作っておいてください。 (ここ
でもカットアンドペーストするときには先頭のスペースを取り除くようにして
ください)
______________________________________________________________________
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
1 ; Serial
8H ; Refresh
2H ; Retry
4W ; 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 はこのファイルを参照しません。参照するのはレゾルバです。
注2: resolv.conf ファイルiには "domain" と書かれた行があるかもしれませ
ん。問題ありませんが、"search" と "domain" の両方を同時には用いないよ
うにしてください。どちらかしか効力を持ちません。)
このファイルの意味を説明しましょう。クライアントが foo の名前引きを行
うと、まず最初に foo.subdomain.your-domain.edu を調べ、次に foo.your-
domain.edu を試し、最後に foo を調べます。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
______________________________________________________________________
もちろん実際には本当のドメイン名を書く必要があります。ドメイン名の最後
にはピリオドを書かないことに注意してください。これは重要なポイントで
す。ドメイン名の最後にはピリオドを書かないことに注意してください。
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 とします) 、以下のような出力が表示されるは
ずです:
(\ で終わっている行は、次の行に続いていることを表します)
Dec 15 23:53:29 localhost named[3768]: starting. named 8.2.2-P7 \
Fri Nov 10 04:50:23 EST 2000 ^Iprospector@porky.\
devel.redhat.com:/usr/src/bs/BUILD/bind-8.2.2_P7/\
src/bin/named
Dec 15 23:53:29 localhost named[3768]: hint zone "" (IN) loaded\
(serial 0)
Dec 15 23:53:29 localhost named[3768]: Zone "0.0.127.in-addr.arpa"\
(file pz/127.0.0): No default TTL set using SOA\
minimum instead
Dec 15 23:53:29 localhost named[3768]: master zone\
"0.0.127.in-addr.arpa" (IN) loaded (serial 1)
Dec 15 23:53:29 localhost named[3768]: listening on [127.0.0.1].53 (lo)
Dec 15 23:53:29 localhost named[3768]: listening on [10.0.0.129].53\
(wvlan0)
Dec 15 23:53:29 localhost named[3768]: Forwarding source address is\
[0.0.0.0].1034
Dec 15 23:53:29 localhost named[3769]: Ready to answer queries.
エラーメッセージがあった場合は、何か間違えているのでしょう。 named は
その間違っているファイルを名指ししてくれるはずです。戻ってファイルを
チェックしてください。修正が終わったら "ndc restart" を実行しましょ
う。
さて、ここまで行ってきた設定を試してみましょう。これまでは nslookup が
テストのためのプログラムでした。最近では dig が推奨されています。
$ dig -x 127.0.0.1
; <<>> DiG 8.2 <<>> -x
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;; 1.0.0.127.in-addr.arpa, type = ANY, class = IN
;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 1D IN PTR localhost.
;; AUTHORITY SECTION:
0.0.127.in-addr.arpa. 1D IN NS ns.penguin.bv.
;; Total query time: 30 msec
;; FROM: lookfar to SERVER: default -- 127.0.0.1
;; WHEN: Sat Dec 16 00:16:12 2000
;; MSG SIZE sent: 40 rcvd: 110
と表示されれば、うまく動いているはずです。こうなるといいですね。何か他
の表示が出たら、やり直し、全部再チェックです。 named.conf を変更した
ら、そのたびに ndc restart コマンドで named を再起動する必要がありま
す。
では問い合わせをしてみましょう。あなたの近くにあるマシンの名前を引いて
みましょう。私の近く (Oslo 大学) には pat.uio.noというマシンがありま
す。
$ dig pat.uio.no
; <<>> DiG 8.2 <<>> pat.uio.no
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUERY SECTION:
;; pat.uio.no, type = A, class = IN
;; ANSWER SECTION:
pat.uio.no. 1D IN A 129.240.130.16
;; AUTHORITY SECTION:
uio.no. 1D IN NS nissen.uio.no.
uio.no. 1D IN NS ifi.uio.no.
uio.no. 1D IN NS nn.uninett.no.
;; ADDITIONAL SECTION:
nissen.uio.no. 1D IN A 129.240.2.3
ifi.uio.no. 1H IN A 129.240.64.2
nn.uninett.no. 1D IN A 158.38.0.181
;; Total query time: 112 msec
;; FROM: lookfar to SERVER: default -- 127.0.0.1
;; WHEN: Sat Dec 16 00:23:07 2000
;; MSG SIZE sent: 28 rcvd: 162
今度は、dig はあなたのマシンで動いている named に pat.uio.no を探すよ
う依頼します。すると named は root.hints ファイルに書かれているネーム
サーバの一つに接続して、問い合わせをします。 /etc/resolv.conf に書かれ
ているドメインすべてについて調べる必要があるかもしれないので、結果が得
られるまでに少々時間がかかることがあります。 "flags" 行の "aa" に注目
してください。これは結果が「信頼できる (authoritative)」ことを示してい
ます。つまり、信頼できるサーバからの最新の結果である、と言うことです。
なにが「信頼できる」のかはのちほど説明します。
ここでもう一度同じ問い合わせを行うと、次のような結果になるでしょう。
$ dig pat.uio.no
; <<>> DiG 8.2 <<>> pat.uio.no
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUERY SECTION:
;; pat.uio.no, type = A, class = IN
;; ANSWER SECTION:
pat.uio.no. 23h59m58s IN A 129.240.130.16
;; AUTHORITY SECTION:
UIO.NO. 23h59m58s IN NS nissen.UIO.NO.
UIO.NO. 23h59m58s IN NS ifi.UIO.NO.
UIO.NO. 23h59m58s IN NS nn.uninett.NO.
;; ADDITIONAL SECTION:
nissen.UIO.NO. 23h59m58s IN A 129.240.2.3
ifi.UIO.NO. 1d23h59m58s IN A 129.240.64.2
nn.uninett.NO. 1d23h59m58s IN A 158.38.0.181
;; Total query time: 4 msec
;; FROM: lookfar to SERVER: default -- 127.0.0.1
;; WHEN: Sat Dec 16 00:23:09 2000
;; MSG SIZE sent: 28 rcvd: 162
今度は結果に "aa" フラグがないことにご注目ください。これが意味するの
は、今回この情報はすでにキャッシュに入っていたので、 named はネットワ
ーク経由で調べたのではない、ということです。でもキャッシュの情報はもし
かすると古いことがあるかもしれません。ですからここでは "aa" を置かない
ことで、この (ほんのわずかな) 可能性を知らされたわけです。でも逆に、
キャッシュが正しく動作していることがわかったことにもなります。
3.2. レゾルバ
標準的な C API を実装しているすべての OS には、 gethostbyname と
gethostbyaddr というシステムコールが存在します。これらは何種類かの異な
る情報源から情報を取得できます。どの情報源から取得するかは、Linux なら
/etc/nsswitch.conf というファイルで設定できます (これを用いている Unix
は他にもあります)。これは長いファイルで、どのファイルから、あるいはど
のデータベースから、いろいろな種類のデータを取得するかを指定します。通
常は先頭にコメント形式の解説がありますので、読んでおきましょう。読み終
わったら `hosts:' ではじまる行を探してください。以下のようになっている
はずです。
______________________________________________________________________
hosts: files dns
______________________________________________________________________
(先頭のスペースのことは覚えていますね？これ以上はもう言及しません。)
`hosts:' ではじまる行が無ければ、上記のような内容を書いておいてくださ
い。これは、プログラムはまず /etc/hosts ファイルを見に行き、次に DNS
を resolv.conf にしたがってチェックせよ、と言っています。
3.3. おめでとう
さて、今やあなたはキャッシュ動作をする named の設定方法を知ったわけで
す。ビールでもミルクでも、お好きなもので乾杯しましょう。
4. フォワード (forwarding)
学術機関や 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'' の章に書いてあります。
ネームサーバを再起動して、dig でテストしてください。うまくいっていると
思います。
5. 単純な ドメイン
あなた自身のドメインの設定方法
5.1. でもまず最初に退屈な理論
まず最初に: ここまでの内容はちゃんと読みましたか？読んでなければ読むよ
うに。
このセクションを実際に始める前に、DNS の動作に関する理論を少々と、実際
の動作例を紹介しておきます。きっと役に立ちますから、ぜひ読みましょう。
読みたくなくても、少なくとも流し読みくらいはしておいてください。
named.conf ファイルの設定に関する部分まできたら流し読みはストップで
す。
DNS は階層的なツリー構造のシステムです。その頂点は `.' と記述され、
(ツリー型データ構造での慣例に従い) 「ルート (root)」と発音されます。
`.' の下にはたくさんの Top Level Domain (TLD) があります。 ORG, COM,
EDU, NET などが有名ですが、他にもたくさんあります。実際の木と同じよう
に、このツリー構造は根を持ち、枝分かれします。計算機科学の知識がある人
には、 DNS は検索ツリーに見えるでしょう。またそこには節点 (node)、端点
(leaf node)、枝 (edge) があることも見て取れるでしょう。
マシンの検索を行うとき、問い合わせはルートから始まる階層に対して再帰的
に行われます。あなたがホスト prep.ai.mit.edu. のアドレスを問い合わせる
と、あなたのネームサーバは、まずどこかに問合わせをしなければなりませ
ん。まずキャッシュにないかどうか探します。もし以前の問合わせがキャッ
シュに残っていて、答を知っていた場合には、直前のセクションにあったよう
に、ただちに答を返します。キャッシュに答がなかった場合は、名前の左側の
部分を消していき、自分が ai.mit.edu., mit.edu., edu. について知ってい
るかチェックしていきます。これらを知らないと . に行くわけですが、この
答は hints ファイルに書いてあるので、見つかります。ここであなたのネー
ムサーバは . のサーバに prep.ai.mit.edu に関する問い合わせを行います。
この . サーバは直接の答は知らないでしょうが、あなたのサーバに参照先を
提示し、次にどこに聞けばいいかを教えてくれます。この参照先提示は同じよ
うに次々に行われ、あなたのネームサーバは答を知っているネームサーバにま
で導かれます。これをいまからお見せしましょう。 +norec で dig に再帰的
な問合わせをしないように命じ、再帰を我々自身で行うことにします。その他
のオプションは、dig に生成する情報を減らすように命じるもので、紙幅を節
約します。
$ dig +norec +noH +noques +nostats +nocmd prep.ai.mit.edu.
;; res options: init defnam dnsrch
;; got answer:
; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 13
;; AUTHORITY SECTION:
. 5d23h48m47s IN NS I.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS E.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS D.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS A.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS H.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS C.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS G.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS F.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS B.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS J.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS K.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS L.ROOT-SERVERS.NET.
. 5d23h48m47s IN NS M.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
I.ROOT-SERVERS.NET. 6d23h48m47s IN A 192.36.148.17
E.ROOT-SERVERS.NET. 6d23h48m47s IN A 192.203.230.10
D.ROOT-SERVERS.NET. 6d23h48m47s IN A 128.8.10.90
A.ROOT-SERVERS.NET. 6d23h48m47s IN A 198.41.0.4
H.ROOT-SERVERS.NET. 6d23h48m47s IN A 128.63.2.53
C.ROOT-SERVERS.NET. 6d23h48m47s IN A 192.33.4.12
G.ROOT-SERVERS.NET. 6d23h48m47s IN A 192.112.36.4
F.ROOT-SERVERS.NET. 6d23h48m47s IN A 192.5.5.241
B.ROOT-SERVERS.NET. 6d23h48m47s IN A 128.9.0.107
J.ROOT-SERVERS.NET. 6d23h48m47s IN A 198.41.0.10
K.ROOT-SERVERS.NET. 6d23h48m47s IN A 193.0.14.129
L.ROOT-SERVERS.NET. 6d23h48m47s IN A 198.32.64.12
M.ROOT-SERVERS.NET. 6d23h48m47s IN A 202.12.27.33
これは参照先の提示です。ここには "Authority section" しかなく、"Answer
section" がありません。私たちの立てたネームサーバは、私たちをこのネー
ムサーバのどれかに指し向けます。どれかひとつをランダムに選んでみましょ
う。
$ dig +norec +noH +noques +nostats +nocmd prep.ai.mit.edu. @H.ROOT-SERVERS.NET.
; (1 server found)
;; res options: init defnam dnsrch
;; got answer:
; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
;; AUTHORITY SECTION:
MIT.EDU. 2D IN NS BITSY.MIT.EDU.
MIT.EDU. 2D IN NS STRAWB.MIT.EDU.
MIT.EDU. 2D IN NS W20NS.MIT.EDU.
;; ADDITIONAL SECTION:
BITSY.MIT.EDU. 2D IN A 18.72.0.3
STRAWB.MIT.EDU. 2D IN A 18.71.0.151
W20NS.MIT.EDU. 2D IN A 18.70.0.160
MIT.EDU のサーバ群がいっぺんに提示されました。ではまたどれかをランダム
に選びましょう。
$ dig +norec +noH +noques +nostats +nocmd prep.ai.mit.edu. @bitsy.mit.edu
; (1 server found)
;; res options: init defnam dnsrch
;; got answer:
; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; ANSWER SECTION:
prep.ai.mit.edu. 3h50m7s IN A 198.186.203.18
;; AUTHORITY SECTION:
AI.MIT.EDU. 6H IN NS FEDEX.AI.MIT.EDU.
AI.MIT.EDU. 6H IN NS LIFE.AI.MIT.EDU.
AI.MIT.EDU. 6H IN NS ALPHA-BITS.AI.MIT.EDU.
AI.MIT.EDU. 6H IN NS BEET-CHEX.AI.MIT.EDU.
;; ADDITIONAL SECTION:
FEDEX.AI.MIT.EDU. 6H IN A 192.148.252.43
LIFE.AI.MIT.EDU. 6H IN A 128.52.32.80
ALPHA-BITS.AI.MIT.EDU. 6H IN A 128.52.32.5
BEET-CHEX.AI.MIT.EDU. 6H IN A 128.52.32.22
今度は "ANSWER SECTION" がありました。そして私たちの知りたかった答も見
つかりました。 "AUTHORITY SECTION" には、次に ai.mit.edu に尋ねる際に
はどのサーバにすべきか、に関する情報が含まれています。したがって次に
ai.mit.edu の名前について知りたいときには、これらに直接聞けば良いわけ
です。
というわけで、. からスタートし、参照先提示を辿ることで、ドメイン名の各
レベルにおけるネームサーバを次々に見つけることができました。自前の DNS
サーバがあれば、これらの他のネームサーバを使わなくても、あなたの named
は、このように掘っていく段階で見つけた情報をすべてキャッシュし、しばら
くは再び尋ねなくても良いようにしてくれます。
ツリーとのアナロジーでいうと、名前の各 ``.'' は枝分かれのポイントに対
応します。そして ``.'' に挟まれた部分はツリー中でのそれぞれの枝の名前
になります。欲しい名前 (prep.ai.it.edu) の名前を得るには、このツリーを
昇っていくことになります。 root (.) や、root から prep.ai.mit.edu に至
る途中のあらゆるサーバに情報を問い合わせ、それらをキャッシュします。
キャッシュの制限に達すると、再帰的なレゾルバはそのサーバへの問合わせを
やめ、そこで参照提示された、名前の端のほうにある次のサーバへと進んでい
きます。
いままでほとんど触れませんでしたが、同じくらい非常に重要なドメインとし
て in-addr.arpa があります。これは「普通の」ドメインのようにネストもし
ます。 in-addr.arpa によって、アドレスがわかっている場合にホスト名を得
ることができるようになります。ここで重要なのは、 IP 番号は in-
addr.arpa ドメインでは逆順に記述されることです。あるマシンのアドレス
192.148.52.43 がわかっていた場合、 named は 先程の prep.ai.mit.edu の
例と同じように動作します: 最初に arpa. のサーバを見つけます。次に in-
addr.arpa. のサーバ、 192.in-addr.arpa. のサーバ、 148.192.in-
addr.arpa. のサーバ、 52.148.192.in-addr.arpa. のサーバを見つけます。
そして必要な 43.52.148.192.in-addr.arpa. に対応するレコードを見つけま
す。賢いでしょ？ (でしょ？) ただし番号の逆転には、慣れるまで何年かかか
るかもしれませんけどね。
5.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 に保存されることなどがわかります。こ
のファイルはすでに設定済みで、以下のような内容のはずです。
______________________________________________________________________
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
1 ; Serial
8H ; Refresh
2H ; Retry
4W ; 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 (Domain Name Pointer) レコードが、サブネット 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 の値をそのまま使えば特に問題ないでしょう。 SOA の前には必須の
行、$TTL 3D と書かれた行があります。これはすべてのゾーンファイルに書い
てください。
さて、ここで named を再起動して (コマンドは ndc restart です)、 dig コ
マンドを使って今までの設定の確認を行いましょう。 -x で逆引きの問合わせ
を行います。
$ dig -x 127.0.0.1
; <<>> DiG 8.2 <<>> -x
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUERY SECTION:
;; 1.0.0.127.in-addr.arpa, type = ANY, class = IN
;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 1D IN PTR localhost.
;; AUTHORITY SECTION:
0.0.127.in-addr.arpa. 1D IN NS ns.penguin.bv.
;; Total query time: 5 msec
;; FROM: lookfar to SERVER: default -- 127.0.0.1
;; WHEN: Sat Dec 16 01:13:48 2000
;; MSG SIZE sent: 40 rcvd: 110
なんとか 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
;
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, todays date + todays serial #
8H ; refresh, seconds
2H ; retry, seconds
4W ; 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 を再起動しましょう。ここまでの設定を dig
で確認しましょう。
$ dig any linux.bogus +pfmin
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23499
;; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1
;; QUERY SECTION:
;; linux.bogus, type = ANY, class = IN
;; ANSWER SECTION:
linux.bogus. 3D IN MX 10 mail.linux.bogus.linux.bogus.
linux.bogus. 3D IN MX 20 mail.friend.bogus.
linux.bogus. 3D IN NS ns.linux.bogus.
linux.bogus. 3D IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial
8H ; refresh
2H ; retry
4W ; expiry
1D ) ; minimum
よく見ると、バグがあることがわかると思います。
linux.bogus. 3D IN MX 10 mail.linux.bogus.linux.bogus.
というのは全くおかしいですね。これは、
linux.bogus. 3D IN MX 10 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
;
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, todays date + todays serial #
8H ; refresh, seconds
2H ; retry, seconds
4W ; 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"
______________________________________________________________________
ここでもいくつか新しい RR が登場します。 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 がファイルを読み込み直します。
$ dig linux.bogus axfr
; <<>> DiG 8.2 <<>> linux.bogus axfr
$ORIGIN linux.bogus.
@ 3D IN SOA ns hostmaster (
199802151 ; serial
8H ; refresh
2H ; retry
4W ; expiry
1D ) ; minimum
3D IN NS ns
3D IN NS ns.friend.bogus.
3D IN MX 10 mail
3D IN MX 20 mail.friend.bogus.
3D IN TXT "Linux.Bogus, your DNS consultants"
gw 3D IN TXT "The router"
3D IN HINFO "Cisco" "IOS"
3D IN A 192.168.196.1
localhost 3D IN A 127.0.0.1
mail 3D IN HINFO "386sx" "Linux 1.2"
3D IN MX 10 mail
3D IN MX 20 mail.friend.bogus.
3D IN A 192.168.196.4
www 3D IN CNAME ns
donald 3D IN TXT "DEK"
3D IN HINFO "i486" "Linux 2.0"
3D IN MX 10 mail
3D IN MX 20 mail.friend.bogus.
3D IN A 192.168.196.3
ns 3D IN HINFO "Pentium" "Linux 2.0"
3D IN MX 10 mail
3D IN MX 20 mail.friend.bogus.
3D IN A 192.168.196.2
ftp 3D IN HINFO "P6" "Linux 2.1.86"
3D IN MX 10 mail
3D IN MX 20 mail.friend.bogus.
3D IN A 192.168.196.5
@ 3D IN SOA ns hostmaster (
199802151 ; serial
8H ; refresh
2H ; retry
4W ; expiry
1D ) ; minimum
;; Received 29 answers (29 records).
;; FROM: lookfar to SERVER: 127.0.0.1
;; WHEN: Sat Dec 16 01:35:05 2000
うまくいっていますね。ご覧の通り、ゾーンファイルそのものととても似てい
ます。 www だけについても調べてみましょう。
$ dig www.linux.bogus +pfmin
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27345
;; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1
;; QUERY SECTION:
;; www.linux.bogus, type = A, class = IN
;; ANSWER SECTION:
www.linux.bogus. 3D IN CNAME ns.linux.bogus.
ns.linux.bogus. 3D IN A 192.168.196.2
つまり www.linux.bogus の本当の名前は ns.linux.bogus なわけです。そし
て named が ns について持っている情報も示してくれています。あなたがプ
ログラムなら、この情報で接続できるはずです。
さて、ここまでが半分。
5.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 とまったく同じです。ファイルの中身も同じよ
うになります。
______________________________________________________________________
$TTL 3D
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; Serial, todays date + todays serial
8H ; Refresh
2H ; Retry
4W ; 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) して、再び dig で調べてみましょ
う。
______________________________________________________________________
$ dig -x 192.168.196.4 +pfmin
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8764
;; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUERY SECTION:
;; 4.196.168.192.in-addr.arpa, type = ANY, class = IN
;; ANSWER SECTION:
4.196.168.192.in-addr.arpa. 3D IN PTR mail.linux.bogus.
______________________________________________________________________
うん、良さそうですね。全体もダンプして調べてみましょう。
______________________________________________________________________
dig -x 192.168.196 AXFR
; <<>> DiG 8.2 <<>> -x AXFR
$ORIGIN 196.168.192.in-addr.arpa.
@ 3D IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial
8H ; refresh
2H ; retry
4W ; expiry
1D ) ; minimum
3D IN NS ns.linux.bogus.
4 3D IN PTR mail.linux.bogus.
2 3D IN PTR ns.linux.bogus.
5 3D IN PTR ftp.linux.bogus.
3 3D IN PTR donald.linux.bogus.
1 3D IN PTR gw.linux.bogus.
@ 3D IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial
8H ; refresh
2H ; retry
4W ; expiry
1D ) ; minimum
;; Received 8 answers (8 records).
;; FROM: lookfar to SERVER: 127.0.0.1
;; WHEN: Sat Dec 16 01:44:03 2000
______________________________________________________________________
よさそうですね！このような出力にならなかった場合は、 syslog にエラー
メッセージが出ていないか見てみましょう。やり方は``named を起動する''
直下の最初のセクションで説明しましたね。
5.4. 気をつけてほしいこと
ここでいくつか付け加えておくことがあります。上記で用いた IP 番号は
'private net' のうちの一つのブロックから取ってきたものです。つまりこれ
らの IP 番号はインターネットでパブリックに用いることはできません。です
からこの HOWTO で例として表示しても安全なわけです。次の点は notify no;
の行です。これは named に対して、「ゾーンファイルのどれかが更新されて
も、それをセカンダリ (スレーブ) サーバに伝えない」という指示をすること
になります。 bind-8 の named は、ゾーンファイルの NS レコードにリスト
されている他のサーバに、ゾーンの更新を知らせることができます。これは通
常は便利な機能ですが、プライベートな実験ではこの機能は off にしておき
ましょう。この実験によってインターネットに迷惑をかけたくはないでしょ
う？
そしてもちろん、このドメインは架空のいいかげんなもので、使われているア
ドレスも同じく架空のものです。現実の世界で用いられている本物の例は、次
の章を見て下さい。
5.5. なぜ逆引きが動作しないのか
名前引きのシステムには、ちょっとした「できの悪い部分」がいくつかありま
す。通常これらが表に出てくることはありませんが、逆引きゾーンの設定では
良くお目にかかることがあります。ここから以降を読み進める前には、あなた
のマシンが「あなたのネームサーバ」から逆引きできることを確認してくださ
い。できない場合は戻ってやり直してからにしてください。
ここでは、逆引きを外部ネットワークから見た場合に生じやすい二つの問題点
について議論します。
5.5.1. 逆引きゾーンが代理されない
サービスプロバイダからネットワークアドレス空間とドメインネームをもらう
ときには、通常そのドメインネームは代理 (delegation) されます。代理とは
橋渡しの役目をする NS レコードのことで、あるネームサーバから別のネーム
サーバを取得するときに用います。先に ``退屈な理論'' の節で説明しまし
た。読んでます、よね？逆引きゾーンが動作していない場合は、今すぐ戻って
読んでください。
逆引きゾーンにも代理が必要です。例えば 192.168.196 のネットワークを
linux.bogus ドメインと一緒にプロバイダからもらったとしたら、プロバイダ
には NS レコードを正引きゾーンだけでなく逆引きゾーンにも加えてもらう必
要があります。 in-addr.arpa からあなたのネットワークまでの繋がりを辿っ
ていくと、おそらくどこかで鎖の輪が切れていることでしょう。多分接続して
いるサービスプロバイダで。「切れている輪」が見付かったら、サービスプロ
バイダに連絡してエラーを修正してもらいましょう。
5.5.2. クラスレス (classless) のサブネットをもらった場合
これはやや高度な話題になります。しかしクラスレスのサブネットは最近非常
に良く使われるようになってきたので、小さな会社に所属している人なら、お
そらく身近にあるでしょう。
最近のインターネットをなんとか維持できているのは、実はクラスレスサブ
ネットのおかげなのです。数年前に IP 番号の枯渇についてちょっとした騒ぎ
になったことがありました。その時 IETF (Internet Engineering Task
Force: インターネットがちゃんと動いているのは彼らのおかげなのです) の
賢い人たちは、彼らの叡智を集めてこの問題を解決したのでした。ただし相応
の対価をもって。その対価とは、``C'' 未満のサブネットを使わなければなら
ないこと、そして動作しなくなるものが出てくること、です。このあたりに関
する説明と、その扱い方に関しては、 Ask Mr. DNS
にある優れた解説を見てくだ
さい。
読みました？ここでは説明しませんから、ちゃんと読んでくださいね。
この問題の半分は、接続先の ISP が Mr. DNS に書いてあったテクニックを理
解していなければならない、というところにあります。小さな ISP では、こ
れを知らずに動かしているところもあるでしょう。その場合は、あなたが彼ら
にがまん強く教えてあげなければいけません。それに、まずあなたが理解しな
いといけませんね ;-) 理解してくれたら、きっとちゃんとした逆引きゾーン
を設定してくれるでしょう。 dig を使って正しいかどうか確かめましょう。
問題の残り半分は、あなたがこのテクニックを理解しなければならない、とい
うところです。自信がなければ、もう一度読みにいきましょう。そして Mr.
DNS の説明にしたがって、自分のクラスレス逆引きゾーンを設定しましょう。
実はここにはもう一つトラップが待ち構えています。古いレゾルバは、名前解
決のチェーンの中に置かれたこの CNAME トリックの部分をたどることができ
ず、あなたのマシンの逆引きに失敗してしまうことがあります。この結果、そ
のレゾルバは正しくないアクセスクラスを返したり、アクセスを拒否したり、
とにかくそんなようなことになります。この問題に引っかかってしまったら、
(私の知るかぎりでは) 接続先の ISP に頼むしかありません。トリックを使っ
たクラスレスゾーンファイルに、 CNAME の代わりにあなたの PTR レコードを
直接書き込んでもらうことになります。
ISP によっては別の解法を提供していることもあります。たとえば Web ベー
スの form によって逆引きのマップを入力できるようになっているとか、ある
いは似たような全自動型登録システムとか。
5.6. スレーブサーバ
マスターサーバでゾーンが正しく設定できたら、少なくとも 1 台のスレーブ
サーバが必要になります。スレーブサーバはシステムを堅牢にするために必要
なものです。マスターが落ちても、ネットにいる外部の人が、スレーブからあ
なたのドメインに関する情報を取得できるようになるのです。スレーブは、あ
なたのいるところからできるだけ離れたところに置きます。マスターとスレー
ブは、電力供給源・LAN・ISP・町・国、などを、できる限り共有していないこ
とが望ましいのです。これらがすべてマスターと異なっているスレーブが見つ
かったら、それは非常に良いスレーブだと言えます。
スレーブは、単にマスターからゾーンファイルをコピーするネームサーバで
す。以下のように設定します。
______________________________________________________________________
zone "linux.bogus" {
type slave;
file "sz/linux.bogus";
masters { 192.168.196.2; };
};
______________________________________________________________________
データのコピーにはゾーン転送という仕組みを用います。ゾーン転送は SOA
レコードで制御します。
______________________________________________________________________
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, todays date + todays serial #
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
______________________________________________________________________
マスターのシリアル番号がスレーブよりも大きいときに限ってゾーンが転送さ
れます。リフレッシュ (refresh) 時間に一回ずつ、スレーブはマスターが更
新されていないかどうかチェックします。チェックできない (マスターに接続
できない) と、スレーブはリトライ (retry) 時間に一回ずつ再接続を試みま
す。期限切れ (expire) 時間が経過しても失敗し続けた場合は、スレーブはそ
のゾーンをファイルシステムから削除し、それ以上はゾーン情報の提供を行わ
なくなります。
6. 基本的なセキュリティオプション
By Jamie Norrish
問題を避けるためのオプション設定
いくつか簡単な作業を行えば、サーバをより安全にでき、またサーバの負荷を
低減できます。ここで紹介する内容は出発点に過ぎません。セキュリティのこ
とを考えるなら (考えるべきです)、ネット上にある他のリソースにあたって
ください (``最後の章''をご覧ください)。
以下の指定は named.conf に行います。これらの指定をこのファイルの
options の内部に書くと、このファイルでリストされたすべてのゾーンに適用
されます。特定の zone エントリの内部に書くと、そのゾーンだけに適用され
ます。 zone 内部に書かれたエントリは options に書かれたエントリよりも
優先されます。
6.1. ゾーン転送の制限
スレーブサーバがドメインに対する問合わせに応えるには、プライマリサーバ
からゾーンの情報を転送してくる必要があります。しかしスレーブサーバ以外
のホストには、この転送の必要はないはずです。ですからゾーン転送は
allow-transfer オプションを使って制限しましょう。例えば
ns.friend.bogus の IP アドレスである 192.168.1.4 と、それからデバッグ
用の自分自身を追加するならば:
______________________________________________________________________
zone "linux.bogus" {
allow-transfer { 192.168.1.4; localhost; };
};
______________________________________________________________________
ゾーン転送を制限すれば、外部の人々から見えるのは、彼らが直接尋ねたホス
トに関する内容だけに限られます。 DNS 設定の詳細全体を問合わせることは
できなくなるのです。
6.2. 不正利用から守る
まず、内部ネットワークとローカルのマシンからのものをのぞき、あなたの管
理するドメイン以外への問合わせは禁止しましょう。これは、悪意を持ってあ
なたの DNS サーバを利用しようとする試みを禁止するだけでなく、本来不必
要な問合わせを減らします。
______________________________________________________________________
options {
allow-query { 192.168.196.0/24; localhost; };
};
zone "linux.bogus" {
allow-query { any; };
};
zone "196.168.192.in-addr.arpa" {
allow-query { any; };
};
______________________________________________________________________
さらに内部/ローカルからのものを除き、再帰的な問合わせも禁止します。こ
れによりキャッシュ汚染攻撃 (cache poisoning attack: 間違ったデータをサ
ーバに送りつけること) の危険性が減らせます。
______________________________________________________________________
options {
allow-recursion { 192.168.196.0/24; localhost; };
};
______________________________________________________________________
6.3. named を root 以外で実行する
named を root 以外から実行するのは良い考えです。破られたときに、クラッ
カーに奪われる権限を減らすことが出来ますから。まず named を動作させる
ユーザとグループを作り、次に named を起動している init スクリプトを修
正します。新しく作ったユーザ名とグループ名を、 named の -u フラグと -g
フラグに指定します。
例えば Debian GNU/Linux 2.2 なら、 /etc/init.d/bind スクリプトを以下の
行のように修正します (ユーザ named、グループ named はあらかじめ作成し
ておきます):
______________________________________________________________________
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -u named -g named
______________________________________________________________________
Red Hat や他のディストリビューションでも同様にできるはずです。 Dave
Lugo は、二つの chroot を用いたセキュアな設定を
で解説しています。きっと
興味を持たれる読者が多いでしょう。
7. 実際のドメインの例
実際に用いられているゾーンファイルの例
チュートリアルの例だけでなく実際に動作している例を載せて欲しい、という
意見があったので、この章を設けました。
この例は LAND-5 の David Bullock の許可の下に用いています。これらの
ファイルは、 1996 年 9 月 24 日現在のものを、私が bind 8 の制限と拡張
にあわせて編集したものです。したがってここでの記述は、実際に LAND-5 の
ネームサーバに問い合わせを行った結果とは多少異なります。
7.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 セクションに追加して、事故が起
こらないようにしてください。
7.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
______________________________________________________________________
7.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.
______________________________________________________________________
適当にインストールされた BIND では、ここでの例のように $TTL の行がない
かもしれません。この行は以前は用いられておらず、8.2 の BIND だけが起動
時にこの行が無い旨の警告を出します。私のおすすめは、$TTL 行が無いゾー
ンファイルを見つけたら、その度ごとに $TTL を入れる、です。
7.4. /var/named/zone/land-5.com
まず必須である SOA レコードと、同じく必須の NS レコードがあります。セ
カンダリのネームサーバが ns2.psi.net に用意されていることもわかります
ね。これは望ましい設定です。必ずサイトの外にバックアップのセカンダリネ
ームサーバを置くべきです。マスターのホストは land-5 で、このホストは同
時に各種のインターネットサービスを提供していることもわかります。これに
は (A レコードでなく) CNAME が用いられています。
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
4W ; 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 レコードを用いています。先に述べたように、こ
れは良い方針です。
7.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 サーバにさえ拒否するものもあります)。ですからマ
シン名の逆引きマップは実のところは必須なのです。
8. メンテナンス
動作を維持するために
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
# named up-test suggested by Erik Bryer.
#
(
echo "To: hostmaster "
echo "From: system "
# Is named up? Check the status of named.
case `ndc status 2>&1` in
*'cannot connect to command channel'*)
echo "named is DOWN. root.hints was NOT updated"
echo
exit 0
;;
esac
PATH=/sbin:/usr/sbin:/bin:/usr/bin:
export PATH
# NOTE: /var/named must be writable only by trusted users or this script
# will cause root compromise/denial of service opportunities.
cd /var/named 2>/dev/null || {
echo "Subject: Cannot cd to /var/named, error $?"
echo
echo "The subject says it all"
exit 1
}
# Are we online? Ping a server at your ISP
case `ping -qnc 1 some.machine.net 2>&1` in
*'100% packet loss'*)
echo "Subject: root.hints NOT updated. The network is DOWN."
echo
echo "The subject says it all"
exit 1
;;
esac
dig @e.root-servers.net . ns >root.hints.new 2> errors
case `cat root.hints.new` in
*NOERROR*)
# It worked
:;;
*)
echo "Subject: The root.hints file update has FAILED."
echo
echo "The root.hints update has failed"
echo "This is the dig output reported:"
echo
cat root.hints.new errors
exit 1
;;
esac
echo "Subject: The root.hints file has been updated"
echo
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 errors
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)
に優しい」のです。
9. バージョン 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 ディレクトリで、コマンドラインから以下のように入力
します (編注: これはソース配布の場合です。バイナリパッケージには、この
スクリプトは入っていないかもしれません。その場合どこから入手すればいい
かはちょっとわかりません)。
______________________________________________________________________
./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 ファイルの書式はまったく同じです。これらを
更新するコマンドも同じです。
10. 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 ファイルを使わないようにして、ゾーンファイルだけを使いま
しょう。 root.hints ファイルをいちいち更新する必要もないわけです。
5. net から切断されているときにも BIND を動作させておきたいんですが
これに関連した記事を 4 つ紹介しましょう。
o BIND 8 に特化したやり方を Adam L Rice が電子メールで教えてくれま
した。ダイアルアップのマシンで DNS を手間をかけずに動作させる方
法です。
私は、最近のバージョンの BIND では、これ [編注: ファイルを切り
替える] がもう不必要であることに気がつきました。 "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
これは気にしなくてもかまいません。
私のところではこれで全く問題なく動作しています。ネットから切断
されているときは、ローカルマシンのネームサーバを外部のドメイン名に
対するタイムアウトの待ち時間なしで使えますし、接続されているとき
には外部のドメインに対する問い合わせを普通に行うことができています。
しかし、Peter Denison は Ian のやり方がまだ充分でないと教えてくれま
した。彼のメッセージによると:
オンライン時) キャッシュされたエントリ (とローカルネットのエントリ) は
ただちに提供する。キャッシュされていないエントリについては、
自分の ISP のネームサーバにフォワードする。
オフライン時) ローカルネットワーク関連の問合わせはただちに提供する。
その他の問合わせについては **ただちに** 失敗する。
root キャッシュファイルの変更と、問合わせのフォワードとの組み合わせは
うまく動作しません。
そこで、私は二つの named を (地域 LUG で議論しながら) 以下のように
設定しました。
named-online: ISP のネームサーバへフォワード
localnet ゾーンのマスター
localnet の逆引きゾーン (1.168.192.in-addr.arpa) のマスター
0.0.127.in-addr.arpa のマスター
ポート 60053 で待機
named-offline: フォワードを行わない
root キャッシュファイルは「にせもの」にする
3 つのローカルゾーンのスレーブ (マスターは 127.0.0.1:60053)
ポート 61053 で待機
そしてこれをポートフォワードと組み合わせ、ポート 53 をオフラインの時には
61053 に、オンラインの時には 60053 にフォワードします (私は 2.3.18 で
新しい netfilter パッケージを使いましたが、以前の (ipchains) の機構でも
動作するはずです。
ただしこれはマシンの外側からの問合わせには動作しません。 BIND 8.2 には
小さなバグがあって、スレーブをマスターと同じ IP アドレスでは (ポートが
異なっても) 同時に動作できないからです (開発者には知らせました)。
明らかなパッチなので、おそらくすぐに直るでしょう。
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 向けに読み替
える必要があります。
6. キャッシュネームサーバはどこにキャッシュを保存しているの？キャッ
シュのサイズは制御できますか？
キャッシュはすべてメモリに保管されています。ディスクに書き込まれる
ことはまったくありません。 named を kill すると、キャッシュも失われ
ます。キャッシュをコントロールする方法はありません。 named のキャッ
シュ管理は単純なルールに従っているからです。キャッシュそのものも、
あるいはキャッシュのサイズも、どんな理由があれコントロールすること
はできません。この点を「修正」したければ named をハックしても良いで
しょう。おすすめはできませんが。
7. named は再起動されるときにキャッシュを保存してくれますか？保存する
ようにできますか？
いいえ、 named は終了時にキャッシュを保存しません。つまり named を
kill して再起動するたびに、キャッシュはゼロから再構成されます。
キャッシュをファイルに保存するように named に指示する方法はないので
す。この点を「修正」したければ named をハックしても良いでしょう。お
すすめはできませんが。
8. ドメインを手に入れるにはどうすればいいですか？私は (例えば) linux-
rules.net というドメインを立ち上げたいのですが、このドメインを割り
当ててもらうにはどうすればいいのでしょうか。
ネットワークサービスプロバイダに連絡してみれば、おそらく助けてもら
えるでしょう。なお世界のほとんどの地域では、ドメインの入手にはお金
が必要であるはずですので念のため。
9. DNS サーバを安全にするにはどうすればいいでしょう？ split DNS の設定
のしかたは？
両方とも高度な話題になります。いずれも
で取り上げられていま
す。この話題は、これ以上ここでは扱いません。
11. より熟練した DNS 管理者になるために
文献とツール
しっかりした文献がちゃんと存在しています。オンラインのものと印刷されて
いるものとがそれぞれあります。即席 DNS 管理者が熟練した DNS 管理者にな
るためのステップを踏むには、この中のいくつかを読むことが必要です。印刷
された書籍としては、私が書いたものに The Concise Guide to DNS and BIND
(by Nicolai Langfeldt, Que, ISDN 0-7897-2273-9) があります。この本はこ
の HOWTO と、とても似ています。多少より詳細に、そしてより幅広い話題を
たくさん扱っています。しかしなんといっても、スタンダードは DNS and
BIND (by C. Liu and P. Albitz, O'Reilly & Associates, Sebastopol, CA,
ISBN 0-937175-82-X) でしょう。これも非常にすぐれた本です。第 3 版は
BIND8 と BIND 4 を両方カバーしていますので、こちらを買いましょう。同じ
く O'Reilly の TCP/IP Network Administration (Craig Hunt, 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 Resources Directory や
でいろいろ見つかります。 FAQ、リファレ
ンスマニュアル (BOG; Bind Operations Guide)、にも論文やプロトコル定義
や DNS の実装ハックもあります。上記や、以下に示す RFC のほとんど
は、bind の配布の中に含まれています。私はこのあたりをしっかり読んでい
ませんので、習熟した DNS 管理者というわけでもありません。一方 Arnt
Gulbrandsen は BOG をすでに読んでおり、それに夢中になっています :-)。
ニュースグループ comp.protocols.tcp-ip.domains では DNS の議論をしてい
ます。また DNS に関する RFC もたくさん存在しています。中でも重要なもの
を以下に挙げておきます。 BCP (Best Current Practice) の番号が付いてい
るものは必読です。
RFC 2671
P. Vixie, Extension Mechanisms for DNS (EDNS0) August 1999.
RFC 2317
BCP 20, H. Eidnes et. al. Classless IN-ADDR.ARPA delegation,
March 1998. This is about CIDR, or classless subnet reverse
lookups.
RFC 2308
M. Andrews, Negative Caching of DNS Queries, March 1998. About
negative caching and the $TTL zone file directive.
RFC 2219
BCP 17, M. Hamilton and R. Wright, Use of DNS Aliases for
Network Services, October 1997. About CNAME usage.
RFC 2182
BCP 16, R. Elz et. al., Selection and Operation of Secondary DNS
Servers, July 1997.
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.
.