Negative Caching of DNS Queries (DNS NCACHE)
RFC 2308
|
| Document |
Type |
|
RFC - Proposed Standard
(March 1998; Errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 2308 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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:
Show full document text