この文書は、東 大亮 <dais@bonz.squares.net> が
ISC BIND バージョン9.2.5 に付属する doc/misc/migration
(ローカルコピー) を日本語に翻訳したものである。この翻訳を使用したことで発生した、いかなる損害に対する責任も、翻訳者は負わない。
auth-nxdomain については こちら(BIND 9.1.2)。
BIND 9 は BIND 8 に対してほとんど上位互換であるように作られているが、 既存の BIND 8 環境から BIND 9 へアップグレードする時に注意すべき点が いくつかある。
umask は変更されない
BIND 9 は、BIND 8 の named.conf における オプション (option) を
ほとんど (全てではない) サポートしている。
実装されているオプションの完全なリストについては
doc/misc/options を参照してほしい。
実装されていないオプションが named.conf ファイルにあると、
named は警告メッセージをログに出力するだろう。
デフォルト値が変更されたオプションについても、
named.conf で明示的にセットされていない限り
メッセージが出力される。
「transfer-format」オプションのデフォルトが
「one-answer」から「many-answers」に
変更された。スレーブサーバが many-answers ゾーン転送形式を
理解できない場合 (たとえば BIND 4.9.5 以前)、options ブロックか
server文で明示的に「transfer-format one-answer;」
を指定する必要がある。
BIND 9 では named.conf にエラーが検出されると、
起動するのを拒否する。以前のバージョンではエラーにかかわらず不完全な形で
起動していた。リロード (reload) で検出されたエラーに関しては、
サーバが停止することはない。
マスタファイル (master file) にエラーがあっても サーバが停止することはないが、ゾーンはリロードされない。
BIND 9 のログ出力カテゴリ (logging categories) は
BIND 8 と異なっている。カテゴリ毎にログ出力を
カスタマイズしているのであれば、新しいカテゴリを使うように
logging 文を変更する必要がある。
もう一つの違いは、named.conf ファイル全体が読み込まれた後に
logging 文が有効になるということだ。
すなわち、サーバが起動する時の設定ファイルのエラーに関するメッセージは、
logging 文の内容にかかわらず
常にデフォルトの宛先 (syslog) に出力されるということだ。
BIND 8 では、logging 文が現われると直ちに新しいログ出力の設定に
切り替わっていた。
これらのソースアドレス/ポートは、
それぞれ notify-source と transfer-source で
制御されるようになった。BIND 8 では query-source であった。
複数のクラス (class) は、それぞれのクラスについて、 明示的なビュー (view) へ入れなければならない。
TTL が省略されたゾーンファイルに関しては、
BIND9 は RFC1035 と RFC2308 のルールに厳密に従う。
TTLが省略されると $TTL ディレクティブで指定された値となる。
$TTL ディレクティブが無い場合は、最後に明示的に与えられた TTL の値となる。
$TTL ディレクティブが無く、最初の資源レコードにも
明示的に TTL が与えられていない場合、そのゾーンファイルは
RFC1035 に違反している。最初の資源レコードの TTL が未定義となるから
である。残念なことに、BIND 4 と BIND 8 の多くのバージョンは
そのようなファイルを警告もなく受理し、SOA レコードの
MINTTL フィールドの値を TTL が未定義となっている
部分に入れる。
BIND 9.0 と BIND 9.1 はそのようなファイルを全く受理しない。
BIND 9.2 は BIND 4/8 の非標準的な SOA MINTTL の振舞いを
エミュレートし、一応ファイルをロードする (SOA がその
ファイルの最初のレコードである場合に限る)。しかし、
「no TTL specified; using SOA MINTTL instead」という警告を発するだろう。
問題を避けるために、それぞれのゾーンファイルに $TTL
ディレクティブを置くことを推奨する。
BIND のいくつかのバージョンは、SOA で
3.002 といったような小数点付きのシリアル番号を許しており、
それを分かりにくい方法で整数に変換していた。
BIND 9 はこれをサポートしない。シリアル番号は整数でなければならない。
BIND のいくつかのバージョンは、
「host TXT "foo」のような対応しない引用符がある
TXT レコードをエラーとしなかった。
BIND 9 は次の引用符が現われるまでそれを全てリテラル文字列として
解釈するので、ゾーンファイルにそのようなレコードが存在
した場合、「unexpected end of file」 といった混乱の恐れとなる
エラーメッセージが出るだろう。
BIND のいくつかのバージョンは、次の SOA のような、括弧で 正しくクオートされていない改行を受け付けた:
@ IN SOA ns.example. hostmaster.example.
( 1 3600 1800 1814400 3600 )
これはマスタファイルの正しい文法ではなく、BIND 9 では
エラーとして取り扱われるだろう。この場合、開括弧 [訳注:「(」]
を 1 行目に移動すればよい。
$GENERATE: リテラル $ を ドメイン名に与える
$$ の使用は推奨されない。
代りに \$ を使うこと。
以前の BIND は 255文字以上の文字列を含む TXT レコードを警告無く受け入れ、プロトコルに合致するようその文字列を分割することがあった。TXT RRの文字列が長過ぎる場合、次のようなエラーに遭遇することがあるかもしれない:
dns_rdata_fromtext: local.db:119: ran out of space
ゾーンファイルに記載されるTXT RRの文字列が、255 文字以下であることを確認すること。そうでない場合は、それぞれが255文字以下となるような複数の文字列に分割して記載すること。
EDNS0
BIND 9 は自分の受信バッファサイズを知らせるために
EDNS0 (RFC2671) を使う。
これはクエリの EDNSフラグビットもセットして
DNSSEC 応答の受信を望むことを示す。このフラグビットの使用は
まだ標準化されていないが、いずれ標準になると期待されている。
EDNS0 をサポートしないほとんどの古いサーバ
(BIND の以前のバージョンも含む) は、これらのクエリに
対して FORMERR または NOTIMP 応答を返す。この場合、
BIND 9 は自動的に EDNS0 を使わないでクエリをやり直す。
不幸にも少なくとも 1 つのネームサーバ実装 (BIND ではない) が これらのクエリに対し、エラー応答をするのではなく黙って無視する。 ゾーンの全てあるいはほとんどの 権威ある (authoritative) サーバが このサーバを使っている場合、このゾーンの名前の解決が 非常に遅くなったり全く失敗してしまうだろう。 我々はそのネームサーバの製造者に連絡した。 彼らは解決のための作業をしている。
BIND 9 が、(他のBIND9 のような) EDNS0をサポートするサーバと
通信する場合、4096 バイトを超えるレスポンスが
単一の UDP データグラムとして送信されるかもしれない。このデータグラムは
IP レベルでのフラグメントの対象となる。
正しく IP フラグメントを通さないファイアウォールが原因で、
名前解決が極めて遅くなったり失敗してしまうことがある。
ゾーン転送の出力は「many-answers」フォーマットが
デフォルトになった。古いバージョンの BIND 4 は
このフォーマットを認識しない。これに
対処するには「transfer-format one-answer;」
オプションを与えればよい。しかし、これらの古いバージョン
にはすべてセキュリティ上の問題がある。スレーブサーバを
アップグレードするのが正しい対処法である。
16K バイト以上の DNS メッセージを正しく扱えないという
Windows 2000 DNS サーバに存在するバグのために、
それらのサーバへのゾーン転送が失敗することがある。
Microsoftから提供される最新のサービスパックを入手すれば
この問題を修正できる。
もしくは「transfer-format one-answer;」を設定することで、
問題を回避することができる。
http://support.microsoft.com/default.aspx?scid=kb;en-us;297936
BIND 9 はドメイン名に使われる文字集合について制限しない。 RFC2181 の第11章にしたがい、完全に 8 ビットクリーンである。
DNS で広報されるホスト名は RFC952 の規則に従うことが強く推奨されるが、 BIND 9 ではそれを強制しない。
gethostbyaddr() から得られる名前のような、
ネットワークから来たデータを十分にチェックしないで利用し、
それに予期しない文字が含まれていたときにセキュリティの
侵害となるような欠陥を含むアプリケーションが存在する。詳細は
<http://www.cert.org/advisories/CA-96.04.corrupt_info_from_servers.html>
を参照すること。以前の BIND のいくつかのバージョンでは、
ホスト名やメールアドレスとしては不適切と考えられる文字を含むデータを
破棄することで、これらの欠陥のあるアプリケーションを
攻撃から守ろうとしている。これは
named.conf の check-names または/および
resolv.conf の options no-check-names
で制御できた。BIND 9 はそのような防御は持たない。そのような欠陥のある
アプリケーションが使われていたら、アップグレードされるべきである。
ndc は rndc
に置き換えられた
ndc プログラムは rndc に置き換えられた。
これはリモートから管理することができる。
rndcはndc とは違い、設定ファイルを
必要とする。
設定ファイルを生成する最も簡単な方法は 「rndc-confgen -a」
を実行することである。詳細は
rndc(8), rndc-confgen(8), rndc.conf(5) を参照すること。
nsupdate の変更
BIND 8 の nsupdate には、そのレコードを
含むゾーンに従ってリクエストを分割するという、文書化されていない
特徴があったが、BIND 9 ではこの振舞いは実装されていない。
それぞれのリクエストは単一のゾーンに対するものでなければ
ならないが、各 update を空行または "send" コマンドで終わるように
することで、複数の更新を nsupdate の 1 回の起動で
行なうことができる。
BIND 9 はそれぞれのゾーンの権威あるデータ (authoritative data) を 分離されたデータ構造で格納する。これは RFC1035 で推奨されている ことであり、DNSSEC と IXFR で必要とされることだ。ある BIND 9 サーバが 子ゾーンとその親ゾーン両方について権威がある場合、 委譲ポイント (delegation point) では 2 つの異なるNS レコード群 を持つであろう。委譲ポイントとは、 子の頂点の権威ある NS レコードと、親の glue NS レコードである。
BIND 8 は、これらの 2 つの NS レコード群を正しく区別できず、 子の NS レコードを親に「漏洩」し、親のゾーンを黙って変更してしまう ことになる: 親からの応答やゾーン転送は、親に設定された glue ではなく 子の NS レコードである (もし存在するなら)。 子のタイプが 「スタブ (stub)」の場合、この振舞いは仕様として 文書化されており、親の設定から glue NS レコードを省略することが 許されていた。
この BIND 8 の振舞いに依存していたサイトは、省略されたあらゆる glue NS レコードと、それに必要な glue A レコードを親に 加える必要がある。
スタブゾーンはもはや NS レコードをその親ゾーンに送り込む仕組みとして 使うことはできないが、ある与えられたドメインに対するクエリを 特定のネームサーバ群へ導く方法としては依然利用できる。
umask は変更されない
BIND 8 の named は無条件に umask を 022
に変更するが、BIND 9 は変更しない。親プロセスから引き継がれた
umaskが使用される。これにより、ジャーナルファイル等の
namedが生成するファイルのパーミッションは、
BIND 8 が生成するものと異なるかもしれない。必要ならば、
named プロセスを起動する
スクリプトで umask を明示的に設定するべきである。
Copyright (C) 2004, 2005 Internet Systems Consortium, Inc. ("ISC")
Copyright (C) 1996-2003 Internet Software Consortium.
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,
INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM
LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE
OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE OF THIS SOFTWARE.
Portions Copyright (C) 1996-2001 Nominum, Inc.
Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
THE SOFTWARE IS PROVIDED "AS IS" AND NOMINUM DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL NOMINUM BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
Copyright (C) 2001, 2004, 2005 Daisuke HIGASHI. All rights reserved.