あなた自身のドメインの設定方法
まず最初に: ここまでの内容はちゃんと読みましたか？ 読んでなければ読むように。
このセクションを実際に始める前に、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. に対応するレコードを見つけます。
賢いでしょ？ (でしょ？)
ただし番号の逆転には、慣れるまで何年かかかるかもしれませんけどね。
さて、私たちのドメインを定義しましょう。ドメイン
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 について持っている情報も示してくれています。
あなたがプログラムなら、この情報で接続できるはずです。
さて、ここまでが半分。
今やプログラムは、 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 を起動する 直下の最初のセクションで説明しましたね。
ここでいくつか付け加えておくことがあります。上記で用いた
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) 時間が経過しても失敗し続けた場合は、 スレーブはそのゾーンをファイルシステムから削除し、 それ以上はゾーン情報の提供を行わなくなります。