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]