[要約] RFC 2308は、DNSクエリのネガティブキャッシュに関する仕様であり、DNSサーバーが無効なクエリ結果を一定期間キャッシュすることを定義しています。目的は、無効なクエリの処理を効率化し、ネットワークトラフィックの削減と応答時間の改善を図ることです。
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.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
ネガティブキャッシングはDNS仕様のオプションの部分であり、RRset [RFC2181]またはドメイン名の非存在のキャッシングを扱います。
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トラフィックの大部分を排除できます。これを念頭に置くと、ネガティブキャッシングは、DNSリゾルバーのオプションの部分として見なされなくなります。
1 - Terminology
1-用語
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またはCNAMEチェーンに解決される場所、最後のCNAMEのデータフィールド。この意味での最後のCNAMEは、別のCNAMEに解決されない値を含むものです。実装では、CNAMEレコードを順番に応答に含めることで、最初のクエリにクエリセクションのラベルが含まれ、次にそれぞれに前のデータセクションのラベルが含まれる（複数のCNAMEが必要）ため、シーケンスは1つのパスで処理され、レシーバーのタスクを大幅に軽減します。その他の関連レコード（SIG RR [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セクション4.1.1]で説明されている「名前エラー」RCODEの代替表現と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"-指定されたクラスに対して名前は有効であるが、指定されたタイプのレコードではないことを示す疑似RCODE。回答から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」-権威あるネームサーバーチェーンを直接使用する代わりに、クエリの解決に使用されるネームサーバー。フォワーダーは通常、インターネットへのアクセスが向上するか、多くのリゾルバー間で共有される可能性のある大きなキャッシュを維持します。サーバーがFORWARDERとして識別される方法、またはサーバーが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).
最も一般的な否定応答は、特定のRRsetがDNSに存在しないことを示しています。このドキュメントの最初のセクションでは、このケースを扱います。他の否定応答はネームサーバーの失敗を示している可能性があり、それらはセクション7（その他の否定応答）で処理されます。
A negative response is indicated by one of the following conditions:
否定的な応答は、次の条件のいずれかによって示されます。
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）は、RCODEフィールドに「名前エラー」が存在することで示されます。この場合、QNAMEによって参照されるドメインは存在しません。注：回答セクションにはSIGとCNAME RRがあり、権限セクションにはSOA、NXT [RFC2065]、SIG RRセットがある場合があります。
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レコードが存在するかどうかに関係なく、R CODEに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
ヘッダー：RDCODE = NXDOMAINクエリ：AN.EXAMPLE。あ
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>
ヘッダー：RDCODE = NXDOMAINクエリ：AN.EXAMPLE。回答：AN.EXAMPLE。 CNAME TRIPPLE.XX。権限：<空>追加：<空>
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
ヘッダー：RDCODE = NXDOMAINクエリ：AN.EXAMPLE。回答：AN.EXAMPLE。 CNAME TRIPPLE.XX。機関：XX。 NSNS1.XX。 XX。 NSNS2.XX。追加：NS1.XX。 127.0.0.2NS2.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
ヘッダー：RDCODE = NOERRORクエリ：AN.EXAMPLE。回答：AN.EXAMPLE。 CNAME TRIPPLE.XX。機関：XX。 NSNS1.XX。 XX。 NSNS2.XX。追加：NS1.XX。 127.0.0.2NS2.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 RRを持っていることが示されていますが、「TRIPPLE.XX」の存在について、他に何も知られていません。それよりも「NS1.XX」または「NS2.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応答は、質問セクションのRRのラベルの名前を参照します。
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応答を正しく検出および処理できません。一部のリゾルバーは、TYPE 1 NXDOMAIN応答を参照として扱います。この問題を軽減するには、NXDOMAIN応答に対して権限のあるサーバーがTYPE 2 NXDOMAIN応答のみを送信することをお勧めします。つまり、権限セクションにはSOAレコードが含まれ、NSレコードは含まれません。権限のないサーバーがタイプ1のNXDOMAIN応答をこれらの古いリゾルバーの1つに送信した場合、結果は権限のあるサーバーへの不要なクエリになります。これは望ましくありませんが、サーバーがFORWARDERを使用している場合を除いて致命的ではありません。ただし、リゾルバーがサーバーをそのようなリゾルバーのFORWARDERとして使用している場合は、TYPE 1 NXDOMAIN応答の送信を無効にする必要があります。代わりにTYPE 2 NXDOMAINを使用してください。
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を返します。これは、ネームサーバーがそのようなリゾルバーのFORWARDERとしてリストされている場合の問題です。ネームサーバーがそのようなリゾルバーによってFORWARDERとして使用されている場合、これらのリゾルバーへのNXDOMAIN応答に対して権限フラグを強制する必要があります。実際には、これが常にオンになっていても問題は発生せず、4.9.3以降のBINDのデフォルトの動作となっています。
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は、RCODEがNOERRORに設定された回答で示され、回答セクションに関連する回答はありません。権限セクションには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を示すRCODE値がないため、NODATA応答は応答の内容からアルゴリズムで決定する必要があります。場合によっては、NODATAが正しい応答であることを確実に判断するために、別のクエリを送信する必要があります。
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 RRsetが含まれる場合があります。 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.
NODATA応答：タイプ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
ヘッダー：RDCODE = NOERRORクエリ：ANOTHER.EXAMPLE。回答：<空>権限：例。 NSNS1.XX。例。 NSNS2.XX。追加：NS1.XX。 127.0.0.2NS2.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レコードはありませんが、NXDOMAINの例と同じように、NDATAが存在する最後のCNAME（QNAME）の値になります。結論。
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応答を正しく検出および処理できないリゾルバーが多数存在しています。一部のリゾルバーは、TYPE 1 NODATA応答を参照として扱います。この問題を緩和するには、NODATA応答に対して権限を持つサーバーがTYPE 2 NODATA応答のみを送信することをお勧めします。つまり、権限セクションにはSOAレコードが含まれ、NSレコードは含まれません。権限のないサーバーからこれらのリゾルバーの1つにTYPE 1 NODATA応答を送信すると、不要なクエリが発生するだけです。サーバーが別のリゾルバーのFORWARDERとしてリストされている場合、権限のないNODATA応答に対するTYPE 1 NODATA応答の送信を無効にする必要がある場合もあります。
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が存在する場合、RCODEを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を報告するとき、または要求されたタイプのデータが存在しないことを示すときに、応答の権限セクションにゾーンのSOAレコードを含める必要があります。これは、応答をキャッシュできるようにするために必要です。このレコードのTTLは、SOAレコードのMINIMUMフィールドとSOA自体のTTLの最小値から設定され、リゾルバーが否定応答をキャッシュできる期間を示します。 SOAレコードに関連付けられたTTL SIGレコードも、SOAのTTLに合わせてトリミングする必要があります。
If the containing zone is signed [RFC2065] the SOA and appropriate NXT and SIG records MUST be added.
包含ゾーンが署名されている場合[RFC2065] SOAおよび適切なNXTおよびSIGレコードを追加する必要があります。
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.
SOA最小フィールドは、3つの異なる意味、ゾーン内のすべてのRRの最小TTL値、TTL値を含まないRRのデフォルト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.
最初に定義された意味にもかかわらず、これらの最初の、ゾーン内のすべてのRRの最小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が含まれていないRRのデフォルトのTTLであり、プライマリサーバーでのみ関連します。ゾーン転送後、すべてのRRには明示的なTTLがあり、レコードのTTLが明示的に設定されたか、ゾーン転送後にデフォルトから派生したかを判断することは不可能です。サーバーがRRにTTL値を明示的に含める必要がない場合、サーバーは、欠落したTTL値を取得するSOAレコードのMINIMUMフィールドの値ではないメカニズムを提供する必要があります。これがどのように行われるかは実装に依存します。
The Master File format [RFC 1035 Section 5] is extended to include the following directive:
マスターファイル形式[RFC 1035セクション5]が拡張され、次のディレクティブが含まれます。
$TTL <TTL> [comment]
$ TTL <TTL> [コメント]
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がないSIGレコードは、SIGレコードの「元のTTL」からTTLを取得します[RFC 2065セクション4.5]。
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フィールドとSOAのTTLの最小値から取得されます。このTTLは、通常のキャッシュされた回答と同様の方法で減少し、ゼロ（0）に達すると、キャッシュされた否定的な回答を再度使用してはならないことを示します。
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レコードは、否定応答の受信された機関セクションに存在する場合、機関セクション内のSIGレコードと同様に、機関セクション内のSOAレコードとともに検索および返却できるように格納する必要があります。 NXDOMAINの回答では、NXTレコードとQNAMEの間に「必要な」明白な関係はありません。 NXTレコードは、NODATA応答のクエリ名と同じ所有者名を持つ必要があります。
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が短い場合でも、サーバーのペア間で否定応答が永久にループするのを防ぐ方法がないため、キャッシュしないでください。
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がサーバーのツリーを形成しているにもかかわらず、さまざまな設定ミスがあると、クエリグラフにループが形成される可能性があります。フォワーダーとして互いにリストしている2つのサーバー、さまざまなlameサーバー構成。 TTLカウントダウンがないと、次のサーバーが受信したときにキャッシュ否定応答が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レコードを追加して、TTLがキャッシュに保存された時間だけ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レコードとともにキャッシュされた場合は、権限セクションに追加する必要があります。 SIGレコードが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を示す方法はありません。転送ループが発生しないように注意する必要があります。
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）、特定のクエリタプル<クエリ名、タイプ、クラス、サーバーIPアドレス>に対してキャッシュする必要があります。
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.
Dead / Unreachableサーバーは、なんらかの方法でクエリへの応答に失敗したサーバー、またはトランスポート層がサーバーが存在しないか到達不能であるという指示を提供したサーバーです。 120秒以内に未解決のクエリに応答しなかった場合、サーバーは停止しているか到達不能であると見なされます。
Examples of transport layer indications are:
トランスポート層の表示の例は次のとおりです。
ICMP error messages indicating host, net or port unreachable. TCP resets IP stack error messages providing similar indications to those above.
ホスト、ネット、またはポートに到達できないことを示すICMPエラーメッセージ。 TCPは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分以上死んでいると見なしてはなりません。サーバーが存在しないことを示すトランスポート層の表示がなかった場合を除き、その指示はクエリタプル<クエリ名、タイプ、クラス、サーバーIPアドレス>に対して保存する必要があります。この場合、その特定のIPアドレスに対するすべてのクエリに適用されます。
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.
権限のない否定的な回答はキャッシュされる場合があります。
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レコードはキャッシュする必要があります。名前エラー表示は、タプル<query name、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は、ターゲットRRが含まれるゾーンのSOA MINIMUM値を使用して、信頼できるエラーを単にキャッシュすることを提案しました。この会話はRFC-973が書かれる前に行われたと確信していますが、この考えがポールが私の質問に応じてその場で思いついたものなのか、それとも彼がすでに計画していたものなのかははっきりしませんRFC-973になったドキュメントに入れます。いずれの場合も、SOA MINIMUM値が実際に使用するのに適切なメトリックであることを私たちは完全に確信していませんでしたが、使用可能であり、ターゲットゾーンの管理者の制御下にありました。重要な機能である。
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リゾルバーを置き換えるために作成したDNSリゾルバーであるCHIVESの最初のベータテストバージョンをリリースしました。 CHIVESには、いくつかのサイト（私のサイトを含む）でかなり頻繁に使用された検索パスメカニズムが含まれていたため、SOA MINIMUM値に基づいたネガティブキャッシュメカニズムも含まれていました。基本的な戦略は、SOA MINIMUM値に等しいキャッシュTTLを使用して、正確なクエリパラメーター（QNAME、QCLASS、およびQTYPE）をキーとする信頼できるエラーコードをキャッシュすることでした。 CHIVESは、信頼できる応答でSOA RRが提供されていない場合、SOA RRの追跡を試みなかったため、不必要な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の経験から、RRは途方もなく長いTTLでしばしば現れることが示され（99999999は、BINDのいくつかの初期バージョンのコードとドキュメントのバグのため、長年特に人気がありました）、そのようなTTLを盲目的に信じていた堅牢なソフトウェアが非常に多くの奇妙なエラーが発生するため、キャッシュからこのガベージをクリアするためにリゾルバを頻繁に再起動する必要がしばしばあります。したがって、CHIVESには構成パラメータ「MAXTTL」があり、受信したRRの最大の「妥当な」TTLを指定していました。 MAXTTLより大きいTTLを持つRRは、別の構成パラメーターの設定に応じて、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値は、通常、RRの巨大な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.
WSMR-SIMTEL20.ARMY.MIL（シャットダウンされる主要なインターネットTOPS-20マシンの最後、つまりCHIVESの最後の主要なユーザー、つまり最も長い実験ベースラインがあった場所）で最適に機能すると思われた構成は、 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つはローカルの信頼できるゾーンデータのみを検索し、もう1つは通常の反復クエリを生成できました。これにより、使用量が予想どおりに多い場合（たとえば、XX.LCS.MIT.EDUのリゾルバーは常にLCS.MIT.EDUとAI.MIT.EDUの両方のゾーンファイルをロードし、両方を配置する場合）のネガティブキャッシュの必要性を削減しました。これらのサフィックスを「ローカル」検索パスに追加します。これらの間では、これらの2つのゾーンのホストがDNSトラフィックの大部分を占めていたためです）。 CHIVESを実行しているすべてのサイトがこの機能の使用を選択したわけではありません。たとえば、C.CS.CMU.EDUは、すべてに「リモート」検索パスを使用することを選択しました。これは、CMUに異なるゾーンが多すぎて、ゾーンシャドウイングが実用的ではないため、ネガティブキャッシュにかなり依存していたためです。ローカルトラフィックでも。
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.
全体的に、ネガティブキャッシングに使用した基本設計はかなり合理的であると私はまだ思います。ゾーン管理者はネガティブな回答をキャッシュする期間を指定し、リゾルバー構成は実際のキャッシュ時間をゼロとゾーン管理者が指定した期間の範囲から選択しました。私が今は別の方法で行う詳細はたくさんあります（MINIMUMフィールドをオーバーロードする代わりに新しいSOAフィールドを使用するなど）が、10年以上経ってから、少なくともいくつかの改善。
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月、BIND 4.9.2 ALPHA、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は、新しいゾーンを読み込んだ後、古い回答を得ていると不満を述べ、オプションはオフになりました（BIND 4.9.3-alpha5、1994年4月）。実際、これは、namedがゾーンが占有するスペースをパージする必要があることを示しています。これを行う機能は、1994年12月のBIND 4.9.3 BETA11 patch2で追加されました。
RETURNSOA was re-enabled by default, BIND 4.9.5-T1A, August 1996.
RETURNSOAはデフォルトで再度有効になりました（BIND 4.9.5-T1A、1996年8月）。
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.
次の例は、ネームサーバー以外は空の署名済みゾーンに基づいています。最初の応答を示すWWW.XX.EXAMPLEをクエリし、10分後に再度クエリします。注1：間にある10分間に、XX.EXAMPLEのNSレコードの有効期限が切れています。注2：SIGレコードのTTLはゾーンファイルで明示的に設定されていないため、それらが署名であるRRsetの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. ...
ヘッダー：RDCODE = NXDOMAIN、AA = 1、QR = 1、TC = 0クエリ：WWW.XX.EXAMPLE。回答：<空>権限：XX.EXAMPLE。 1200 IN SOA NS1.XX.EXAMPLE。 ... XX.EXAMPLE。 1200 IN SIG SOA ... XX。例...
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. ...
NS2.XX.EXAMPLE。 1200 IN NXT XX.EXAMPLE。 NXT A NXT SIG NS2.XX.EXAMPLE。 1200 IN SIG NXT ... XX.EXAMPLE。 ... XX.EXAMPLE。 NS NS1.XX.EXAMPLEの86400。 XX.EXAMPLE。 86400 IN NS NS2.XX.EXAMPLE。 XX.EXAMPLE。 86400 IN SIG NS ... XX.EXAMPLE。 ...追加のXX.EXAMPLE。 86400 IN KEY 0x4100 1 1 ... XX.EXAMPLE。 86400 IN SIG KEY ...例。 ... 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 ... . ...
ヘッダー：RDCODE = NXDOMAIN、AA = 0、QR = 1、TC = 0クエリ：WWW.XX.EXAMPLE。回答：<空>権限：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。 ...例。 NS NS1.YY.EXAMPLEの65799。例。 NS NS2.YY.EXAMPLEの65799。例。 65799 IN SIG NS ... XX.EXAMPLE。 ...追加のXX.EXAMPLE。 65800 IN KEY 0x4100 1 1 ... XX.EXAMPLE。 65800 IN SIG KEY ...例。 ... NS1.YY.EXAMPLE。 65799 IN A 10.100.0.1 NS1.YY.EXAMPLE。 65799 IN SIG A ...例。 ... NS2.YY.EXAMPLE。 65799 IN A 10.100.0.2 NS3.YY.EXAMPLE。 65799 IN SIG A ...例。 ...例。 65799 IN KEY 0x4100 1 1 ...例。 65799 IN SIGキー...。 ...
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インディケーションを親サーバー（またはビジーキャッシングリゾルバー）に挿入する必要があります。これは、CNAMEを使用してこれを行う方法の1つで、親サーバーが攻撃者のサーバーにクエリを送信することになります。このような攻撃を防止したいリゾルバは、このクエリに対して受け取ったクエリ応答内の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およびSIGレコードを使用して、否定応答が有効かどうかを検証するメカニズムを提供します。このドキュメントでは、セキュリティに対応していないサーバーでも、関連するセキュリティレコードの送信を促進することにより、そのメカニズムの使用をサポートしています。
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.
[RFC1034] Mockapetris、P。、「DOMAIN NAMES-CONCEPTS AND FACILITIES」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION," STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「DOMAIN NAMES-IMPLEMENTATION AND SPECIFICATION」、STD 13、RFC 1035、1987年11月。
[RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Security Extensions," RFC 2065, January 1997.
[RFC2065] Eastlake、D。、およびC. Kaufman、「ドメインネームシステムセキュリティ拡張機能」、RFC 2065、1997年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2181] Elz, R., and R. Bush, "Clarifications to the DNS Specification," RFC 2181, July 1997.
[RFC2181] Elz、R。、およびR. Bush、「Clarifications to the DNS Specification」、RFC 2181、1997年7月。
Author's Address
著者のアドレス
Mark Andrews CSIRO - Mathematical and Information Sciences Locked Bag 17 North Ryde NSW 2113 AUSTRALIA
マークアンドリュースCSIRO-数学と情報科学のロックされたバッグ17ノースライドNSW 2113オーストラリア
Phone: +61 2 9325 3148
EMail: Mark.Andrews@cmis.csiro.au
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。