この文書は、東 大亮 mailto:dais@aso.ecei.tohoku.ac.jp が RFC 1912 "Common DNS Operational and Configuration Errors" を日本語に翻訳したものである。原文と解釈の相違がある場合は原文を正しいものとする。この文書の利用により発生したいかなる損害に対する責任も、訳者は負わない。翻訳の誤りなどの指摘は常に歓迎する。
尚、RFC 1912 の原著者である Barr 氏自身による訂正文が公開されている が、この翻訳には採り入れられていない。併せて参照すること。
このメモはインターネットコミュニティに情報を提供します。このメモはいかなる意味でもインターネットの規格を規定するものではありません。このメモの配布は無制限です。
このメモは ドメインネームシステム (Domain Name System; DNS) サーバの運用および、これらの DNS サーバが保持するデータによく見られる間違いを記述しています。さらに、DNSの運用と設定についての習慣のみならず、現在のインターネットの要求事項について要約することを試みています。また、[RFC 1537] で挙げられた問題を要約し、あるいは詳しく述べています。
ネームサーバを運用するのは単純なことではありません。事が悪くなる可能性はたくさんある上に、DNS にどのようなデータを入れるかや、サーバをどのようにセットアップするかといったような決めなければならないことがたくさんあります。このメモは、ネームサーバの運用や DNS のデータにおける、よくある間違いや落し穴を扱おうとしています。それに関連して、サーバやリゾルバのバグ、インターネットのおける DNSの運用に関するいくつかの政治的問題などの他の問題についての議論もまた扱っています。
この節では、ネームサーバがメモリへロードするゾーンデータファイルに見られる、ネームサーバの DNS データについて人々が経験する典型的な問題について議論します。
インターネットに接続されているすべてのホストに名前を持たせるべきです。そうすることの重要性はより明らかになっています。もしあなた (のホスト) が DNS に正しく登録されていなければ、インターネットにおける多くのサービスはあなた (のホスト) と話をしなくなるでしょう。
PTRレコード とAレコードを一致させてください。すべての IP
アドレスについて、対応するPTRレコードが
in-addr.arpaドメインに存在するべきです。もしホストがマルチホーム ( 2 つ以上のIPアドレスを持つ) ならば、すべての
IP アドレスに対応するPTRレコードを持つようにしてください(最初の1つだけではなく)。 PTRレコード
とAレコードが一致しないと、全く DNS に登録されていない場合と同様に、受けられないサービスが出てくるかもしれません。また
PTR レコードは、CNAMEで定義された別名ではなく、正当な A
レコードを指していなければなりません。これを自動的にチェックするソフトウェアを使ったり、矛盾のないデータを自動的に生成するデータベースから、
DNSデータを作ることが強く推奨されます。
DNS ドメインネームは単一のドットで区切られた「ラベル」から成ります。 DNS はドメインネームの中で使用できる文字の規則に関して非常にリベラルです。しかし、あるドメインネームがあるホストを命名するために使われている場合、ホスト名について制限している規則に従うべきです。さらに、その名前がメイルのために使われている場合、メイルアドレスの名前に関する命名規則に従っていなければなりません。
ホスト名に使用できる文字は、ASCII
ラテン文字と数字と「-」だけです。ラベルは全部が数字であってはなりませんが、数字で始まるものもあります(例えば
3com.com)。ラベルの最初と最後の文字はラテン文字か数字でなければなりません。 [RFC
1035] と [RFC
1123] を参照してください。 (最初に[RFC
1035]が、ラベルがラテン文字から始まるという制限をつけました。 [RFC
1123] はその制限を緩和していますが、これによりいくつかの古いホストで問題が起きていることが報告されています。)
いくつかのインターネットホスト名がこの規則に違反していることに注意してください (411.org,
1776.com)。ラベルにアンダースコアを利用することが[RFC
1033] で許されていますが、 [RFC
1033] は 情報提供 (informational) が目的であり、標準(standard)を定義するものではありません。少なくとも 1
つのある有名なTCP/IPの実装が、ラベルにアンダースコアを含む名前のホストと通信することを拒否します。 [1035]
における言明は、これらの規則が自主的 (voluntary)
なものに近いということに注意しなければなりません。問題を最小限に抑えることを願う人々のためにその規則は存在します。インターネットホスト名の規則は SMTP
(RFC 821を参照) で使われるホストとアドレスにも適用されることに注意してください。
ドメイン名がメイルに使われる場合 (SMTP が介在しない場合)、それは [RFC 822]
の規則に従っていなければなりません。実際は、その規則は上の規則よりリベラルです。メイルに使われるラベルは「specials」と制御文字および空白文字を除く、任意のASCII
文字を使うことができます。「specials」はアドレスの解析に使われる特定の記号で、「()<>@,;:\".[]」です
(「!」は [RFC 822] では現れませんでしたが、 RFC 976で定義される UUCP
メイルと衝突するので使うべきではありません
)。しかしながら、今日インターネットにおいて、メイルに使われるほとんど全ての名前はホスト名にも使われているので、これらの緩和された規則を使ったアドレスに出会うことは稀です。しかし、メイルソフトウェアはこれらのアドレスを受け入れるように、十分にリベラルでロバストに作られているべきです。
inet_ntoa()ライブラリ関数のもう 1 つの文法に適合するアドレスを持たせないように気をつけるべきです。例えば
0xe は正しい名前ですが、もしあなたが「telnet 0xe」とタイプしたとしたら、
0.0.0.14という IP アドレスへ接続することになるでしょう。いくつかの正しくない実装の
inet_ntoa() ルーチンは、例えばx400のようなアドレスを IP
アドレスとして認識するという噂もあります。
ある種のオペレーティングシステムは、自分のホスト名の長さについて制限があります。厳密には DNS の問題ではありませんが、ホストの名前を選ぶ前にオペレーティングシステムのほうの長さ制限に注意すべきです。
多くの資源レコード (resource records; RR と略されます) は 1 つ以上の引数をとります。HINFO は
RPと同じく 2
つの引数をとります。十分な引数を与えないと、サーバがそのレコードに関してゴミを返すこともあります。もしデータに空白を入れる必要があれば、クオートで囲まなければなりません。
すべてのゾーンの SOA レコードに、あなたのサイトで DNS を管理している人
(一般的に「hostmaster」と呼ばれます)へ届く電子メイルアドレスを記入することを忘れないでください。まずは、アドレスの「@」は「.」に置き換えなければなりません。このアドレスには「@」記号を入れないでください。すでにこのアドレスのローカル部に「.」が含まれる場合
(例えば
John.Smith@widget.xx)、その前に「\」を付加することで「.」をクオートする必要があります
(John\.Smith.widget.xx
のようになります)。あるいは、汎用的な名前である「hostmaster」を使うこともできます
(この方法が好ましいです)。それをメイルエイリアスを使って適切な人々へ転送します。そのゾーンの連絡先としての電子メイルアドレスをこのフィールドを使い自動的に生成するソフトウェアが存在します。もしこのフィールドが正しい形式でないと、このソフトは停止するでしょう。
1人あるいはそれ以上の実在する人へ届くアドレスの必要があります。そのアドレスは、正しくない DNS
データの報告からセキュリティ関連事故の報告まで、あらゆることに頻繁に使われるからです。
いくつかの BIND のバージョンでは、シリアル番号 (serial
number)に小数を使うことが可能ですが、使わないでください。小数のシリアル番号は、内部でいいかげんな方法で符号無し 32 ビット整数へ変換されます。
n.m と表現されたシリアル番号を変換する公式は n*10^(3+int(0.9+log10(m))) +
m であり、むしろ予期しない値になります。数字としては大きくなるように増加させる (多分 SCCS で自動的に生成させているのかもしれません)
ことで小数のシリアル番号を利用することが単純に可能のように見えますが、上の変換を行うことで、以前のものよりも小さいシリアル番号を生成してしまうことになります。BIND
の最近のバージョンでは、小数のシリアル番号を正式に推奨していません。推奨される形式は YYYYMMDDnn
(YYYY=年、MM=月、
DD=日、nn=リビジョン番号) です。この形式を使えば 4294 年まで桁溢れを起こすことはないでしょう。
SOA レコードに対し、理に叶ったタイマ値を選んでください
(下の値はゾーンデータの中で秒単位で表現されていなければなりません):
そのゾーンのシリアル番号が増えたかどうかを、セカンダリサーバがプライマリサーバへ問い合わせる頻度です(増えたことを知ると、そのゾーンのデータのコピーを要求します)。どれだけ長い間、セカンダリが古いデータを余裕を持って保持していられるかをセットしてください。ネットワーク帯域が少々増えても気にしないのであれば、この時間を短くする (20 分から 2時間) ことができます。インターネットの接続が遅かったり、要求に応じて接続するような形式の場合、より長くすることができます(2時間から12時間)。最近の版 (4.9.3) の BIND は、データが変更されたことをセカンダリへ自動的に通知するオプションのコードを含んでおり、この期限を大きな値 (1 日以上)にセットすることが可能になっています。
セカンダリによる最後のリフレッシュ (Refresh) 動作においてプライマリと通信できなかった場合に、再試行する前にこの時間だけ待ちます。この値は、プライマリからセカンダリまでのネットワーク距離が長かったりプライマリが停電しがちな場合でない限りは、他の値に比べて重要ではありません。典型的にはリフレッシュ (refresh) 間隔の何分の1かの値になります。
セカンダリがプライマリと通信できない場合、どれだけ長い間ゾーンデータのコピーを正当なものとして扱うかを示す時間です。この値は、大きな停電が通常続く時間よりも長くあるべきで、最小有効期限 (minimum) や 再試行時間 (retry) よりも長くなければなりません。それは、セカンダリが新しいコピーを入手する機会を得る前に、セカンダリがゾーンデータを無効なものとしてしまうことを防ぐためです。ゾーンデータを無効にした後、依然セカンダリはプライマリへの通信を試みますが、そのゾーンについてのネームサービスは提供しなくなります。 2 週間から 4 週間が提案されている値です。
資源レコード (resource recoerd) のデフォルト有効期限 (TTL; time-to-live) です。他のネームサーバのキャッシュに残る時間です。 ([RFC 1035] はこれをその最小値と定義していますが、大抵サーバはこれをデフォルト値として実装しているようです)。これは断然最も重要な時間値です。あなたがネームサーバをどの位の頻度で更新するかで与えられる、適当な長さを設定してください。もし大きな変更を計画しているのであれば、前もってこの値を一時的に小さくすることはよいアイディアです。それから以前の Minimum (最小有効期限) だけ待ち、変更を実行し、それに間違いが無いかどうかを確かめ、そしてこの値を元に戻します。1 日から 5 日が典型的な値です。この値は各資源レコードの設定を優先させることができることを覚えておいてください。
このように、タイマの典型的な値というのは大きく変わります。 [RFC
1033] のようなよく知られた文書では、最小有効期限 (minimum TTL) に 1
日を推奨していますが、これは常に変化するデータを持つゾーン以外では小さすぎる値だと現在考えられています。一度 DNS が安定したら、3
日かそれ以上のオーダの値が推奨されます。よく参照される、あるいはあまり変更されない資源レコードについて各々有効期限を長いもの ( 1 週間から 2 週間)
に上書きすることもまた推奨されています。例えば メイルホストの MX、A および
PTR レコード、ゾーンの NS レコード、ネームサーバの A
レコードです。
A レコードグルー(glue)レコードは、ネームサーバに「ブートストラッピング」情報を提供するために、 NSレコードに連携する
A レコードです。例えば:
podunk.xx. in ns ns1.podunk.xx.
in ns ns2.podunk.xx.
ns1.podunk.xx. in a 1.2.3.4
ns2.podunk.xx. in a 1.2.3.5
この中の A レコードが「グルーレコード」として参照されます。
グルーレコードは委譲されている現在のゾーンのサブドメインに位置するネームサーバの、正引きゾーンファイルに中にのみ必要です。
in-addr.arpa ゾーンのファイルに A レコードが存在するべきではありません (RFC 1101
スタイルのサブネットマスクの表現を使っている場合を除きます)。
ネームサーバがマルチホーム ( 2つ以上の IP アドレスを持つ ) 場合、全てのアドレスをグルーレコードに書かなければなりません。ネームサーバの全てのアドレスが見つからないという事態を引き起こす、 TTL 値の違いによるキャッシュの矛盾を防ぐためです。
NSレコードを加える度に常にグルーレコードを加えるという悪い習慣を持った人がいます。ゾーンファイルに重複するグルーレコードがあると、ネームサーバの
IP アドレスを変えたり削除したりすることが難しくなります。何故いくつかのホストの古い IP
アドレスに出くわすのかを理解するのに、あなたは何時間も費やすことでしょう。それは、誰かが他のファイルに存在するグルーレコードの変更あるいは削除を忘れたからです。新しいバージョンの
BIND は、ローカルゾーンファイルの中のこれらの余分なグルーレコードを無視するようになるでしょう。
古い版の BIND (4.8.3 以前) では、セカンダリへのゾーン転送データの中にこれらの余分なグルーレコードが挿入されていると問題が発生します。もし これらのグルーレコードのうちの一つが間違っていたら、この間違いは他のネームサーバへも伝播します。もし 2 つのネームサーバが互いに相手のゾーンのセカンダリである場合、どちらかのサーバが古いグルーレコードをもう一方へ出し続けることがあります。この古いデータを取り除く唯一の方法は、両方のサーバを停止し、バックアップファイルを削除し、再起動することです。それと関連して、同じバージョンの BIND はセカンダリでない他のネームサーバから得られた偽のデータ (ルートゾーンのデータのような) にもっと簡単に汚されやすいという傾向があります。
CNAME レコードCNAMEレコードは他のどんなデータとも一緒に存在することが許されていません。言い換えれば、もし
suzy.podunk.xx が sue.podunk.xx
の別名の場合、suzy.podunk.xx に MX レコードを持たせることはできません。
A レコードも、 TXT レコードさえも持たせることはできません。特に、次のように
CNAME と NS レコードを一緒にしてはいけません !:
podunk.xx. IN NS ns1
IN NS ns2
IN CNAME mary
mary IN A 1.2.3.4
これは、しばしば経験の少ない管理者が、ドメイン名もホストとするための簡単な方法として試みることです。しかし BIND のような DNS サーバは
CNAME を検出し、その名前の他の資源レコードを追加することを拒否するでしょう。他のレコードは CNAME
と一緒に存在することが許されないので、 NS レコードは無視されます。したがって、podunk.xx ドメインのすべてのホストも同様に無視されることになります!
ドメインをホストとしたい場合は次のようにしてください:
podunk.xx. IN NS ns1
IN NS ns2
IN A 1.2.3.4
mary IN A 1.2.3.4
CNAME を乱用しないでください。 CNAME
はホストの名前を変えようとする時に使ってください。しかし、それを削除するつもりでいてください。
(そしてそのことをユーザに周知させてください)。ただし、CNAME は一般的なサーバの名前をつけるのに便利です
(そうすることは推奨されます)。 ――「ftp」は FTP サーバ、「www」は Web
サーバ、「gopher」は Gopherサーバ、「news」は Usenet news サーバというように。
別名がつけられているホストを削除する場合に、その別名を定義する CNAME
レコードを削除するのを忘れないでください。そのような「新鮮でない CNAME」 は資源の浪費です。
MX、CNAME、 NS
のような、他の名前を指している資源レコードと共同で CNAME を使わないでください。 (クラスレスな
in-addr ドメインの委譲を行うときは、 PTR に関しては例外です。) 例えば、これは推奨されません:
podunk.xx. IN MX mailhost
mailhost IN CNAME mary
mary IN A 1.2.3.4
[RFC
1034]の 3.6.2節では、こういうことをすべきでないと述べられています。また [RFC
974] は、MX レコードは CNAME
で定義された別名を指さないこととしています。データへのアクセス時に不必要に冗長な動作が発生することになり、答えを得るために DNS
リゾルバやサーバがさらに働く必要があります。もしあなたが本当にこれをしたいなら、m4 のようなプリプロセッサをホストファイル (host files)
に使って同じことを達成できるでしょう。
CNAMEを指す CNAME のような、連鎖した (chained)
レコードは管理を簡単にするかもしれませんが、いくつかのリゾルバにはループを正しくチェックするのに失敗するというじれったいバグが存在することが知られています。その結果、いくつかのホストがそのような名前を解決できなくなるかもしれません。
CNAME を指す NS レコードは不正であり、現在の BIND
サーバと悪い具合いに衝突するでしょう。実際、BIND の実装ではそのようなレコードは無視され、おそらく不十分な委譲 (lame delegation)
をもたらします。DNS の NS レコードを偽造することを防ぐ、ある程度のセキュリティチェックが BIND
でなされています。また、旧い BIND サーバは、別名がつけられたネームサーバのアドレスを解決するための無限ループに捕えられ、DNS
リクエストを絶え間なく送信することになってしまうと報告されています。
MX レコードすべてのホストに MX レコードを与えるのはよい考えです。自分自身を指すものであってもです! いくつかの メイラーは
MX レコードをキャッシュするでしょうが、メイルを送信する前に MX をチェックする必要が常にあるでしょう。
MX 問い合わせに対する返答には大抵 MX ホストの IP アドレスも含むので、もしサイトが MX
レコードを持たない場合メール 1 通毎に 1 回分の余計な問い合わせが発生するかもしれません。インターネットの SMTP メイラーは
MX の機構をサポートすることが求められています。
メイルを送受信しないつもりのホストにも MX
レコードを与えて下さい。これらのホストに関係するセキュリティ関連の問題が存在する場合、「本来の」(訳注:
サイトのセキュリティに責任を持つ人へ届くメイルを受け取るべき)
ホストであるか電子メイルを受信できない単なる端末やパーソナルコンピュータであるかを初めに確認せずに、そのサイトの postmaster や root
へメイルを誤って送信しようとするでしょう。これらのホストに MX
レコードを与えていれば、電子メイルは本来の人へリダイレクトされます。そうでなければ、そのメイルはメイラーがあきらめるまで数時間または数日間キューに居座るでしょう。
MX
レコードを加える時には、最初のホストを「local」として扱うかどうかをターゲットのメイラーに教える必要があることを忘れないでください(例えば sendmail
では 「Cw」というフラグです)。
(メイルルーティングのバックアップ目的などのために) 外部のホストを指す MX
レコードを加える時は、そのサイトの許可を得るようにしてください。そうしないと彼らを驚かせ、なんらかの行動を起こさせるでしょう。
(たとえばあなたのメイルを捨てたり、あなたの 親 DNS 管理者やネットワークプロバイダのような上級の権威へ連絡したりするでしょう。)
WKSWKS レコードは [RFC
1123] で非推奨とされています。 LISP マシンの間で内部的に使われる以外は、何ら便利な機能はありません。これは使わないでください。
HINFOHINFOレコードに関しては、セキュリティ的な問題があるという人がいるでしょう
(ハードウェアやオペレーティングシステムのベンダを広報するので、そのセキュリティホールをシステマティックに攻撃することができます)。もしこれを敢えて使うならば、ベンダのセキュリティ問題を常に追いかけるべきです。しかしながら、これらは便利です。
HINFO は 2 つの引数をとることを忘れないでください。ハードウェアタイプとオペレーティングシステムです。
HINFO は他の情報を提供する目的で、誤って利用されることがあります。これはマシン自身の特定の情報を提供するものです。 DNS
でホストに関する他の情報を示す必要があれば、TXTを使ってください。
TXTTXT
レコードには特別な定義はありません。ほとんど何でも書くことができます。ホストの一般的な説明を書くのに使われることもありますし、ホストの位置や主要なユーザのような特定の情報を書くこともあります。電話番号さえ書かれるかもしれません。
RPRP レコードは比較的新しいものです。そのホストに関して「対応できる人(Responsible
Person)」の電子メイルアドレスを指定するのに使われます。TXT でさらなる情報を得ることができます。[RFC
1183] を参照してください。
ワイルドカード MX は IP 接続ではないサイトに便利です。よくある間違いは、あるゾーンのワイルドカード
MXがそのゾーンのすべてのホストに適用されると考えてしまうことです。ワイルドカードMXは DNS でその
ゾーン のまったく定義されていない名前に対してのみ適用されます。
podunk.xx. IN NS ns1
IN NS ns2
mary IN A 1.2.3.4
*.podunk.xx. IN MX 5 sue
mary.podunk.xx 宛のメイルはそれ自身に配送されます。 jane.podunk.xx
等の、上に現れない名前のホスト宛のメイルが MXに送信されます。ほとんどのインターネットサイトにはワイルドカード
MXは不要です。各ホストについて明示的なMX レコードを与える必要があります。
ワイルドカードMXには害になることもあります。元々失敗すべき操作も、成功させてしまうことがあるからです。ドメイン
「widget.com」の誰かが
「joe@larry」宛てにメイルを送ろうとしているという場合を考えてみます。 ホスト 「larry」
が実際には存在しなければ、メイルは直ちにバウンス (bounce; 送信人に戻される) するべきです。しかし、ドメイン検索のためにこのアドレスは
「larry.widget.com」と解決され、さらにワイルドカード MX により
DNS的には正しいアドレスとなります。あるいは、誰かが単にアドレスのホスト名を打ち間違ったのかもしれません。メイルメッセージはメイルホストへ渡され、 "I
refuse to talk to myself" とか "Local configuration error"
のような、不可解なエラーメッセージとともに受け取り拒否されます。
インターネットに直接接続されていないホストを多く抱えていて (例えばファイアーウォールに囲まれているなど)、管理上または政治上の理由ですべてのホストに
MX
を与えることが困難だとか、全ての電子メイルアドレスを特定のドメイン名のうしろに「隠したい」場合、ワイルドカードMXは便利なものです。この場合、DNS
を内部用と外部用の二つに分割しなくてはなりません。外部用 DNS は、少数のホストと明示的な MX
レコードと、そして内部ドメインのためのワイルドカード MX を1つあるいは複数持たせます。内部用 DNS は全てのホストに明示的な
MX レコードを持たせワイルドカードは使わない完全なものとします。
ワイルドカードAレコードやCNAMEも可能ですが、ユーザを混乱させやすいものです。よく考えないで使うと悪夢にうなされることになるでしょう。ドメインに登録されていないホストへのあらゆる
telnet や ftp は (またもやドメイン検索のために) 1 つのアドレスにリダイレクトされる結果をもたらします。そのようなあるワイルドカード
CNAME(*.edu.com)
が原因となって、予期しないドメイン検索動作が発生し、全インターネットに影響するサービス停止とセキュリティ低下の可能性という悪夢を引き起こしました。素早い修正が行なわれ、RFC
([RFC
1535])にも問題が記述されています。
NSレコード)ドメイン毎にネームサーバを少なくとも 2
つ持つことが求められています。それ以上の数を持つことが好ましいです。セカンダリをあなたのネットワークの外部に置いてください。あなたがそのセカンダリをコントロールできなければ、定期的にチェックして現在のゾーンデータを持っているか確かめてください。それらのネームサーバへあなたのホストに関する問い合わせをしたときに、「権威のある」(authoritative)
応答が返ってくるべきです。そうでない場合、これは「不完全委譲」(lame delegation) と呼ばれます。ネームサーバが
(NSレコードにより)
ゾーンのネームサービスを提供する責任を委譲されているのに、ぞのゾーンのネームサービスを行わない場合、不完全委譲が発生します
(大抵はそのゾーンのプライマリあるいはセカンダリとして設定されいないためです)。
「古典的な」不完全委譲は次の例で示されるでしょう:
podunk.xx. IN NS ns1.podunk.xx.
IN NS ns0.widget.com.
「podunk.xx」
は最近つくられた新しいドメインで、「ns1.podunk.xx」はゾーンのネームサービスを行うように設定されています。すべての設定がすっかり終了したわけではなく、「ns0.widget.com」の管理者はこれを正しくセカンダリとして設定していません。したがってこのセカンダリは
podunk.xx の情報を持っていません。それにもかかわらず、DNS
はこのネームサーバが情報を持っていると言っています。不完全委譲は、運が良ければ余分な DNS
トラフィックを生成するだけで済みます。最悪の場合、名前解決できないホストや、送信できずに戻ってくるメイルがあるかもしれません。
また、ネームサーバが他のホストに移ったりセカンダリのリストから削除されることがあります。不運にも
NSレコードのキャッシュのために、そのホストがネームサービスの提供を停止した後でも、そのホストがセカンダリであると多くのサイトは思っているでしょう。キャッシュが生きている間の不完全委譲を防ぐために、旧いネームサーバでも、ゾーンとその親ゾーンの
Minimum(最小TTL) + Refresh(リフレッシュ) の最大値の期間はサービスを続けてください(2.2節を参照してください)。
プライマリやセカンダリを削除したり変更する場合は、常に当事者間(サイト自身、その親、セカンダリを置いているサイト)
のある程度の共同作業が発生します。プライマリが移動する場合、すべてのセカンダリサーバの named.boot (訳注: BIND8 は
named.conf)
が更新され、サーバがリロードしたことを確認してください。セカンダリが移動する場合、プライマリと親レベルの両方のアドレスレコードが変更したことを確認してください。
関係のないサイトが、そのサイトの付加的なネームサービスを行うように期待して、
"ns.uu.net"のようなよく知られたネームサーバを選び、単純にそれを NS
レコードに追加することがあるという報告があります。これは、負荷の高いネームサーバにさらにトラフィックを追加するもので、不完全委譲の悪い形態です。不完全委譲を持つサイトの管理者に連絡してあげてください。不完全委譲を検出したり、アクティブに見つけるための様々なツールが利用できます。
BIND の配布物に含まれる寄贈ソフトウェアのリストを見てください。
親ドメインがあなたのゾーンと同じ
NSレコードを持っていることを確認してください(in-addr.arpaゾーンも同様に!)。あまりにも大量にリストしないでください
(推奨される最大値は 7
つです)。これは管理を面倒にするだけで、大変よく知られたトップレベルドメインやルートゾーンだけに必要とされるものです。NS
クエリに対する応答において、512 バイトという UDP パケットの 制限を超えてしまう危険もあります。これが起こると、リゾルバは TCP
リクエストを使ったものに「フォールバック」するでしょう。これはネームサーバの負荷の増加をもたらします。
信頼性を向上させるのと同様、遅延を小さくするためにセカンダリサーバの地理的な位置を選択することは重要です。常にネットワークのトポロジに気をつけてください。例えば、あなたのサイトがローカルあるいは国際的な遅いリンクの終点にある場合、平均的な遅延時間を減らすために、リンクのもう片方の位置にセカンダリを置くことを考えてください。あなたが利用できるセカンダリの情報に関して、インターネットサービスプロバイダや親ドメインに問い合わせてください。
この章では、実際のネームサーバ (特に BIND) の運用に関して人々が陥りやすい問題を議論します。データが正しいだけでなく、そのデータが利用できるようにネームサーバが正しく運用されなければなりません。
ゾーンはぞれぞれシリアル番号を持っています。これは、誰が最新のデータを持っているかを追跡するために使います。プライマリが持っているゾーンのシリアル番号の方が大きい場合にだけ、そのセカンダリはプライマリに対して新しいゾーンデータを要求します (特別な場合については下記を参照してください)。
データを変更する時はシリアル番号を変更することを忘れないでください! 変更しないと、セカンダリは新しいゾーン情報を転送しないでしょう。ソフトウェアでシリアル番号を自動的に増加させるのも良い考えです。
シリアル番号を間違って大きすぎる値にしてしまい、小さい値にリセットしたい場合は次のようにしてください:
その「正しくない」シリアル番号に 2147483647 を足してください。それが 4294967296 を超えているなら、4294967296 を減じてください。その値をシリアル番号として与えてください。そして、それがすべてのサーバに伝播されるように、リフレッシュ時間の2倍の期間待ってください。
以上を、シリアル番号が目標とするシリアル番号より小さくなるまで繰り返してください。
目標とするシリアル番号に上げてください。
この手続きはセカンダリが古い BIND (4.8.3 以前) の場合、うまくいかないでしょう。もしそうであれば、そのセカンダリの管理者に連絡し、セカンダリサーバを停止してセーブされているバックアップファイルを削除し、サーバを再起動してもらってください。シリアル番号を変更する時は注意してください。―― DNS の管理者はネームサーバを再起動するのを嫌がります。キャッシュされたデータを失うからです。
ゾーンファイルを構築するにあたって、役に立ついくつかのヒントを示します。間違いを発見するのに役立ち、同じ間違いを繰り返すことを防止します。
DNS ファイルは一貫したスタイルにしてください。 $ORIGIN が podunl.xx.
の場合、次のようにエントリを書かないようにしてください:
mary IN A 1.2.3.1
sue.podunk.xx. IN A 1.2.3.2
あるいは:
bobbi IN A 1.2.3.2
IN MX mary.podunk.xx.
全て FQDN (Fully Qualified Domain Names; 完全修飾ドメイン名) とするか、非修飾名とするかのどちらかにしてください。あるいは右側はすべて FQDN とし、左側を非修飾名としてください。とりわけ一貫性を持たせてください。
フィールドの間にはタブを使い、列を揃えてください。置き忘れたフィールドの発見を容易にします
(「IN」といったいくつかのフィールドは前の行から受け継がれ、ある状況では省略されることに注意してください。)
1つのホストに対して複数のレコードを定義する場合は、ホスト名を何回も書く必要はないことを覚えておいてください。ホストに関連するレコードが、すべてそのファイルに集まっているようにしてください。ホストを削除したり名前を変更する時が来た場合に、物事を単純に済ますことになります。
いつも $ORIGIN に注意してください。 FQDN の末尾に「.」が無いと、それは FQDN として認識されません。
FQDN でないものは、ネームサーバによって $ORIGIN
が追加されるでしょう。それらの末尾のドットを何重にもチェックしてください。特にin-addr.arpa
ゾーンのファイルについては、最もチェックが必要とされます。
SOA および WKSレコード (括弧で囲まれるレコード)
の文法に注意してください。それらのレコードの解析に関しては、 BIND はそれほど融通が利きません。BIND のドキュメントを参照してください。
dig (またはお気に入りの DNS ツール。BIND の配布物にたくさん含まれています。)
でリゾルバへ問い合わせることで、あなたが入力あるいは変更したデータを検証してください。数秒の二重チェックが、何時間にも渡るトラブル、メイルの損失、様々な頭痛の種を防ぎます。また、ネームサーバをリロードした時は
syslog の出力をチェックするようにしてください。 DNS のデータやブートファイルに重大な間違いがあれば、 named はそれを報告するでしょう。
ネームサーバにロードされる前にデータファイルの健全性をチェックするソフトウェアと、ネームサーバにすでにロードされたデータをチェックするソフトウェアの両方を使ってチェックを自動化することが強く推奨されます。BIND の配布物にはそのための寄贈ソフトウェアがいくつか含まれています。
ある種のゾーンがネームサーバの設定に存在するべきです:
primary localhost localhost
primary 0.0.127.in-addr.arpa 127.0
primary 255.in-addr.arpa 255
primary 0.in-addr.arpa 0
これらは「特別な」アドレスのためのサービスと、ブロードキャストあるいはローカルアドレスに対して偶然発生したクエリがルートネームサーバへ送信されることを無くすために設定します。これらのファイルは、すべてあなたが保守している他のゾーンと同じ
NSおよびSOA レコードを含みます。ただし、その内容は変更されることはないので、おそらく
SOA のタイマは非常に長くすることができます。
「localhost」アドレスは常にローカルのホストを示す「特別な」アドレスです。次のような行を含んでいるべきです。
localhost. IN A 127.0.0.1
「127.0」ファイルは次のような行を含んでいるべきです:
1 PTR localhost.
ローカルのドメインを加えるべきか否か、ということについては大いに議論がなされました。結論は
「localhost.」が最善の解であろう、ということです。その理由は:
「
localhost」はいくつかのシステムで使われ、正しく動くことが期待されている。
127.0.0.1を 「localhost.dom.ain」へ変換することは、いくつかのソフトウェアが、「localhost」が 「localhost.dom.ain」と同一ではないために意図せずそのループバックインタフェイスへ接続することになるかもしれない。
「255」および 「0」ファイルは NS および
SOA レコード以外は何も含むべきではありません。
BIND の将来の版は、設定を付加しなくてもこれらのデータのすべて、あるいはいくつかを自動的に挿入するかもしれないことに注意してください。
非常に古い DNS リゾルバ には、IP アドレスによく似た名前に対するクエリを消失してしまうというバグがあります。ユーザは IP アドレスを与えたが、ソフトウェアがそれを名前解決する必要がないことを理解していないためです。このバグは修正されてきましたが、それでも時々現れます。このバグはこれらのクエリが直接ルートサーバに送信されてしまい、もともと負荷が高い DNS にさらに負荷をかけることになるので、重要なものです。
ほかのセカンダリネームサーバから、あるセカンダリネームサーバに[訳注: データを]流すことは可能ですが、ネットワークトポロジのためにそうする必要がある場合以外は推奨されません。それは、嘘の TTL 値のような問題につながる場合が知られています。これは古い、あるいは欠陥のある DNS の実装が原因ですが、それでもセカンダリを他のセカンダリに連鎖させるべきではありません。ゾーンデータの更新に時間がかかるだけでなく、信頼性に関する依存性が増えるからです。
DNS は主に UDP (User Datagram Protocol) メッセージで動いています。いくつかの UNIX オペレーティングシステムでは、 CPU サイクルを節約するために UDP のチェックサムの計算をオフにしてします。その比較的なメリットは長い間議論されています。しかしながら、CPU の速度が向上するにつれそのパフォーマンスについての検討はそれほど重要でなくなっています。DNS だけでなく、UDP を利用する他のサービス (例えば NFS) でデータが壊れることを防ぐために、チェックサムの計算をオンにすることが強く推奨されます。チェックサムが有効になっているかどうか確かめるために、あなたが使っているオペレーティングシステムのドキュメントをチェックしてください。
セキュリティに関する問題はこのメモでは論じられていません。