INTERNET-DRAFT Mark Andrews (CSIRO) <draft-ietf-dnsind-ncache-01.txt> January 1997 Updates: RFC 1034 Negative Caching of DNS Queries (DNS NCACHE) Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other docu- ments at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract When [RFC1034] was written there were no DNS servers that imple- mented negative caching [RFC1034 Section 4.3.4]. This document replaces [RFC1034 Section 4.3.4] in the light of experience. Negative caching is a optional part of the DNS specification and deals with the caching of the non-existence of a RRset or domainname. 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 servers hence overall network traffic. Expires July 1997 [Page 1]
INTERNET-DRAFT DNS NCACHE January 1997 0 - History [ Anyone want to say why negative caching wasn't implemented in the early servers or why not in BIND? If I don't get anything this section will go. MPA ] 1 - Terminology The terms MAY, SHALL, MUST and their negative forms, MAY NOT, SHALL NOT, MUST NOT are described in [RFC ....]. An understanding of [RFC1034], [RFC1035] and [RFC2065] is expected when reading this document. 2 - Negative Responses Negative responses usually refer to the existence or lack there of a particular RRset in the DNS. The first sections of this document deals with these responses. There are other negative responses that indicate failures of servers and they are dealt with from section ``5 - Other negative responses'' onwards. A negative response is indicated by one of the following conditions: 2.1 - Name Error NXDOMAIN (Name Error) in the RCODE field. In this case the domain that does not exist is referred to in the query name, or is the data field of the last CNAME in the answer section. Note the answer section may have SIG RRs and authority section may have SOA, NXT and SIG RRsets. Some nameserver did not look at the RCODE and continued processing in the presence of NS records in the authority section. NS records MUST NOT be sent in the authority section as a result. Some nameserver incorrectly continue processing if the authority flag is not set. The authority flag MUST be set even in non-authoritive answers. It is hoped that this restriction can be relaxed at some future time. With this in mind all servers MUST accept and correctly process messages with the authority flag not set. 2.1 - No Data This has to algorithmically determined from the responses contents as there is no RCODE field to indicate NODATA. In some cases you have to Expires July 1997 [Page 2]
INTERNET-DRAFT DNS NCACHE January 1997 requery to get a definitive answer. No data is indicated by an answer with a RCODE of NOERROR, no answers in the answer section and no NS records in the authority section. The authority section may contain SOA, NXT and SIG RRsets. CNAMEs and SIG records may exist in the answer section. The domain containing NODATA for the requested type is that listed in the query section or in the last CNAME's data field. Some server fail to set the RCODE to NXDOMAIN in the presence of CNAMEs in the answer section. If a definitive NXDOMAIN / NODATA answer is required you must requery with the last CNAME data field. As there is no RCODE indicating NODATA non-authoritive answer MUST NOT contain NS records in the authority section. 3 - Negative Answers from Authorative Servers A server SHOULD add the SOA record of the containing zone to the author- ity section of the answer. The TTL of this record is set from the MINIMUM field of the SOA record and is not the TTL of the SOA itself and indicates how long a server may cache this negative answer. If the containing zone is signed [RFC2065] the SOA and appropriate NXT and SIG records MUST be added. 4 - Caching Negative Answers The TTL of the SOA record in the authority section indicates how long the negative response may be cached for. As this TTL is different to the TTL value of the SOA record itself, this SOA record MUST not be used to answer SOA queries. A negative answer that resulted from a name error should be cached such that it can be retrieved and returned in response to another query for the same <query name, QCLASS> that resulted in the cached negative response. A negative answer that resulted from a no data error should be cached such that it can be retrieved and returned in response to another query for the same <query name, QTYPE, QCLASS> that resulted in the cached negative response. The NXT record, if it exists, MUST be stored such that it can be be located, also the SIG record. There is no obvious relationship between Expires July 1997 [Page 3]
INTERNET-DRAFT DNS NCACHE January 1997 the NXT records and cached SOA record. Negative responses without SOA records SHOULD NOT be cached as there is no way to reliably purge them from the cache. 5 - Negative answers from the cache A server when encountering a cached negative response MUST add the cached SOA to the answer section of the response. 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. NS record MUST NOT be added to the authority section as existing servers to not look for the SOA record that would indicate the difference between a NODATA response and a referal. 6 - Changes from RFC 1034 Non-authoritative negative answers MAY be cached. The SOA record from the authority section MUST be cached so that it is retrievable by reference to the <query name, QTYPE, QCLASS> tuple. Name error indications need only match <query name, QCLASS>. A cached SOA record MUST be added to the response. This was explicitly not allowed. 6 - Other Negative Responses Caching of other negative responses are not covered by any existing RFC. Additionally there is no way to indicated a desired TTL of these responses. Care need to be taken to ensure that there are not forwarding loops. 6.1 Server Failure (Optional) Server failures fall into two classes. Self detection where a server detects it is list as a server for a zone but is not configured as a server for that zone. A server cannot process a query due to failures else where in the network. A server failure response MAY be store for up to five (5) minutes against the specific query tuple <query name, type, class, server IP Expires July 1997 [Page 4]
INTERNET-DRAFT DNS NCACHE January 1997 address>. 6.2 Dead Server (Optional) This is were a server fails to respond in any way to a query or a ICMP port unreachable is returned to a UDP based query or a TCP reset is returned to a TCP connection request. A server is deemed to be dead if it hasn't responded to an outstanding query within 120 seconds. A server MAY be deemed dead for no more than five (5) minutes. The indi- cation MUST be stored against query tuple <query name, type, class, server IP address> unless there was a transport layer indication that the server did not exists, in which case it is stored against the specific IP address involved. Security This document is believed to not introduce any security issues addi- tional to those already inherent in the DNS. References [RFC1034] P. Mockapetris, ``DOMAIN NAMES - CONCEPTS AND FACILITIES,'' RFC 1034, ISI, November 1987. [RFC1035] P. Mockapetris, ``DOMAIN NAMES - IMPLEMENTATION AND SPECIFICA- TION,'' RFC 1035, ISI, November 1987. [RCF2065] D. Eastlake, 3rd, C. Kaufman, ``Domain Name System Security Extensions,'' RFR 2065, CyberCash, Iris, January 1997 Authors' Addresses Mark Andrews CSIRO - Mathematical and Information Sciences Locked Bag 17 North Ryde NSW 2113 AUSTRALIA +61 2 9325 3148 <Mark.Andrews@cmis.csiro.au> Expires July 1997 [Page 5]
