この文書はRFC2308の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


Network Working Group                                          M. Andrews
Request for Comments: 2308                                          CSIRO
Updates: 1034, 1035                                            March 1998
Category: Standards Track


              Negative Caching of DNS Queries (DNS NCACHE)
             DNS問合せのネガティブキャッシュ(DNS NCACHE)

Status of this Memo
この文書の状態


   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.
   この文書はインターネット共同体のためのインターネット標準化作業中のプ
   ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
   態とこのプロトコル状態は「インターネット公式プロトコル標準」(STD
   1)の現在の版を参照してください。このメモの配布は無制限です。

Copyright Notice
著作権表示

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract
概要

   [RFC1034] provided a description of how to cache negative responses.
   It however had a fundamental flaw in that it did not allow a name
   server to hand out those cached responses to other resolvers, thereby
   greatly reducing the effect of the caching.  This document addresses
   issues raise in the light of experience and replaces [RFC1034 Section
   4.3.4].
   [RFC1034]が否定的な応答をキャッシュする方法の記述を供給しました。し
   かしそれは、ネームサーバーが他のリゾルバに対するキャッシュされた応答
   を配ることを許さなかったという点で、大いにキャッシュ効果を減らす、基
   本的な欠陥を持っていました。この文書は経験を考慮に入れて問題を扱い、
   [RFC1034の4.3.4章]を置き換えます。

   Negative caching was an optional part of the DNS specification and
   deals with the caching of the non-existence of an RRset [RFC2181] or
   domain name.
   ネガティブキャッシュは資源レコード集合[RFC2181]やドメイン名の非存在
   をキャッシュする機能で、DNS仕様の処理のオプション部分でした。

   Negative caching is useful as it reduces the response time for
   negative answers.  It also reduces the number of messages that have
   to be sent between resolvers and name servers hence overall network
   traffic.  A large proportion of DNS traffic on the Internet could be
   eliminated if all resolvers implemented negative caching.  With this
   in mind negative caching should no longer be seen as an optional part
   of a DNS resolver.
   ネガティブキャッシュが、否定的な回答の時間を減らすから有用です。また
   リゾルバとネームサーバ間で送るメッセージの数を減らし、それ故全体的に
   ネットワークトラフィックを減らします。インターネット上のDNSトラ
   フィックの大きな割合が、もしすべてのリゾルバがネガティブキャッシュを
   実行したなら、削除できます。これを考えると、ネガティブキャッシュがD
   NSリゾルバのオプション部分と見られるべきではありません。

1 - Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].
   キーワードMUSTとMUST NOTとREQUIREDとSHALLとSHALL NOTとSHOULDとSHOULD
   NOTとRECOMMENDEDとMAYとOPTIONALは[RFC2119]で記述されるように解釈し
   ます。

   "Negative caching" - the storage of knowledge that something does not
   exist.  We can store the knowledge that a record has a particular
   value.  We can also do the reverse, that is, to store the knowledge
   that a record does not exist.  It is the storage of knowledge that
   something does not exist, cannot or does not give an answer that we
   call negative caching.
   「ネガティブキャッシュ」 − 何かが存在しないという知識の貯蔵。レコー
   ドが特定の値を持つという知識をしまっておくことができます。逆もできま
   す、すなわち、レコードが存在しないという知識をしまっておくことができ
   ます。これは何かが存在しない、答えられないという知識の貯蔵で、ネガティ
   ブキャッシュと呼びます。

   "QNAME" - the name in the query section of an answer, or where this
   resolves to a CNAME, or CNAME chain, the data field of the last
   CNAME.  The last CNAME in this sense is that which contains a value
   which does not resolve to another CNAME.  Implementations should note
   that including CNAME records in responses in order, so that the first
   has the label from the query section, and then each in sequence has
   the label from the data section of the previous (where more than one
   CNAME is needed) allows the sequence to be processed in one pass, and
   considerably eases the task of the receiver.  Other relevant records
   (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs.
   「QNAME」 − 回答の問合せセクションの名前、あるいはCNAMEやCNA
   ME鎖の確認できる最後のCNAMEのデータフィールド。ここでの最後の
   CNAMEは値を含むが、他のCNAMEを導かないものです。解答に含ま
   れるCNAMEレコードが、最初のラベルが問い合わせセクションの値で、
   残りのCNAMEのラベルが直前のCNAMEの値である(複数のCNAM
   Eがある場合)様に順番に含まれていると、受信側の処理が容易になること
   を指摘します。(SIG資源レコード[RFC2065]のような)他のレコードが
   CNAME間に存在できます。
 

   "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as
   described in [RFC1035 Section 4.1.1] and the two terms are used
   interchangeably in this document.
   「NXDOMAIN」 − [RFC1035 Section 4.1.1]で記述された「名前エラー」応
   答コードの代わりの表現で、2つの用語はこの文書で同じ意味に使われます。

   "NODATA" - a pseudo RCODE which indicates that the name is valid, for
   the given class, but are no records of the given type.  A NODATA
   response has to be inferred from the answer.
   「NODATA」 − 所定のクラスで、名前が正当であるが指定されたレコードが
   ないことを示す疑似応答コード。NODATA応答は応答メッセージから推定します。

   "FORWARDER" - a nameserver used to resolve queries instead of
   directly using the authoritative nameserver chain.  The forwarder
   typically either has better access to the internet, or maintains a
   bigger cache which may be shared amongst many resolvers.  How a
   server is identified as a FORWARDER, or knows it is a FORWARDER is
   outside the scope of this document.  However if you are being used as
   a forwarder the query will have the recursion desired flag set.
   「FORWARDER」 − 直接正式なネームサーバチェーンを使う代わりに質問を解
   決で使われるネームサーバ。フォワーダはインターネットに典型的により良
   いアクセスを持つか、あるいは多くのリゾルバの間で共有される大きいキャッ
   シュを保守します。サーバーがフォワーダであると認知されるか、あるいは
   それがフォワーダであると知る方法はこの文書の範囲の外です。しかし、も
   しフォワーダとして用いられているなら、問合せは再帰希望フラグを設定さ
   れるでしょう。

   An understanding of [RFC1034], [RFC1035] and [RFC2065] is expected
   when reading this document.
   [RFC1034]と[RFC1035]と[RFC2065]の理解がこの文書を読む時、期待されます。

2 - Negative Responses
2 - ネガティブ応答

   The most common negative responses indicate that a particular RRset
   does not exist in the DNS.  The first sections of this document deal
   with this case.  Other negative responses can indicate failures of a
   nameserver, those are dealt with in section 7 (Other Negative
   Responses).
   最も一般的な否定回答は特定の資源レコード集合がDNSで存在しないこと
   を示します。この文書の最初の章はこのケースを扱います。他の否定的な回
   答がネームサーバの失敗を示すことができ、それらは7章(他の否定的な回
   答)で扱われます。

   A negative response is indicated by one of the following conditions:
   否定的な回答が次の条件の1つによって示されます:

2.1 - Name Error
2.1 - 名前エラー

   Name errors (NXDOMAIN) are indicated by the presence of "Name Error"
   in the RCODE field.  In this case the domain referred to by the QNAME
   does not exist.  Note: the answer section may have SIG and CNAME RRs
   and the authority section may have SOA, NXT [RFC2065] and SIG RRsets.
   名前エラー(NXDOMAIN)が応答コードフィールドに「名前エラー」と設定さ
   れることで示されます。この場合QNAMEによって示されたドメインは存在し
   ません。メモ:解答セクションは署名とCNAME資源レコードを持つかも
   しれません、そして権威セクションはSOAとNXT[RFC2065]と署名資源
   レコード集合を持つかもしれません。

   It is possible to distinguish between a referral and a NXDOMAIN
   response by the presense of NXDOMAIN in the RCODE regardless of the
   presence of NS or SOA records in the authority section.
   権威セクションのNSやSOAレコードの存在にかかわらず、回答コードで
   NXDOMAINの存在によって参照とNXDOMAIN回答を区別することは可能です。

   NXDOMAIN responses can be categorised into four types by the contents
   of the authority section.  These are shown below along with a
   referral for comparison.  Fields not mentioned are not important in
   terms of the examples.
   NXDOMAIN回答が権威セクションの内容によって4つのタイプに分類される
   ことができます。これらと参照を以下に示します。例で記述されていない
   フィールドは重要ではありません。

           NXDOMAIN RESPONSE: TYPE 1.
           NXDOMAIN 回答:タイプ1

           Header:
               RDCODE=NXDOMAIN
           Query:
               AN.EXAMPLE. A
           Answer:
               AN.EXAMPLE. CNAME TRIPPLE.XX.
           Authority:
               XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
               XX. NS NS1.XX.
               XX. NS NS2.XX.
           Additional:
               NS1.XX. A 127.0.0.2
               NS2.XX. A 127.0.0.3

           NXDOMAIN RESPONSE: TYPE 2.
           NXDOMAIN 回答:タイプ2

           Header:
               RDCODE=NXDOMAIN
           Query:
               AN.EXAMPLE. A
           Answer:
               AN.EXAMPLE. CNAME TRIPPLE.XX.
           Authority:
               XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
           Additional:
               <empty>

           NXDOMAIN RESPONSE: TYPE 3.
           NXDOMAIN 回答:タイプ3

           Header:
               RDCODE=NXDOMAIN
           Query:
               AN.EXAMPLE. A
           Answer:
               AN.EXAMPLE. CNAME TRIPPLE.XX.
           Authority:
               <empty>
           Additional:
               <empty>

           NXDOMAIN RESPONSE: TYPE 4
           NXDOMAIN 回答:タイプ4

           Header:
               RDCODE=NXDOMAIN
           Query:
               AN.EXAMPLE. A
           Answer:
               AN.EXAMPLE. CNAME TRIPPLE.XX.
           Authority:
               XX. NS NS1.XX.
               XX. NS NS2.XX.
           Additional:
               NS1.XX. A 127.0.0.2
               NS2.XX. A 127.0.0.3

           REFERRAL RESPONSE.
           参照回答

           Header:
               RDCODE=NOERROR
           Query:
               AN.EXAMPLE. A
           Answer:
               AN.EXAMPLE. CNAME TRIPPLE.XX.
           Authority:
               XX. NS NS1.XX.
               XX. NS NS2.XX.
           Additional:
               NS1.XX. A 127.0.0.2
               NS2.XX. A 127.0.0.3

   Note, in the four examples of NXDOMAIN responses, it is known that
   the name "AN.EXAMPLE." exists, and has as its value a CNAME record.
   The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to
   exist.  On the other hand, in the referral example, it is shown that
   "AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is
   known one way or the other about the existence of "TRIPPLE.XX", other
   than that "NS1.XX" or "NS2.XX" can be consulted as the next step in
   obtaining information about it.
   NXDOMAIN回答の4つの例で「AN.EXAMPLE.」の名前が存在するのがわかり、
   それはCNAMEレコードの値です。NXDOMAIN は「TRIPPLE.XX」を参照し
   ますが、それは存在しないとわかります。他方、参照の例で、「AN.EXAMPLE」
   が存在し、その値としてCNAME資源レコードがあるが、「NS1.XX」や
   「NS2.XX」がある以外「TRIPPLE.XX」の存在についてはなにもわからず、
   この情報を得て次のステップで調べられることができます。

   Where no CNAME records appear, the NXDOMAIN response refers to the
   name in the label of the RR in the question section.
   CNAMEレコードが現われない場合、NXDOMAIN応答は質問セクションの
   資源レコードラベルの名前に対してです。

2.1.1 Special Handling of Name Error
2.1.1 名前エラーの特別な扱い

   This section deals with errors encountered when implementing negative
   caching of NXDOMAIN responses.
   この章は、 NXDOMAIN 回答のネガティブキャッシュを実装する時、出会うエ
   ラーを扱います。

   There are a large number of resolvers currently in existence that
   fail to correctly detect and process all forms of NXDOMAIN response.
   Some resolvers treat a TYPE 1 NXDOMAIN response as a referral.  To
   alleviate this problem it is recommended that servers that are
   authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN
   responses, that is the authority section contains a SOA record and no
   NS records.  If a non- authoritative server sends a type 1 NXDOMAIN
   response to one of these old resolvers, the result will be an
   unnecessary query to an authoritative server.  This is undesirable,
   but not fatal except when the server is being used a FORWARDER.  If
   however the resolver is using the server as a FORWARDER to such a
   resolver it will be necessary to disable the sending of TYPE 1
   NXDOMAIN response to it, use TYPE 2 NXDOMAIN instead.
   現在正確にすべてのNXDOMAIN回答の形式を検出し処理できない多数のリゾル
   バが存在します。あるリゾルバがタイプ1のNXDOMAIN回答を参照と扱います。
   この問題を軽減するために、NXDOMAIN回答の正式サーバーがタイプ2NXDOMAIN
   回答を送るだけなことが勧められます、これは権威セクションがNSレコー
   ドではなく、SOAレコードを含んでいるということです。もし正式でない
   サーバーがこれらの古いリゾルバの1つにタイプ1NXDOMAIN回答を送るなら、
   結果は正式なサーバーに不必要な質問となるでしょう。これは、サーバーが
   フォワーダーとして使われた場合以外、望ましくありませんが、致命的でも
   ありません。もしリゾルバがサーバをこのようなリゾルバへのフォワーダと
   して用いているとしても、それに対するタイプ1NXDOMAIN回答を送ることに
   障害を与えることが必要であるなら、その代わりにタイプ2NXDOMAINを使っ
   てください。

   Some resolvers incorrectly continue processing if the authoritative
   answer flag is not set, looping until the query retry threshold is
   exceeded and then returning SERVFAIL.  This is a problem when your
   nameserver is listed as a FORWARDER for such resolvers.  If the
   nameserver is used as a FORWARDER by such resolver, the authority
   flag will have to be forced on for NXDOMAIN responses to these
   resolvers.  In practice this causes no problems even if turned on
   always, and has been the default behaviour in BIND from 4.9.3
   onwards.
   あるリゾルバが、もし正式な解答フラグが設定されないなら、間違って処理
   を続けます、問合せ回数の制限を越えるまで問合せが続けられ、SERVFAILを
   返します。これは、あなたのネームサーバがこのようなリゾルバのフォワー
   ダとされた時、問題です。もしネームサーバがこのようなリゾルバにフォワー
   ダに用いられるなら、正式フラグがこのリゾルバにNXDOMAIN回答を強要する
   でしょう。実際はこれは常にオンでも問題を起こさなず、BIND4.9.3
   以前でデフォルト動作でした。

2.2 - No Data
2.2 - データなし

   NODATA is indicated by an answer with the RCODE set to NOERROR and no
   relevant answers in the answer section.  The authority section will
   contain an SOA record, or there will be no NS records there.
   NODATAは、応答コードはエラーなしで、解答セクションに適切な答えがない
   事で示されます。権威セクションはSOA レコードを含むでしょう、あるい
   はNSレコードがないでしょう。

   NODATA responses have to be algorithmically determined from the
   response's contents as there is no RCODE value to indicate NODATA.
   In some cases to determine with certainty that NODATA is the correct
   response it can be necessary to send another query.
   応答コードでNODATAを示すことはないので、NODATA回答はを示すアルゴリズ
   ム的に回答の中身から決定しなければなりません。しばしばNODATAが正しい
   回答かどうか決定するためにもう1つの質問を送ることが必要です。

   The authority section may contain NXT and SIG RRsets in addition to
   NS and SOA records.  CNAME and SIG records may exist in the answer
   section.
   権威セクションはNSとSOAレコードのほかにNXTとSIG資源レコー
   ド集合を含むかもしれません。CNAMEとSIGレコードが解答セクショ
   ンで存在するかもしれません。

   It is possible to distinguish between a NODATA and a referral
   response by the presence of a SOA record in the authority section or
   the absence of NS records in the authority section.
   権威セクションでのSOAレコードの存在か、権威セクションのNSレコー
   ドの欠如でNODATAと参照の回答を区別することは可能です。

   NODATA responses can be categorised into three types by the contents
   of the authority section.  These are shown below along with a
   referral for comparison.  Fields not mentioned are not important in
   terms of the examples.
   NODATA回答が権威セクションの内容によって3つのタイプに分類できます。
   これらと参照を下に示します。例で記述していないフィールドは重要ではあ
   りません。

           NODATA RESPONSE: TYPE 1.
           データなし回答:タイプ1

           Header:
               RDCODE=NOERROR
           Query:
               ANOTHER.EXAMPLE. A
           Answer:
               <empty>
           Authority:
               EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
               EXAMPLE. NS NS1.XX.
               EXAMPLE. NS NS2.XX.
           Additional:
               NS1.XX. A 127.0.0.2
               NS2.XX. A 127.0.0.3

           NO DATA RESPONSE: TYPE 2.
           データなし回答:タイプ2

           Header:
               RDCODE=NOERROR
           Query:
               ANOTHER.EXAMPLE. A
           Answer:
               <empty>
           Authority:
               EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
           Additional:
               <empty>

           NO DATA RESPONSE: TYPE 3.
           データなし回答:タイプ3

           Header:
               RDCODE=NOERROR
           Query:
               ANOTHER.EXAMPLE. A
           Answer:
               <empty>
           Authority:
               <empty>
           Additional:
               <empty>

           REFERRAL RESPONSE.
           参照回答

           Header:
               RDCODE=NOERROR
           Query:
               ANOTHER.EXAMPLE. A
           Answer:
               <empty>
           Authority:
               EXAMPLE. NS NS1.XX.
               EXAMPLE. NS NS2.XX.
           Additional:
               NS1.XX. A 127.0.0.2
               NS2.XX. A 127.0.0.3


   These examples, unlike the NXDOMAIN examples above, have no CNAME
   records, however they could, in just the same way that the NXDOMAIN
   examples did, in which case it would be the value of the last CNAME
   (the QNAME) for which NODATA would be concluded.
   NXDOMAINの例ではいずれの場合も最後のCNAME(QNAME)の値が
   NODATAが終わっていましたが、これらの例は上記のNXDOMAINの例と異なり
   CNAMEレコードがありません。

2.2.1 - Special Handling of No Data
2.2.1 - データなしの特別な処理

   There are a large number of resolvers currently in existence that
   fail to correctly detect and process all forms of NODATA response.
   Some resolvers treat a TYPE 1 NODATA response as a referral.  To
   alleviate this problem it is recommended that servers that are
   authoritative for the NODATA response only send TYPE 2 NODATA
   responses, that is the authority section contains a SOA record and no
   NS records.  Sending a TYPE 1 NODATA response from a non-
   authoritative server to one of these resolvers will only result in an
   unnecessary query.  If a server is listed as a FORWARDER for another
   resolver it may also be necessary to disable the sending of TYPE 1
   NODATA response for non-authoritative NODATA responses.
   現在正確にすべてのNODATA回答の形式を発見して処理するのができないリゾ
   ルバが多数います。あるリゾルバがタイプ1NODATA回答を参照として扱いま
   す。この問題を軽減するために、NODATA回答の正式なサーバーがタイプ2
   NODATA回答を送るだけであることが勧められます、これは権威セクションに
   NSレコードがなくSOAレコードを含むことです。タイプ1NODATA回答を
   正式でないサーバーからこれらのリゾルバの1人へ送ることはただ不必要な
   質問をもたらすだけでしょう。もしサーバーが他のリゾルバのフォワーダと
   登録される、正式でないNODATA回答のためにタイプ1NODATA回答を送ること
   を止めることが必要かもしれません。

   Some name servers fail to set the RCODE to NXDOMAIN in the presence
   of CNAMEs in the answer section.  If a definitive NXDOMAIN / NODATA
   answer is required in this case the resolver must query again using
   the QNAME as the query label.
   あるネームサーバーが解答セクションでにCNAMEがある時応答コードに
   NXDOMAINを設定し損ねます。もし最終的なNXDOMAIN/NODATA回答がこの場合
   必要なら、リゾルバはQNAMEを質問ラベルとして用いて再び質問しなくては
   なりません。

3 - Negative Answers from Authoritative Servers
3 - 正式なサーバーからの否定的な答え

   Name servers authoritative for a zone MUST include the SOA record of
   the zone in the authority section of the response when reporting an
   NXDOMAIN or indicating that no data of the requested type exists.
   This is required so that the response may be cached.  The TTL of this
   record is set from the minimum of the MINIMUM field of the SOA record
   and the TTL of the SOA itself, and indicates how long a resolver may
   cache the negative answer.  The TTL SIG record associated with the
   SOA record should also be trimmed in line with the SOA's TTL.
   ゾーンの正式なネームサーバーが、NXDOMAINを報告するか、求められたタイ
   プのデータが存在しないことを示す時、回答の権威セクションにゾーンのS
   OAレコードを含めなくてはなりません(MUST)。これは、応答をキャッシュ
   するために必要とされます。このレコードのTTLはSOAレコードの
   MINIMUMフィールドとSOA自身のTTLの小さいほうに設定され、どれぐらい
   長くリゾルバが否定的な答えのキャッシュしてもよいか示します。SOAレ
   コードに関連する署名レコードのTTLはSOAのTTLと一致させるべき
   です。

   If the containing zone is signed [RFC2065] the SOA and appropriate
   NXT and SIG records MUST be added.
   もしゾーンが署名[RFC2065]されるなら、SOAと適切なNXTと署名レ
   コードを加えなくてはなりません(MUST)。

4 - SOA Minimum Field
4 - SOA最小フィールド

   The SOA minimum field has been overloaded in the past to have three
   different meanings, the minimum TTL value of all RRs in a zone, the
   default TTL of RRs which did not contain a TTL value and the TTL of
   negative responses.
   最小フィールドは過去3つの異なる意味で使われました、すべてのゾーンの
   資源レコードの最小TTL、TTL値がない場合のデフォルトTTL、否
   定回答のTTL。

   Despite being the original defined meaning, the first of these, the
   minimum TTL value of all RRs in a zone, has never in practice been
   used and is hereby deprecated.
   元々の定義は最初の、ゾーンの資源レコードの最小TTLですが、実際にこ
   の意味で使われたことはなく、ここで廃止します。

   The second, the default TTL of RRs which contain no explicit TTL in
   the master zone file, is relevant only at the primary server.  After
   a zone transfer all RRs have explicit TTLs and it is impossible to
   determine whether the TTL for a record was explicitly set or derived
   from the default after a zone transfer.  Where a server does not
   require RRs to include the TTL value explicitly, it should provide a
   mechanism, not being the value of the MINIMUM field of the SOA
   record, from which the missing TTL values are obtained.  How this is
   done is implementation dependent.
   2つ目は、プライマリーサーバに関して、マスターゾーンファイルで明示的
   なTTLを含まない資源レコードのデフォルトTTLとしてだけ適切です。
   ゾーン転送後はすべての資源レコードは明示的なTTLを持ち、レコードの
   TTLが明示的に定められているか、ゾーン転送の後にデフォルトから生じ
   たかどうか決定することは不可能です。サーバーが資源レコードに明示的に
   TTL値を含むように要求しない場合、SOAレコードの最小フィールドの
   値ではなく、省略したTTL値が得られるメカニズムを供給するべきです。
   この方法は実装に依存します。

   The Master File format [RFC 1035 Section 5] is extended to include
   the following directive:
   マスターファイルフォーマット[RFC 1035 5章]は次の指令を含むために拡
   張されます:。

                           $TTL <TTL> [comment]

   All resource records appearing after the directive, and which do not
   explicitly include a TTL value, have their TTL set to the TTL given
   in the $TTL directive.  SIG records without a explicit TTL get their
   TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5].
   すべての指令後に現われる明示的なTTL値を含まない資源レコードは、
   $TTL指令で与えられたTTL値を設定します。明示的なTTLがない署名レ
   コードは、「オリジナルのTTL」[RFC 2065 4.5章]からTTLを得ます。

   The remaining of the current meanings, of being the TTL to be used
   for negative responses, is the new defined meaning of the SOA minimum
   field.
   残りの意味は、否定的な回答に使われるTTLで、SOA最小限フィールド
   の新しい定義された意味です。

5 - Caching Negative Answers
5 - 否定的な答えのキャッシュ

   Like normal answers negative answers have a time to live (TTL).  As
   there is no record in the answer section to which this TTL can be
   applied, the TTL must be carried by another method.  This is done by
   including the SOA record from the zone in the authority section of
   the reply.  When the authoritative server creates this record its TTL
   is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
   This TTL decrements in a similar manner to a normal cached answer and
   upon reaching zero (0) indicates the cached negative answer MUST NOT
   be used again.
   標準的な答えのように否定的な答えが寿命(TTL)を持ちます。TTLの適用
   できるレコードが解答セクションにないので、TTLは他の方法で運ばなければ
   なりません。これはゾーンの答えの権威セクションにSOAレコードを含め
   ることでされます。正式なサーバーがこのレコードを作る時、そのTTLは
   SOA.MINIMUMフィールドとSOATTLの小さいほうから得られます。このTT
   Lは標準キャッシュと同じ方法で減算され、ゼロや負の否定回答は使っては
   なりません(MUST NOT)。

   A negative answer that resulted from a name error (NXDOMAIN) should
   be cached such that it can be retrieved and returned in response to
   another query for the same <QNAME, QCLASS> that resulted in the
   cached negative response.
   名前エラーの結果として生じた否定的な答え(NXDOMAIN)が、検索できるよ
   うにキャッシュされ、同じ<QNAME, QCLASS>の質問で否定応答として返される
   べきです。

   A negative answer that resulted from a no data error (NODATA) should
   be cached such that it can be retrieved and returned in response to
   another query for the same <QNAME, QTYPE, QCLASS> that resulted in
   the cached negative response.
   データエラーなし(NODATA)の結果生じたネガティブ回答が、同じ<QNAME,
   QTYPE, QCLASS>の検索の回答として使うため、キャッシュされるべきで、こ
   れはキャッシュされたネガティブ回答を返します。

   The NXT record, if it exists in the authority section of a negative
   answer received, MUST be stored such that it can be be located and
   returned with SOA record in the authority section, as should any SIG
   records in the authority section.  For NXDOMAIN answers there is no
   "necessary" obvious relationship between the NXT records and the
   QNAME.  The NXT record MUST have the same owner name as the query
   name for NODATA responses.
   NXTレコードは、もしそれが受信した否定的な解答の権威セクションに存
   在しているなら、そのまま保存し、権威セクションの署名レコード同様に、
   SOAレコードと共に権威セクションで返します(MUST)。NXDOMAIN解答でN
   XTレコードとQNAMEの間の明白な関係が必要ありません。NXTレコードは
   NODATA回答の質問名と同じ所有者名を持っていなくてはなりません(MUST)。

   Negative responses without SOA records SHOULD NOT be cached as there
   is no way to prevent the negative responses looping forever between a
   pair of servers even with a short TTL.
   SOAレコードがない否定的解答は、例えTTLが小さくても、対のサーバー
   間での否定的解答が永久にループするのを妨ぐ方法がないので、キャッシュ
   されるべきではありません(SHOULD NOT)。

   Despite the DNS forming a tree of servers, with various mis-
   configurations it is possible to form a loop in the query graph, e.g.
   two servers listing each other as forwarders, various lame server
   configurations.  Without a TTL count down a cache negative response
   when received by the next server would have its TTL reset.  This
   negative indication could then live forever circulating between the
   servers involved.
   DNSがサーバーの木を形成しているにもかかわらず、種々の間違えた設定
   で問合せグラフにループを作ることが可能です、例えばお互いをフォワーダ
   と設定したり、様々な不完全なサーバ設定によりです。キャッシュのネガティ
   ブ解答のカウントダウンをしないと、次のサーバでTTLをリセットしてし
   まいます。この否定的な表示は関連サーバーの間でループし永久に残ること
   ができます。

   As with caching positive responses it is sensible for a resolver to
   limit for how long it will cache a negative response as the protocol
   supports caching for up to 68 years.  Such a limit should not be
   greater than that applied to positive answers and preferably be
   tunable.  Values of one to three hours have been found to work well
   and would make sensible a default.  Values exceeding one day have
   been found to be problematic.
   プロトコルは68年以上のキャッシュをサポートするが、ポジティブキャッ
   シュ同様に、リゾルバがネガティブキャッシュでもキャッシュ時間に制限を
   設けるべきです。このような制限はポジティブキャッシュに適用するものよ
   り大きくはなく、調整可能であるべきではありません。1時間から3時間ぐ
   らいの値でうまく動作し、デフォルトにすべきでしょう。1日を超える値は
   問題が多いことがわかっています。

6 - Negative answers from the cache
6 - キャッシュからのネガティブ解答

   When a server, in answering a query, encounters a cached negative
   response it MUST add the cached SOA record to the authority section
   of the response with the TTL decremented by the amount of time it was
   stored in the cache.  This allows the NXDOMAIN / NODATA response to
   time out correctly.
   サーバーが、問合せの答えで、キャッシュされた否定反応に遭遇する時、
   キャッシュされたSOAレコードを解答の権威セクションに追加し(MUST)、
   TTLはキャッシュした時間分現象しなければなりません。これは
   NXDOMAIN/NODATA回答が正確にタイムアウトするようにします。

   If a NXT record was cached along with SOA record it MUST be added to
   the authority section.  If a SIG record was cached along with a NXT
   record it SHOULD be added to the authority section.
   もしNXTレコードがSOAレコードとともにキャッシュされたなら、これ
   を権威セクション追加します(MUST)。もし署名レコードがNXTレコードと
   ともにキャッシュされたなら、これも権威セクションに加えるべきです
   (SHOULD)。

   As with all answers coming from the cache, negative answers SHOULD
   have an implicit referral built into the answer.  This enables the
   resolver to locate an authoritative source.  An implicit referral is
   characterised by NS records in the authority section referring the
   resolver towards a authoritative source.  NXDOMAIN types 1 and 4
   responses contain implicit referrals as does NODATA type 1 response.
   すべてのキャッシュから来る答えと同様に、否定的な答えが答えに組み込
   まれた暗黙の参照を持つべきです(SHOULD)。これはリゾルバに正式な情報
   源を突き止めることができるようにします。暗黙の参照が、正式な情報源
   に向かってリゾルバを導く、権威セクションのNSレコードです。
   NXDOMAINタイプ1とタイプ4回答が暗示的な参照を含んでいて、NODATAタ
   イプ1回答もそうです。

7 - Other Negative Responses
7 - 他の否定応答

   Caching of other negative responses is not covered by any existing
   RFC.  There is no way to indicate a desired TTL in these responses.
   Care needs to be taken to ensure that there are not forwarding loops.
   他の否定的な反応をキャッシュすることは既存のRFCでカバーされません。
   これらの回答に望ましいTTLを示す方法がありません。ループがないこと
   を保証する注意が必要です。

7.1 Server Failure (OPTIONAL)
7.1 サーバ障害(オプション)

   Server failures fall into two major classes.  The first is where a
   server can determine that it has been misconfigured for a zone.  This
   may be where it has been listed as a server, but not configured to be
   a server for the zone, or where it has been configured to be a server
   for the zone, but cannot obtain the zone data for some reason.  This
   can occur either because the zone file does not exist or contains
   errors, or because another server from which the zone should have
   been available either did not respond or was unable or unwilling to
   supply the zone.
   サーバ障害が大きく2つに分類されます。1つめはサーバのゾーン設定に誤
   りがある場合です。これはあるゾーンのサーバと記録されて、しかしそのソー
   ンのサーバに設定されてないか、ゾーンのサーバーと設定されているが、何
   らかの理由でゾーンデータが得られなかった場合かもしれません。これは、
   ゾーンファイルが存在しないかエラーを含むか、他のサーバから得ようとし
   てるが、そのサーバが応答しないか利用不可能か、ゾーン供給が不可能かで
   す。

   The second class is where the server needs to obtain an answer from
   elsewhere, but is unable to do so, due to network failures, other
   servers that don't reply, or return server failure errors, or
   similar.
   2つめはサーバーが他のところから答えを得る必要がある場合で、しかしネッ
   トワーク障害か他のサーバが応答しないか応答サーバがサーバ障害エラーを
   返すかなどで、解答が不可能な場合です。

   In either case a resolver MAY cache a server failure response.  If it
   does so it MUST NOT cache it for longer than five (5) minutes, and it
   MUST be cached against the specific query tuple <query name, type,
   class, server IP address>.
   いずれかの場合、リゾルバがサーバー失敗応答をキャッシュしてもよいです
   (MAY)。もしそうするなら、これは5分以上キャッシュしてはならず(MUST
   NOT)、キャッシュは<問合せ名、タイプ、クラス、サーバーIPアドレス>の
   組合せでしなければなりません(MUST)。

7.2 Dead / Unreachable Server (OPTIONAL)
7.2 停止/到達不可能サーバー(オプション)

   Dead / Unreachable servers are servers that fail to respond in any
   way to a query or where the transport layer has provided an
   indication that the server does not exist or is unreachable.  A
   server may be deemed to be dead or unreachable if it has not
   responded to an outstanding query within 120 seconds.
   停止/到達不可能サーバーは、何らかの意味で問合せに失敗したか、転送
   レイヤがサーバが存在しないか到達不能と表示されるサーバです。サーバー
   が、もし120秒の以内に明確に質問に返答しなかったなら、停止してい
   るか到達不可能と思われるかもしれません。

   Examples of transport layer indications are:
   輸送レイヤの表示の例が以下です:

      ICMP error messages indicating host, net or port unreachable.
      到達不可能なホストやネットやポートを示すICMPエラーメッセージ
      TCP resets
      TCPリセット
      IP stack error messages providing similar indications to those above.
      上記に類似した表示を供給しているIPスタックエラーメッセージ

   A server MAY cache a dead server indication.  If it does so it MUST
   NOT be deemed dead for longer than five (5) minutes.  The indication
   MUST be stored against query tuple <query name, type, class, server
   IP address> unless there was a transport layer indication that the
   server does not exist, in which case it applies to all queries to
   that specific IP address.
   サーバは停止サーバー表示をキャッシュできます(MAY)。もしそうするなら、
   5分以上、停止してるとみなされてはなりません(MUST NOT)。キャッシュは、
   転送レイヤでサーバーが存在しないと表示された場合は全てのそのIPアド
   レスへの問合せに対して行い、そうでなければ表示は<問合せ名、タイプ、
   クラス、サーバーIPアドレス>の組合せで行われなければなりません(MUST)。

8 - Changes from RFC 1034
8 - RFC 1034からの変更点

   Negative caching in resolvers is no-longer optional, if a resolver
   caches anything it must also cache negative answers.
   リゾルバのネガティブキャッシュは任意ではありません、もしリゾルバが何
   かをキャッシュするなら、否定的な答えもキャッシュしなくてはなりません。

   Non-authoritative negative answers MAY be cached.
   正式でない否定的な答えがキャッシュされるかもしれません(MAY)。

   The SOA record from the authority section MUST be cached.  Name error
   indications must be cached against the tuple <query name, QCLASS>.
   No data indications must be cached against <query name, QTYPE,
   QCLASS> tuple.
   権威セクションのSOAレコードはキャッシュしなければなりません(MUST)。
   名前エラー表示が<質問名前、QCLASS> に対してキャッシュされなくてはな
   りません。データなし表示が<質問名、QTYPE、QCLASS>に対してキャッシュ
   されてはなりません。

   A cached SOA record must be added to the response.  This was
   explicitly not allowed because previously the distinction between a
   normal cached SOA record, and the SOA cached as a result of a
   negative response was not made, and simply extracting a normal cached
   SOA and adding that to a cached negative response causes problems.
   キャッシュされたSOAレコードを回答に加えなければなりません。以前は
   標準的にキャッシュされたSOAレコードと否定的な回答の結果キャッシュ
   されたSOAの間の区別ができなかったので、明示的に許されませんでした、
   そして標準的にキャッシュされたSOAを使い、キャッシュされた否定応答
   にこれを加えることは問題を起こします。

   The $TTL TTL directive was added to the master file format.
   マスターファーいるフォーマットに$TTL TTL指令が追加されました。

9 - History of Negative Caching
9 - ネガティブキャッシュの歴史

   This section presents a potted history of negative caching in the DNS
   and forms no part of the technical specification of negative caching.
   この章はDNSのネガティブキャッシュの歴史を提出し、ネガティブキャッ
   シュの専門仕様の一部ではありません。

   It is interesting to note that the same concepts were re-invented in
   both the CHIVES and BIND servers.
   同じ概念がCHIVESとBINDの両方で再発明されたこと興味深いです。

   The history of the early CHIVES work (Section 9.1) was supplied by
   Rob Austein <sra@epilogue.com> and is reproduced here in the form in
   which he supplied it [MPA].
   初期のCHIVESの仕事の歴史(9.1章)はRob Austein <sra@epilogue.com>
   によって供給されて、彼が[MPA]で供給した形式でここで示します。

   Sometime around the spring of 1985, I mentioned to Paul Mockapetris
   that our experience with his JEEVES DNS resolver had pointed out the
   need for some kind of negative caching scheme.  Paul suggested that
   we simply cache authoritative errors, using the SOA MINIMUM value for
   the zone that would have contained the target RRs.  I'm pretty sure
   that this conversation took place before RFC-973 was written, but it
   was never clear to me whether this idea was something that Paul came
   up with on the spot in response to my question or something he'd
   already been planning to put into the document that became RFC-973.
   In any case, neither of us was entirely sure that the SOA MINIMUM
   value was really the right metric to use, but it was available and
   was under the control of the administrator of the target zone, both
   of which seemed to us at the time to be important feature.
   1985年の春ごろに、私はPaul Mockapetrisに彼のJEEVES DNSリゾルバと
   の経験が何らかの種類のネガティブキャッシュの必要を指摘していたと述べ
   ました。Paulは我々がただ目標資源レコードを含んでいたゾーンのSOAMINIMUM
   値を使って正式なエラーをキャッシュすることを提案しました。この会話が、
   RFC-973が書かれる前に、起きたことがかなり確かです、しかしこのアイデア
   がPaulが私の質問に応えて思い付いた何かか、あるいは彼がすでにRFC-973に
   なった文書に入れることを計画していた何かであったかどうかは、私には明
   確ではありませんでした。どちらにしろ、我々のいずれもがSOA MINIMUM値が
   本当に使うべき正しい尺度か確かではありませんでしたが、利用可能で、ゾー
   ンの管理者の制御下にあり、この2つが重要な特徴に思われました。

   Late in 1987, I released the initial beta-test version of CHIVES, the
   DNS resolver I'd written to replace Paul's JEEVES resolver.  CHIVES
   included a search path mechanism that was used pretty heavily at
   several sites (including my own), so CHIVES also included a negative
   caching mechanism based on SOA MINIMUM values.  The basic strategy
   was to cache authoritative error codes keyed by the exact query
   parameters (QNAME, QCLASS, and QTYPE), with a cache TTL equal to the
   SOA MINIMUM value.  CHIVES did not attempt to track down SOA RRs if
   they weren't supplied in the authoritative response, so it never
   managed to completely eliminate the gratuitous DNS error message
   traffic, but it did help considerably.  Keep in mind that this was
   happening at about the same time as the near-collapse of the ARPANET
   due to congestion caused by exponential growth and the the "old"
   (pre-VJ) TCP retransmission algorithm, so negative caching resulted
   in drasticly better DNS response time for our users, mailer daemons,
   etcetera.
   1987年の遅くに、私はPaulのJEEVESリゾルバを置き換えるために、
   CHIVESの最初のベータテストバージョンDNSリゾルバをリリースしました。
   CHIVES が(私自身のものを含めて)いくつかのサイトにおいてかなりひどく
   使われた捜索パスメカニズムを含み、それでCHIVESがSOA MINIMUM値に基づく
   ネガティブキャッシュメカニズムを含みました。基本的な戦略は、正確な問
   合せパラメータ(QNAMEとQCLASSとQTYPE)を鍵として、SOA MINIMUM値をTT
   Lとして正式なエラーコードをキャッシュする事でした。CHIVESは、もし正
   式な回答で供給されなかったなら、SOA資源レコードを追う事をを試みま
   せんでした、そのため完全に根拠のないDNSエラーメッセージトラフィッ
   クを削除することに成功しませんでしたが、かなり減らしました。これが、
   指数関数的な成長や「古い」(VJ前の)TCP送信アルゴリズムにより起
   きた混雑でARPANETが崩壊寸前の時に起きて、ネガティブキャッシュがユーザ
   やメーラーなどにDNS応答時間をとても良くした事を念頭において下さい。

   As far as I know, CHIVES was the first resolver to implement negative
   caching.  CHIVES was developed during the twilight years of TOPS-20,
   so it never ran on very many machines, but the few machines that it
   did run on were the ones that were too critical to shut down quickly
   no matter how much it cost to keep them running.  So what few users
   we did have tended to drive CHIVES pretty hard.  Several interesting
   bits of DNS technology resulted from that, but the one that's
   relevant here is the MAXTTL configuration parameter.
   私が知っている限り、CHIVESはネガティブキャッシュを実装する最初のリゾ
   ルバでした。CHIVESはTOPS-20の黄昏時年の間に開発され、そのため決して多
   くの機械上では動きませんでしたが、動作していた少数の機械が、動作させ
   るのに費用がかかったかにもかかわらず、速くシャットダウンするのがあま
   りにも問題でした。それで我々がしたわずかなユーザーすべてはCHIVESをか
   なり硬くする傾向がありました。DNS技術のいくつかの面白いビットがそ
   れの結果として生じましたが、適切なのはMAXTTL設定パラメータです。

   Experience with JEEVES had already shown that RRs often showed up
   with ridiculously long TTLs (99999999 was particularly popular for
   many years, due to bugs in the code and documentation of several
   early versions of BIND), and that robust software that blindly
   believed such TTLs could create so many strange failures that it was
   often necessary to reboot the resolver frequently just to clear this
   garbage out of the cache.  So CHIVES had a configuration parameter
   "MAXTTL", which specified the maximum "reasonable" TTL in a received
   RR.  RRs with TTLs greater than MAXTTL would either have their TTLs
   reduced to MAXTTL or would be discarded entirely, depending on the
   setting of another configuration parameter.
   JEEVESの経験ですでにばかげて長いTTL(BINDのいくつかの初期バー
   ジョンのコードと文書のバグで、99999999が何年も存在しました)の資源レ
   コードがしばしば現われました、そしてやみくもにこのようなTTLを信じ
   た強靭なソフトウェアは多くの妙な障害に対ししばしばキャッシュからごみ
   をきれいにするためリゾルバをリブートするのが必要でした。それでCHIVES
   が設定パラメータ「MAXTTL」を持ち、容認できる資源レコードの最大の「合
   理的な」 TTLを指定しました。MAXTTL以上のTTLを持つ資源レコードは
   TTLをMAXTTLに減らされるか、他の設定パラメータ設定に従って捨てられ
   ます。

   When we started getting field experience with CHIVES's negative
   caching code, it became clear that the SOA MINIMUM value was often
   large enough to cause the same kinds of problems for negative caching
   as the huge TTLs in RRs had for normal caching (again, this was in
   part due to a bug in several early versions of BIND, where a
   secondary server would authoritatively deny all knowledge of its
   zones if it couldn't contact the primaries on reboot).  So we started
   running the negative cache TTLs through the MAXTTL check too, and
   continued to experiment.
   我々がCHIVESのネガティブキャッシュコードでフィールド実験を始めた時、
   SOA MINIMUM値がしばしば巨大で、通常のキャッシュのTTLの大きな資源
   レコード同様の問題を、ネガティブキャッシュで起こしました(これもいく
   つかの初期のバージョンのBINDの問題で、セカンダリサーバがゾーンの
   情報をリブートするまでプライマリに持ってこないバグのためです)。その
   ため我々は同じくMAXTTLチェックによりネガティブキャッシュTTLを処理
   し、実験し続けました。

   The configuration that seemed to work best on WSMR-SIMTEL20.ARMY.MIL
   (last of the major Internet TOPS-20 machines to be shut down, thus
   the last major user of CHIVES, thus the place where we had the
   longest experimental baseline) was to set MAXTTL to about three days.
   Most of the traffic initiated by SIMTEL20 in its last years was
   mail-related, and the mail queue timeout was set to one week, so this
   gave a "stuck" message several tries at complete DNS resolution,
   without bogging down the system with a lot of useless queries.  Since
   (for reasons that now escape me) we only had the single MAXTTL
   parameter rather than separate ones for positive and negative
   caching, it's not clear how much effect this setting of MAXTTL had on
   the negative caching code.
   (最後の主要なインターネットTOPS-20がシャットダウンし、最後の主要な
   CHIVESユーザがいて、それで我々が最も長い実験基盤を持っていた)
   WSMR-SIMTEL20.ARMY.MILで最も良く作動するように思われた設定はMAXTTLを
   およそ3日にする事でした。その最後の年にSIMTEL20によって始められたト
   ラフィックの大部分がメール関連で、メールキューのタイムアウトが1週に
   設定されていました、そのため多くの無用な問合せでシステムを窮地に落と
   し入れないで、「押し込まれた」メッセージに何度か完全なDNS解決の試
   みを与えました。(今私が忘れてしまった理由で)我々がポジティブとネガ
   ティブキャッシュを切り離さずひとつのMAXTTLパラメータを持っだけだった
   ので、このMAXTTLの設定がネガティブキャッシュコードの上にどれぐらいの
   効果を持っていたかは明確ではありません。

   CHIVES also included a second, somewhat controversial mechanism which
   took the place of negative caching in some cases.  The CHIVES
   resolver daemon could be configured to load DNS master files, giving
   it the ability to act as what today would be called a "stealth
   secondary".  That is, when configured in this way, the resolver had
   direct access to authoritative information for heavily-used zones.
   The search path mechanisms in CHIVES reflected this: there were
   actually two separate search paths, one of which only searched local
   authoritative zone data, and one which could generate normal
   iterative queries.  This cut down on the need for negative caching in
   cases where usage was predictably heavy (e.g., the resolver on
   XX.LCS.MIT.EDU always loaded the zone files for both LCS.MIT.EDU and
   AI.MIT.EDU and put both of these suffixes into the "local" search
   path, since between them the hosts in these two zones accounted for
   the bulk of the DNS traffic).  Not all sites running CHIVES chose to
   use this feature; C.CS.CMU.EDU, for example, chose to use the
   "remote" search path for everything because there were too many
   different sub-zones at CMU for zone shadowing to be practical for
   them, so they relied pretty heavily on negative caching even for
   local traffic.
   CHIVESがある場合にはネガティブキャッシュの代わりになった2番目の、幾
   分論争の的なメカニズムを含みました。CHIVESリゾルバデーモンは、今日
   「ステルスセカンダリ」と呼ばれるであろう能力があり、DNSマスター
   ファイルをロードするように設定できました。すなわち、このようにして設
   定された時、リゾルバはよく使われたゾーンの正式な情報に直接アクセスを
   持ちました。CHIVESの捜索パスメカニズムはこれを反映しました:実際に2
   つの別の捜索パスがあり、1つはただローカルな正式ゾーンデータと標準的
   な反復の質問で生成できたものを捜索しただけでした。これは使用が予想可
   能に激しかった事例でネガティブキャッシュの必要を減らしました。(例え
   ば、XX.LCS.MIT.EDU上のリゾルバは常にLCS.MIT.EDUとAI.MIT.EDUの両方の
   ゾーンファイルをロードし、そして両者のサフィックスを「ローカル」探索
   パスにいれ、これらの2つのゾーン内のホストのDNSトラフィックを集め
   ました)。すべてのCHIVESを動かすサイトがこの機能を使うと決めたわけで
   はありません;C.CS.CMU.EDUは、例えば、ゾーンをキャッシュするのを実用
   的にするには多すぎるサブゾーンがあったので、すべて「遠隔」捜索パスを
   使うことに決め、ローカルなトラフィックに対してもかなりネガティブ
   キャッシュに頼りました。

   Overall, I still think the basic design we used for negative caching
   was pretty reasonable: the zone administrator specified how long to
   cache negative answers, and the resolver configuration chose the
   actual cache time from the range between zero and the period
   specified by the zone administrator.  There are a lot of details I'd
   do differently now (like using a new SOA field instead of overloading
   the MINIMUM field), but after more than a decade, I'd be more worried
   if we couldn't think of at least a few improvements.
   全体的に、私はまだ我々がネガティブキャッシュのために使った基本的なデ
   ザインがかなり合理的であったと思います:ゾーン管理者はどれほど長い間
   否定的な答えをキャッシュするべきか明示しました、そしてリゾルバ設定は
   0からゾーン管理者によって指定された期間までの間からの実際のキャッ
   シュ時間を選択しました。(最小フィールドに負担をかけ過ぎる代わりに新
   しいSOAフィールドを使うように)今では違っているであろう多くの細部
   がありますが、10年以上たって、もし我々が少なくとも少数の改良につい
   て考えることができなかったらと考えると、いっそう心配になります。

9.2 BIND
9.2 BIND

   While not the first attempt to get negative caching into BIND, in
   July 1993, BIND 4.9.2 ALPHA, Anant Kumar of ISI supplied code that
   implemented, validation and negative caching (NCACHE).  This code had
   a 10 minute TTL for negative caching and only cached the indication
   that there was a negative response, NXDOMAIN or NOERROR_NODATA. This
   is the origin of the NODATA pseudo response code mentioned above.
   ネガティブキャッシュをBINDに入れる最初の試みではないが、1993
   年7月にBIND4.9.2アルファで、ISIのAnant Kumarは検証とネガ
   ティブキャッシュ(NCACHE)を実装したコードを供給しました。このコードは
   ネガティブキャッシュのために10分のTTLを持ち、否定的な回答、
   NXDOMAINかNOERROR_NODATAがあったという表示をキャッシュしただけでした。
   これは上記NODATA疑似応答コードの起源です。

   Mark Andrews of CSIRO added code (RETURNSOA) that stored the SOA
   record such that it could be retrieved by a similar query.  UUnet
   complained that they were getting old answers after loading a new
   zone, and the option was turned off, BIND 4.9.3-alpha5, April 1994.
   In reality this indicated that the named needed to purge the space
   the zone would occupy.  Functionality to do this was added in BIND
   4.9.3 BETA11 patch2, December 1994.
   CSIROのMark Andrewsは、類似の問合せで検索できるように、SOAレコード
   を蓄積するコード(RETURNSOA)を加えました。UUnetは新しいゾーンを読込
   んだ後で古い答えを受信すると不平を言い、このオプションは1994年4
   月のBIND 4.9.3-alpha5で止められました。実際はこれはnamedがゾーン空間
   を浄化する必要があっることを示しました。1994年12月のBIND 4.9.3
   BETA11 patch2で、この機能を加えました。

   RETURNSOA was re-enabled by default, BIND 4.9.5-T1A, August 1996.
   RETURNSOAは1996年8月のBIND 4.9.5-T1Aで再びデフォルトになりました。

10 Example
10 例

   The following example is based on a signed zone that is empty apart
   from the nameservers.  We will query for WWW.XX.EXAMPLE showing
   initial response and again 10 minutes later.  Note 1: during the
   intervening 10 minutes the NS records for XX.EXAMPLE have expired.
   Note 2: the TTL of the SIG records are not explicitly set in the zone
   file and are hence the TTL of the RRset they are the signature for.
   次の例はネームサーバを別にして署名されたゾーンに基づいています。我々
   は10分後に最初の応答を示したWWW.XX.EXAMPLEに、再び質問するでしょう。
   メモ1:10分間でXX.EXAMPLEのNSレコードは期限が切れました。
   メモ2:署名レコードのTTLはゾーンファイルで明示的に設定してなく、
   それ故資源レコード集合のTTLです。

        Zone File:
        ゾーンファイル

        $TTL 86400
        $ORIGIN XX.EXAMPLE.
        @       IN      SOA     NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. (
                                1997102000      ; serial
                                1800    ; refresh (30 mins)
                                900     ; retry (15 mins)
                                604800  ; expire (7 days)
                                1200 ) ; minimum (20 mins)
                IN      SIG     SOA ...
          1200  IN      NXT     NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY
                IN      SIG     NXT ... XX.EXAMPLE. ...
           300  IN      NS      NS1.XX.EXAMPLE.
           300  IN      NS      NS2.XX.EXAMPLE.
                IN      SIG     NS ... XX.EXAMPLE. ...
                IN      KEY     0x4100 1 1 ...
                IN      SIG     KEY ... XX.EXAMPLE. ...
                IN      SIG     KEY ... EXAMPLE. ...
        NS1     IN      A       10.0.0.1
                IN      SIG     A ... XX.EXAMPLE. ...
          1200  IN      NXT     NS2.XX.EXAMPLE. A NXT SIG
                IN      SIG     NXT ...
        NS2     IN      A       10.0.0.2

                IN      SIG     A ... XX.EXAMPLE. ...
          1200  IN      NXT     XX.EXAMPLE. A NXT SIG
                IN      SIG     NXT ... XX.EXAMPLE. ...

        Initial Response:
        最初の応答:

        Header:
            RDCODE=NXDOMAIN, AA=1, QR=1, TC=0
        Query:
            WWW.XX.EXAMPLE. IN A
        Answer:
            <empty>
        Authority:
            XX.EXAMPLE.      1200 IN SOA NS1.XX.EXAMPLE. ...
            XX.EXAMPLE.      1200 IN SIG SOA ... XX.EXAMPLE. ...
            NS2.XX.EXAMPLE.  1200 IN NXT XX.EXAMPLE. NXT A NXT SIG
            NS2.XX.EXAMPLE.  1200 IN SIG NXT ... XX.EXAMPLE. ...
            XX.EXAMPLE.     86400 IN NS  NS1.XX.EXAMPLE.
            XX.EXAMPLE.     86400 IN NS  NS2.XX.EXAMPLE.
            XX.EXAMPLE.     86400 IN SIG NS ... XX.EXAMPLE. ...
        Additional
            XX.EXAMPLE.     86400 IN KEY 0x4100 1 1 ...
            XX.EXAMPLE.     86400 IN SIG KEY ... EXAMPLE. ...
            NS1.XX.EXAMPLE. 86400 IN A   10.0.0.1
            NS1.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
            NS2.XX.EXAMPLE. 86400 IN A   10.0.0.2
            NS3.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...

         After 10 Minutes:
         10分後の応答:

         Header:
             RDCODE=NXDOMAIN, AA=0, QR=1, TC=0
         Query:
             WWW.XX.EXAMPLE. IN A
         Answer:
             <empty>
         Authority:
             XX.EXAMPLE.       600 IN SOA NS1.XX.EXAMPLE. ...
             XX.EXAMPLE.       600 IN SIG SOA ... XX.EXAMPLE. ...
             NS2.XX.EXAMPLE.   600 IN NXT XX.EXAMPLE. NXT A NXT SIG
             NS2.XX.EXAMPLE.   600 IN SIG NXT ... XX.EXAMPLE. ...
             EXAMPLE.        65799 IN NS  NS1.YY.EXAMPLE.
             EXAMPLE.        65799 IN NS  NS2.YY.EXAMPLE.
             EXAMPLE.        65799 IN SIG NS ... XX.EXAMPLE. ...
         Additional
             XX.EXAMPLE.     65800 IN KEY 0x4100 1 1 ...
             XX.EXAMPLE.     65800 IN SIG KEY ... EXAMPLE. ...
             NS1.YY.EXAMPLE. 65799 IN A   10.100.0.1
             NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
             NS2.YY.EXAMPLE. 65799 IN A   10.100.0.2
             NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
             EXAMPLE.        65799 IN KEY 0x4100 1 1 ...
             EXAMPLE.        65799 IN SIG KEY ... . ...


11 Security Considerations
11 セキュリティの考察

   It is believed that this document does not introduce any significant
   additional security threats other that those that already exist when
   using data from the DNS.
   この文書が、DNSを使うことにより既に存在している脅威を除き、重要な追加
   のセキュリティ脅威をもたらさないと信じられます。

   With negative caching it might be possible to propagate a denial of
   service attack by spreading a NXDOMAIN message with a very high TTL.
   Without negative caching that would be much harder.  A similar effect
   could be achieved previously by spreading a bad A record, so that the
   server could not be reached - which is almost the same.  It has the
   same effect as far as what the end user is able to do, but with a
   different psychological effect.  With the bad A, I feel "damn the
   network is broken again" and try again tomorrow.  With the "NXDOMAIN"
   I feel "Oh, they've turned off the server and it doesn't exist any
   more" and probably never bother trying this server again.
   ネガティブキャッシュで非常に大きいTTLでNXDOMAINメッセージを広める
   ことでサービス攻撃の拒否を伝えることは可能であるかもしれません。ネガ
   ティブキャッシュ無しでそれはずっともっと難しいでしょう。類似の効果が
   以前に悪いAレコードを広めることで成し遂げできました、それでサーバー
   は連絡できませんでした−これはほとんど同じです。それはエンドユーザが
   できない意味では同じだが、異なる心理的効果を持っています。悪いAレコー
   ドは、「ネットワークが壊れている」と感じ、そして明日再び試みます。
   「NXDOMAIN」では、「サーバーが消えて、存在しない」と感じ、恐らく決し
   て再びこのサーバーを試みようと努めません。

   A practical example of this is a SMTP server where this behaviour is
   encoded.  With a NXDOMAIN attack the mail message would bounce
   immediately, where as with a bad A attack the mail would be queued
   and could potentially get through after the attack was suspended.
   これの実際的な例はこの動作がコード化されるSMTPサーバーです。NXDOMAIN
   攻撃でメールメッセージはすぐに返送されるであろうが、悪いA攻撃はメー
   ルは待ち行列に入れられ、攻撃がとまった後に完了する可能性があります。

   For such an attack to be successful, the NXDOMAIN indiction must be
   injected into a parent server (or a busy caching resolver).  One way
   this might be done by the use of a CNAME which results in the parent
   server querying an attackers server.  Resolvers that wish to prevent
   such attacks can query again the final QNAME ignoring any NS data in
   the query responses it has received for this query.
   このような攻撃が成功しているために、 NXDOMAIN表示はは親サーバー(ある
   いは忙しいキャッシュリゾルバ)に導入されなくてはなりません。1つの方
   法でこれは親サーバーが攻撃者サーバーに問い合わせるという結果になる
   CNAMEの使用によってされるかもしれません。このような攻撃を妨げることを
   望むリゾルバが、問合せの回答で受取ったNSデータを無視して最終のQNAME
   を質問することができます。

   Implementing TTL sanity checking will reduce the effectiveness of
   such an attack, because a successful attack would require re-
   injection of the bogus data at more frequent intervals.
   TTL安全性調査の実装はこのような攻撃の有効性を減らすでしょう、なぜ
   なら攻撃の成功はより頻繁な間隔でのにせのデータの再注射を必要とするか
   らです。

   DNS Security [RFC2065] provides a mechanism to verify whether a
   negative response is valid or not, through the use of NXT and SIG
   records.  This document supports the use of that mechanism by
   promoting the transmission of the relevant security records even in a
   non security aware server.
   DNSセキュリティ[RFC2065]が、NXTと署名レコードの使用を通して、
   否定的な回答が正当であるかどうか確かめるメカニズムを供給します。この
   文書はセキュリティの認識のないサーバでさえ適切なセキュリティレコード
   の送信を促進することでそのメカニズムの使用をサポートします。

Acknowledgments
謝辞

   I would like to thank Rob Austein for his history of the CHIVES
   nameserver. The DNSIND working group, in particular Robert Elz for
   his valuable technical and editorial contributions to this document.
   私はCHIVESネームサーバの歴史に対してRob Austeinに感謝したいです。
   DNSINDワークグループの、特にRobert Elzにこの文書の専門的な編集の貢献
   のために。

References
参考文献

   [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.

   [RFC2065]
           Eastlake, D., and C. Kaufman, "Domain Name System Security
           Extensions," RFC 2065, January 1997.

   [RFC2119]
           Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels," BCP 14, RFC 2119, March 1997.

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

Author's Address
著者のアドレス

   Mark Andrews
   CSIRO - Mathematical and Information Sciences
   Locked Bag 17
   North Ryde NSW 2113
   AUSTRALIA

   Phone: +61 2 9325 3148
   EMail: Mark.Andrews@cmis.csiro.au


Full Copyright Statement
著作権表示全文

   Copyright (C) The Internet Society (1998).  All Rights Reserved.
   著作権(C)インターネット学会(1998)。すべての権利は保留される。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.
   上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
   この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
   を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
   版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
   ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
   や他のインターネット組織は著作権表示や参照を削除されるような変更がで
   きません、インターネット標準を開発する場合はインターネット標準化プロ
   セスで定義された著作権の手順に従われます。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.
   上に与えられた限定された許可は永久で、インターネット学会やその後継者
   や譲渡者によって無効にされません。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   この文書とここに含む情報は無保証で供給され、そしてインターネット学会
   とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
   報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、すべての保証を拒否します。

Japanese translation by Ishida So