あなた自身のドメインの設定方法
まず最初に: ここまでの内容はちゃんと読みましたか？ 読んでなければ読むように。
このセクションを実際に始める前に、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 +noques +nostats +nocmd prep.ai.mit.edu.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 980
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
;; AUTHORITY SECTION:
. 518400 IN NS J.ROOT-SERVERS.NET.
. 518400 IN NS K.ROOT-SERVERS.NET.
. 518400 IN NS L.ROOT-SERVERS.NET.
. 518400 IN NS M.ROOT-SERVERS.NET.
. 518400 IN NS A.ROOT-SERVERS.NET.
. 518400 IN NS B.ROOT-SERVERS.NET.
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS D.ROOT-SERVERS.NET.
. 518400 IN NS E.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS H.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
これは参照先の提示です。 ここには "Authority section" しかなく、"Answer section" がありません。 私たちの立てたネームサーバは、 私たちをこのネームサーバのどれかに指し向けます。 どれかひとつをランダムに選んでみましょう。
$ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @D.ROOT-SERVERS.NET.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58260
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
;; AUTHORITY SECTION:
mit.edu. 172800 IN NS BITSY.mit.edu.
mit.edu. 172800 IN NS STRAWB.mit.edu.
mit.edu. 172800 IN NS W20NS.mit.edu.
;; ADDITIONAL SECTION:
BITSY.mit.edu. 172800 IN A 18.72.0.3
STRAWB.mit.edu. 172800 IN A 18.71.0.151
W20NS.mit.edu. 172800 IN A 18.70.0.160
MIT.EDU のサーバ群がいっぺんに提示されました。 ではまたどれかをランダムに選びましょう。
$ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @BITSY.mit.edu.
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29227
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; ANSWER SECTION:
prep.ai.mit.edu. 10562 IN A 198.186.203.77
;; AUTHORITY SECTION:
ai.mit.edu. 21600 IN NS FEDEX.ai.mit.edu.
ai.mit.edu. 21600 IN NS LIFE.ai.mit.edu.
ai.mit.edu. 21600 IN NS ALPHA-BITS.ai.mit.edu.
ai.mit.edu. 21600 IN NS BEET-CHEX.ai.mit.edu.
;; ADDITIONAL SECTION:
FEDEX.ai.mit.edu. 21600 IN A 192.148.252.43
LIFE.ai.mit.edu. 21600 IN A 128.52.32.80
ALPHA-BITS.ai.mit.edu. 21600 IN A 128.52.32.5
BEET-CHEX.ai.mit.edu. 21600 IN A 128.52.32.22
今度は "ANSWER SECTION" がありました。
そして私たちの知りたかった答も見つかりました。
"AUTHORITY SECTION" には、次回
ai.mit.edu に尋ねる際にはどのサーバにすべきか、
という情報が含まれています。
したがって次に ai.mit.edu の名前について知りたいときには、
これらに直接聞けば良いわけです。
named は同時に mit.edu に関する情報も集めるので、
次に例えば www.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.186.203.77 がわかっていた場合、
named は 先程の prep.ai.mit.edu の例と同じように
77.203.168.198.in-addr.arpa を探そうとします。
いま例えば、 `.' 以外全くマッチしないような、
キャッシュにないエントリを探すとしましょう。
root サーバに訪ね、
m.root-servers.net は他の root サーバへの参照を返します。
b.root-servers.net は直接 bitsy.mit.edu/
への参照を返してくれるので、そこから情報を取得することになります。
さて、私たちのドメインを定義しましょう。ドメイン
linux.bogus を作り、そこに私たちのマシンを定義しましょう。
ここでは完全に架空のドメイン名を使って、間違っても外部の人に迷惑が
かからないようにしましょう。
始める前にもう一点。ホスト名に使える文字には制限があります。
英語のアルファベット a-z、数字 0-9、および '-' (ダッシュ) 文字
だけが使えます。守るようにしてください
(この規則を破っても BIND 9 では大丈夫ですが、BIND 8 はダメです)。
大文字小文字は 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 レコードはどんなゾーンファイルでも先頭に置かれます。
また各ゾーンファイルにつき一つ、先頭に
(ただし $TTL 指定のあとに) 書きます。
このレコードはゾーンの説明です。
どこから得られるのか (ns.linux.bogusというマシン)、
内容に関する責任者は誰か (hostmaster@linux.bogus:
ここにはあなたの電子メールアドレスを入れましょう)、
ゾーンファイルのバージョンはいくつか (シリアル番号: 1)、
その他キャッシュやセカンダリ DNS サーバなどに関連した内容などを書きます。
残りのフィールド (refresh, retry, expire, minimum) については、
この HOWTO の値をそのまま使えば特に問題ないでしょう。
SOA の前には必須の行、$TTL 3D と書かれた行があります。
これはすべてのゾーンファイルに書いてください。
では、ここで named を再起動 (rndc stop; named) して、
dig コマンドで今までの設定の確認を行いましょう。
-x を使うと逆引きの問合わせを行います。
$ dig -x 127.0.0.1
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30944
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;1.0.0.127.in-addr.arpa. IN PTR
;; ANSWER SECTION:
1.0.0.127.in-addr.arpa. 259200 IN PTR localhost.
;; AUTHORITY SECTION:
0.0.127.in-addr.arpa. 259200 IN NS ns.linux.bogus.
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:02:39 2001
;; MSG SIZE rcvd: 91
なんとか 127.0.0.1 から localhost が得られました。いい感じですね。
ではメインのお仕事である linux.bogus ドメインのために、
named.conf に新しい `zone' セクションを書きましょう。
zone "linux.bogus" {
type master;
notify no;
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 です。
rndc reload を実行して、named に設定ファイルを再び読ませます。
ここまでの設定を dig で確認しましょう。
$ dig any linux.bogus
; <<>> DiG 9.1.3 <<>> any linux.bogus
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55239
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;linux.bogus. IN ANY
;; ANSWER SECTION:
linux.bogus. 259200 IN SOA ns.linux.bogus. \
hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
linux.bogus. 259200 IN NS ns.linux.bogus.
linux.bogus. 259200 IN MX 20 mail.friend.bogus.
linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus.
;; AUTHORITY SECTION:
linux.bogus. 259200 IN NS ns.linux.bogus.
;; ADDITIONAL SECTION:
ns.linux.bogus. 259200 IN A 192.168.196.2
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:06:45 2001
;; MSG SIZE rcvd: 184
よく見ると、バグがあることがわかると思います。
linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus.
というのは全くおかしいですね。これは、
linux.bogus. 259200 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
TXT "The router"
ns A 192.168.196.2
MX 10 mail
MX 20 mail.friend.bogus.
www CNAME ns
donald A 192.168.196.3
MX 10 mail
MX 20 mail.friend.bogus.
TXT "DEK"
mail A 192.168.196.4
MX 10 mail
MX 20 mail.friend.bogus.
ftp A 192.168.196.5
MX 10 mail
MX 20 mail.friend.bogus.
CNAME (Canonical NAME) は、各マシンを複数の名前で呼ぶ方法です。 よって www は ns の別名になります。CNAME レコードの利用については、 多少議論の余地があります。 でも以下のルールを守っておけば大丈夫でしょう。 MX, CNAME, SOA の 各レコードでは CNAME レコードを参照してはいけません。 これらは A レコードだけを参照すべきなのです。したがって
foobar CNAME www ; NO!
という指定はすべきではなく、
foobar CNAME ns ; Yes!
という指定が正しいものとなります。
rndc reload を実行して新しいデータベースをロードしましょう。
すると named がファイルを読み込み直します。
$ dig linux.bogus axfr
; <<>> DiG 9.1.3 <<>> linux.bogus axfr
;; global options: printcmd
linux.bogus. 259200 IN SOA ns.linux.bogus. hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
linux.bogus. 259200 IN NS ns.linux.bogus.
linux.bogus. 259200 IN MX 10 mail.linux.bogus.
linux.bogus. 259200 IN MX 20 mail.friend.bogus.
donald.linux.bogus. 259200 IN A 192.168.196.3
donald.linux.bogus. 259200 IN MX 10 mail.linux.bogus.
donald.linux.bogus. 259200 IN MX 20 mail.friend.bogus.
donald.linux.bogus. 259200 IN TXT "DEK"
ftp.linux.bogus. 259200 IN A 192.168.196.5
ftp.linux.bogus. 259200 IN MX 10 mail.linux.bogus.
ftp.linux.bogus. 259200 IN MX 20 mail.friend.bogus.
gw.linux.bogus. 259200 IN A 192.168.196.1
gw.linux.bogus. 259200 IN TXT "The router"
localhost.linux.bogus. 259200 IN A 127.0.0.1
mail.linux.bogus. 259200 IN A 192.168.196.4
mail.linux.bogus. 259200 IN MX 10 mail.linux.bogus.
mail.linux.bogus. 259200 IN MX 20 mail.friend.bogus.
ns.linux.bogus. 259200 IN MX 10 mail.linux.bogus.
ns.linux.bogus. 259200 IN MX 20 mail.friend.bogus.
ns.linux.bogus. 259200 IN A 192.168.196.2
www.linux.bogus. 259200 IN CNAME ns.linux.bogus.
linux.bogus. 259200 IN SOA ns.linux.bogus. hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
;; Query time: 41 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:12:31 2001
;; XFR size: 23 records
うまくいっていますね。
ご覧の通り、ゾーンファイルそのものとちょっと似ています。
www だけについても調べてみましょう。
$ dig www.linux.bogus
; <<>> DiG 9.1.3 <<>> www.linux.bogus
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16633
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;www.linux.bogus. IN A
;; ANSWER SECTION:
www.linux.bogus. 259200 IN CNAME ns.linux.bogus.
ns.linux.bogus. 259200 IN A 192.168.196.2
;; AUTHORITY SECTION:
linux.bogus. 259200 IN NS ns.linux.bogus.
;; Query time: 5 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:14:14 2001
;; MSG SIZE rcvd: 80
つまり www.linux.bogus の本当の名前は
ns.linux.bogus なわけです。
そして named が ns について持っている情報も示してくれています。
あなたがプログラムなら、この情報で接続できるはずです。
さて、ここまでが半分。
今やプログラムは、 linux.bogus にある名前を、 実際に接続すべきアドレスに変換できるようになったわけです。 でも逆引きのゾーンも必要です。 これは DNS でアドレスを名前に変換できるようにするためのものです。 この名前はさまざまな種類のたくさんのサーバ (FTP, IRC, WWW などなど) において、あなたとの通信を認めるか、 また認めた場合、どの程度の優先性を付与するかなどの判断に用いられます。 インターネットにあるサービスすべてにアクセスするためには、 逆引きのゾーンが必要になります。
以下を named.conf に記述してください。
zone "196.168.192.in-addr.arpa" {
type master;
notify no;
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.
では rndc reload を実行し、named に設定ファイルを再び読ませ、
再び dig でこれまでの設定を確認しましょう。
$ dig -x 192.168.196.4 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58451 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;4.196.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 4.196.168.192.in-addr.arpa. 259200 IN PTR mail.linux.bogus. ;; AUTHORITY SECTION: 196.168.192.in-addr.arpa. 259200 IN NS ns.linux.bogus. ;; ADDITIONAL SECTION: ns.linux.bogus. 259200 IN A 192.168.196.2 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:16:05 2001 ;; MSG SIZE rcvd: 107
うん、良さそうですね。全体もダンプして調べてみましょう。
$ dig 196.168.192.in-addr.arpa. AXFR
; <<>> DiG 9.1.3 <<>> 196.168.192.in-addr.arpa. AXFR
;; global options: printcmd
196.168.192.in-addr.arpa. 259200 IN SOA ns.linux.bogus. \
hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
196.168.192.in-addr.arpa. 259200 IN NS ns.linux.bogus.
1.196.168.192.in-addr.arpa. 259200 IN PTR gw.linux.bogus.
2.196.168.192.in-addr.arpa. 259200 IN PTR ns.linux.bogus.
3.196.168.192.in-addr.arpa. 259200 IN PTR donald.linux.bogus.
4.196.168.192.in-addr.arpa. 259200 IN PTR mail.linux.bogus.
5.196.168.192.in-addr.arpa. 259200 IN PTR ftp.linux.bogus.
196.168.192.in-addr.arpa. 259200 IN SOA ns.linux.bogus. \
hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400
;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 23 03:16:58 2001
;; XFR size: 9 records
よさそうですね！このような出力にならなかった場合は、 syslog にエラーメッセージが出ていないか見てみましょう。 やり方は named を起動する 直下の最初のセクションで説明しましたね。
ここでいくつか付け加えておくことがあります。上記で用いた
IP 番号は 'private net' のうちの一つのブロックから取ってきたものです。
つまりこれらの IP 番号はインターネットでパブリックに用いることはできません。
ですからこの HOWTO で例として表示しても安全なわけです。
次の点は notify no; の行です。これは named に対して、
「ゾーンファイルのどれかが更新されても、それをセカンダリ (スレーブ)
サーバに伝えない」という指示をすることになります。
BIND 8 以降の named は、
ゾーンファイルの NS レコードにリストされている他のサーバに、
ゾーンの更新を知らせることができます。
これは通常は便利な機能ですが、
プライベートな実験ではこの機能は off にしておきましょう。
この実験によってインターネットに迷惑をかけたくはないでしょう？
そしてもちろん、このドメインは架空のいいかげんなもので、 使われているアドレスも同じく架空のものです。 現実の世界で用いられている本物の例は、次の章を見て下さい。
名前引きのシステムには、ちょっとした「できの悪い部分」がいくつか あります。通常これらが表に出てくることはありませんが、 逆引きゾーンの設定では良くお目にかかることがあります。 ここから以降を読み進める前には、あなたのマシンが 「あなたのネームサーバ」から逆引きできることを確認してください。 できない場合は戻ってやり直してからにしてください。
ここでは、逆引きを外部ネットワークから見た場合に生じやすい 二つの問題点について議論します。
サービスプロバイダからネットワークアドレス空間とドメインネームを もらうときには、通常そのドメインネームは代理 (delegation) されます。 代理とは橋渡しの役目をする NS レコードのことで、 あるネームサーバから別のネームサーバを取得するときに用います。 先に 退屈な理論 の節で説明しました。読んでます、よね？ 逆引きゾーンが動作していない場合は、今すぐ戻って読んでください。
逆引きゾーンにも代理が必要です。
例えば 192.168.196 のネットワークを
linux.bogus ドメインと一緒にプロバイダからもらったとしたら、
プロバイダには NS レコードを正引きゾーンだけでなく
逆引きゾーンにも加えてもらう必要があります。
in-addr.arpa からあなたのネットワークまでの繋がりを辿っていくと、
おそらくどこかで鎖の輪が切れていることでしょう。
多分接続しているサービスプロバイダで。「切れている輪」が見付かったら、
サービスプロバイダに連絡してエラーを修正してもらいましょう。
これはやや高度な話題になります。 しかしクラスレスのサブネットは最近非常に良く使われるようになってきたので、 小さな会社に所属している人なら、おそらく身近にあるでしょう。
最近のインターネットをなんとか維持できているのは、 実はクラスレスサブネットのおかげなのです。 数年前に IP 番号の枯渇についてちょっとした騒ぎになったことがありました。 その時 IETF (Internet Engineering Task Force: インターネットがちゃんと動いているのは彼らのおかげなのです) の賢人たちは、彼らの叡智を集めてこの問題を解決したのでした。 ただし相応の対価をもって。 その対価の一部は、``C'' 未満のサブネットを使わなければならないこと、 それによって動作しなくなるものが出てくること、です。 このあたりに関する説明と、その扱い方に関しては、 Ask Mr. DNS にある優れた解説を見てください。
読みました？ここでは説明しませんから、ちゃんと読んでくださいね。
この問題の半分は、接続先の ISP が Mr. DNS に書いてあったテクニックを理解していなければならない、 というところにあります。 小さな ISP では、これを知らずに動かしているところもあるでしょう。 その場合は、あなたが彼らにがまん強く教えてあげなければいけません。 それに、まずあなたが理解しないといけませんね ;-) 理解してくれたら、きっとちゃんとした逆引きゾーンを設定してくれるでしょう。 dig を使って正しいかどうか確かめましょう。
問題の残り半分は、あなたがこのテクニックを理解しなければならない、 というところです。自信がなければ、もう一度読みにいきましょう。 そして Mr. DNS の説明にしたがって、 自分のクラスレス逆引きゾーンを設定しましょう。
実はここにはもう一つトラップが待ち構えています。
(非常に) 古いレゾルバは、名前解決のチェーンの中に置かれた
この CNAME トリックの部分をたどることができず、
あなたのマシンの逆引きに失敗してしまうことがあります。
この結果、そのレゾルバは正しくないアクセスクラスを返したり、
アクセスを拒否したり、とにかくそんなようなことになります。
この問題に引っかかってしまったら、
(私の知るかぎりでは) 接続先の ISP に頼むしかありません。
トリックを使ったクラスレスゾーンファイルに、
CNAME の代わりにあなたの PTR レコードを
直接書き込んでもらうことになります。
ISP によっては別の解法を提供していることもあります。 たとえば Web ベースの form によって逆引きのマップを 入力できるようになっているとか、 あるいは似たような全自動型登録システムとか。
マスターサーバでゾーンが正しく設定できたら、 少なくとも 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) 時間が経過しても失敗し続けた場合は、 スレーブはそのゾーンをファイルシステムから削除し、 それ以上はゾーン情報の提供を行わなくなります。