idnits 2.17.1 draft-dnsop-eden-alias-rr-type-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 29, 2017) is 2582 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 1035' is mentioned on line 52, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group A. Eden 3 Internet-Draft DNSimple 4 Intended status: Standards Track March 29, 2017 5 Expires: September 30, 2017 7 Alias RR Type 8 draft-dnsop-eden-alias-rr-type-00 10 Abstract 12 This document describes a new DNS record type, ALIAS, which is used 13 by authoritative name servers to resolve a stored host name to its 14 corresponding A or AAAA records at request time. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 30, 2017. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 1. Introduction 50 1.1. Background and Motivation 52 DNS [RFC 1035] forbids the use of CNAME records on a node with other 53 records. It is common practice for web sites publish content on 54 their second-level domain name, and currently the only standards- 55 compliant way to acheive this is to use A and AAAA records on the 56 zone apex. 58 The challenge with this limitation is that service providers would 59 like to have flexibility over their network addressing but are 60 required to communicate any address changes to all customers and give 61 appropriate time for customers to update their DNS entries to ensure 62 a smooth transition to a new address space. As the number of 63 customers increases for a service provider, this approach becomes 64 increasingly difficult to manage and results in difficulties for both 65 the service provider and their customers. 67 The ALIAS record type (also known as ANAME or flattened CNAME) 68 provides a way for DNS managers to specify a hostname in their DNS 69 records which is then resolved to the correct A or AAAA records at 70 request time. 72 1.2. Terminology 74 "QTYPE" - The query type as defined in [RFC1035] and subsequent DNS 75 RFCs. 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 [RFC2119]. 81 2. The ALIAS Resource Record 83 Its RDATA is comprised of a single field, "target", which contains a 84 fully qualified domain name that MUST be sent in uncompressed form 85 [RFC1035]. The "target" field MUST be present. The presentation 86 format of "target" is that of a domain name [RFC1035]. 88 The presentation format of the RR is as follows: 90 owner ttl class ALIAS target 92 An ALIAS record includes a TTL value that represents the maximum 93 time-to-live for a cached ALIAS record response in a resolver. 95 The ALIAS RDATA wire representation is only used for zone transfers. 97 3. Implementation 99 3.1. Resolution Guidelines 101 Authoritative name servers with support for ALIAS records MUST 102 support both A and AAAA materialization. When an authoritative name 103 server receives a request for a name, and the zone contains an ALIAS 104 record at that location, the authoritative name server MUST respond 105 as follows: 107 The server will respond with one or more A records (for a QTYPE A) or 108 one or more AAAA records (for a QTYPE AAAA) obtained by either: * 109 executing a recursive query for the ALIAS content or, * returning a 110 previously cached response. 112 If the recursive query returns an NXDOMAIN response, then the 113 authoritative name server MUST return an NXDOMAIN response as well. 115 If the recursive query fails, then the server MAY return a cached 116 response as long as the cache value is not older than the specified 117 TTL value. 119 3.2. TTL Calculation 121 As described in section [3.1] the ALIAS is stored with its own TTL 122 value. When an ALIAS is resolved to its corresponding A or AAAA 123 records, the authoritative name server MUST return the TTL from the 124 resolver response. 126 When the authoritative name server uses a cached value, it returns 127 the lower TTL value. 129 3.3. Handling CNAME QTYPE 131 Authoritative name servers that receive a CNAME request at a an ALIAS 132 node should treat the request as a QTYPE A. 134 Authoritative name servers that receive a CNAME request at an ALIAS 135 node MUST treat the request as a QTYPE A. 137 3.4. Handling ANY QTYPE 139 Authoritative name servers that receive an ANY request at an ALIAS 140 node SHOULD respond with any A and AAAA records materialized from the 141 ALIAS record. 143 4. Security Considerations 145 To function properly with DNSSEC-aware resolvers, authoritative name 146 servers MUST sign the materialized records produced by the ALIAS 147 resolution. 149 Implementors MAY either materialize A and AAAA records offline and 150 sign the resulting records at that time, or sign the resulting 151 materialized records at request time. 153 5. Privacy Considerations 155 There are no additional privacy concerns introduced by this document. 157 6. IANA Considerations 159 This document uses a new DNS RR type, ALIAS, whose value must be 160 allocated by IANA from the Resource Record (RR) TYPEs subregistry of 161 the Domain Name System (DNS) Parameters registry. 163 7. Normative References 165 [RFC1035] Mockapetris, P., "Domain names - implementation and 166 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 167 November 1987, . 169 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 170 Requirement Levels", BCP 14, RFC 2119, March 1997. 172 Author's Address 174 Anthony Eden 175 DNSimple 177 Email: anthony.eden@dnsimple.com 178 URI: https://dnsimple.com/