Network Working Group T. Hardie Internet-Draft October 28, 2016 Intended status: Informational Expires: May 1, 2017 Alternative Context Resolution Pointers draft-hardie-arc-pointers-00 Abstract In RFC 2826, the IAB set out the benefits of a globally unique public name space. As alternative contexts of resolution emerge, such as those implied by RFC 7686, maintaining a single namespace for the Internet requires a method to indicate the context of resolution for a name. This document proposes a registry for such alternative resolution contexts as well as a set of pointer resource record types useful for allowing conformant resolvers which query for the name in the DNS to be redirected to the appropriate alternative resolution context. 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 1, 2017. Copyright Notice Copyright (c) 2016 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 (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 Hardie Expires May 1, 2017 [Page 1] Internet-Draft arc-pointers October 2016 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. 1. Introduction RFC 2826[RFC2826] begins "To remain a global network, the Internet requires the existence of a globally unique public name space". At the time it was written, that global name space was expressed almost completely in the DNS, which achieves uniqueness by descent from a single root. As new naming methods have emerged, the distinction between a DNS name and a name in the Internet name space but not in the DNS has been difficult to draw. The Special Use Names registry [RFC6761] has been used to note some alternative name resolution contexts, for example those used by TOR [RFC7686]. This registry is, however, problematic for this use because it permanently links a particular name or label with the resolution method. It is also strongly focused on resolution systems which occupy a place parallel to names in the root zone, creating policy considerations which would not apply to other parts of the Internet name space. This document proposes a set of mechanisms to address the addition of alternative contexts of resolution, with the intent that this be possible at multiple levels of the Internet namespace. 2. Basic Approach This document proposes the creation of a registry for alternative resolution contexts which share the Internet's global name space. Entry into this registry will be specification required, with the IESG as the approver of new entries. This document also proposes the creation of a subdomain under .arpa, arc.arpa. Each label under arc.arpa will have an ARC resource record storing a URN from the IETF protocol parameter registry [RFC3553] that identifies the registry entry for the alternative resolution context. Lastly, this document propose the creation of an ARCPOINTER resource recorder. To indicate that part of the Internet namespace uses an alternative resolution context, an ARCPOINTER resource record is placed at the appropriate label. The ARCPOINTER resource record should be the only resource record for that label other than those needed to secure the entry. Hardie Expires May 1, 2017 [Page 2] Internet-Draft arc-pointers October 2016 A system encountering the name first receives the ARCPOINTER resource record, then retrieves the ARC resource record at the domain name to which the ARCPOINTER record referred, if it does not have a cached entry. The URN present at the ARC record is used as a stable identifier with which to index the name resolver's capabilities, so that it asks the right resolution system to provide answers for the name. If it has no match for the URN, the resolution fails. If it does find a match, it resolves the name by presenting the identifier to the alternative resolution system. This allows alternative resolution contexts to be part of the Internet name space at multiple levels of the hierarchy while still matching the syntax expected by URIs and common Internet protocols like HTTP or SMTP. 3. Example Imagine that a provider of names based on cryptographic identifiers, the Allium Identifiers Foundation, wishes to reference these names as part of the Internet namespace. The provider furnishes a specification of how these names are dereferenced to IANA, which asks the IESG to review. Upon approval, a new entry is created in the registry and a URN, urn:ietf:params:arc:allium, is assigned. Concurrently, a new label, allium.arc.arpa, is created and populated with an ARC resource record containing the URN. If example.com wishes to use Allium identifiers, it can do so by placing an ARCPOINTER record at the label in their portion of the Internet name space below which the identifiers will appear. An ARCPOINTER record at secid.example.com, for example, means that the Internet name 88917287893.secid.example.com should be interpreted as being the Alium identifier 88917287893, and the Alium resolution context consulted rather than the DNS. An ARC-aware resolver presented with 8917287893.secid.example.com will encounter the ARCPOINTER record pointing to allium.arc.arpa upon attempting to iteratively resolve secid.example.com within the DNS. It will then use the ARC record present at allium.arc.arpa to retrieve the URN urn:ietf:params:arc:allium. The ARC-aware resolver will then match its local capabilties against that index value (Note that the ARC records at a label under arc.arpa should be highly cacheable, so it should not need to retrieve these often). If it has an allium-capable resolution method available, it will present the identifier in the form required by that resolution method. In this case, it might present 88917287893 to the allium subsystem for resolution. In other cases, the fully qualified Internet name will be presented to the identified alternative resolution system. Hardie Expires May 1, 2017 [Page 3] Internet-Draft arc-pointers October 2016 4. A note on Indirection There is a layer of indirection in this approach that may or may not be needed. It is possible to avoid creating the ARCPOINTER resource record and dereferencing labels under arc.arpa entirely, simply by placing ARC records at the same label at which this proposal places ARCPOINTER records. This proposal chose this approach in order to ensure that ARC record entries present in the system were drawn from the registered set. For the Internet name space to remain unique in the presence of alternative resolution systems, both elements of the tuple (name, alternative resolution system identifier) must remain unique. This approach is based on the assumption that having a limited set of places to retrieve the identifiers for alternative resolution systems improves the odds that they will not drift over time. Other methods to achieve this, such as configuring ARC-aware resolvers to reject values not beginning with urn:ietf:params:arc, may be equivalent or needed in any case. 5. Applicability There is currently no way to assess the number of systems which are using a portion of the Internet namespace without using DNS resolution, and there is, therefore, an unknown risk of collision as the DNS portion of the namespace grows. Providing a mechanism to permit alternative name resolution to be expressed within the DNS at multiple levels of the hierarchy may mitigate this risk, by allowing the name resolution to start at an arbitrary depth. This approach may also allow for the creation of fairly simple alternative resolution mechanisms. One potential use case is the variant problem. In that use case, a party controls two different identifiers within the Internet namespace and wishes to have them treated as entirely equivalent, so that a resolution request is indifferent to whether or one or the other is used. Within the DNS, this is very difficult to achieve, requiring tight integration at the registries of every level of the namespace involved. It is, however, a very simple alternative resolution. Imagine, for example, that a particular party controls both .colour.example and .color.example and wishes all identifiers using .color.example to be mapped to .colour.example on resolution. By registering an alternative resolution context and placing the appropriate ARCPOINTER and ARC records, that party ensures that any ARC-aware resolver will present names like blue.ismy.favorite.color to an alternative resolution context, which knows to query blue.ismy.favorite.colour and return the answer there. Hardie Expires May 1, 2017 [Page 4] Internet-Draft arc-pointers October 2016 The difficulty with using this for variants is that one answer comes from the DNS and one from an alternative resolution context, so it is not truly a bundled DNS name (even if implemented by consulting the DNS after a transformation). Since the alternative resolution mechanism will have a long road to deployment equivalence with the DNS, this is really only useful when one variant is strongly preferred and the other a permitted alternative. Two equally prefered variants would be hard to assign to a resolution system without implicitly assigning a preference. 6. Indicating support for Alternative Resolution Indicating supporting for alternative resolution is one of the most difficult problems in constructing a multi-resolution system for Internet names, as deployment of end-to-end extensions to the DNS is very difficult. As an initial proposal, this document suggests nodes test for support by sending an EDNS[RFC6891] Option Code of (TBD). A resolver capable of alternative resolution should include this Option when sending requests, unless it has cached information which indicates the Internet name is within the DNS. A responder which understands the option must include the Option in its reply. An authoritative server for a zone containing an ARCPOINTER record must not send that record in a response to a request from a system that does not speak EDNS or does not include the relevant option. Instead, it should send an NXDOMAIN response for any name covered by the ARCPOINTER record. This answers the narrow question: "Is this name in the domain name system?" asked by DNS-only resolvers, rather than the broader question "Is this a known Internet name?" which may be asked by systems aware of alternative resolution mechanism. If an alternative-aware requester is speaking to a responder that does not speak EDNS or does not include this option in a reply, it must treat an NXDOMAIN response as a partial answer to the broader question above and should cache such an answer only as a narrow response; it should not assume that there is no such Internet name in any context. It should cache NSEC-validated negative answers, however, as a zone maintainer for a zone containing an ARCPOINTER would not foster aggressive negative caching for the names covered by an ARCPOINTER. The approach laid out above allows for incremental deployment. It has, however, known failure modes that mean a system aware of alternative resolution systems would likely have to manage uncertainty for a long transition. Sending an ARCPOINTER record as additional data to an NXDOMAIN response might be possible, as the semantics of both responses are true, but support for this approach is harder to gauge. Hardie Expires May 1, 2017 [Page 5] Internet-Draft arc-pointers October 2016 The author invites further discussion of this point. 7. IANA Considerations This memo, if approved, asks IANA to set up a registry for resolution methods, populate URN parameters for those methods, as well as to register two new DNS resource record types and an EDNS Option. It also asks the IAB to create a new subdomain under .arpa, to be named arc.arpa. Registration of a label under arc.arpa will be permitted on creation of a new entry in the registry noted above, with the only permitted resource records being the ARC record along with the records necessary to secure the entry. 7.1. ARC Resource Record =================== TODO: Specify syntax which allows the relevant URNs and, if posible, disallows other options. 7.2. ARCPOINTER Resource Record =================== TODO: Specify syntax which permits a pointer to the relevant name under arc.arpa and, if possible, disallows other pointers. 7.3. ARC EDNS Option ===================== TODO: Specify syntax. 8. Security Considerations This method allows for a different resolution mechanism to replace the standard DNS mechanisms for names in the Internet name space. An attacker capable of redirecting a name into an alternative resolution service will be able to deny name resolution or cause the wrong results to be returned. Because the results must come from a specified alternative resolution service, this does not result in attacker capable of returning completely arbitrary results, but the effect is similar. Hardie Expires May 1, 2017 [Page 6] Internet-Draft arc-pointers October 2016 9. Contributors {Contributors} This document was discussed Warren Kumari, Andrew Sullivan, and Suzanne Wolfe, but all errors are those of the author. 10. References 10.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, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . 10.2. Informative References [RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 2000, . [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 2015, . [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, . [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, . Author's Address Ted Hardie Email: ted.ietf@gmail.com Hardie Expires May 1, 2017 [Page 7]