rfc2308.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 1,068 行 · 第 1/3 页
TXT
1,068 行
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)
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.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
[RFC1034] provided a description of how to cache negative responses.
It however had a fundamental flaw in that it did not allow a name
server to hand out those cached responses to other resolvers, thereby
greatly reducing the effect of the caching. This document addresses
issues raise in the light of experience and replaces [RFC1034 Section
4.3.4].
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.
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.
Andrews Standards Track [Page 1]
RFC 2308 DNS NCACHE March 1998
1 - Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
"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.
"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.
"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.
"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.
An understanding of [RFC1034], [RFC1035] and [RFC2065] is expected
when reading this document.
Andrews Standards Track [Page 2]
RFC 2308 DNS NCACHE March 1998
2 - Negative Responses
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).
A negative response is indicated by one of the following conditions:
2.1 - Name Error
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.
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.
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 RESPONSE: TYPE 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.
Header:
RDCODE=NXDOMAIN
Query:
AN.EXAMPLE. A
Andrews Standards Track [Page 3]
RFC 2308 DNS NCACHE March 1998
Answer:
AN.EXAMPLE. CNAME TRIPPLE.XX.
Authority:
XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
Additional:
<empty>
NXDOMAIN RESPONSE: TYPE 3.
Header:
RDCODE=NXDOMAIN
Query:
AN.EXAMPLE. A
Answer:
AN.EXAMPLE. CNAME TRIPPLE.XX.
Authority:
<empty>
Additional:
<empty>
NXDOMAIN RESPONSE: TYPE 4
Header:
RDCODE=NXDOMAIN
Query:
AN.EXAMPLE. A
Answer:
AN.EXAMPLE. CNAME TRIPPLE.XX.
Authority:
XX. NS NS1.XX.
XX. NS NS2.XX.
Additional:
NS1.XX. A 127.0.0.2
NS2.XX. A 127.0.0.3
REFERRAL RESPONSE.
Header:
RDCODE=NOERROR
Query:
AN.EXAMPLE. A
Answer:
AN.EXAMPLE. CNAME TRIPPLE.XX.
Authority:
XX. NS NS1.XX.
XX. NS NS2.XX.
Additional:
NS1.XX. A 127.0.0.2
Andrews Standards Track [Page 4]
RFC 2308 DNS NCACHE March 1998
NS2.XX. A 127.0.0.3
Note, in the four examples of NXDOMAIN responses, it is known that
the name "AN.EXAMPLE." exists, and has as its value a CNAME record.
The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to
exist. On the other hand, in the referral example, it is shown that
"AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is
known one way or the other about the existence of "TRIPPLE.XX", other
than that "NS1.XX" or "NS2.XX" can be consulted as the next step in
obtaining information about it.
Where no CNAME records appear, the NXDOMAIN response refers to the
name in the label of the RR in the question section.
2.1.1 Special Handling of Name Error
This section deals with errors encountered when implementing negative
caching of NXDOMAIN responses.
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.
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.
2.2 - No Data
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.
Andrews Standards Track [Page 5]
RFC 2308 DNS NCACHE March 1998
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.
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.
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.
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 RESPONSE: TYPE 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.
Header:
RDCODE=NOERROR
Query:
ANOTHER.EXAMPLE. A
Answer:
<empty>
Authority:
EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
Additional:
<empty>
Andrews Standards Track [Page 6]
RFC 2308 DNS NCACHE March 1998
NO DATA RESPONSE: TYPE 3.
Header:
RDCODE=NOERROR
Query:
ANOTHER.EXAMPLE. A
Answer:
<empty>
Authority:
<empty>
Additional:
<empty>
REFERRAL RESPONSE.
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?