Internet DRAFT - draft-wang-dns-inconsis-ncache

draft-wang-dns-inconsis-ncache



Network Working Group                                      Zheng Wang
Internet Draft                                                  CNNIC
Updates: 1035, 2308
(if approved)
Intended status: Standards Track
Expires: April 19, 2010



      Handling of the Inconsistency of Negative Caching of DNS Queries
                   draft-wang-dns-inconsis-ncache-00.txt




Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be modified,
   and derivative works of it may not be created, and it may not be
   published except as an Internet-Draft.

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be modified,
   and derivative works of it may not be created, except to publish it
   as an RFC and to translate it into languages other than English.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November 10,
   2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   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 documents at any



Wang, et al.           Expires April 19, 2010                 [Page 1]
 

Internet-Draft   draft-wang-dns-inconsis-ncache-00.txt   October 2009


   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on April 19, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The introduction of negative caching of DNS queries may make DNS
   resolvers more frequently exposed to the cache inconsistency. This
   document describes the negative caching inconsistency and gives a
   solution for DNS resolvers to handle it.

Table of Contents


   1. Introduction................................................2
   2. Definitions.................................................3
   3. Inconsistency of Negative Caching...........................3
   4. Handling of the Inconsistency of Negative Caching...........4
   5. Security Considerations.....................................5
   6. IANA Considerations.........................................5
   7. References..................................................5
   Author's Addresses.............................................6


1. Introduction

   The DNS resolver [RFC1035] is expected to cache appropriate data
   which it receives in responses since it may be useful in answering
   future client requests. Nevertheless, [RFC1035] specified several


Wang, et al.           Expires April 19, 2010                 [Page 2]
 

Internet-Draft   draft-wang-dns-inconsis-ncache-00.txt   October 2009


   types of data which should not be cached. It also referred to the
   circumstances when the data in the response is not consistent with
   that in the cache and defined the necessity of checking the cache for
   already existing resource records. Negative caching is specified in
   [RFC2308]. While negative caching facilitates the answering of
   requests for the invalid name and non-existing records of the given
   type, it also complicates the cache management. First, the data of
   negative caching is not RR, which is not covered by [RFC1035]. Second,
   the NXDOMAIN answer is related to all existing data in the cache for
   the same name, thus increases the opportunities of cache
   inconsistency.

   This document is a self-contained revised specification complementing
   [RFC1035] and [RFC2308].

2. Definitions

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

3. Inconsistency of Negative Caching

   As specified by [RFC2308], there are typically two types of negative
   caching, NXDOMAIN and NODATA. Both of them denote the negative
   expression for the QNAME and the only difference is that NODATA
   indicate that the name is valid, for the given class, but there are
   no records of the given type. Thus NXDOMAIN, NODATA and common
   resource records (positive answer) actually express different
   knowledge about the existence of name. When the resolvers encounter
   negative answers with NXDOMAIN/NODATA and positive answers from the
   cache for the same name, they must decide which one is to be used.

   In principle, there are two circumstances when the negative caching
   inconsistency occurs. One is that the NXDOMAIN response conflicts
   with the already existing data in the cache. The other is that NODATA
   or positive answer conflicts with the already existing NXDOMAIN cache.
   However, the latter is not generally believed to happen since the
   NXDOMAIN cache should prevent the resolvers from sending out requests
   for a name. An example, which explains the first circumstance, is
   described as follows:

   First, the resolver requests for www.example.com of type A:

   Question 1:  www.example.com  IN  A




Wang, et al.           Expires April 19, 2010                 [Page 3]
 

Internet-Draft   draft-wang-dns-inconsis-ncache-00.txt   October 2009


   It gets a NODATA answer and caches it with a TTL according to the SOA
   record in the authority section of the reply:

   Cache 1:  www.example.com  IN  A  NODATA

   The resolver also requests for www.example.com of type AAAA:

   Question 2:  www.example.com  IN  AAAA

   It gets the positive answer and caches it:

   Cache 2:  www.example.com  IN  AAAA  4321:0:1:2:3:4:567:89ab

   Before the cache 1 or cache 2 expires, the resolver requests for
   www.example.com of type MX:

   Question 3:  www.example.com  IN  MX

   Since the question can neither hit the negative cache 1 nor positive
   cache 2, it can be sent to the DNS authoritative server. But the zone
   file of the authoritative server may have changed. Suppose that the
   name www.example.com does not exist now and so the authoritative
   server replies with "Name Error" RCODE. The resolver then caches the
   NXDOMAIN response:

   Cache 3:  www.example.com  IN  NXDOMAIN

   Therefore cache 3 conflicts with cache 1 and cache 2, and the
   resolver has to choose one as the final answer from the cache.

4. Handling of the Inconsistency of Negative Caching

   On the determination of the final answer, either the data in the
   response or the cache is preferred, but the two should never be
   combined. But if the NXDOMAIN response is from authoritative data in
   the answer section, it is always preferred. If so, the procedure of
   processing the NXDOMAIN response for the DNS resolver should include:

   - Check whether there are NODATA or positive caches for the same
   QNAME.

   - If any, substitute all of them with the NXDOMAIN cache (That is, in
   the above example, the resolver should replace cache 1 and cache 2
   with cache 3).

   - Use the NXDOMAIN response as the final answer to the request.



Wang, et al.           Expires April 19, 2010                 [Page 4]
 

Internet-Draft   draft-wang-dns-inconsis-ncache-00.txt   October 2009


5. Security Considerations

   One possible arising threat is related to the authentication of the
   NXDOMAIN response. If the NXDOMAIN response is the injected forged
   one by the attackers, the actually existing name may be blocked from
   being requested until the TTL expires.  This threat is both
   alleviated by the Domain Name System Security Extensions (DNSSEC)
   [RFC4033] [RFC4034] [RFC4035] (or more specifically, DNS Security
   (DNSSEC) Hashed Authenticated Denial of Existence for authenticated
   denial of existence [RFC5155]) and [RFC5452]. DNSSEC adds data origin
   authentication and data integrity to the Domain Name System. [RFC5452]
   specified measures to make 'spoofing' DNS resolvers harder while
   saving large amounts of cryptographical computation.

6. IANA Considerations

   This document does not require any IANA actions.

7. References

   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
             Specifications", STD 13, RFC 1035, November 1987.

   [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
             RFC 2308, March 1998.

   [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
             Rose, "DNS Security Introduction and Requirements", RFC
             4033, March 2005.

   [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
             Rose, "Resource Records for the DNS Security Extensions",
             RFC 4034, March 2005.

   [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
             Rose, "Protocol Modifications for the DNS Security
             Extensions", RFC 4035, March 2005.

   [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
             Security (DNSSEC) Hashed Authenticated Denial of Existence",
             RFC 5155, March 2008.

   [RFC5155] Hubert, A., Mook, R., "Measures for Making DNS More
             Resilient against Forged Answers", RFC 5452, January 2009.





Wang, et al.           Expires April 19, 2010                 [Page 5]
 

Internet-Draft   draft-wang-dns-inconsis-ncache-00.txt   October 2009


             Authors' Addresses

   Zheng Wang
   CNNIC
   4, South 4th Street, Zhongguancun
   Beijing 100190
   P.R. China
   Email: wangzheng@cnnic.cn








































Wang, et al.           Expires April 19, 2010                 [Page 6]