Browse Prior Art Database

Negative Caching of DNS Queries (DNS NCACHE) (RFC2308)

IP.com Disclosure Number: IPCOM000002873D
Original Publication Date: 1998-Mar-01
Included in the Prior Art Database: 2019-Feb-15
Document File: 19 page(s) / 25K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. Andrews: AUTHOR

Related Documents

10.17487/RFC2308: DOI

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. [STANDARDS-TRACK]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 8% of the total text.

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

Processing...
Loading...