ネットワークワーキンググループ R. Elz Request for Comments: 2182 University of Melbourne BCP: 16 R. Bush 分類: 現状の最良の方法 RGnet, Inc. (Best Current Practice) S. Bradner Harvard University M. Patton Consultant 1997年7月 セカンダリーDNSサーバーの選択と運用 本文書の位置づけ 本文書は、インターネットコミュニティに対して現時点における最良の方法 を示し、改善のための議論や提案を求めるものである。本文書の配布は 制限されない。 要旨 Domain Name Systemは、委任された各ドメイン(ゾーン)について、 複数のサーバーが存在することを必要とする。本文書はDNSゾーンの セカンダリーサーバーの選択について論じるものである。 セカンダリーサーバーを選択する際には、各サーバーの物理的位置と トポロジカルな位置両方が検討材料となる。また、あるゾーンに対する 適切なサーバー数について検討し、幾つかの一般的なセカンダリー サーバー保守の問題について考察する。 Elz, et al. Best Current Practice [Page 1] RFC 2182 Selection and Operation of Secondary DNS Servers July 1997 目次 要旨 ....................................................... 1 1 はじめに ................................................... 2 2 定義 ....................................................... 2 3 セカンダリーサーバー ....................................... 3 4 到達不能なサーバー ......................................... 5 5 何台のセカンダリーが適切か？ ............................... 7 6 適切なセカンダリーサーバーの発見 ........................... 8 7 シリアル番号の保守 ......................................... 9 セキュリティに関する考察 .................................. 11 参考文献 ................................................... 11 謝辞 ....................................................... 11 著者の連絡先 ............................................... 11 1. はじめに 今日のDNSの運用の中で発生する多くの問題は、DNSゾーンに対する セカンダリーサーバーの選択が貧弱であることが主な原因である。 あるゾーンに対するDNSサーバーを、地理的な位置とネットワーク接続性の 多様化を考慮して配置することにより、そのゾーンの信頼性を向上させ、 全体的なネットワークパフォーマンスおよびアクセス特性を改善することが 可能となる。サーバー選択において他の検討を行う場合、それによって 予期しない信頼性の低下を引き起こしたり、ネットワークに付加的な要求を 課す可能性がある。 本文書は、あるゾーンに対するセカンダリーサーバーを選択する際に 考慮すべき多くの問題について論じる。本文書は、任意のゾーンを 提供するための、最善のサーバー選択法に関するガイドラインを提示する。 2. 定義 本文書では、本文書内部に限定して以下の定義を使用する。 DNS Domain Name System [RFC1034, RFC1035]。 ゾーン DNS木構造の一部で、一体として処理される。 正引きゾーン 名前からホストアドレス、メール送信先(mail exchange (Forward Zone) target)、その他に対応するデータを含むゾーン。 Elz, et al. Best Current Practice [Page 2] RFC 2182 Selection and Operation of Secondary DNS Servers July 1997 逆引きゾーン アドレスから名前に対応させるために使用する (Reverse Zone) データを含むゾーン。 サーバー 問い合わせに対して応答を提供可能なDNSプロトコルの 実装。応答はサーバーが既知の情報から得られるか、 または他のサーバーから得られる情報である。 権威サーバー DNSゾーンの内容を自身が保持する情報から得るサーバー。 したがってそのゾーンに関する問い合わせに対して、 他のサーバーに問い合わせをする必要なく応答可能。 明記サーバー ゾーンの中に、そのサーバーの"NS"リソース (Listed Server) レコード(RR)が存在する権威サーバー プライマリーサーバー 権威サーバーの中で、最初にゾーン情報がサーバー上に 設定されるもの。マスターサーバーとも呼ばれる。 セカンダリーサーバー ゾーンの情報をプライマリーサーバーからゾーン転送の 仕組みを使用して得る権威サーバー。スレーブサーバー とも呼ばれる。 ステルスサーバー 権威サーバーの一つで、通常はセカンダリーである。 明記サーバーではない。 リゾルバー DNSのクライアントで、ゾーンに含まれる情報を DNSプロトコルを使用して検索するもの。 3. セカンダリーサーバー 各ゾーンに対して複数のサーバーを持つ主な理由は、インターネット全体を 通して、ゾーンから得られる情報をクライアントが広く確実に、たとえ1台の サーバーが使用不可能または到達不可能になってしまったとしても利用できる ようにするためである。 また、複数のサーバーは名前解決の負荷を分散させるとともに、サーバーを リゾルバーのより近くに置くことにより、システムの全体的な効率を改善させる。 これらの目的について、ここではこれ以上触れない。 複数のサーバーが存在する状況では、通常一台のサーバーがプライマリー サーバーになり、他のものがセカンダリーサーバーになる。ある種の特別な 設定では複数のプライマリーサーバーを使用するが、データの不整合を 引き起こす可能性があり、推奨されないことに注意してもらいたい。 Elz, et al. Best Current Practice [Page 3] RFC 2182 Selection and Operation of Secondary DNS Servers July 1997 プライマリーサーバーとセカンダリーサーバーの違いは、それらのサーバーが 管理するゾーンのネームサーバーにだけ意味がある。そのゾーンを管理しない ネームサーバーにとっては、それらは単に複数のサーバーでしかない。 最初のアクセスでは、全てのサーバーは等しく扱われる。たとえゾーンを 委任した親サーバーがアクセスする場合でもそれは変わらない。 リゾルバーは大抵の場合、様々なサーバーのパフォーマンスを測定し、 ある定義に従う"最善"なサーバーを選択し、ほとんどの問い合わせで そのサーバーを優先して使用する。これらは自動で処理されるものであり、 ここでは考慮しない。 プライマリーサーバーはゾーンファイルの複製元を持つ。 つまり、プライマリーサーバーにおいてデータがDNS外のソースから DNS内へと入力されるということである。セカンダリーサーバーは、 プライマリーサーバーからゾーンを得る際に使用するDNSプロトコルの 仕組みを利用して、ゾーンのデータを取得する。 3.1. セカンダリーサーバーの選択 セカンダリーサーバーを選択する際には、起こり得る様々な障害形態に 対して注意を払うべきである。サーバーは、起こり得るあらゆる障害に おいても、インターネットの大部分で少なくとも1台のサーバーが利用可能で あるように設置されるべきである。 したがって、全てのサーバーを一つのサイト内に設置するというのは、 手配が容易で管理も楽だが、良いポリシーではない。以下に示す障害が 何か一つでも発生すれば、全てのサーバーがインターネットから切り離され得る からである。単一リンクは切れることがあるし、敷地・建物・部屋内での 電源障害もあるので、そのような設定では全てのサーバがインターネットから 切り離され得る。 単一の障害によって全てのサーバーが使用不能になってしまう可能性を 最小限にするために、セカンダリーサーバーはインターネット上で トポロジー的にも地理的にも分散した場所に配置されなければならない。 少なくとも、セカンダリーサーバーは地理的に離れた場所に設置し、 電源断のような障害によって全てのサーバーが同時に使用不能になる 可能性を無くすべきである。また、セカンダリーサーバーは多様化を 徹底したパスを経てネットワークに接続されるべきである。 これは、単一リンクの障害または(サービスプロバイダーのような) ネットワークのある区域内のルーティング障害が発生しても、 全てのサーバーが到達不能にはならないことを意味する。 3.2. 不適当な設定 不幸なことに、そうすることが非常に一般的になっているのだが、あるゾーンに 対するサーバー全てを、同じ建物の同じ部屋の同じLAN区域に設置する ことは決してしてはならず、これらの条件のどれか一つでも満たされては ならない。このような状況は、複数のサーバーを持つ要件、有用性を ほとんど無にしてしまう。1台のサーバーがダウンした場合の冗長性だけは この状況でも通常提供されるが、長期に渡るものも含めた電源障害など、 他にも考慮すべき多数の障害形態の可能性が存在する。 Elz, et al. Best Current Practice [Page 4] RFC 2182 Selection and Operation of Secondary DNS Servers July 1997 3.3. 神話の打破 あるドメイン内のホストが到達不能である場合、そのドメインを管理する ドメインネームサーバーにアクセス可能である必要はないという反論が 時折見られる。その反論は誤りである。 + クライアントの反応は、名前解決できない場合と接続できない場合では 異なる。そして、前者の反応はいつも望ましいものとは限らない。 + ゾーンが名前解決可能な状態で特定の名前だけが解決できない場合、 クライアントはその処理を放棄することができる。 そのため、名前解決の再試行を行って望ましくないネットワーク負荷を 発生させなくなる。 + DNSによる名前解決の結果が得られた場合、通常その情報はキャッシュ されるが、一方で結果が得られなかったという情報はキャッシュされない。 したがって、不必要な名前解決の阻害は、ネット上に望ましくない負荷を 発生させる。 + ゾーン内の全ての名前が切り離されたネットワーク内のアドレスに名前解決 されるわけではない。この可能性は時間の経過とともに大きくなる。 したがって、神話の基本的な前提は大抵の場合正しくなくなる。 全ての正引きゾーンに対して、問い合わせを受けられるネームサーバーが 存在し、それが常に利用可能であることが重要である。 4. 到達不能なサーバー ネットワークの大部分から到達できないサーバーを明記することにより、 これまで述べてきたものとは異なる問題が発生する。このような状況は ファイアーウォールの内側に存在し、完全に隔離されたマシンの名前を明記 した場合や、デュアルホームマシン(*1)のうち外部からアクセス不可能な セカンダリーアドレス側を明記している場合などに起こり得る。 NSレコードにリストされるサーバーの名前は、NSレコードを返す先の領域から 到達可能なアドレスに名前解決できるようにすべきである。 ネットワークのほとんどの領域から到達不可能なアドレスを含めても、 何ら信頼性は向上しないし、幾つかの問題を生じさせる。それらの問題は、 結果としてゾーンの信頼性を低下させる。 《脚注》 *1: 「デュアルホームマシン」 2つのインターフェースを持つコンピュータ。ここで想定されている利用 形態は、片方のインターフェースにプライマリーアドレスとして外部から アクセス可能なアドレスを設定しておき、残りのインターフェースに セカンダリーアドレスとして外部からはアクセスできないアドレスを設定 するというものである。(このように設定しておき、DNSサーバーを適切に 設定すれば、ファイアーウォール外部からもファイアーウォール内部からも 同じホスト名で同一のサーバーにアクセスすることが可能となる) まず、リゾルバーがアドレスが到達不能であるかを判断する唯一の方法は、 アクセスを試みることである。その後、そのアドレスが使用できないことを 知るためには、リゾルバーは応答のタイムアウト(あるいはICMPエラー応答の 場合もある)を待つ必要がある。さらに、これは一般に単純なパケットロスとの 識別ができないため、サーバーが到達不能であるという何か現実的な証拠を 得るまでに、この一連の処理は必ず数回繰り返される。この検証とタイムアウトの 処理全ては非常に長い時間を要することがあるため、オリジナルのクライアント プログラムまたはユーザーは応答が得られないと判断し、見かけ上のゾーン障害が 発生する結果となる。加えて、定常的に到達不能なサーバーと一時的に 到達不能なサーバーを識別するために、これら一連の全作業は幾度も 繰り返される必要がある。 Elz, et al. Best Current Practice [Page 5] RFC 2182 Selection and Operation of Secondary DNS Servers July 1997 最後に、これらの処理全ては、ネットワーク上に存在する全リゾルバーに 実行される必要があるかもしれない。この結果、トラフィックと、 おそらくはこのアクセスをブロックするファイアーウォールのフィルター 負荷を増大させる。この余分な負荷の全てはサービスの信頼性を著しく低下 させる。 4.1. 間欠的に接続されるリンクの背後にあるサーバー インターネットから時々切り離されるネットワークに設置された DNSサーバーでも同様の問題が生じる。例として、間欠的に接続される(*2) リンクを経由して接続しているDNSサーバーが挙げられる。このような サーバーは、ファイアーウォールの内側にあり、サーバーが設置された ネットワークには常に到達できないものとして処理されるべきである。 《脚注》 *2: 「間欠的に接続される」 ネットワークに固定的に接続されているのではなく、ダイヤルアップ接続の ような形態で、不定期に接続されたり接続が断になったりする状態を指す。 4.2. 他の問題事例 リゾルバーとサーバーの間にNetwork Address Translator(NAT)[RFC1631]が 存在する場合に同様の問題が発生する。[RFC1631]で提案されているにも かかわらず、実際に使用されているNATはパケットに埋め込まれたアドレスを 変換せず、ヘッダー内にあるものだけを変換する。[RFC1631]が示唆するように、 これはDNSにとって少々問題である。この問題は、NATにApplication Layer Gateway(ALG)機能を付加するか、またはNATをALGに置き換えることによって 解決できることがある。ALGのような装置はDNSプロトコルを理解し、 パケットが通過する際に適切に全てのアドレスを変換する。 このような装置を使用するとしても、これらの事例の全てで以下の セクションに記述される問題解決策を採用するほうがよいだろう。 4.3. 問題解決策 これらの問題を回避するために、あらゆる応答に含まれるゾーンの NSレコードには、情報を問い合わせたリゾルバーが到達可能な サーバーのみを明記すべきである。あるリゾルバーは、同時に 他のリゾルバーの代わりに検索を実行するサーバーでもある。したがって、 返されるNSレコードは、情報を問い合わせたリゾルバーからだけでは なく、その情報を転送した他の全てのリゾルバーからも到達可能にすべき である。また、返される全てのサーバーの全てのアドレスは到達可能で なければならない。各サーバーのアドレスはResource Record Set[RFC2181]を 形成するので、全てのアドレスを返すか、何も返さないかのどちらかで なければならない。したがって、到達できないサーバーのアドレスを削除する ことは許容されないし、また到達できないサーバーのアドレスに低いTTLを 設定して(他のサーバーのアドレスについてはより高いTTLを設定して)返す ことも許容されない。 特に、サーバーがファイアーウォールの内側にある場合、間欠的に接続される リンクの先にある場合、NATの内側にある場合に、DNSの問い合わせや応答が できなかったり問題が発生するようなことがある。そのような場合には、 サーバーの名前またはアドレスをファイアーウォールの外側に存在する クライアントに対して返すべきではない。同様に、サーバーがファイアー ウォールの外側にあり、クライアントがファイアーウォールの内側にある場合、 クライアントがサーバーに問い合わせ可能でないならば、サーバーの情報は クライアントに知らされるべきではない。 Elz, et al. Best Current Practice [Page 6] RFC 2182 Selection and Operation of Secondary DNS Servers July 1997 この実装を行うためには、通常2系列のDNS(dual DNS)の構成を必要とする。 1台をファイアーウォールの内側で使用し、もう1台を外側で使用する。 この構成は多くの場合、似たような環境で発生する他の問題も解決する。 サーバーがファイアーウォール境界(boudary)に設置されている場合、 すなわち両側から到達可能だが、それぞれ異なるアドレスを使用している 場合、そのサーバーは2つの名前を使用すべきである。そしてそれぞれの 名前を適切なAレコードに関連付け、それぞれがファイアーウォールの 適切な側からだけ到達可能にするべきである。これらの処理を行った後は、 このサーバーはそれぞれファイアーウォールの片側に存在するような、 2台のサーバーとして扱われるべきである。ALG上で実装されたサーバーは 通常この事例である。このようなサーバーがそれぞれの側に存在する クライアントに正しい応答を返せるように、特別な注意が払われる必要が ある。すなわち、応答を返す側から到達可能なホストと、応答を返す側から 見える正しいホストのIPアドレスに関する情報だけを返すということである。 この環境に存在するサーバーは大抵の場合、ルートサーバーへのアクセスを 得るために特別な対策を必要とする。"模造ルート(fake root)"設定によって これを実現する例も多い。そのような場合、サーバーはDNSの残りの部分から 充分に隔離され、特別な設定が他を汚染しないようにすべきである。 5. 何台のセカンダリーが適切か？ DNSの仕様とドメイン名登録規則は、各ゾーンに対して最低2台のサーバーを 要求している。通常これはプライマリーと1台のセカンダリーである。 2台であっても注意深く配置すれば大抵の場合は充分であるが、2台では 不十分な場合もよく発生するので、我々は2台より多くの明記サーバーの 使用を勧める。様々な問題により、1台のサーバーが長期間に渡って 使用不可能になる可能性がある。そのような期間中は、2台の明記サーバーを 持つゾーンは実際には1台のサーバーで稼動することになる。 どのサーバーも諸々の理由で利用不可能になることがあるので、このゾーンは 何かの拍子に機能するサーバーを全く持てなくなる可能性がある。 一方で、多数のサーバーを保持しても、コストの増加に対してわずかな 利益しか得られない。最も単純な例では、より多くのサーバーはパケットを 大きくし、より多くの帯域を必要とする。これは些細なことに思える だろうし、実際に些細なことではある。しかしDNSパケットのサイズには 制限があり、その制限に達することはより深刻なパフォーマンスへの影響を もたらす。この制限をクリアーする状況を維持することが賢明である。 また、多くのサーバーの保持は、検知されないまま1台のサーバーが誤って 設定されたり誤動作する可能性を増大させる。 一般的な組織のゾーンでは、3台のサーバーを設定し、3台のうち少なくとも 1台を他のサーバーから充分に離すことを推奨する。より高い信頼性を 必要とするゾーンに対しては4台、あるいは5台のサーバーが望ましい。 Elz, et al. Best Current Practice [Page 7] RFC 2182 Selection and Operation of Secondary DNS Servers July 1997 5台のうち2台、または場合によっては3台を一つのサイト内に設置し、 他のものは地理的またはトポロジー的にサイトから遠ざけられた場所に、 互いに離されて設置されることになるだろう。 逆引きゾーン、すなわち.IN-ADDR.ARPA.のサブドメインはどちらかと 言えば重要度が低いため、より少ない台数のサーバーをあまり分散 させなくても大抵は充分である。なぜなら、アドレスから名前への変換は、 概してパケットが該当アドレスから受信された場合にだけ必要とされる ものであり、パケットの送信先またはその近傍にあるサーバーだけにしか 必要とされないからである。このことは、パケット発信元またはその近傍に 設置されたサーバー、例えば同じネットワーク上に設置されたサーバーは、 検索を実行する必要があるリゾルバーから到達可能であるという 保証を与える。したがって、正引きゾーンに対するサーバーを 計画する際に考慮される必要がある幾つかの障害形態は、逆引きゾーンを 計画する場合には適切ではないかもしれない。 5.1. ステルスサーバー ゾーンに対して権威を持つが、NSレコードに明記されないサーバー ("ステルス"サーバーとして知られる)はサーバーの数に含まれない。 大抵の場合、サイトに置かれた全てのサーバーを権威サーバー(セカンダリー)に しておき、うち1台か2台だけを明記サーバーにし、残りはサーバーが 保持するサイト内のゾーン全てについて、明記されない、すなわちステルス サーバーにしておくというのは便利である。 こうすることにより、これらのサーバーはサイト内のゾーンに対する 問い合わせに対して、他のサーバーに問い合わせすることなく、直接 応答することが可能となる。もしも他のサーバーへの問い合わせが 必要であったならば、委任木構造(delegation tree)を追うためには 通常ルートサーバーへの問い合わせが必要となるため、そのゾーンが サイト内のゾーンだとわからないかもしれない。これは、外部への通信が 断になった場合、サイト内のゾーンに対する問い合わせの幾つかは応答 されないかもしれないことを意味する。 サイト内の全サーバーをNSレコードに明記する場合、それが1つまたは 2つよりも多ければ、もしそのサイト全体がリンク障害またはルーティング 障害でアクセス不能になると、そのサイト以外のインターネット全体で、 そのサイト内に設置された、障害によって到達できないサーバー全てに コンタクトしようとする無用な労力が発生してしまう。 6. 適切なセカンダリーサーバーの発見 セカンダリーサーバーの運用は通常ほとんどが自動的に行われる作業である。 一旦構築されてしまえば、サーバーは一般にプライマリーサーバーの動作に 基づいて自ら動作する。このため、多くの組織はその要望があれば セカンダリーサーバーを提供する。最善のアプローチは、通常同じ規模の 組織を発見し、セカンダリーゾーンの交換に合意することである。これは すなわち組織がお互いに相手組織のゾーンに対するセカンダリーサーバー として動作するサーバーを提供しあうことに同意するということである。 Elz, et al. Best Current Practice [Page 8] RFC 2182 Selection and Operation of Secondary DNS Servers July 1997 ここで、機密データの消失は発生しないことに注意してもらいたい。 交換されるデータはサーバーであればどれでも公然と利用可能な ものである。 7. シリアル番号の保守 セカンダリーサーバーは、保持するゾーンの複製を更新する必要がある 場合、ゾーンのSOAレコードのシリアル番号を使用する。基本的に、 シリアル番号は32ビットの符号無し整数(unsigned integer)で、理論的な 最大値から0に周回する。シリアル番号のより厳密な定義については [RFC1982]を参照のこと。 プライマリーサーバー上のゾーンに1つ変更が加えられる毎に、あるいは 幾つかの変更が加えられる毎に、シリアル番号を増加させなければ ならない。これにより、セカンダリーサーバーにゾーンの複製を更新する 必要があることを通知する。シリアル番号を減少させることは できないことに注意してもらいたい。値の増加が定義されている唯一の 修正である。 時折、編集のエラーや他の要因により、シリアル番号を小さく変更する 必要がある場合が生じる。セカンダリーサーバーはその変更を無視し、 更には先に設定した大きなシリアル番号が追い越されるまで、 小さく変更した後の値の増加処理を無視するだろう。 シリアル番号を大きな値から小さな値に周回させる代わりに、 値が望ましいものに到達するまで、数回に分けて、絶対的に大きな値で シリアル番号を増加させよ。処理の各段階において、処理を先に 進める前に、全てのセカンダリーサーバーが新しい値に更新するのを 待つこと。 例として、ゾーンのシリアル番号が10であると仮定する。この値が誤って 1000に設定されてしまい、これを11に戻したい場合を考える。 単純に値を1000から11に変更してはいけない。1000というシリアル番号を 検知したセカンダリーサーバー(常に最低1台は存在することを想定する)は この変更を無視し、プライマリーサーバーのシリアル番号がその値を 追い越すまで、シリアル番号1000のバージョンのゾーンを使い続ける。 これは長期間になる可能性がある。事実上、セカンダリーは大抵の場合に おいて、ゾーンを再度更新する前にゾーンの複製を廃棄してしまう。 この例の場合には、そのようにする代わりにプライマリーサーバーの シリアル番号を2000000000に設定し、セカンダリーサーバーがゾーンを 更新するのを待つ。2000000000という値は現在の値よりも遥かに大きいが、 それでも2^31よりは大きくない(2^31は2147483648)値として選択されている。 これはシリアル番号の増加である[RFC1982]。 次に、更新する必要がある全てのサーバーがそのシリアル番号のゾーンを 得た後に、シリアル番号を4000000000に設定する。4000000000は (極めて明確なことに)2000000000よりも2000000000大きいので、 これもまた値の増加である(追加された値は2^31よりも小さい)。 Elz, et al. Best Current Practice [Page 9] RFC 2182 Selection and Operation of Secondary DNS Servers July 1997 一旦このゾーンの複製が全てのサーバーに行き渡ったならば、シリアル 番号は単に11に設定することができる。シリアル番号の計算では、 4000000000から11への変更は値の増加である。シリアル番号は2^32 (4294967296)で周回するので、11は4294967307(4294967296+11)と等しい。 4294967307は4000000000よりも294967307だけ大きく、294967307は 2^31よりは小さい。したがって、これは値の増加である。 この手続きにしたがう場合、各段階において、関係する全サーバーが更新を 行ったことを検証することが大切である。何についても思い込みをしては いけない。この処理に失敗すると、修正を試みる以前に存在した状態よりも 更に混乱が悪化する結果となる。また、重要なことは様々なシーケンス番号の 値の間の関係であって、値そのものではないことに注意してもらいたい。 上記で使用した値はあの例の中でのみ正しいものである。 本質的には、全ての事例においてシリアル番号の選択をより積極的な ものにすることで、2回の処理でシリアル番号を訂正することも可能である。 しかし、その場合使用されるシリアル番号はあまり"扱いやすい"ものでは なくなる(less nice)ので、より多くの注意が要求される。 また、全てのネームサーバー実装がシリアル番号処理を正しく 実装しているわけではないことに注意してもらいたい。そのようなサーバーが セカンダリーになっている場合、一般にサーバーの管理者に連絡をとり、 ゾーンに対する既存データを消去してもらう以外にシリアル番号を 小さくする方法は存在しない。その後、そのセカンダリーは最初に起動された 場合と同様に、プライマリーから再びデータを取得する。 正しく動作しないサーバーはどのような場合でも手動操作の労力を 必要とするので、上記の手続きを実行しても依然として安全である。 先に記述したシリアル番号を変更するための一連の操作の後に、適切な 実装にしたがうセカンダリーサーバーはシリアル番号が設定しなおされて いる。その後、プライマリーサーバーが正しい(望ましい)シリアル番号を 保持していれば、残りのセカンダリーサーバーにコンタクトし、シリアル番号を 正しく訂正するためには手動の操作が必要であることを納得させ、その作業を 要求せよ。おそらくは、同時にセカンダリーサーバーが使用するソフトウェアを 標準に準拠した実装に更新するよう提案することになるだろう。 このアルゴリズムを実装しないサーバーは不完全であり、以下のように検出 される。ある状況、通常はシリアル番号の符号無し整数が小さくなった場合に、 この固有の問題を持つサーバーは変更を無視する。この種の問題を持つ サーバーは、少なくともSOAのrefreshフィールドで指定された時間待った後に、 SOAに対する問い合わせを送信することによって検出可能である。 この問題を持つサーバーは依然として古いシリアル番号を保持しているだろう。 この問題を検出する他の手段を我々は知らない。 Elz, et al. Best Current Practice [Page 10] RFC 2182 Selection and Operation of Secondary DNS Servers July 1997 セキュリティに関する考察 本文書ではDNSに関する既存のセキュリティ問題に何ら付け加えるものでは ないし、何も差し引くものでもない。 しかし、ある状況におけるドメインに対するサーバーのセキュリティ侵害は ドメイン内のホストのセキュリティ侵害につながることを管理者は意識すべき である。セカンダリーサーバーを選択する際には、この脅威を最小化 するよう注意が払われるべきである。 参考文献 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987 [RFC1631] Egevang, K., Francis, P., "The IP Network Address Translator (NAT)", RFC 1631, May 1994 [RFC1982] Elz, R., Bush, R., "Serial Number Arithmetic", RFC 1982, August 1996. [RFC2181] Elz, R., Bush, R., "Clarifications to the DNS specification", RFC 2181, July 1997. 謝辞 Brian CarpenterとYakov Rekhterはファイヤーウォールに関する記述に 付随して、NATとALGについて言及するよう提案してくれた。Dave Crockerは 神話を明示的に打破するよう提案してくれた。 著者の連絡先 Robert Elz Computer Science University of Melbourne Parkville, Vic, 3052 Australia. EMail: kre@munnari.OZ.AU Elz, et al. Best Current Practice [Page 11] RFC 2182 Selection and Operation of Secondary DNS Servers July 1997 Randy Bush RGnet, Inc. 5147 Crystal Springs Drive NE Bainbridge Island, Washington, 98110 United States. EMail: randy@psg.com Scott Bradner Harvard University 1350 Mass Ave Cambridge, MA, 02138 United States. EMail: sob@harvard.edu Michael A. Patton 33 Blanchard Road Cambridge, MA, 02138 United States. EMail: MAP@POBOX.COM Elz, et al. Best Current Practice [Page 12] RFC2182-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Service Co., Ltd. http://jprs.jp/tech/