dns 設定におけるよくある間違い & dns 設定チェックリスト

Dec/19/2002 IW2002 DNS DayCopyright(C) 2002 Koh-ichi Ito, All rights, reserved,

DNS 設定におけるよくある間違い&

DNS 設定チェックリストインターネット総合研究所

伊藤高一[email protected]


Q.1

　 PC UNIX より遅いので始末に困っていた 3 年前のワークステーションをネームサーバにした。

　保守契約には入っていないので OS は3 年前のままだが、運よく named が OSについてきていたので、それを使っている。


A.1

×　 3 年前の named にはセキュリティホールが存在

します。　 BIND でセキュリティホールが見つかっていな

いのは以下のバージョンだけです。– 4.9.11– 8.2.7– 8.3.4– 9.2.1

• 資料作成時点、 TxB 、 rc などは除く。

　


Q.2

　 BIND 9.2.1 をインストールしているが、レゾルバライブラリのセキュリティ対策のために OS のパッチを当てた。


A.2

○　 BIND 9 では、意識的にインストールしないと

レゾルバライブラリはコンパイルすらされません。

　後からレゾルバライブラリをインストールしても、バイナリを再リンクしたり動的ライブラリのモジュールを差し替えるなどしないと、元々のルーチンが使われています。


Q.3

　 11 月の頭にメーリングリストで named.root がどーのこーのと書いてあるメールが流れてきたが、英語だったので読み飛ばした。


A.3

×　 11 月 5 日に J.ROOT-SERVERS.NET. の

アドレスが変更された named.root が配布されました。


Q.4

　メールサーバは yamada.nishiki.gr.jp. というホストがやっているが、 MX レコードには mail.nishiki.gr.jp. と書きたかったので、 yamada とは別に mail という A レコードを作って yamada と同じ IP アドレスを書いた。


A.4

○　 mail の A レコードを作らずに yamada を指

す CNAME レコードを作ってはいけません。同様に NS の RDATA も alias ではいけません。– (RFC2181)

　送信元の MTA によっては MX を要求して CNAME が返ってくると無視する実装もあるそうです。

　ちなみに次ホップでの Received: ヘッダにはmail ではなく逆索きして得られた yamada が表示される可能性があります。


Q.5

　ルータの Serial4/0:17 に振ったアドレスを DNS に登録するのにSerial4/0:17.ko.nishiki.gr.jp.

　という名前で A レコードと PTR レコードを設定した。


A.5

×ホスト名は

– 数字またはアルファベットで始まり– 数字、アルファベット、ハイフンを繰り返

し– 数字またはアルファベットで終わること

になっています。– (RFC1035,RFC1123)


Q.6

メールサーバは– yamada.nishiki.gr.jp.– sasa.nishiki.gr.jp.

の 2 台なので nishiki.gr.jp. ゾーンに@ IN MX 10 yamada.nishiki.gr.jp.

IN MX 20 sasa.nishiki.gr.jp.

と設定した。


A.6

○末尾の‘ .’ を忘れると相対表記と解釈され

yamada.nishiki.gr.jp.nishiki.gr.jp.

sasa.nishiki.gr.jp.nishiki.gr.jp.

に展開されてしまいますので注意しましょう。


Q.7

　 ISP から来たセカンダリネームサービスの案内という紙に書いてあったセカンダリのホスト名を自分のところの NSレコードに書いた。

　プライマリの設定さえしておけば、商売なんだから後は ISP が勝手に設定して当然だ。


A.7

×　参照すべきマスタの IP アドレスがわ

からなければ ISP 側も設定のしようがありません。

　ましてやセカンダリの希望の有無は、言われなければもっとわかりません。


Q.8

　 ISP からの案内にしたがって32/27.0.168.192.in-addr.arpa.

　というゾーンを設定したが、逆索きできないのでメーカーのサポートを呼んだところ、「ゾーン名が間違ってますね」と言って0.168.192.in-addr.arpa.

　に直してくれたら索けるようになった。　やはり ISP のサポートよりメーカーの

サポートの方が腰も低いしソフトのことをよく知っているので頼りになる。


A.8

×　 RFC2317 を使う場合は ISP 側の設定が済ま

ないと逆索きできません。　ユーザ側が /24 に対応するゾーン名で設定し

てしまうと ISP 側から authority が委任できないばかりでなく、ユーザ側でも同じ /24 に同居するサイトの逆索きができなくなります。


Q.9

　古い本に載っていた例では SOA レコードの最後の数字が 86400 になっていたが、 $TTL 86400 と書いたので、 SOA レコードの最後の数字は 7200 に設定した。


A.9

○　 SOA レコードの最後の数字は、以前は

TTL のデフォルト値でしたが、 BIND 8以降では negative cache の TTL に意味が変更されています。


Q.10

　マスタサーバのホスト名は miyama.nishiki.gr.jp. で

@ IN NS miyama.nishiki.gr.jp.

　と設定しているが、 ns.nishiki.gr.jp. の方が体裁がいいので、 JPRS には ns.nishiki.gr.jp. というホスト名で登録した。


A.10

×　例えばクライアント側のサーバで

nishiki.gr.jp. IN NS ns.nishiki.gr.jp.

はキャッシュ上にあり、 ns.nishiki.gr.jp.の A レコードの TTL が切れると authorityにたどり着けなくなります。

　また実装によっては miyama が返した NSレコードを無視する物もあるようです。


Q.11

　 www.nishiki.gr.jp. と imap.nishiki.gr.jp. はtochi.nishiki.gr.jp. を指す CNAME レコードとして定義していたが、 tochi.nishiki.gr.jp. のリースが切れたので、 tochi.nishiki.gr.jp. の A レコードも koto.nishiki.gr.jp.を指す CNAME レコードに書き換えた。

　これで www と imap も koto.nishiki.gr.jp.を指すようになった。


A.11

△　循環参照を避けるために、多段 CNAME

の段数が制限されている実装もあります。– BIND 4.x/8.x: 8段– BIND 9.x: 16段– djbdns: 4段

　 Authority 側のサーバではなくクライアント側のサーバに依存するので、使わないのが無難です。


Q.12

　 NOTIFY が導入されたので、ゾーンデータを変更した後、 serial を増やす必要はなくなった。


A.12

×　 NOTIFY が届かないこともありますし、

解釈しない実装もあります。　それ以前に NOTIFY は SOA が変更さ

れたことの通知なので、 NOTIFY が飛んできたのに実際には serial が変化していなければ、 slave はゾーン転送しないかもしれません。


FIN

•最後までお付き合いありがとうございました。

• あなたのサーバ、大丈夫でしたか ?


Errata


A.10

×　例えばクライアント側のサーバで

nishiki.gr.jp. IN NS miyama.nishiki.gr.jp.

はキャッシュ上にあり、 miyama.nishiki.gr.jp. のA レコードの TTL が切れると glue がないので authority にたどり着けなくなります。

　このような状況が発生するシナリオについては森下さんのスライド #33,#34(NS レコードの取り扱い ) を参照して下さい。

dns 設定におけるよくある間違い & dns 設定チェックリスト

Documents