One document matched: draft-ietf-dnsind-ncache-01.txt

Differences from draft-ietf-dnsind-ncache-00.txt

   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]