Network Working Group K. Fujiwara Internet-Draft JPRS Updates: 1034, 2181 (if approved) November 01, 2016 Intended status: Standards Track Expires: May 5, 2017 Updating Resolver Algorithm draft-fujiwara-dnsop-resolver-update-00 Abstract Parent side NS RRSet and glue records are all information to access servers for child zone. However, they may be overwritten by child zone data (zone apex NS RRSet and other A/AAAA RRSets). The overwrite makes name resolution unstable and induces vulnerabilities. RFC 2181 section 5.4.1 specifies trustworthiness of DNS data. And it is deemed that that all cached data (authoritative data, non- authoritative data, referrals and glue records) are merged into one. Resolvers may answer non-authoritative data, referrals and glue records that should not be returned. This document proposes updating resolver algorithm that separates the cache to "authoritative data cache" and "delegation cache". The former is used to answer stub resolvers, and the latter is used to iterate zones. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 5, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Fujiwara Expires May 5, 2017 [Page 1]
Internet-Draft resolver-clarification November 2016 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Traditional resolver algorithm . . . . . . . . . . . . . . . 3 3.1. Importance of parent side NS RRSet . . . . . . . . . . . 3 3.2. Recommendation of resolver's answer . . . . . . . . . . . 4 3.3. Traditional resolver algorithm . . . . . . . . . . . . . 5 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 5. Updating of Resolver Algorithm . . . . . . . . . . . . . . . 6 5.1. Recommendations to resolvers . . . . . . . . . . . . . . 6 5.2. Update to resolver algorithm . . . . . . . . . . . . . . 6 5.3. Characteristics of the update . . . . . . . . . . . . . . 7 5.4. Issues of the update . . . . . . . . . . . . . . . . . . 8 6. Implementation Ideas . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Resolver algorithm is defined in [RFC1034] and updated by [RFC2181]. The resolver algorithm seems to assume single cache that holds all RRSets from received responses. [RFC2181] Section 5.4.1 Ranking data specifies the trustworthiness order of RRSets. When a resolver receives higher trustworthy data, the cached data is replaced by the received data. Parent side NS RRSet is very important because it creates new zone and specifies how to access name servers for the created zone described in Section 3.1. However, parent side NS RRSets and glue records have least trustworthiness. The parent side NS RRSets and Fujiwara Expires May 5, 2017 [Page 2]
Internet-Draft resolver-clarification November 2016 glue records are replaced by authoritative data if resolvers receive authoritative data described in Section 3.3. The overwrite makes name resolution unstable and some vulnerabilities described in Section 4. And it may break requirements of resolvers' answers described in Section 3.2. This document proposes updated resolver algorithm that separate authoritative data cache that is answered to stub resolvers and delegation cache that is used to iterate zones. Details are described in Section 5 2. 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 RFC 2119 [RFC2119]. Many of the specialized terms used in this specification are defined in DNS Terminology [RFC7719]. 3. Traditional resolver algorithm [RFC1034] defines "zone cut", "delegation", "referral", "glue records", "authoritative", and "resolver algorithm". [RFC2181] clarified the resolver algorithm defined in [RFC1034]. 3.1. Importance of parent side NS RRSet [RFC1034], [RFC2181] and [RFC7719] defines zone "cut", "delegation", "referral", and parent side NS RRSet functions as follows. "'cuts' in the name space can be made between any two adjacent nodes. After all cuts are made, each group of connected name space is a separate zone. The zone is said to be authoritative for all names in the connected region." (Quoted from RFC 1034, Section 4.2) "The RRs that describe cuts around the bottom of the zone are NS RRs that name the servers for the subzones. Since the cuts are between nodes, these RRs are NOT part of the authoritative data of the zone, and should be exactly the same as the corresponding RRs in the top node of the subzone." (Quoted from RFC 1034, section 4.2.1) "That is, parent zones have all the information needed to access servers for their children zones." (Quoted from RFC 1034, section 4.2.1) Fujiwara Expires May 5, 2017 [Page 3]
Internet-Draft resolver-clarification November 2016 "Resolvers must be able to access at least one name server and use that name server's information to answer a query directly, or pursue the query using referrals to other name servers." (Quoted from RFC 1034, Section 2.4) "Delegation is the process by which a separate zone is created in the name space beneath the apex of a given domain. Delegation happens when an NS RRset is added in the parent zone for the child origin." (Quoted from RFC 7719) "This situation typically occurs when the glue address RRs have a smaller TTL than the NS RRs marking delegation," (Quoted from RFC 1035, Section 7.2) "The existence of a zone cut is indicated in the parent zone by the existence of NS records specifying the origin of the child zone." (Quoted from RFC 2181, Section 6) As described above, parent side NS RRSet makes a new zone. Parent side NS RRSet (referral) and glue records are all the information to access servers for the child zone. That is, resolvers SHOULD NOT use child side NS RRSet to iterate zones. 3.2. Recommendation of resolver's answer RFC 1034 describes resolver's answer as follows. "The ideal answer is one from a server authoritative for the query which either gives the required data or a name error. The data is passed back to the user and entered in the cache for future use if its TTL is greater than zero." (Quoted from RFC 1034, Section 5.3.3) "The simplest mode for the client is recursive, since in this mode the name server acts in the role of a resolver and returns either an error or the answer, but never referrals." (Quoted from RFC 1034, Section 4.3.1) Recently, most of full-service resolver implementations answer only authoritative data to stub resolvers. As described above, recommendation of resolver's answer is "answer only authoritative data." It does not break existing standards. Fujiwara Expires May 5, 2017 [Page 4]
Internet-Draft resolver-clarification November 2016 3.3. Traditional resolver algorithm Resolver algorithm is defined in [RFC1034] Section 5.3.3. Resolvers cache all RRSets during the iterations in their cache. When resolvers receive new data, they will update their cache. The update is explained using an example resolution of "www.example.com/A" in "example.com" zone as follows. When a resolver iterates "www.example.com/A" query, then one of root servers responds "com" NS RRSet (referral) with glue records, one of "com" servers responds "example.com" NS RRSet with glue records, and one of "example.com" servers responds "www.example.com" A RRSet. As a result, the resolver caches all RRSets during the iterations in its cache. After then, a resolver receives "example.com/NS" query, it retrieves "example.com" NS authoritative data defined in zone apex of "example.com" and it overwrites "example.com/NS" in the resolver's cache as "trustworthiness" rule of [RFC2181]. If the parent side "example.com" NS RRSet and the child side "example.com" NS RRSet are different, next resolution result will be changed because the resolver will send "www.example.com/A" query to name servers that are specified by "example.com" NS RRSet defined in zone apex. Glue records in the cache are also overwritten by authoritative data, and then, IP addresses of name servers that the resolver send to will be changed. The other case, if one of "example.com" name servers responds "www.example.com" A RRSet with "example.com" NS RRSet in authority section (several existing authoritative server implementations perform this) , "example.com" NS RRSet from "com" TLD servers (referral) is overwritten by "example.com" NS data attached in the authoritative answer from child zone. The overwrite is specified by [RFC2181] Section 5.4.1 Ranking data. "Referrals" is the ranking 7: "Data from the authority section of a non-authoritative answer". And "example.com" NS RRSet attached in the authoritative answer is the ranking 4: "Data from the authority section of an authoritative answer". 4. Problem Statement [RFC1034] section 4.2.1 states that "the parent side NS RRSet should be exactly the same as the corresponding RRs in the top node of the subzone". Fujiwara Expires May 5, 2017 [Page 5]
Internet-Draft resolver-clarification November 2016 However, people sets different NS RRSets with mistakes, or intentionally. Name server configuration changes will make the differences because the changes take time. If the zone data of name server(s) specified by referrals and specified by zone apex NS RRSet are different, name resolution becomes unstable. The cache overwrite of NS RRSet may break "Referrals and glue records are information to access servers for child zones" specified by [RFC1034] section 4.2.1. The overwrite by zone apex NS RRSet induced security vulnerabilities. In 2012, "Ghost Domain Names: Revoked Yet Still Resolvable" [DUAN2012GHOST] was reported. The attack uses updates of NS RRSet attached in authoritative answer. Assume a resolver caches and uses zone apex NS RRSet, and the parent side NS RRSet is updated or removed. The resolver send queries to name servers specified by zone apex NS RRSet and update NS RRSet by the NS RRSet attached in the authority section of the answer. Parent side NS RRSet specifies the existence of delegation, however, resolvers may not check the existence of the parent side NS RRSet and the domain name will remain in the resolvers. DNS software vendors fixed the problem to restrict the TTL of NS RRSet not to exceed the cached TTL value of old NS RRSet when replacing it. 5. Updating of Resolver Algorithm 5.1. Recommendations to resolvers Resolvers MUST answer one of the following results: required data, name error, or empty (NODATA) from a server that is authoritative for the query, other name resolution errors (SERVFAIL, REFUSED), or no answer. Resolvers iterate queries using referrals with corresponding glue records to other name servers. If referrals contain out-of-bailiwick name server names, resolvers need to resolve address records of out- of-bailiwick name servers. Resolvers MUST NOT use glue records and referrals except iterating delegations. Resolvers MUST NOT use zone apex NS RRSets to iterate. 5.2. Update to resolver algorithm This document update RFC 1034 Section 5.3.3. Algorithm as follows. Fujiwara Expires May 5, 2017 [Page 6]
Internet-Draft resolver-clarification November 2016 Separate the cache into "authoritative data cache" and "delegation cache". Pre-load root hint information (root NS RRSet and root server addresses) into the delegation cache. "Step 4.a." is changed as "if the response answers the question or contains a name error, cache the data into authoritative cache as well as returning it back to the client". "Step 4.b." is changed as if the response contains a better delegation to other servers, cache the delegation information into delegation cache, and go to step 2". The cache in "Step 1" is the authoritative data cache. The cache used in "step 2" is the delegation cache. "Set up their addresses using local data" is replaced as "Set up their addresses using the delegation cache". As a result, RFC 2181 Section 5.4.1 Ranking data becomes useless because the overwrite will not happen. Pre-loaded zone files (or zones retrieved from zone transfer) are treated as answers from authoritative servers. They are treated as static authoritative data, referrals, and glue records. Referrals and glue records in pre-loaded zone files MUST NOT be answered to stub resolvers. They MUST be used to iterate name servers only. Root zone is special because it is not delegated. Root hint and priming are exceptions because priming replaces pre-configured root hint by root zone apex NS RRSet (authoritative data). 5.3. Characteristics of the update This update does not change resolver algorithm described in RFC 1034 section 5.3.3, except updates of referrals. It separates authoritative data (possible to answer) and referrals (used to iterate DNS tree). It does not require no special ordering (e.g. trustworthiness and ranking data). It offers more stability of name resolution because the results of traditional name resolution will flap if NS RRSets between the parent and the child are different. This algorithm is similar to traditional algorithm when the cache is empty. The update does not effect to DNSSEC [RFC4033] [RFC4034] [RFC4035] because DNSSEC validates authoritative data and does not validate referrals. Fujiwara Expires May 5, 2017 [Page 7]
Internet-Draft resolver-clarification November 2016 The update does not effect to DNS Query Name Minimisation [RFC7816] because answers from authoritative servers don't change. Delegation cache and authoritative data cache separation will need small implementation changes. 5.4. Issues of the update This update makes impossible to control of TTL value of NS RRSet by the child zone owner. However, overwrite of the referral does not occur always and TTL control may increase queries to authoritative servers. 6. Implementation Ideas Some implementers already implemented similar algorithm to their products. 7. IANA Considerations {#:ianacons} This document has no IANA actions. 8. Security Considerations 9. Acknowledgments 10. Change History 11. References 11.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <http://www.rfc-editor.org/info/rfc2181>. Fujiwara Expires May 5, 2017 [Page 8]
Internet-Draft resolver-clarification November 2016 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>. [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, <http://www.rfc-editor.org/info/rfc7719>. 11.2. Informative References [DUAN2012GHOST] D, H., Jiang, J., Liang, J., Li, K., Li, J., and J. Wu, "Ghost domain names:Revoked yet still resolvable", 2012, <The 19th Annual Network & Distributed System Security Symposium (NDSS 2012)>. [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, <http://www.rfc-editor.org/info/rfc7816>. Author's Address Kazunori Fujiwara Japan Registry Services Co., Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan Phone: +81 3 5215 8451 Email: fujiwara@jprs.co.jp Fujiwara Expires May 5, 2017 [Page 9]
