Network Working Group J. Abley Internet-Draft Public Interest Registry Intended status: Experimental February 12, 2021 Expires: August 16, 2021 REFER: A New Referral Mechanism for the DNS draft-jabley-dnsop-refer-00 Abstract The Domain Name System (DNS) incorporates a namespace that is comprised, in practice, of multiple so-called zones. Each zone is, in principal, a finite tree structure which can be administered autonomously, and is connected to exactly one parent zone and zero or more child zones. These connection points are known as zone cuts; a parent zone contains information that allows the servers responsible for the child zone to be found. The current DNS specification encodes that information about child zones using an "NS" resource record set in the parent zone, and a corresponding "NS" resource record set in the child zone. These two resource record sets have identical owner names, class, and resource record type but can differ in other respects such as the time-to-live (TTL) attribute, the resource record data associated with each set and the availability of cryptographic signatures. This property of being similar, related but potentially different has led to operational complexity. This document proposes a change to how zone cuts are encoded in the parent zone, allowing the resource records in the parent and the child zone to be more clearly distinguished and protected separately using cryptographic signatures. It is not at all clear that this is a good idea. To restate in stronger terms, the goal of the experiment described in this document is to determine just how bad an idea this is. 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/. Abley Expires August 16, 2021 [Page 1] Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021 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 August 16, 2021. Copyright Notice Copyright (c) 2021 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 (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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. An Assortment of Problem Statements . . . . . . . . . . . . . 4 3.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Ambiguity Across a Zone Cut . . . . . . . . . . . . . . . 4 3.3. Masking of Parental RRSets by Children . . . . . . . . . 5 4. The REFER Mechanism . . . . . . . . . . . . . . . . . . . . . 5 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. The REFER Resource Record Type . . . . . . . . . . . . . 6 4.3. The REFER OK EDNS(0) Option . . . . . . . . . . . . . . . 6 4.4. DNS Protocol Modifications . . . . . . . . . . . . . . . 7 4.4.1. Changes to Deployed Zone Data . . . . . . . . . . . . 7 4.4.2. Changes to DNS Server Behaviour . . . . . . . . . . . 8 4.4.2.1. Authoritative Servers . . . . . . . . . . . . . . 8 4.4.2.2. Recursive Servers . . . . . . . . . . . . . . . . 9 4.4.2.3. Other DNS Servers . . . . . . . . . . . . . . . . 9 4.5. Backwards Compatibility and Incremental Deployment . . . 9 4.6. Transport Considerations . . . . . . . . . . . . . . . . 9 5. Goals of Experiment . . . . . . . . . . . . . . . . . . . . . 10 5.1. Implementation . . . . . . . . . . . . . . . . . . . . . 10 5.2. Gauging the Desperation of the Camel . . . . . . . . . . 10 5.3. Incremental Deployment . . . . . . . . . . . . . . . . . 10 5.4. Effects on DNS Traffic . . . . . . . . . . . . . . . . . 10 5.5. Effects on DNS Zone Provisioning . . . . . . . . . . . . 11 Abley Expires August 16, 2021 [Page 2] Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021 5.6. Policy Hurdles At and Near the Root . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 13 A.1. Venue for Discussion . . . . . . . . . . . . . . . . . . 13 A.2. Change History . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction The Domain Name System (DNS) base specification ([RFC1034], [RFC1035]) has been extended many times since its original publication. The use of two corresponding NS resource-record sets to signal the existence of a zone cut, one in the parent zone and one in the child zone, has resulted in some operational complexity. However the cost of changing the nature of the referral mechanism given the wide and varied assortment of dependent software deployed on the Internet has always been assumed to be so high that it makes more sense to work around that complexity than it does to review the suitability of the incumbent mechanism. This document proposes to challenge that assumption. This document is organised as follows. A curated assortment of problems associated with the incumbent referral mechanism can be found in Section 3. Section 4 contains a proposed, experimental replacement mechanism. Experiments intended to assess the proposed new mechanism and compare it with the incumbent mechanism are described in Section 5. IANA considerations, including code-point assignments, are presented in Section 7 and the security implications of the proposed new mechanism are discussed in Section 6. 2. Terminology This document uses various terminology specific to the DNS. For definitions and discussion of particular terms, see [RFC8499]. The new referral mechanism described in this document is referred to in this document "the REFER Mechanism" and referral responses that follow it are referred to as "REFER Responses". The conventional, current, standard mechanism described in [RFC1034] and [RFC1035] that the REFER Mechanism seeks to replace (or augment, see Section 4.5) is referred to as the "Standard Referral Mechanism" and corresponding referrals using that mechanism are referred to as Standard Referrals. Abley Expires August 16, 2021 [Page 3] Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021 This document uses capitalized keywords such as MUST and MAY to describe the requirements for using the registered RR types. The intended meaning of those keywords in this document are the same as those described in [RFC2119]. Although these keywords are often used to specify normative requirements in IETF Standards, their use in this document does not imply that this document is a standard of any kind. 3. An Assortment of Problem Statements A handful of indicative problem statements that seem relevant to this proposal are included below. This is not an exhaustive list. 3.1. Privacy A Standard Referral response from an authoritative DNS server includes an NS RRset. It is not possible for the response to include a corresponding RRSIG RRset, since the administrator of a parent zone is generally not in possession of the private keys needed to make signatures in a child zone. The lack of signatures means that the Standard Referral response is subject to on-path substitution attacks, even if both parent and child zones are signed and the originator of the request that triggered the referral response requests DNSSEC data (with DO=1) and is capable of validating responses. While it is to be hoped that a validating resolver that falls victim to such an attack would not cache subsequent responses from an attacker's server, since sooner or later something would fail validation, the metadata about the query and the query contents (e.g. a non-minimised QNAME) will have leaked in the process of finding out. The REFER Mechanism does not suffer from this problem, since the delegation information published in the parent and child zones does not overload the same RRtype, and hence can be unambiguously signed separately in both places, allowing validators to identify on-path substitution attacks without leaking queries to rogue servers. Other work has attempted to address this problem, e.g. [I-D.fujiwara-dnsop-delegation-information-signer]. 3.2. Ambiguity Across a Zone Cut When following a Standard Referral response from an authoritative server to a child zone, DNS resolvers cannot always be relied upon to retrieve an NS RRset from child nameservers. Instead they may simply cache the NS RRset with the same owner name received in the Standard Referral response from the parent. This can result in NS RRsets Abley Expires August 16, 2021 [Page 4] Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021 being cached without signatures, since no signatures over the NS RRset can normally be included in a referral response, or the parent's choice of TTL being used in the cache instead of the child's, or inaccurate data being cached in the case where the child's authoritative data is not the same as the data published in the parent zone. The REFER Mechanism does not suffer from this problem, since the RRset obtained from the parent has a different RRtype from any set obtained from the child; any query that requires an NS RRset would necessarily involve a response from the child and cannot be satisfied by a referral response from the parent. Other work has attempted to address this problem, e.g. [I-D.ietf-dnsop-ns-revalidation]. 3.3. Masking of Parental RRSets by Children A nameserver serving both parent and child zones will normally not provide a Standard Referral response from the parent if a response can be formulated with data obtained from the child. This means that the parent's NS RRset will normally be obscured from view, masked by the corresponding NS RRset at the child's apex. This has the potential to hide operational problems that might later become apparent, e.g. if the child zone is moved to different nameservers. The REFER Mechanism does not suffer from the same problem, since the delegation information in the parent and child do not share the same, overloaded RRtype; consequently both the parent zone data and the child zone data can be queried independently, without ambiguity. 4. The REFER Mechanism 4.1. Overview The REFER Mechanism can be summarised as follows: o Introduce a new RRtype for publishing delegation information in the parent zone, which has similar semantics to NS used for the same purpose, except that the rules for signing the RRset are specified to be the same as DS, i.e. signatures belong in the parent; o Specify a new EDNS(0) option which, when present in a query sent to an authoritative server, signals to the server that REFER referrals are supported and requested by the client; o Introduce new, optional functionality in authoritative servers such that queries requesting REFER responses will receive a REFER Response, if available; Abley Expires August 16, 2021 [Page 5] Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021 o Preserve the Standard Referral response for queries that do not explicitly request the new behaviour, or for responses that are generated from zones that do not include new-style delegation RRtypes. Complete deployment of the REFER Mechanism requires changes in all DNS zones, all authoritative servers and all clients of authoritative servers (e.g. recursive servers). This seems like an unrealistic expectation. However, it seems intuitively true that certain modes of incremental deployment may have useful characteristics; determining whether this hypothesis holds in practice is one of the objectives of this experiment, as described in Section 5. For more discussion of incremental deployment, see Section 4.5. The REFER Mechanism is described in more detail in the sections that follow. 4.2. The REFER Resource Record Type The REFER resource record (RR) is used to store a single nameserver name in the DNS. It is intended to be used in a parent zone to signal the presence of a zone cut and to specify the nameservers to which a child zone is delegated. The type value for the REFER RR is TBA1. The REFER RR is class-independent. However, interpretation of the REFER RR by DNS servers in processing DNS queries and responses is only specified for class IN. The REFER RR has no special time-to-live (TTL) requirements. The RDATA for a REFER RR and its wire format is precisely the same as for the NS RR, as described in [RFC1035] section 3.3.11. The presentation format of the REFER RR is precisely the same as for the NS RR, with the REFER keyword replacing the NS keyword. 4.3. The REFER OK EDNS(0) Option The REFER Mechanism requires a means for the originator of a query to signal to a server that if a referral response is generated, a REFER Response is requested. The most consistent approach to achieve this signalling seems to follow the approach used with the DO bit, as specified in [RFC3225] and [RFC4035] section 3.2.1. However, since EDNS(0) header bits are in short supply (there are only 15 of them available for assignment, see [RFC6891]) this seems inappropriate for Abley Expires August 16, 2021 [Page 6] Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021 an experimental proposal. Instead, this document specifies a separate, optional EDNS(0) option. The REFER OK EDNS(0) option is encoded as an OPTION-CODE of TBA2, an OPTION-LENGTH of zero and no OPTION-DATA, as follows: +0 (MSB) +1 (LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | OPTION-CODE = TBA2 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 2: | OPTION-LENGTH = 0 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ The REFER OK EDNS(0) option MAY be included alongside other EDNS(0) options in the same query. A single DNS query SHOULD include zero or one REFER OK option; including more than one does not change the intended signal and hence serves no purpose. Systems which receive more than one REFER OK option in a single query should behave precisely as if only a single REFER OK option had been included. A DNS response generated by a system that supports the REFER Mechanism, in response to a query that included the REFER OK option, should also include a single REFER OK option in the response, even if the response is not a referral. Any DNS system which receives a DNS message containing more than one REFER OK option should behave precisely as if only a single REFER OK option had been included. 4.4. DNS Protocol Modifications 4.4.1. Changes to Deployed Zone Data In order for a referral response to be constructed using the REFER Mechanism, the corresponding zone cut must be provisioned in the zone data loaded in the server using a REFER RRset. An NS RRset with the same owner name MAY also be present, but is not required. If both NS and REFER RRsets exist at the same owner name, both RRsets SHOULD point to the same set of servers, since operational confusion might well result from them being different. However, zone administrators MAY deliberately make the RDATA of each RRset different, e.g. for the purposes of experimental measurement. In a signed zone REFER RRsets MUST be signed, regardless of whether the zone cut that they are being used to provision represents a secure delegation or an insecure delegation. The keys used to Abley Expires August 16, 2021 [Page 7] Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021 generate RRSIGs over a REFER RRset are those published in the parent zone that contains the REFER RRset, similarly to the way in which DS RRsets are signed. 4.4.2. Changes to DNS Server Behaviour 4.4.2.1. Authoritative Servers An authoritative server that supports the REFER Mechanism MUST check for the existence of the RO option in queries it receives. The existence or non-existence of the RO option in the query MUST be retained as part of the query attributes used to build a corresponding response. When generating a referral response, the intention is that an authoritative server that supports the REFER Mechanism should send referrals that are identical to the Standard Mechanism if the corresponding query does not include the RO option, but should always prefer to include REFER RRsets over NS RRsets at all other times. 1. If the query included the RO option and zone data above the zone cut incudes a REFER RRset, that REFER RRset MUST be included in the referral response precisely as an NS RRset would be included under the Standard Mechanism. An RRSIG RRset over the REFER RRset MUST also be included, if available. 2. If the query included the RO option and zone data above the zone cut does not include a REFER RRset, the NS RRset MUST be included precisely as it would under the Standard Mechanism. 3. If the query did not include the RO option and zone data above the zone cut includes an NS RRset, that NS RRset MUST be included precisely as it would be under the Standard Mechanism. 4. If the query did not include the RO option and zone data above the zone cut does not include an NS RRset, an NS RRset MUST be synthesised from the REFER RRset that is present. No referral response should ever include both a REFER and an NS RRset to communicate the target servers of a delegation. An authoritative server that supports the REFER Mechanism MUST include the RO option in every response to a query in which the RO option was present, and MUST NOT include the RO option in any other response, regardless of whether the response is a referral. Abley Expires August 16, 2021 [Page 8] Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021 4.4.2.2. Recursive Servers A recursive server that supports the REFER Mechanism: 1. MUST include the RO option in every query it sends; 2. MUST interpret and use REFER RRsets received in referral responses in precisely the same way that NS RRsets received in referral responses are interpreted when following the iterative resolution process; 3. MUST use NS RRsets in preference to REFER RRsets with the same owner name and QCLASS if both are present in the cache. 4.4.2.3. Other DNS Servers No changes are required to DNS forwarders. 4.5. Backwards Compatibility and Incremental Deployment The intent is that authoritative DNS servers supporting the REFER Mechanism should generate identical responses to those following the Standard Mechanism for all queries received without the RO option. This allows a single server to support clients that do not support the REFER Mechanism as well as those that do, and ensures a consistent experience for clients that do not support the REFER Mechanism regardless of whether it is deployed on any authoritative server. A recursive DNS server that supports the REFER Mechanism may complete the iterative resolution process in the process of responding to a query by means of inbound REFER responses. Such a server might not be able to respond to a subsequent query received with QTYPE=NS from the cache, but would need to initiate a new query in order to retrieve the apex NS RRset from the servers that are authoritative for the closest enclosing zone. This additional query has the potential to increase response time, but has the advantage that the ambiguity that might otherwise arise around whether a particular NS RRset originates from above or below a zone cut is avoided. Additionally, NS RRsets that are consistently retrieved from servers below the zone cut have the opportunity to be cryptographically signed, improving cache integrity through the validation process. 4.6. Transport Considerations The REFER Mechanism imposes no special requirements on DNS transport protocols. Abley Expires August 16, 2021 [Page 9] Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021 5. Goals of Experiment The overarching ambition of this experiment is to gauge whether a change in a fundamental aspect of the deployed DNS protocol, the referral mechanism, is plausible. This document does not specify any experiments, but attempts to frame some indicative research questions. Since the two code points that are needed to carry out experiments will be allocated from protocol registries that are not generally managed with leases (i.e. assignments are essentially permanent) there is no time period specified for this experiment. The following are not intended to be an exhaustive list of research questions, but rather examples intended to seed discussion. 5.1. Implementation Is the REFER Mechanism specification proposed in this document unambiguous and sufficient for it to be implemented? 5.2. Gauging the Desperation of the Camel Can the REFER Mechanism be implemented in commonly-used DNS code bases without causing unacceptable complexity? This is a subjective question, but perhaps by gathering a diversity of answers from different teams working on different code bases a reasonable assessment can be made. 5.3. Incremental Deployment Can the REFER Mechanism be deployed in an environment where support is absent in other clients and servers? A DNS implementation should interact with other clients and servers that do not support the REFER Mechanism identically regardless of whether it supports the REFER Mechanism itself. That is, the mechanisms intended to provide backwards compatability to the Standard Mechanism should work. 5.4. Effects on DNS Traffic What effect would the REFER Mechanism have on traffic if it was widely deployed? Abley Expires August 16, 2021 [Page 10] Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021 5.5. Effects on DNS Zone Provisioning What other systems, beyond those contemplated in this document, depend upon delegations being provisioned in DNS zones using NS RRsets? This proposal allows deployment of both NS and REFER RRsets at a single zone cut which might mitigate any negative effects of an NS- to-REFER transition, but that mitigation comes at the cost of increased zone size that might be significant in large, delegation- centric zones such as those published by some TLD registries. 5.6. Policy Hurdles At and Near the Root How practical might it be to deploy REFER RRsets in the root zone, or TLD zones, and to support the REFER Mechanism in TLD and root servers? 6. Security Considerations The REFER Mechanism, if implemented by authoritative DNS servers and their clients, has the potential to improve confidentiality of communications since it allows a referral response from an authoritative server to be signed. A signed referral response can be validated and confirmed to be authentic before subsequent queries are sent to the servers listed in the referral, avoiding the possibility that the existence and contents of a query might be disclosed to an unauthorised endpoint. Since the signalling mechanism by which a client requests that the REFER Mechanism be used in sending any referral response has no cryptographic protection, this protocol is vulnerable to downgrade attacks: that is, an on-path attacker could eliminate the RO option from a query or replace a signed REFER RRset in a response with an unsigned NS RRset. The impact of such an attack would be to eliminate any benefits of the REFER Mechanism and revert to the security characteristics of the Standard Mechanism. No new concerns relating to Systems Security [RFC3552] associated with the implementation or use of the REFER Mechanism have been identified. 7. IANA Considerations This section is a placeholder, intended to demonstrate that there is an IANA action here without actually being very thorough about what it should be. For example, both registries below support early assignment by expert review, and if that path is chosen then the Abley Expires August 16, 2021 [Page 11] Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021 requests this document makes of the IANA will be different. No request for code points has been made at this time. The IANA is requested to assign a value to the RRtype described in this document as TBA1 and to add the value to the Resource Record (RR) TYPEs registry as follows: +-------+-------+-------------------------------------+-------------+ | TYPE | Value | Meaning | Reference | +-------+-------+-------------------------------------+-------------+ | REFER | TBA1 | an authoritative name server viewed | (this | | | | from a parent | document) | +-------+-------+-------------------------------------+-------------+ The IANA is requested to assign a value to the EDNS(0) option code described in this document as TBA2 and to add the value to the DNS EDNS0 Option Codes (OPT) registry as follows: +-------+----------+----------+-----------------+ | Value | Name | Status | Reference | +-------+----------+----------+-----------------+ | TBA2 | REFER OK | Optional | (this document) | +-------+----------+----------+-----------------+ 8. Acknowledgements Many people have daydreamed wistfully over the years about the entrenched overloading of the NS RRset in the DNS. At least some of them have done so out loud in bars, although it is entirely possible that they did not realise anybody was listening. 9. References 9.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Abley Expires August 16, 2021 [Page 12] Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . 9.2. Informative References [I-D.fujiwara-dnsop-delegation-information-signer] Fujiwara, K., "Delegation Information (Referrals) Signer for DNSSEC", draft-fujiwara-dnsop-delegation-information- signer-00 (work in progress), November 2020. [I-D.ietf-dnsop-ns-revalidation] Huque, S., Vixie, P., and R. Dolmans, "Delegation Revalidation by DNS Resolvers", draft-ietf-dnsop-ns- revalidation-00 (work in progress), September 2020. [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, DOI 10.17487/RFC3225, December 2001, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [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, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . Appendix A. Editorial Notes This section (and sub-sections) to be removed prior to publication. A.1. Venue for Discussion This is not an IETF working group document. However, at the risk of upsetting the dnsop working group chairs and having to buy them all drinks the next time we have a chance to actually travel to an actual meeting with an actual beer, the dnsop working group mailing list seems like a reasonable place to express fear and loathing at the idea that someone even bothered to write this document. Abley Expires August 16, 2021 [Page 13] Internet-Draft REFER: A New Referral Mechanism for the DNS February 2021 There is no need to suggest that the previous paragraph seems expressly designed to manufacture opportunities for mild, amateur experiments in alcoholism. A.2. Change History 00 Initial draft, circulated for the purposes of entertainment. Author's Address Joe Abley Public Interest Registry 470 Moore Street London, ON N6C 2C2 Canada Email: jabley@pir.org Abley Expires August 16, 2021 [Page 14]