RFC2308 日本語訳
2308 Negative Caching of DNS Queries (DNS NCACHE). M. Andrews. March 1998. (Format: TXT=41428 bytes) (Updates RFC1034, RFC1035) (Updated by RFC4035, RFC4033, RFC4034) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Andrews Request for Comments: 2308 CSIRO Updates: 1034, 1035 March 1998 Category: Standards Track
コメントを求めるワーキンググループM.アンドリュース要求をネットワークでつないでください: 2308のCSIROアップデート: 1034、1035年1998年3月のカテゴリ: 標準化過程
Negative Caching of DNS Queries (DNS NCACHE)
DNS質問の否定的キャッシュ(DNS NCACHE)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(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.
否定的キャッシュは、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レゾルバの任意の部分と考えるべきではありません。
Andrews Standards Track [Page 1] RFC 2308 DNS NCACHE March 1998
アンドリュースStandardsは1998年のDNS NCACHE行進のときにRFC2308を追跡します[1ページ]。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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記録を含んでいて、実現はそれに注意するべきです、1番目が質問部からラベルを持っていて、次に、前のセクション(1CNAMEが必要であるところ)が1個のパスで処理されるのを系列を許容するデータからラベルをそれぞれ連続して持って、受信機に関するタスクをかなり緩和するように。他の関連記録(SIG RRs[RFC2065]などの)はCNAMEsの中に点在できます。
"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]の理解は予想されます。
Andrews Standards Track [Page 2] RFC 2308 DNS NCACHE March 1998
アンドリュースStandardsは1998年のDNS NCACHE行進のときにRFC2308を追跡します[2ページ]。
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(他のNegative Responses)で対処されています。
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)はRCODE分野での「名前誤り」の存在によって示されます。 この場合、QNAMEによって言及されたドメインは存在しません。 以下に注意してください。 答え部にはSIGとCNAME RRsがあるかもしれません、そして、権威部には、SOA、NXT[RFC2065]、およびSIG RRsetsがあるかもしれません。
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記録の存在にかかわらずRCODEで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
ヘッダー: RDCODE=NXDOMAINは以下について質問します。 AN.EXAMPLE。 答え: AN.EXAMPLE。 CNAME TRIPPLE.XX。 権威: XX。 SOA NS1.XX。 HOSTMASTER.NS1.XX。 .... XX。 ナノ秒NS1.XX。 XX。 ナノ秒NS2.XX。 追加する: NS1.XX。 127.0 .0 .2 NS2.XX。 A127.0.0、.3
NXDOMAIN RESPONSE: TYPE 2.
NXDOMAIN応答: 2をタイプしてください。
Header:
RDCODE=NXDOMAIN
Query:
AN.EXAMPLE. A
ヘッダー: RDCODE=NXDOMAINは以下について質問します。 AN.EXAMPLE。 A
Andrews Standards Track [Page 3] RFC 2308 DNS NCACHE March 1998
アンドリュースStandardsは1998年のDNS NCACHE行進のときにRFC2308を追跡します[3ページ]。
Answer:
AN.EXAMPLE. CNAME TRIPPLE.XX.
Authority:
XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
Additional:
<empty>
以下に答えてください。 AN.EXAMPLE。 CNAME TRIPPLE.XX。 権威: XX。 SOA NS1.XX。 HOSTMASTER.NS1.XX。 .... 追加する: <の空の>。
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。 ナノ秒NS1.XX。 XX。 ナノ秒NS2.XX。 追加する: NS1.XX。 127.0 .0 .2 NS2.XX。 A127.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
ヘッダー: RDCODE=NOERRORは以下について質問します。 AN.EXAMPLE。 答え: AN.EXAMPLE。 CNAME TRIPPLE.XX。 権威: XX。 ナノ秒NS1.XX。 XX。 ナノ秒NS2.XX。 追加する: NS1.XX。 A127.0.0、.2
Andrews Standards Track [Page 4] RFC 2308 DNS NCACHE March 1998
アンドリュースStandardsは1998年のDNS NCACHE行進のときにRFC2308を追跡します[4ページ]。
NS2.XX. A 127.0.0.3
NS2.XX。 A127.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のラベルの名前を呼びます。
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応答を検出して、処理しない現在現存する多くのレゾルバがあります。 TYPE1NXDOMAIN応答を紹介として扱うレゾルバもあります。 この問題を軽減するために、NXDOMAIN応答に、正式のサーバがNXDOMAIN応答をTYPE2に送るだけであるのが、お勧めである、すなわち、SOA記録を含んでいますが、権威部はどんなNS記録も含みません。 非正式のサーバがサーバが使用されているとき. これが望ましくないのですが、致命的でない正式のサーバへの不要な質問がFORWARDERであるつもりであったならこれらの年取ったレゾルバのひとり、結果への応答をタイプ1NXDOMAINに送るなら。 レゾルバがFORWARDERとしてどのようにそのようなレゾルバにサーバを使用してもそれへのTYPE1NXDOMAIN応答の発信を無能にするのが必要であるなら、代わりにTYPE2NXDOMAINを使用してください。
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応答にオンに押し込まれなければならないでしょう。 これが実際には、いつもつけられても問題を全く引き起こさないで、BINDのデフォルトのふるまいである、4.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は答え部でNOERRORに用意ができているRCODEにもかかわらず、どんな関連答えでも答えで示されません。 権威部がSOA記録を含むだろうか、またはNS記録が全くそこにないでしょう。
Andrews Standards Track [Page 5] RFC 2308 DNS NCACHE March 1998
アンドリュースStandardsは1998年のDNS NCACHE行進のときにRFC2308を追跡します[5ページ]。
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応答は応答のコンテンツから断固としたalgorithmicallyでなければなりません。 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 RRsetsを含むかもしれません。 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
ヘッダー: RDCODE=NOERRORは以下について質問します。 ANOTHER.EXAMPLE。 答え: <の空の>権威: 例。 SOA NS1.XX。 HOSTMASTER.NS1.XX。 .... 例。 ナノ秒NS1.XX。 例。 ナノ秒NS2.XX。 追加する: NS1.XX。 127.0 .0 .2 NS2.XX。 A127.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>
ヘッダー: RDCODE=NOERRORは以下について質問します。 ANOTHER.EXAMPLE。 答え: <の空の>権威: 例。 SOA NS1.XX。 HOSTMASTER.NS1.XX。 .... 追加する: <の空の>。
Andrews Standards Track [Page 6] RFC 2308 DNS NCACHE March 1998
アンドリュースStandardsは1998年のDNS NCACHE行進のときにRFC2308を追跡します[6ページ]。
NO DATA RESPONSE: TYPE 3.
データ応答がありません: 3をタイプしてください。
Header:
RDCODE=NOERROR
Query:
ANOTHER.EXAMPLE. A
Answer:
<empty>
Authority:
<empty>
Additional:
<empty>
ヘッダー: RDCODE=NOERRORは以下について質問します。 ANOTHER.EXAMPLE。 答え: <の空の>権威: <の空の>追加する: <の空の>。
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。 答え: <の空の>権威: 例。 ナノ秒NS1.XX。 例。 ナノ秒NS2.XX。 追加する: NS1.XX。 127.0 .0 .2 NS2.XX。 A127.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の例がしたちょうど同じように、その場合、それはNODATAが結論づけられる最後のCNAME(QNAME)の値でしょう。
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応答を検出して、処理しない現在現存する多くのレゾルバがあります。 TYPE1NODATA応答を紹介として扱うレゾルバもあります。 この問題を軽減するために、NODATA応答に、正式のサーバがNODATA応答をTYPE2に送るだけであるのが、お勧めである、すなわち、SOA記録を含んでいますが、権威部はどんなNS記録も含みません。 非正式のサーバからこれらのレゾルバのひとりまでのNODATA応答をTYPE1に送ると、不要な質問はもたらされるだけでしょう。 また、サーバが別のレゾルバのためのFORWARDERとして記載されるなら、非正式のNODATA応答のためのTYPE1NODATA応答の発信を無能にするのも必要であるかもしれません。
Andrews Standards Track [Page 7] RFC 2308 DNS NCACHE March 1998
アンドリュースStandardsは1998年のDNS NCACHE行進のときにRFC2308を追跡します[7ページ]。
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.
いくつかのネームサーバは答え部のCNAMEsの面前でNXDOMAINにRCODEを設定しません。 決定的な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つの異なった意味、ゾーンのすべてのRRsの最小のTTL値、TTL値を含まなかったRRsのデフォルト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.
オリジナルの定義された意味、これらの1番目ですが、ゾーンのすべてのRRsの最小の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も含まないRRsのデフォルトTTL)は単にプライマリサーバで関連しています。ゾーン転送の後に、すべてのRRsには明白なTTLsがあって、記録のためのTTLがゾーン転送の後に明らかに用意ができていたか、またはデフォルトから得られたかを決定するのは不可能です。 サーバが、RRsが明らかにTTL値を含んでいるのを必要としないところに、メカニズムを提供するべきです、なくなったTTL値が得られるSOA記録のMINIMUM分野の値でなく。 これがどう完了しているかは、実装に依存しています。
The Master File format [RFC 1035 Section 5] is extended to include the following directive:
Master File形式[RFC1035セクション5]は以下の指示を含むように広げられます:
$TTL <TTL> [comment]
$TTL<TTL>。[コメント]
Andrews Standards Track [Page 8] RFC 2308 DNS NCACHE March 1998
アンドリュースStandardsは1998年のDNS NCACHE行進のときにRFC2308を追跡します[8ページ]。
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記録[RFC2065セクション4.5]の「オリジナルのTTL」からそれらの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記録を含んでいることによって、これをします。 正式のサーバがこの記録を作成すると、SOA.MINIMUM分野とSOAのTTLの最小限から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は記録します、見つけられて、ともに帰られたそれがあることであるかもしれない保存されたそのようなものが権威部でのSOA記録であったに違いないなら受けられた否定的な返答の権威部に存在しているなら、権威部でのどんなSIG記録であるべきであるののようにも。 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のない否定応答はSHOULD NOTを記録します。否定応答がいつまでも1組のサーバの間で短い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
様々な誤構成でサーバの木を形成するDNSにもかかわらず、質問グラフ、例えば、互いについて混載業者に記載する2つのサーバで輪を形成するのは可能です、様々な不十分なサーバ構成。 キャッシュ否定応答の下側へのTTLカウントなしで
Andrews Standards Track [Page 9] RFC 2308 DNS NCACHE March 1998
アンドリュースStandardsは1998年のDNS NCACHE行進のときにRFC2308を追跡します[9ページ]。
when received by the next server would have its TTL reset. This negative indication could then live forever circulating between the servers involved.
次のサーバで受け取ると、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時間の値は、上手に仕事に見つけられて、賢明なaデフォルトを作るでしょう。 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.
サーバが質疑に答える際にキャッシュされた否定応答に遭遇すると、それは、TTLがそれがキャッシュで保存された時間までに減少している状態でキャッシュされたSOAが応答の権威部に記録すると言い足さなければなりません。 これは正しくタイムアウトへの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を示す方法が全くありません。 そこでそれを確実にするために取られるべき注意の必要性は輪を進めていません。
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番目はサーバが、それがゾーンにmisconfiguredされたことを決定できるところです。 それがどこでサーバとして記載されていますが、ゾーンへのサーバになるように構成されていないか、そして、またはそれがゾーンへのサーバになるようにどこで構成されたかということであるかもしれませんが、これは、ある理由でゾーンデータを得ることができません。 ゾーンが利用可能であるべきであった別のサーバがゾーンファイルが存在しなくしたがっていませんし、誤りを含みたがっていませんし、応じなくしたがっていませんでしたし、ゾーンを供給したがっていなかったので、これは起こることができます。
Andrews Standards Track [Page 10] RFC 2308 DNS NCACHE March 1998
アンドリュースStandardsは1998年のDNS NCACHE行進のときにRFC2308を追跡します[10ページ]。
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.
二等は、サーバがほかの場所から答えを得る必要があるところですが、ネットワーク失敗のためそう返答しない他のサーバをするか、サーバ失敗誤りを返すことができない、または同様です。
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>.
どちらの場合ではも、レゾルバはサーバ失敗応答をキャッシュするかもしれません。 そうするなら、数5(5)分より長い間、それをキャッシュしてはいけません、そして、特定の質問tuple<質問名に対してそれをキャッシュしなければなりません、タイプ、クラス、サーバIPアドレス>。
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.
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.
サーバは死んでいるサーバ指示をキャッシュするかもしれません。 そうするなら、数5(5)分より長い間死んでいるとそれを考えてはいけません。 質問tuple<質問名、タイプ、クラスに対して指示を保存しなければなりません、そこでないならサーバIPアドレス>がサーバが存在していないというトランスポート層指示であった、その場合、それはその特定のIPへの質問が扱うすべてに適用されます。
8 - Changes from RFC 1034
8 --RFC1034からの変化
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記録をキャッシュしなければなりません。 tuple<質問名、QCLASS>に対して名前誤り指摘をキャッシュしなければなりません。 <質問名、QTYPE、QCLASS>tupleに対してデータ指摘を全くキャッシュしてはいけません。
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とキャッシュされた否定応答に問題を起こす付加をキャッシュしたので、これは明らかに許容されませんでした。
Andrews Standards Track [Page 11] RFC 2308 DNS NCACHE March 1998
アンドリュースStandardsは1998年のDNS NCACHE行進のときにRFC2308を追跡します[11ページ]。
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)の歴史がロブ Austein <sra@epilogue.com によって提供された、gt;、ここ、彼がそれ[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年春頃に、私は、彼のJEEVES DNSレゾルバの私たちの経験がある種の否定的キャッシュ体系の必要性を指摘したとポールMockapetrisに言及しました。 ポールは、私たちが単に正式の誤りをキャッシュすることを提案しました、目標RRsを含んだゾーンに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年遅く、私はCHIVESの初期のベータテストバージョンをリリースしました、私がポールのJEEVESレゾルバを取り替えるために書いたDNSレゾルバ。CHIVESはいくつかのサイトでかなり大いに使用された検索経路メカニズムを含んでいました(私自身のを含んでいて)、したがって、また、CHIVESはSOA MINIMUM値に基づく否定的キャッシュメカニズムを含んでいました。 基本戦略は正確な質問パラメタ(QNAME、QCLASS、およびQTYPE)によって合わせられた正式のエラーコードをキャッシュすることでした、SOA MINIMUM値と等しいキャッシュTTLと共に。 彼らが正式の応答で供給されなかったなら、CHIVESは、SOA RRsを捜し出すのを試みませんでしたが、したがって、何とか完全に無料のDNSエラーメッセージトラフィックを決して排除したというわけではありませんが、それはかなり助かりました。 キャッシュがこれはアルパネットの近い崩壊とほぼ同じくらいの時に急激な増加と「古い」(プレVJ)TCP再送信アルゴリズムで引き起こされた混雑のため起こっていました、非常に否定的であるので私たちのユーザには、抜本的により良いDNS応答時間で結果として生じたのを覚えておいてください、メーラ・デーモン、種々のもの。
Andrews Standards Track [Page 12] RFC 2308 DNS NCACHE March 1998
アンドリュースStandardsは1998年のDNS NCACHE行進のときにRFC2308を追跡します[12ページ]。
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の経験はRRsがばかばかしく長いTTLsと共にしばしば現れて(99999999はバグのために何年間もBINDのいくつかの早めのバージョンのコードとドキュメンテーションで特にポピュラーでした)、盲目的にそのようなTTLsを信じていた強健なソフトウェアがとても多くの奇妙な失敗を作成するかもしれないのでただキャッシュからこのゴミをきれいにするために頻繁にレゾルバをリブートするのがしばしば必要であることを既に示しました。 それで、CHIVESには、"MAXTTL"という設定パラメータがありました。(それは、容認されたRRで最大の「妥当な」TTLを指定しました)。 TTLsがMAXTTLには彼らのTTLsがあるだろうよりすばらしいRRsは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値がRRsの巨大なTTLsとしての否定的キャッシュのための同じ種類の問題が正常なキャッシュのために持っていた原因にしばしば十分大きかったのは(一方、これは一部リブートのときに予備選挙に連絡できないならセカンダリサーバが厳然とゾーンに関するすべての知識を否定するBINDのいくつかの早めのバージョンのバグのためでした)明確になりました。 それで、私たちは、MAXTTLチェックでも否定的キャッシュTTLsを実行し始めて、実験し続けていました。
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の最後の大口使用者、私たちが持っていた中で実験基線最も長い場所になるように機械加工する主要なインターネットの最終)でうまくいくように思えた構成はおよそ3日間にMAXTTLを設定することでした。 メール待ち行列タイムアウトが1週間に設定されたので、晩年にSIMTEL20によって開始されたトラフィックの大部分はメール関連であり、これは完全な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
また、CHIVESは1秒、いくつかの場合、否定的キャッシュの代理をしたいくらか論議を呼んだメカニズムを含んでいました。 DNS基本ファイルをロードするためにCHIVESレゾルバデーモンを構成できました、どんな今日が「こっそり」と呼ばれるだろうかとして機能する能力をそれに与えて
Andrews Standards Track [Page 13] RFC 2308 DNS NCACHE March 1998
アンドリュースStandardsは1998年のDNS NCACHE行進のときにRFC2308を追跡します[13ページ]。
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つの別々の検索経路、および通常の繰り返しの質問を発生させることができたものが実際にありました。その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.
全体的に見て、私は、私たちが否定的キャッシュに使用した基本的なデザインがかなり妥当であったとまだ思っています: ゾーンの管理者は長く否定的な返答をキャッシュする方法を指定しました、そして、レゾルバ構成はゾーンの管理者によって指定されたゼロと期間の間の範囲からの実際のキャッシュ時間を選びました。 私が現在(MINIMUM野原を積みすぎることの代わりに新しいSOA分野を使用するように)異なってする多くの詳細がありますが、10年以上後に、私は私たちが少なくともいくつかの改良を考えることができないかどうかより心配でしょう。
9.2 BIND
9.2 ひも
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.
4.9.2アルファー、1993年7月のBINDをBINDにキャッシュしながら否定的になる最初の試みでない間、ISIのAnantクマーはそれが実行したコード、合法化、および否定的キャッシュを供給しました(NCACHE)。 このコードは、否定的キャッシュのためのTTLを10分持って、否定応答、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のマーク・アンドリュースは同様の質問でそれを検索できるだろうというようにSOA記録を格納したコード(RETURNSOA)を加えました。 UUnetは、新しいゾーンをロードした後に彼らが古い答えを得ていたと不平を言いました、そして、オプションはオフにされました、BIND 4.9.3-alpha5、1994年4月。 ほんとうは、これは、命名が、ゾーンが占めるスペースを掃除する必要だったのを示しました。 これをする機能性はBIND4.9.3BETA11 patch2、1994年12月に加えられました。
RETURNSOA was re-enabled by default, BIND 4.9.5-T1A, August 1996.
RETURNSOAはデフォルトで、BIND 4.9.5-T1A、1996年8月、再有効にされました。
Andrews Standards Track [Page 14] RFC 2308 DNS NCACHE March 1998
アンドリュースStandardsは1998年のDNS NCACHE行進のときにRFC2308を追跡します[14ページ]。
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. ...
TTL86400ドルの$起源XX.EXAMPLE。 @SOA NS1.XX.EXAMPLEで。 HOSTMATER.XX.EXAMPLE。 (1997102000; 連続の1800;は900をリフレッシュします(30mins); 再試行(15mins)604800; 1200年の(7日間)の間、期限が切れます) ; 最小(20mins)のIN SIG SOA… NXT NS1.XX.EXAMPLEの1200。 SIG NXTで主要なNXT SIG SOAナノ秒… XX.EXAMPLE。 ... 300 ナノ秒NS1.XX.EXAMPLEで。 300 ナノ秒NS2.XX.EXAMPLEで。 SIGナノ秒に… XX.EXAMPLE。 ... キー0x4100 1 1で… SIGキーで… XX.EXAMPLE。 ... SIGキーで… 例。 ... A10.0.0.1IN SIG A…におけるNS1 XX.EXAMPLE。 ... NXT NS2.XX.EXAMPLEの1200。 SIG NXTのNXT SIG… A10.0.0.2IN SIG A…におけるNS2 XX.EXAMPLE。 ... NXT XX.EXAMPLEの1200。 SIG NXTのNXT SIG… 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。 SOA NS1.XX.EXAMPLEの1200。 ... XX.EXAMPLE。 1200 SIG SOAで… XX.EXAMPLE。 ...
Andrews Standards Track [Page 15] RFC 2308 DNS NCACHE March 1998
アンドリュースStandardsは1998年のDNS NCACHE行進のときにRFC2308を追跡します[15ページ]。
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。 NXT XX.EXAMPLEの1200。 NXT A NXT SIG NS2.XX.EXAMPLE。 1200 SIG NXTで… XX.EXAMPLE。 ... XX.EXAMPLE。 86400 ナノ秒NS1.XX.EXAMPLEで。 XX.EXAMPLE。 86400 ナノ秒NS2.XX.EXAMPLEで。 XX.EXAMPLE。 86400 SIGナノ秒に… XX.EXAMPLE。 ... 追加XX.EXAMPLE。 86400 キー0x4100 1 1で… XX.EXAMPLE。 86400 SIGキーで… 例。 ... NS1.XX.EXAMPLE。 Aの86400、10.0 .0 .1 NS1.XX.EXAMPLE。 86400 SIG Aで… XX.EXAMPLE。 ... NS2.XX.EXAMPLE。 Aの86400、10.0 .0 .2 NS3.XX.EXAMPLE。 86400 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 SOA NS1.XX.EXAMPLEで。 ... XX.EXAMPLE。 600 SIG SOAで… XX.EXAMPLE。 ... NS2.XX.EXAMPLE。 600 NXT XX.EXAMPLEで。 NXT A NXT SIG NS2.XX.EXAMPLE。 600 SIG NXTで… XX.EXAMPLE。 ... 例。 65799 ナノ秒NS1.YY.EXAMPLEで。 例。 65799 ナノ秒NS2.YY.EXAMPLEで。 例。 65799 SIGナノ秒に… XX.EXAMPLE。 ... 追加XX.EXAMPLE。 65800 キー0x4100 1 1で… XX.EXAMPLE。 65800 SIGキーで… 例。 ... NS1.YY.EXAMPLE。 Aの65799、10.100 .0 .1 NS1.YY.EXAMPLE。 65799 SIG Aで… 例。 ... NS2.YY.EXAMPLE。 Aの65799、10.100 .0 .2 NS3.YY.EXAMPLE。 65799 SIG Aで… 例。 ... 例。 65799 キー0x4100 1 1で… 例。 65799 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からのデータを使用するとき既に存在するもの。
Andrews Standards Track [Page 16] RFC 2308 DNS NCACHE March 1998
アンドリュースStandardsは1998年のDNS NCACHE行進のときにRFC2308を追跡します[16ページ]。
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 Security[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ネームサーバの歴史のための感謝ロブAusteinがそうしたいです。このドキュメントへの彼の貴重な技術的で編集の貢献のための特定のロバートElzのDNSINDワーキンググループ。
Andrews Standards Track [Page 17] RFC 2308 DNS NCACHE March 1998
アンドリュースStandardsは1998年のDNS NCACHE行進のときにRFC2308を追跡します[17ページ]。
References
参照
[RFC1034]
Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES,"
STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1035]
Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION," STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実現AND仕様、」、STD13、RFC1035、11月1987日
[RFC2065]
Eastlake, D., and C. Kaufman, "Domain Name System Security
Extensions," RFC 2065, January 1997.
[RFC2065] イーストレーク、D.とC.コーフマン、「ドメインネームシステムセキュリティ拡大」、RFC2065、1997年1月。
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2181]
Elz, R., and R. Bush, "Clarifications to the DNS
Specification," RFC 2181, July 1997.
1997年7月の[RFC2181]Elz、R.とR.ブッシュ、「DNS仕様への明確化」RFC2181。
Author's Address
作者のアドレス
Mark Andrews CSIRO - Mathematical and Information Sciences Locked Bag 17 North Ryde NSW 2113 AUSTRALIA
マークアンドリュースCSIRO--数学と情報Sciences鍵をかけた袋17の北のライドNSW2113オーストラリア
Phone: +61 2 9325 3148 EMail: Mark.Andrews@cmis.csiro.au
以下に電話をしてください。 +61 2 9325 3148はメールされます: Mark.Andrews@cmis.csiro.au
Andrews Standards Track [Page 18] RFC 2308 DNS NCACHE March 1998
アンドリュースStandardsは1998年のDNS NCACHE行進のときにRFC2308を追跡します[18ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Andrews Standards Track [Page 19]
アンドリュース標準化過程[19ページ]
一覧
スポンサーリンク
