あなた自身のドメインの設定方法
このセクションを実際に始める前に、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 は今まで書いてきた通り全くそのままに動作するわけではありません。 でもほぼこの通りと思っていただいてかまいません。
さて、私たちのドメインを定義しましょう。ドメイン
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 について持っている情報も示してくれています。
あなたがプログラムなら、この情報で接続できるはずです。
さて、ここまでで半分来たことになります。
今やプログラムは、 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 にエラーメッセージが出ていないか見てみましょう。 やり方はこの章の一番最初で説明しましたね。
ここでいくつか付け加えておくことがあります。上記で用いた
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 では、これを知らずに動かしているところもあるでしょう。 その場合は、あなたが彼らにがまん強く教えてあげなければいけません。 それに、まずあなたが理解しないといけませんね ;-) 理解してくれたら、きっとちゃんとした逆引きゾーンを設定してくれるでしょう。 nslookup を使って正しいかどうか確かめましょう。
問題の残り半分は、あなたがテクニックを理解しなければならない、 というところです。自信がなければ、もう一度読みにいきましょう。 そして Mr. DNS の説明にしたがって、 自分のクラスレス逆引きゾーンを設定しましょう。
実はここにはもう一つトラップが待ち構えています。
古いレゾルバは、名前解決のチェーンの中に置かれた
この CNAME トリックの部分をたどることができず、
あなたのマシンの逆引きに失敗してしまうことがあります。
この結果、そのレゾルバは正しくないアクセスクラスを返したり、
アクセスを拒否したり、とにかくそんなようなことになります。
この問題に引っかかってしまったら、
(私の知るかぎりでは) 接続先の ISP に頼むしかありません。
トリックを使ったクラスレスゾーンファイルに、
CNAME の代わりにあなたの PTR レコードを
直接書き込んでもらうことになります。
ISP によっては別の解法を提供していることもあります。 たとえば Web ベースの form によって逆引きのマップを 入力できるようになっているとか、 似たような全自動型登録システムなどです。