Network Working Group K. Fujiwara Internet-Draft JPRS Intended status: Informational 19 March 2025 Expires: 20 September 2025 Another Resolver Algorithm draft-fujiwara-dnsop-resolver-update-01 Abstract NS RRSet mismatch between parent side and child side makes name resolution unstable. DNS specification defines 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 authoritative A/AAAA RRSets). The overwrite makes name resolution unstable and induces some vulnerabilities. RFC 2181 section 5.4.1 specifies trustworthiness order 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 might answer non-authoritative data, referrals and glue records that should not be returned. This document proposes another resolver algorithm that separates cached data into "authoritative data" and "delegation data". 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 https://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 20 September 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Fujiwara Expires 20 September 2025 [Page 1] Internet-Draft resolver-update March 2025 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology{#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 . . . . . . . . . . . . . . . . . . . . . . 6 5. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Recommendations to resolvers . . . . . . . . . . . . . . 6 5.2. Another resolver algorithm . . . . . . . . . . . . . . . 7 5.3. Characteristics of the algorithm . . . . . . . . . . . . 8 5.4. Issues of the algorithm . . . . . . . . . . . . . . . . . 8 5.5. Implementations . . . . . . . . . . . . . . . . . . . . . 8 6. Comparisons with traditional resolver algorithms . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 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. Fujiwara Expires 20 September 2025 [Page 2] Internet-Draft resolver-update March 2025 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 glue records are replaced by authoritative data if resolvers receive authoritative data described in Section 3.3. The replacement makes name resolution unstable and induces vulnerabilities described in Section 4. And it may break requirements of resolvers' answers described in Section 3.2. This document proposes another resolver algorithm that separate authoritative data that is answered to stub resolvers and delegation data that is used to iterate zones. Details are described in Section 5 2. Terminology{#terminology} The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Many of the specialized terms used in this specification are defined in DNS Terminology [RFC9499]. 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 [RFC8499] 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) Fujiwara Expires 20 September 2025 [Page 3] Internet-Draft resolver-update March 2025 "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) "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) Fujiwara Expires 20 September 2025 [Page 4] Internet-Draft resolver-update March 2025 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. 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". Fujiwara Expires 20 September 2025 [Page 5] Internet-Draft resolver-update March 2025 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". 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 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 if the parent NS RRSet has already been removed. 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. Proposed solution 5.1. Recommendations to resolvers Resolvers answer one of the following results: * required data from a server that is authoritative for the query * name error from a server that is authoritative for the query * empty (NODATA) from a server that is authoritative for the query * other name resolution errors (SERVFAIL, REFUSED), * 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. Fujiwara Expires 20 September 2025 [Page 6] Internet-Draft resolver-update March 2025 Resolvers must not use glue records and referrals except iterating delegations. 5.2. Another resolver algorithm This document proposes another resolver algorithm that does not use zone apex NS RRSets to iterate as a change to RFC 1034 Section 5.3.3 Algorithm as follows. Separate cache data into "authoritative data" and "delegation data". Each domain name entry may have both authoritative data and delegation data. Pre-load root hint information (root NS RRSet and root server addresses) as delegation data. "Step 4.a." is changed as "if the response answers the question or contains a name error, cache the data as authoritative data 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 as delegation data, and go to step 2". The cache used in "Step 2" is the delegation data. "Set up their addresses using local data" is replaced as "Set up their addresses using the delegation data and resolution results of out-of-bailiwick name server names". As a result, RFC 2181 Section 5.4.1 Ranking data becomes useless because the overwrite will not happen with this algorithm. 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 are 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). Fujiwara Expires 20 September 2025 [Page 7] Internet-Draft resolver-update March 2025 5.3. Characteristics of the algorithm This algorithm 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 the same as 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. The update does not effect to DNS Query Name Minimisation [RFC9156] 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 algorithm This algorithm 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. 5.5. Implementations Some implementers already implemented similar algorithm to their products. 6. Comparisons with traditional resolver algorithms To be described 7. IANA Considerations This document has no IANA actions. 8. Security Considerations 9. Acknowledgments The author would like to thank discussions of dnsop WG. Fujiwara Expires 20 September 2025 [Page 8] Internet-Draft resolver-update March 2025 10. Change History 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9156] Bortzmeyer, S., Dolmans, R., and P. Hoffman, "DNS Query Name Minimisation to Improve Privacy", RFC 9156, DOI 10.17487/RFC9156, November 2021, . 11.2. Informative References [DUAN2012GHOST] Jiang, J., Liang, J., Li, K., Li, J., Duan, H., and J. Wu, "Ghost domain names:Revoked yet still resolvable", 2012, . [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, . [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, . [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, . Fujiwara Expires 20 September 2025 [Page 9] Internet-Draft resolver-update March 2025 [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, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 8499, DOI 10.17487/RFC8499, January 2019, . [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, . Author's Address Kazunori Fujiwara Japan Registry Services Co., Ltd. Email: fujiwara@jprs.co.jp Fujiwara Expires 20 September 2025 [Page 10]