Dismiss
InnovationQ/InnovationQ Plus content will be updated on Sunday, June 25, 10am ET, with new patent and non-patent literature collections. Click here to learn more.
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: 2000-Sep-13
Document File: 15 page(s) / 38K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. Andrews: AUTHOR

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

This text was extracted from a ASCII Text document.
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.

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