RFC2182 日本語訳

Network Working Group                                             R. Elz
Request for Comments: 2182                       University of Melbourne
BCP: 16                                                          R. Bush
Category: Best Current Practice                              RGnet, Inc.
                                                              S. Bradner
                                                      Harvard University
                                                               M. Patton
                                                              Consultant
                                                               July 1997

Elzがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2182年のメルボルンBCP大学: 16R.ブッシュカテゴリ: 最も良い現在の練習のS.ブラドナーハーバード大学M.パットンコンサルタントRGnet Inc.1997年7月

            Selection and Operation of Secondary DNS Servers

セカンダリDNSサーバの選択と操作

Status of this Memo

このMemoの状態

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。

Abstract

要約

   The Domain Name System requires that multiple servers exist for every
   delegated domain (zone).  This document discusses the selection of
   secondary servers for DNS zones.  Both the physical and topological
   location of each server are material considerations when selecting
   secondary servers.  The number of servers appropriate for a zone is
   also discussed, and some general secondary server maintenance issues
   considered.

ドメインネームシステムは、複数のサーバがあらゆる代表として派遣されたドメイン(ゾーン)に存在するのを必要とします。 このドキュメントはDNSゾーンとセカンダリサーバの品揃えについて議論します。 セカンダリサーバを選択するとき、物理的とそれぞれのサーバの位相的な位置の両方が物質的な問題です。 また、ゾーンに、適切なサーバの数について議論しました、そして、メインテナンスが支給する何らかの一般的なセカンダリサーバが考えました。

Elz, et al.              Best Current Practice                  [Page 1]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997

Elz、他 セカンダリDNSサーバ1997年7月の最も良い現在の習慣[1ページ]RFC2182選択と操作

Contents

コンテンツ

       Abstract  ...................................................   1
    1  Introduction  ...............................................   2
    2  Definitions  ................................................   2
    3  Secondary Servers  ..........................................   3
    4  Unreachable servers  ........................................   5
    5  How many secondaries?  ......................................   7
    6  Finding Suitable Secondary Servers  .........................   8
    7  Serial Number Maintenance  ..................................   9
       Security Considerations  ....................................  11
       References  .................................................  11
       Acknowledgements  ...........................................  11
       Authors' Addresses  .........................................  11

要約… 1 1序論… 2 2の定義… 2 3のセカンダリサーバ… 3 4の手の届かないサーバ… 5 5、何人の代理人-- ...................................... 7 6の調査結果の適当なセカンダリサーバ… 8 7通し番号メインテナンス… 9 セキュリティ問題… 11の参照箇所… 11の承認… 11人の作者のアドレス… 11

1. Introduction

1. 序論

   A number of problems in DNS operations today are attributable to poor
   choices of secondary servers for DNS zones.  The geographic placement
   as well as the diversity of network connectivity exhibited by the set
   of DNS servers for a zone can increase the reliability of that zone
   as well as improve overall network performance and access
   characteristics.  Other considerations in server choice can
   unexpectedly lower reliability or impose extra demands on the
   network.

DNSゾーンにおいて、今日のDNS操作における多くの問題がセカンダリサーバの不十分な選択に起因しています。 DNSサーバのセットによってゾーンに示されたネットワークの接続性の多様性と同様に地理的なプレースメントは、そのゾーンの信頼性を増強して、総合的なネットワーク性能とアクセスの特性を向上させることができます。 サーバ選択における他の問題は、不意に信頼性を下げるか、または付加的な要求をネットワークに課すことができます。

   This document discusses many of the issues that should be considered
   when selecting secondary servers for a zone.  It offers guidance in
   how to best choose servers to serve a given zone.

このドキュメントはセカンダリサーバをゾーンに選択するとき考えられるべきである問題の多くについて議論します。 それは与えられたゾーンに役立つようにどうサーバを最もよく選ぶかの指導を提供します。

2. Definitions

2. 定義

   For the purposes of this document, and only this document, the
   following definitions apply:

このドキュメントの目的、およびこのドキュメントだけに関しては、以下の定義は適用されます:

   DNS                    The Domain Name System [RFC1034, RFC1035].

DNSドメインネームシステム[RFC1034、RFC1035]。

   Zone                   A part of the DNS tree, that is treated as a
                          unit.

木であって、すなわち、ユニットとして扱われたDNSのゾーンのA部分。

   Forward Zone           A zone containing data mapping names to host
                          addresses, mail exchange targets, etc.

ホスト・アドレス、メール交換目標などに名前を写像するデータを含む前進のZone Aゾーン

Elz, et al.              Best Current Practice                  [Page 2]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997

Elz、他 セカンダリDNSサーバ1997年7月の最も良い現在の習慣[2ページ]RFC2182選択と操作

   Reverse Zone           A zone containing data used to map addresses
                          to names.

データがアドレスを名前に写像するのに使用したZone Aゾーン含有を逆にしてください。

   Server                 An implementation of the DNS protocols able to
                          provide answers to queries.  Answers may be
                          from information known by the server, or
                          information obtained from another server.

提供できるDNSプロトコルのサーバAn実装は質問に対応します。 答えはサーバによって知られていた情報、または別のサーバから得られた情報から来ているかもしれません。

   Authoritative Server   A server that knows the content of a DNS zone
                          from local knowledge, and thus can answer
                          queries about that zone without needing to
                          query other servers.

局所的知識からDNSゾーンの内容を知って、その結果そのゾーンに関して他のサーバについて質問する必要はなくて質問に答えることができる正式のServer Aサーバ。

   Listed Server          An Authoritative Server for which there is an
                          "NS" resource record (RR) in the zone.

「ナノ秒」リソースがある記載されたServer An Authoritative Serverは(RR)をゾーンに記録します。

   Primary Server         An authoritative server for which the zone
                          information is locally configured.  Sometimes
                          known as a Master server.

ゾーン情報が局所的に構成されるプライマリServer An正式のサーバ。 Masterサーバとして時々知られています。

   Secondary Server       An authoritative server that obtains
                          information about a zone from a Primary Server
                          via a zone transfer mechanism.  Sometimes
                          known as a Slave Server.

Primary Serverからゾーントランスファ・メカニズムでゾーンの情報を得るセカンダリServer An正式のサーバ。 Slave Serverとして時々知られています。

   Stealth Server         An authoritative server, usually secondary,
                          which is not a Listed Server.

Listed Serverでない通常セカンダリのこっそりServer An正式のサーバ。

   Resolver               A client of the DNS which seeks information
                          contained in a zone using the DNS protocols.

ゾーンにDNSプロトコルを使用することで保管されていた情報を求めるDNSのレゾルバAクライアント。

3. Secondary Servers

3. セカンダリサーバ

   A major reason for having multiple servers for each zone is to allow
   information from the zone to be available widely and reliably to
   clients throughout the Internet, that is, throughout the world, even
   when one server is unavailable or unreachable.

各ゾーンへの複数のサーバを持つ主要な理由はインターネット中のクライアントにとって、ゾーンからの情報が広さと確かに利用可能であることを許容することです、すなわち、世界中で、1つのサーバが入手できないか、または手が届かないときにさえ。

   Multiple servers also spread the name resolution load, and improve
   the overall efficiency of the system by placing servers nearer to the
   resolvers.  Those purposes are not treated further here.

複数のサーバが、レゾルバには、より近い置くサーバでまた、名前解決負荷を広げて、システムの全体的効率を改良します。 それらの目的はさらにここに扱われません。

   With multiple servers, usually one server will be the primary server,
   and others will be secondary servers.  Note that while some unusual
   configurations use multiple primary servers, that can result in data
   inconsistencies, and is not advisable.

通常、複数のサーバで、1つのサーバがプライマリサーバになるでしょう、そして、他のものはセカンダリサーバになるでしょう。 それがいくつかの珍しい構成が複数のプライマリサーバを使用しますが、データ矛盾をもたらすことができて、賢明でないことに注意してください。

Elz, et al.              Best Current Practice                  [Page 3]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997

Elz、他 セカンダリDNSサーバ1997年7月の最も良い現在の習慣[3ページ]RFC2182選択と操作

   The distinction between primary and secondary servers is relevant
   only to the servers for the zone concerned, to the rest of the DNS
   there are simply multiple servers.  All are treated equally at first
   instance, even by the parent server that delegates the zone.
   Resolvers often measure the performance of the various servers,
   choose the "best", for some definition of best, and prefer that one
   for most queries.  That is automatic, and not considered here.

複数のサーバが単にあることをDNSの残りに心配させるゾーンにおいて、プライマリの、そして、セカンダリのサーバの区別はサーバだけに関連しています。 すべてが最初のインスタンスで等しく扱われて、親サーバさえによるその代表はゾーンです。 レゾルバは、しばしば様々なサーバの性能を測定して、最善の何らかの定義に「最もよく」選んで、ほとんどの質問のためにそれを好みます。 それは、自動で、ここで考えられません。

   The primary server holds the master copy of the zone file.  That is,
   the server where the data is entered into the DNS from some source
   outside the DNS.  Secondary servers obtain data for the zone using
   DNS protocol mechanisms to obtain the zone from the primary server.

プライマリサーバはゾーンファイルのマスターコピーを支えます。 すなわち、データがDNSの外のソースからDNSに入力されるサーバ。 セカンダリサーバは、プライマリサーバからゾーンを得るのにDNSプロトコルメカニズムを使用することでゾーンのためのデータを得ます。

3.1. Selecting Secondary Servers

3.1. セカンダリサーバを選択します。

   When selecting secondary servers, attention should be given to the
   various likely failure modes.  Servers should be placed so that it is
   likely that at least one server will be available to all significant
   parts of the Internet, for any likely failure.

セカンダリサーバを選択するとき、様々なありそうな故障モードに注意を与えるべきです。 サーバはインターネットのすべての重要な地域に利用可能であるのが少なくとも1つのサーバがなるありそうであるように、置かれるべきです、どんなありそうな失敗のためにも。

   Consequently, placing all servers at the local site, while easy to
   arrange, and easy to manage, is not a good policy.  Should a single
   link fail, or there be a site, or perhaps even building, or room,
   power failure, such a configuration can lead to all servers being
   disconnected from the Internet.

その結果、手配しやすくて、管理するのが簡単である間、すべてのサーバをローカル・サイトにみなすのは、得策ではありません。 単一のリンクは失敗するか、サイトであるか、恐らく建てるか、または余地、停電、そのような構成は建てることができます。インターネットから切断されながら、すべてのサーバに通じるべきであってください。

   Secondary servers must be placed at both topologically and
   geographically dispersed locations on the Internet, to minimise the
   likelihood of a single failure disabling all of them.

セカンダリサーバは、ただ一つの失敗がそれらを皆、無効にするという見込みを最小とならせるためにはインターネットの両方に位相的に置かれた、地理的に分散している位置でなければなりません。

   That is, secondary servers should be at geographically distant
   locations, so it is unlikely that events like power loss, etc, will
   disrupt all of them simultaneously.  They should also be connected to
   the net via quite diverse paths.  This means that the failure of any
   one link, or of routing within some segment of the network (such as a
   service provider) will not make all of the servers unreachable.

すなわち、セカンダリサーバが地理的に遠方の位置にあるべきであるので、電力損などのようなイベントが同時にそれらを皆、混乱させるのは、ありそうもないです。 また、それらはかなり多様な経路を通してネットに接続されるべきです。 これは、いずれの失敗でリンクするか、またはサーバのすべてが手が届かなくネットワーク(サービスプロバイダーなどの)の何らかの区分の中のルーティングでならないことを意味します。

3.2. Unsuitable Configurations

3.2. 不適当な構成

   While it is unfortunately quite common, servers for a zone should
   certainly not all be placed on the same LAN segment in the same room
   of the same building - or any of those.  Such a configuration almost
   defeats the requirement, and utility, of having multiple servers.
   The only redundancy usually provided in that configuration is for the
   case when one server is down, whereas there are many other possible
   failure modes, such as power failures, including lengthy ones, to
   consider.

残念ながら、それが全く一般的である間、確かに、同じLANセグメントに関して同じビルの同じ部屋、またはそれらのいずれでもゾーンへのサーバをすべて課すべきではありません。 そのような構成は複数のサーバを持つ要件、およびユーティリティをほとんど破ります。 1つのサーバが下がっていますが、他の多くの可能な故障モードがあるとき、通常、その構成に提供された唯一の冗長がケースのためのものです、停電などのように、考えるために長いものを含んでいて。

Elz, et al.              Best Current Practice                  [Page 4]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997

Elz、他 セカンダリDNSサーバ1997年7月の最も良い現在の習慣[4ページ]RFC2182選択と操作

3.3. A Myth Exploded

3.3. 神話は爆発しました。

   An argument is occasionally made that there is no need for the domain
   name servers for a domain to be accessible if the hosts in the domain
   are unreachable.  This argument is fallacious.

時折そのドメインのホストが手が届かないならドメインがアクセスしやすくなるドメイン名サーバの必要は全くないという主張をします。 この議論は当てになりません。

     + Clients react differently to inability to resolve than inability
       to connect, and reactions to the former are not always as
       desirable.
     + If the zone is resolvable yet the particular name is not, then a
       client can discard the transaction rather than retrying and
       creating undesirable load on the network.
     + While positive DNS results are usually cached, the lack of a
       result is not cached.  Thus, unnecessary inability to resolve
       creates an undesirable load on the net.
     + All names in the zone may not resolve to addresses within the
       detached network.  This becomes more likely over time.  Thus a
       basic assumption of the myth often becomes untrue.

+ クライアントは接続できないこと、および前者への反応より望ましいとしていつも決議する無能に異なって反応します。 + ゾーンが溶解性であるか、しかし、存在でないという特定の名前、そして、クライアントは望ましくない負荷をネットワークに再試行して、作成するよりむしろトランザクションを捨てることができます。 積極的なDNSが結果になっている間、通常、+によってキャッシュされて、結果の不足はキャッシュされません。 したがって、決議する不要な無能は望ましくない負荷をネットに作成します。 + ゾーンの名前が離れているネットワークの中でアドレスに決議しないかもしれないすべて。 これは時間がたつにつれてよりありそうになります。 したがって、神話の基本仮定はしばしば虚偽になります。

   It is important that there be nameservers able to be queried,
   available always, for all forward zones.

そこに、いてください。それが重要である、それ、いつもすべての前進のゾーンに質問されていて、利用可能であることができるネームサーバ。

4. Unreachable servers

4. 手の届かないサーバ

   Another class of problems is caused by listing servers that cannot be
   reached from large parts of the network.  This could be listing the
   name of a machine that is completely isolated behind a firewall, or
   just a secondary address on a dual homed machine which is not
   accessible from outside.  The names of servers listed in NS records
   should resolve to addresses which are reachable from the region to
   which the NS records are being returned.  Including addresses which
   most of the network cannot reach does not add any reliability, and
   causes several problems, which may, in the end, lower the reliability
   of the zone.

もう1人のクラスの問題は、ネットワークのかなりの部分から達することができないサーバを記載することによって、引き起こされます。 これはマシンの名前を記載できました、すなわち、完全に隔離されて、a二元的では、外部からアクセスしやすくないマシンがファイアウォール、またはまさしくセカンダリアドレスの後ろで家へ帰っていました。 サーバの名前は記録がNS記録が返されている領域から届いているアドレスに決議するべきであるNSに記載しました。 ネットワークの大部分が達することができないアドレスを含んでいると、少しの信頼性も加えられないで、いくつかの問題が引き起こされます。(問題は結局、ゾーンの信頼性を下げるかもしれません)。

   First, the only way the resolvers can determine that these addresses
   are, in fact, unreachable, is to try them.  They then need to wait on
   a lack of response timeout (or occasionally an ICMP error response)
   to know that the address cannot be used.  Further, even that is
   generally indistinguishable from a simple packet loss, so the
   sequence must be repeated, several times, to give any real evidence
   of an unreachable server.  All of this probing and timeout may take
   sufficiently long that the original client program or user will
   decide that no answer is available, leading to an apparent failure of
   the zone.  Additionally, the whole thing needs to be repeated from
   time to time to distinguish a permanently unreachable server from a
   temporarily unreachable one.

1(レゾルバが、事実上、これらのアドレスが手が届かないと決心できる唯一の方法)番目はそれらを試みることです。 そして、彼らは、無反応タイムアウト(または、時折ICMP誤り応答)でアドレスを使用できないのを知っているのを待つ必要があります。 さらに、それさえ簡単なパケット損失から一般に区別がつかないので、どんな答えも利用可能でないというオリジナルのクライアントプログラムかユーザが決める. この調べとタイムアウトのすべてが十分長い間かかるかもしれない手の届かないサーバに関するどんな物的証拠も与えるために何度か系列を繰り返さなければなりません、ゾーンの明らかな失敗に通じて。 さらに、全体のものは、一時手の届かないものと永久に手の届かないサーバを区別するために時々繰り返される必要があります。

Elz, et al.              Best Current Practice                  [Page 5]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997

Elz、他 セカンダリDNSサーバ1997年7月の最も良い現在の習慣[5ページ]RFC2182選択と操作

   And finally, all these steps will potentially need to be done by
   resolvers all over the network.  This will increase the traffic, and
   probably the load on the filters at whatever firewall is blocking
   this access.  All of this additional load does no more than
   effectively lower the reliability of the service.

そして、最終的に、これらのすべてのステップが、潜在的にネットワーク全体にわたるレゾルバによって行われる必要があるでしょう。 これはこのアクセサリーを妨げているいかなるファイアウォールのフィルタでもトラフィック、およびたぶん負荷を増強するでしょう。 事実上、この追加負荷のすべてがサービスの信頼性を下げるだけです。

4.1. Servers behind intermittent connections

4.1. 間欠接続の後ろのサーバ

   A similar problem occurs with DNS servers located in parts of the net
   that are often disconnected from the Internet as a whole.  For
   example, those which connect via an intermittent connection that is
   often down.  Such servers should usually be treated as if they were
   behind a firewall, and unreachable to the network at any time.

DNSサーバが全体でインターネットからしばしば切断されるネットの部分に位置している状態で、同様の問題は起こります。 例えば、間欠接続で接続するものはしばしばダウンします。 通常、そのようなサーバはまるでいつでもファイアウォールの後ろにあって、ネットワークに手が届かないかのように扱われるべきです。

4.2. Other problem cases

4.2. 他の問題事件

   Similar problems occur when a Network Address Translator (NAT)
   [RFC1631] exists between a resolver and server.  Despite what
   [RFC1631] suggests, NATs in practice do not translate addresses
   embedded in packets, only those in the headers.  As [RFC1631]
   suggests, this is somewhat of a problem for the DNS.  This can
   sometimes be overcome if the NAT is accompanied by, or replaced with,
   an Application Layer Gateway (ALG).  Such a device would understand
   the DNS protocol and translate all the addresses as appropriate as
   packets pass through.  Even with such a device, it is likely to be
   better in any of these cases to adopt the solution described in the
   following section.

Network Address Translator(NAT)[RFC1631]がレゾルバとサーバの間に存在していると、同様の問題は起こります。[RFC1631]が示すことにもかかわらず、実際にはNATsはパケットに埋め込まれたアドレスを翻訳しません、ヘッダーのそれらだけ。 [RFC1631]が示すように、これはいくぶんDNSのための問題です。 時々これをNATで伴走するなら打ち勝つか、または取り替えることができる、Application Layerゲートウェイ(ALG)。 パケットが通り抜けるとき、そのようなデバイスは、DNSプロトコルを理解して、適宜すべてのアドレスを翻訳するでしょう。 そのようなデバイスがあっても、それは以下のセクションで説明されたソリューションを採用するこれらの場合のどれかで、より良い傾向があります。

4.3. A Solution

4.3. ソリューション

   To avoid these problems, NS records for a zone returned in any
   response should list only servers that the resolver requesting the
   information, is likely to be able to reach.  Some resolvers are
   simultaneously servers performing lookups on behalf of other
   resolvers.  The NS records returned should be reachable not only by
   the resolver that requested the information, but any other resolver
   that may be forwarded the information.  All the addresses of all the
   servers returned must be reachable.  As the addresses of each server
   form a Resource Record Set [RFC2181], all must be returned (or none),
   thus it is not acceptable to elide addresses of servers that are
   unreachable, or to return them with a low TTL (while returning others
   with a higher TTL).

これらの問題を避けるために、どんな応答でも返されたゾーンのためのNS記録はサーバだけを記載するべきです。情報を要求するレゾルバは達することができそうです。 同時に、何人かのレゾルバが他のレゾルバを代表してルックアップを実行するサーバです。 記録が返したNSは単に情報を要求したレゾルバで届くのではなく、情報が転送されるかもしれないいかなる他のレゾルバでも届いているべきです。 サーバが返したすべてのすべてのアドレスが届いているに違いありません。 それぞれのサーバのアドレスがResource Record Set[RFC2181]を形成するとき、すべてを返さなければなりません(または、なにも)、その結果、手が届かないサーバのアドレスを削除するか、または低いTTLと共にそれらを返すのが許容できません(より高いTTLをもっている他のものを返している間)。

   In particular, when some servers are behind a firewall, intermittent
   connection, or NAT, which disallows, or has problems with, DNS
   queries or responses, their names, or addresses, should not be
   returned to clients outside the firewall.  Similarly, servers outside
   the firewall should not be made known to clients inside it, if the

特に、問題を禁じるか、または持っているファイアウォール、間欠接続、またはNATの後ろにいくつかのサーバがいつをもってあるか、そして、DNS質問か応答(それらの名前、またはアドレス)をファイアウォールの外のクライアントに返すべきではありません。 同様に、それの中のクライアントにファイアウォールの外のサーバを明らかにするべきではありません。

Elz, et al.              Best Current Practice                  [Page 6]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997

Elz、他 セカンダリDNSサーバ1997年7月の最も良い現在の習慣[6ページ]RFC2182選択と操作

   clients would be unable to query those servers.  Implementing this
   usually requires dual DNS setups, one for internal use, the other for
   external use.  Such a setup often solves other problems with
   environments like this.

クライアントはそれらのサーバについて質問できないでしょう。 通常、これを実装するのは二元的なDNSセットアップ、内部の使用のためのもの、外部の使用のためのもう片方を必要とします。 そのようなセットアップはしばしばこのような環境に関する他の問題を解決します。

   When a server is at a firewall boundary, reachable from both sides,
   but using different addresses, that server should be given two names,
   each name associated with appropriate A records, such that each
   appears to be reachable only on the appropriate side of the firewall.
   This should then be treated just like two servers, one on each side
   of the firewall.  A server implemented in an ALG will usually be such
   a case.  Special care will need to be taken to allow such a server to
   return the correct responses to clients on each side.  That is,
   return only information about hosts reachable from that side and the
   correct IP address(es) for the host when viewed from that side.

サーバがファイアウォール限界にあるとき、両側から届きますが、異なったアドレスを使用して、2つの名前をそのサーバに与えるべきです、適切なA記録に関連しているそれぞれの名前、それぞれがファイアウォールの適切な側面だけで届くように見えるように。 そして、これはまさしく2つのサーバ、ファイアウォールの各側面の1のように扱われるべきです。 通常、ALGで実装されたサーバはそのような場合になるでしょう。 特別な注意は、そのようなサーバがそれぞれの側でクライアントへの正しい応答を返すのを許容するために取られる必要があるでしょう。 その側から見られると、すなわち、リターンのその側から届いているホストの情報と正しいIPだけがホストのために(es)を扱います。

   Servers in this environment often need special provision to give them
   access to the root servers.  Often this is accomplished via "fake
   root" configurations.  In such a case the servers should be kept well
   isolated from the rest of the DNS, lest their unusual configuration
   pollute others.

この環境におけるサーバは、ルートサーバーへのアクセスをそれらに与えるためにしばしば特別条項を必要とします。 しばしば、これは「にせの根」構成で達成されます。 このような場合にはサーバはDNSの残りで孤立しているようによく保たれるべきです、彼らの珍しい構成が他のものを汚染するといけないので。

5. How many secondaries?

5. 何人の代理人?

   The DNS specification and domain name registration rules require at
   least two servers for every zone.  That is, usually, the primary and
   one secondary.  While two, carefully placed, are often sufficient,
   occasions where two are insufficient are frequent enough that we
   advise the use of more than two listed servers.  Various problems can
   cause a server to be unavailable for extended periods - during such a
   period, a zone with only two listed servers is actually running with
   just one.  Since any server may occasionally be unavailable, for all
   kinds of reasons, this zone is likely, at times, to have no
   functional servers at all.

DNS仕様とドメイン名登録規則は各ゾーンあたり少なくとも2つのサーバを必要とします。 通常、それは、予備選挙とある2番目です。 慎重に置かれた2はしばしば十分ですが、2が不十分であるところで時は私たちが2つ以上の記載されたサーバを使用に知らせるほど頻繁です。 様々な問題は、そのような期間に長期間の間、サーバが入手できないことを引き起こす場合があります、と2つの記載されたサーバだけがあるゾーンはちょうど1で実際に述べています。 どんなサーバも時折すべての種類の理由を入手できないかもしれないので、このゾーンは時には、機能的なサーバを全く持たないようにありそうです。

   On the other hand, having large numbers of servers adds little
   benefit, while adding costs.  At the simplest, more servers cause
   packets to be larger, so requiring more bandwidth.  This may seem,
   and realistically is, trivial.  However there is a limit to the size
   of a DNS packet, and causing that limit to be reached has more
   serious performance implications.  It is wise to stay well clear of
   it.  More servers also increase the likelihood that one server will
   be misconfigured, or malfunction, without being detected.

他方では、多くのサーバを持っている場合、利益はコストを加えている間、ほとんど加えません。 最も簡単では、より多くのサーバが、したがって、より多くの帯域幅を必要として、パケットが、より大きいことを引き起こします。 これは、見えるかもしれなくて、現実的にあります。些細。 しかしながら、DNSパケットのサイズへの限界があります、そして、その限界に達することを引き起こすのにおいて、より重大な性能意味があります。 それをよく避けるのは賢明です。 検出されないで、より多くのサーバが、また、1つのサーバがmisconfiguredされる可能性を広げるか、または誤動作します。

   It is recommended that three servers be provided for most
   organisation level zones, with at least one which must be well
   removed from the others.  For zones where even higher reliability is
   required, four, or even five, servers may be desirable.  Two, or

ほとんどの機構レベルゾーンに3つのサーバを提供するのはお勧めです、少なくとも他のものから上手に取り除かなければならないもので。 さらに高い信頼性が必要であるゾーン、4、または5においてさえ、サーバは望ましいかもしれません。 2

Elz, et al.              Best Current Practice                  [Page 7]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997

Elz、他 セカンダリDNSサーバ1997年7月の最も良い現在の習慣[7ページ]RFC2182選択と操作

   occasionally three of five, would be at the local site, with the
   others not geographically or topologically close to the site, or each
   other.

5時3分時折前、ローカル・サイトに、サイト、または互いの近くに他のものと共に地理的か位相的でなくいるでしょう。

   Reverse zones, that is, sub-domains of .IN-ADDR.ARPA, tend to be less
   crucial, and less servers, less distributed, will often suffice.
   This is because address to name translations are typically needed
   only when packets are being received from the address in question,
   and only by resolvers at or near the destination of the packets.
   This gives some assurances that servers located at or near the packet
   source, for example, on the the same network, will be reachable from
   the resolvers that need to perform the lookups.  Thus some of the
   failure modes that need to be considered when planning servers for
   forward zones may be less relevant when reverse zones are being
   planned.

ゾーン、すなわち、.IN-ADDR.ARPAに関するサブドメインを逆にして、それほど重要でない傾向があってください。そうすれば、より少ないより分配されなかったサーバがしばしば十分でしょう。 これは目的地における、または、パケットの目的地の近くの問題のアドレスからパケットを受け取っているときだけ、翻訳を命名するアドレスが通常必要である、およびレゾルバだけであります。 これは、サーバがソースにおいてパケットソースの近くで場所を見つけられたといういくつかの保証を与えて、例えば、同じネットワークでルックアップを実行する必要があるレゾルバから届くでしょう。 逆のゾーンが計画されているとき、したがって、前進のゾーンへのサーバを計画しているとき、考えられる必要がある故障モードのいくつかがそれほど関連していないかもしれません。

5.1. Stealth Servers

5.1. こっそりサーバ

   Servers which are authoritative for the zone, but not listed in NS
   records (also known as "stealth" servers) are not included in the
   count of servers.

ゾーンに正式の、そして、しかし記載されなかったサーバはサーバのカウントにNS記録(また、「こっそり」サーバとして、知られている)に含まれていません。

   It can often be useful for all servers at a site to be authoritative
   (secondary), but only one or two be listed servers, the rest being
   unlisted servers for all local zones, that is, to be stealth servers.

しばしばすべてのサーバ1かtwoだけの役に立つのは、記載されたサーバです、残りがすべてのローカルのゾーンへの非記載されたサーバでありことであるかもしれない、こっそりサーバになるように、それがいます。

   This allows those servers to provide answers to local queries
   directly, without needing to consult another server.  If it were
   necessary to consult another server, it would usually be necessary
   for the root servers to be consulted, in order to follow the
   delegation tree - that the zone is local would not be known.  This
   would mean that some local queries may not be able to be answered if
   external communications were disrupted.

これで、それらのサーバは直接地方の質問の答えを提供できます、別のサーバに相談する必要はなくて。それが別のサーバに相談するのに必要であるなら、通常、ルートサーバーが相談されるのが必要でしょうに、委譲木に続くように--ゾーンがローカルであることは知られていないでしょう。 これは、外部コミュニケーションが混乱させられたならいくつかの地方の質問が答えることができないかもしれないことを意味するでしょう。

   Listing all such servers in NS records, if more than one or two,
   would cause the rest of the Internet to spend unnecessary effort
   attempting to contact all servers at the site when the whole site is
   inaccessible due to link or routing failures.

1か2以上ならNS記録のそのようなすべてのサーバを記載するのに、全体のサイトがリンクかルーティング失敗のためにアクセスできないときに、サイトのすべてのサーバに連絡するのを試みるのにインターネットの残りは不要な取り組みを費やすでしょう。

6. Finding Suitable Secondary Servers

6. 適当なセカンダリサーバを見つけます。

   Operating a secondary server is usually an almost automatic task.
   Once established, the server generally runs itself, based upon the
   actions of the primary server.  Because of this, large numbers of
   organisations are willing to provide a secondary server, if
   requested.  The best approach is usually to find an organisation of
   similar size, and agree to swap secondary zones - each organisation
   agrees to provide a server to act as a secondary server for the other

通常、セカンダリサーバを操作するのは、ほとんど自動であるタスクです。 いったん設立されると、一般に、サーバはそれ自体を実行します、プライマリサーバの動作に基づきます。これで、多くの機構が、セカンダリサーバを提供しても構わないと思っています、要求されるなら。 セカンダリゾーンを交換するのに同意してください--最も良いアプローチが通常、同様のサイズの機構に当たることであり、各機構は、もう片方のためのセカンダリサーバとして機能するようにサーバを提供するのに同意します。

Elz, et al.              Best Current Practice                  [Page 8]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997

Elz、他 セカンダリDNSサーバ1997年7月の最も良い現在の習慣[8ページ]RFC2182選択と操作

   organisation's zones.  Note that there is no loss of confidential
   data here, the data set exchanged would be available publically
   whatever the servers are.

機構のゾーン。 ここと、データセットが交換した秘密のデータの損失が全くないというメモはサーバが何であってもpublicallyに利用可能です。

7. Serial Number Maintenance

7. 通し番号メインテナンス

   Secondary servers use the serial number in the SOA record of the zone
   to determine when it is necessary to update their local copy of the
   zone.  Serial numbers are basically just 32 bit unsigned integers
   that wrap around from the biggest possible value to zero again.  See
   [RFC1982] for a more rigorous definition of the serial number.

セカンダリサーバは、ゾーンの地元のコピーをアップデートするのがいつ必要であるかを決定するのにゾーンに関するSOA記録の通し番号を使用します。 通し番号は基本的に再び可能な限り大きい値からゼロまで巻きつけられるちょうど32の噛み付いている符号のない整数です。 通し番号の、より厳しい定義に関して[RFC1982]を見てください。

   The serial number must be incremented every time a change, or group
   of changes, is made to the zone on the primary server.  This informs
   secondary servers they need update their copies of the zone.  Note
   that it is not possible to decrement a serial number, increments are
   the only defined modification.

変更、または変化のグループを. これがそれらのゾーンのコピーをアップデートすることを彼らが必要とするセカンダリサーバに知らせるプライマリサーバのゾーンにするときはいつも、通し番号を増加しなければなりません。 通し番号を減少させるのが可能でないことに注意してください、そして、増分は唯一の定義された変更です。

   Occasionally due to editing errors, or other factors, it may be
   necessary to cause a serial number to become smaller.  Never simply
   decrease the serial number.  Secondary servers will ignore that
   change, and further, will ignore any later increments until the
   earlier large value is exceeded.

時折誤り、または他の要素を編集するので、通し番号が、より小さくなることを引き起こすのが必要であるかもしれません。 通し番号を単に決して減少させないでください。 セカンダリサーバはその変化を無視するでしょう、そして、さらに、以前の大きい値が超えられるまで、どんな後の増分も無視するでしょう。

   Instead, given that serial numbers wrap from large to small, in
   absolute terms, increment the serial number, several times, until it
   has reached the value desired.  At each step, wait until all
   secondary servers have updated to the new value before proceeding.

絶対項でのその大きいのから小さくなるまでの通し番号包装を考えて、望まれていた値に達するまで、代わりに通し番号を何度か増加してください。 各ステップでは、セカンダリサーバが進行の前に新しい値にアップデートしたすべてまで待ってください。

   For example, assume that the serial number of a zone was 10, but has
   accidentally been set to 1000, and it is desired to set it back to
   11.  Do not simply change the value from 1000 to 11.  A secondary
   server that has seen the 1000 value (and in practice, there is always
   at least one) will ignore this change, and continue to use the
   version of the zone with serial number 1000, until the primary
   server's serial number exceeds that value.  This may be a long time -
   in fact, the secondary often expires its copy of the zone before the
   zone is ever updated again.

例えば、ゾーンの通し番号が10でしたが、偶然1000に設定されて、それを11に遅らせることが望まれていると仮定してください。 値を1000〜11に絶対に変えないでください。 1000年の値(実際には、少なくとも1つがいつもある)を見たセカンダリサーバは、この変化を無視して、通し番号1000と共にゾーンのバージョンを使用し続けるでしょう、プライマリサーバの通し番号がその値を超えるまで。 これは長い時間であるかもしれません--事実上、二度とゾーンをアップデートする前にセカンダリはしばしばゾーンのコピーを吐き出します。

   Instead, for this example, set the primary's serial number to
   2000000000, and wait for the secondary servers to update to that
   zone.  The value 2000000000 is chosen as a value a lot bigger than
   the current value, but less that 2^31 bigger (2^31 is 2147483648).
   This is then an increment of the serial number [RFC1982].

この例には、代わりに予備選挙の通し番号を2000000000に設定してください、そして、そのゾーンにアップデートするセカンダリサーバを待ってください。 値2000000000は、その2^31より大きく現行価値よりはるかに大きい値として選ばれていますが、少ないです(2^31は2147483648です)。 そして、これは通し番号[RFC1982]の増分です。

   Next, after all servers needing updating have the zone with that
   serial number, the serial number can be set to 4000000000.
   4000000000 is 2000000000 more than 2000000000 (fairly clearly), and

次に、アップデートする必要があるすべてのサーバがその通し番号があるゾーンを持った後に4000000000に通し番号を設定できます。 そして4000000000が2000000000よりさらに(かなり明確に)2000000000である。

Elz, et al.              Best Current Practice                  [Page 9]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997

Elz、他 セカンダリDNSサーバ1997年7月の最も良い現在の習慣[9ページ]RFC2182選択と操作

   is thus another increment (the value added is less than 2^31).

その結果、別のものは増分(付加価値は2未満^31である)ですか?

   Once this copy of the zone file exists at all servers, the serial
   number can simply be set to 11.  In serial number arithmetic, a
   change from 4000000000 to 11 is an increment.  Serial numbers wrap at
   2^32 (4294967296), so 11 is identical to 4294967307 (4294967296 +
    11).  4294967307 is just 294967307 greater than 4000000000, and
   294967307 is well under 2^31, this is therefore an increment.

ゾーンファイルのこのコピーがすべてのサーバでいったん存在していると、単に11に通し番号を設定できます。 通し番号演算では、4000000000〜11までの変化は増分です。 2^32(4294967296)での11が4294967307(4294967296+11)と同じの通し番号包装。 4294967307 294967307が2^31の下で良い、ちょうど294967307は4000000000よりすばらしく、したがって、これは増分です。

   When following this procedure, it is essential to verify that all
   relevant servers have been updated at each step, never assume
   anything.  Failing to do this can result in a worse mess than existed
   before the attempted correction.  Also beware that it is the
   relationship between the values of the various serial numbers that is
   important, not the absolute values.  The values used above are
   correct for that one example only.

各ステップですべての関連サーバをアップデートしたことを確かめるのは続くとき、この手順が何も決して仮定しないのが不可欠です。 これをしないと、試みられた修正の前に存在しているより悪い混乱はもたらされることができます。 また、それが絶対値ではなく、様々な通し番号の値の間の重要な関係であるのに注意してください。 その1つの例だけに、上で使用された値は正しいです。

   It is possible in essentially all cases to correct the serial number
   in two steps by being more aggressive in the choices of the serial
   numbers.  This however causes the numbers used to be less "nice", and
   requires considerably more care.

本質的にはすべての場合では、通し番号の選択で、より攻撃的であることによって2ステップにおける通し番号を修正するのは可能です。 これは、しかしながら、それほど「良く」ならないように使用される数を引き起こして、かなり多くの注意を必要とします。

   Also, note that not all nameserver implementations correctly
   implement serial number operations.  With such servers as secondaries
   there is typically no way to cause the serial number to become
   smaller, other than contacting the administrator of the server and
   requesting that all existing data for the zone be purged.  Then that
   the secondary be loaded again from the primary, as if for the first
   time.

また、すべてのネームサーバ実装が正しく通し番号操作を実装するというわけではないことに注意してください。 代理人のようなサーバで、通し番号が、より小さくなることを引き起こす方法が全く通常ありません、サーバの管理者に連絡して、ゾーンのためのすべての既存のデータが掃除されるよう要求するのを除いて。 そして、セカンダリは再びまるで初めてかのように予備選挙からロードされます。

   It remains safe to carry out the above procedure, as the
   malfunctioning servers will need manual attention in any case.  After
   the sequence of serial number changes described above, conforming
   secondary servers will have been reset.  Then when the primary server
   has the correct (desired) serial number, contact the remaining
   secondary servers and request their understanding of the correct
   serial number be manually corrected.  Perhaps also suggest that they
   upgrade their software to a standards conforming implementation.

安全なままで、誤動作サーバがどのような場合でも手動の注意を必要とするとき、上の手順を行うのは残っています。 上で説明された通し番号変化の系列の後に、セカンダリサーバを従わせるのはリセットされてしまうでしょう。 次に、プライマリサーバに正しい(必要な)通し番号があるときには残っているセカンダリサーバに連絡してください、そして、彼らの正しい通し番号の理解が手動で修正されるよう要求してください。 恐らくまた、彼らが実装を従わせる規格に自分達のソフトウェアをアップグレードさせるのを示してください。

   A server which does not implement this algorithm is defective, and
   may be detected as follows.  At some stage, usually when the absolute
   integral value of the serial number becomes smaller, a server with
   this particular defect will ignore the change.  Servers with this
   type of defect can be detected by waiting for at least the time
   specified in the SOA refresh field and then sending a query for the
   SOA.  Servers with this defect will still have the old serial number.
   We are not aware of other means to detect this defect.

このアルゴリズムを実装しないサーバは、欠陥があって、以下の通り検出されるかもしれません。 何らかの段階では、通常、通し番号の絶対整数値が、より小さくなると、この特別の欠陥があるサーバは変化を無視するでしょう。 少なくとも指定されて、SOAが分野をリフレッシュする時の待ちと次に、SOAのために質問を送ることによって、このタイプの欠陥があるサーバを検出できます。 この欠陥があるサーバには、それでも、古い通し番号があるでしょう。 私たちはこの欠陥を検出する他の手段を意識していません。

Elz, et al.              Best Current Practice                 [Page 10]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997

Elz、他 セカンダリDNSサーバ1997年7月の最も良い現在の習慣[10ページ]RFC2182選択と操作

Security Considerations

セキュリティ問題

   It is not believed that anything in this document adds to any
   security issues that may exist with the DNS, nor does it do anything
   to lessen them.

何も本書ではDNSと共に存在するどんな安全保障問題にも加えると信じられていなくて、またそれは彼らを少なくするようなことを何もしません。

   Administrators should be aware, however, that compromise of a server
   for a domain can, in some situations, compromise the security of
   hosts in the domain.  Care should be taken in choosing secondary
   servers so that this threat is minimised.

管理者が意識しているべきである、しかしながら、いくつかの状況で、ドメインへのサーバのその感染はそのドメインにおける、ホストのセキュリティに感染することができます。 セカンダリサーバを選びながら注意を中に入れるべきであるので、この脅威は最小となります。

References

参照

   [RFC1034]   Mockapetris, P., "Domain Names - Concepts and Facilities",
               STD 13, RFC 1034, November 1987.

[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日

   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
               Specification", STD 13, RFC 1035, November 1987

[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、1987年11月

   [RFC1631]   Egevang, K., Francis, P., "The IP Network Address Translator
               (NAT)", RFC 1631, May 1994

[RFC1631]Egevang、K.、フランシス、P.、「IPネットワークアドレス変換機構(NAT)」(RFC1631)1994年5月

   [RFC1982]   Elz, R., Bush, R., "Serial Number Arithmetic",
               RFC 1982, August 1996.

[RFC1982] Elz、R.、ブッシュ、R.、「通し番号演算」、RFC1982、1996年8月。

   [RFC2181]   Elz, R., Bush, R., "Clarifications to the DNS specification",
               RFC 2181, July 1997.

[RFC2181] Elz、R.、ブッシュ、R.、「DNS仕様への明確化」、RFC2181、1997年7月。

Acknowledgements

承認

   Brian Carpenter and Yakov Rekhter suggested mentioning NATs and ALGs
   as a companion to the firewall text.  Dave Crocker suggested
   explicitly exploding the myth.

ブライアンCarpenterとヤコフRekhterは、仲間としてNATsとALGsをファイアウォールテキストに言うのを示しました。 デーヴ・クロッカーは、神話を明らかに爆発させることを提案しました。

Authors' Addresses

作者のアドレス

   Robert Elz
   Computer Science
   University of Melbourne
   Parkville, Vic,  3052
   Australia.

メルボルンParkville、ヴィク、3052オーストラリアのロバートElzコンピュータサイエンス大学。

   EMail: kre@munnari.OZ.AU

メール: kre@munnari.OZ.AU

Elz, et al.              Best Current Practice                 [Page 11]

RFC 2182    Selection and Operation of Secondary DNS Servers   July 1997

Elz、他 セカンダリDNSサーバ1997年7月の最も良い現在の習慣[11ページ]RFC2182選択と操作

   Randy Bush
   RGnet, Inc.
   5147 Crystal Springs Drive NE
   Bainbridge Island, Washington,  98110
   United States.

ランディブッシュRGnet Inc.5147水晶スプリングスドライブNeベーンブリッジ島、ワシントン、98110合衆国。

   EMail: randy@psg.com

メール: randy@psg.com

   Scott Bradner
   Harvard University
   1350 Mass Ave
   Cambridge, MA,  02138
   United States.

スコットブラドナーハーバード大学1350はAveケンブリッジ、MA02138合衆国を一かたまりにします。

   EMail: sob@harvard.edu

メール: sob@harvard.edu

   Michael A. Patton
   33 Blanchard Road
   Cambridge, MA,  02138
   United States.

Roadケンブリッジ、マイケル・A.パットン33ブランシャールMA02138合衆国。

   EMail: MAP@POBOX.COM

メール: MAP@POBOX.COM

Elz, et al.              Best Current Practice                 [Page 12]

Elz、他 最も良い現在の習慣[12ページ]