idnits 2.17.1 draft-ietf-dnsop-aname-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 seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (May 24, 2017) is 2529 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: 'TBD' is mentioned on line 145, but not defined ** Downref: Normative reference to an Unknown state RFC: RFC 1033 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Hunt 3 Internet-Draft ISC 4 Intended status: Standards Track P. van Dijk 5 Expires: November 25, 2017 PowerDNS 6 A. Eden 7 DNSimple 8 May 24, 2017 10 Address-specific DNS Name Redirection (ANAME) 11 draft-ietf-dnsop-aname-00 13 Abstract 15 This document defines the "ANAME" DNS RR type, to provide similar 16 functionality to CNAME, but only redirects type A and AAAA queries. 17 Unlike CNAME, an ANAME can coexist with other record types. The 18 ANAME RR allows zone owners to redirect queries for apex domain names 19 in a standards compliant manner. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 25, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. The ANAME Resource Record . . . . . . . . . . . . . . . . . . 4 58 3. Authoritative Server Behavior . . . . . . . . . . . . . . . . 4 59 3.1. Address records returned with ANAME . . . . . . . . . . . 4 60 3.2. Coexistence with other types . . . . . . . . . . . . . . 6 61 3.3. DNSSEC signing . . . . . . . . . . . . . . . . . . . . . 6 62 4. Recursive Server Behavior . . . . . . . . . . . . . . . . . . 7 63 5. Operational Considerations . . . . . . . . . . . . . . . . . 8 64 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 10.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 Websites hosted by content distribution networks are often served by 76 multiple IP addresses handling different geographic areas. In many 77 cases, an initial query for a domain name returns a CNAME record 78 whose is a name served by the CDN, and which ultimately 79 resolves to a different final answer depending on the client's IP 80 address or subnet, geographic location, or other considerations. 82 It is common practice for websites to publish content at their 83 registered domain name (sometimes referred to as a "bare domain" or 84 "zone apex": for example, "example.com" rather than 85 "www.example.com"). However, [RFC1033] forbids the use of CNAME 86 records at the same node as any other record type. Zone apex nodes 87 always contain SOA and NS RRsets, and frequently contain other types 88 such as DNSKEY, MX, TXT/SPF, etc. Consequently, a CNAME record is 89 not permitted at zone apex nodes. 91 It should be noted that [RFC4034] relaxed this restriction by 92 allowing coexistence of CNAME with RRSIG and NSEC records, but such 93 exceptions are not applicable to other resource records. RRSIG and 94 NSEC exist to prove the integrity of the CNAME record; they are not 95 intended to associate arbitrary data with the domain name. 97 DNAME [RFC6672] is also not a solution, as its function is to 98 redirect all names in the namespace below the DNAME , not the 99 DNAME itself. 101 Redirecting website lookups to an alternate domain name via SRV or 102 URI resource records would be an effective solution, but to date this 103 approach has not been accepted by browser implementations. In 104 addition, it is not possible to use SRV records with wildcard names. 106 As a result of the above, the only widely supported and standards- 107 compliant way to publish content at a zone apex is to to place A and/ 108 or AAAA records at that node. The flexibility afforded by CNAME is 109 not available. 111 This document specifies a new RR type "ANAME", which provides similar 112 functionality to CNAME, but only for address queries (i.e., for type 113 A or AAAA). The ANAME record can be present at any DNS node, and can 114 coexist with most other RR types, enabling it to be present at a zone 115 apex. Authoritative servers configured with ANAME records will 116 answer address queries for the ANAME owner with addresses found at 117 the ANAME's target, and also with the ANAME itself. Recursive 118 resolvers which understand ANAME can re-query for the ANAME target, 119 just as if they had received a CNAME response. Recursive resolvers 120 which do not understand ANAME will ignore the ANAME and consume the 121 provided A/AAAA records directly. 123 Similar authoritative functionality has been implemented and deployed 124 by a number of DNS software vendors and service providers, using 125 names such as ALIAS, ANAME, apex CNAME, CNAME flattening, and top 126 level redirection. These approaches have all been standards- 127 noncompliant in one way or another, and none have provided a 128 mechanism for a recursive resolver to follow the redirection chain 129 itself. 131 1.1. Terminology 133 "Address type" refers to a DNS RR type that encodes a network 134 address. Currently the set of address types consists of A and AAAA. 136 "Address query" refers to a DNS query for any address type. 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 2. The ANAME Resource Record 144 This document defines the "ANAME" DNS resource record type, with RR 145 TYPE value [TBD]. 147 The ANAME presentation format is identical to that of CNAME 148 [RFC1033]: 150 owner ttl class ANAME target 152 The wire format is also identical to CNAME, except that name 153 compression is not permitted in ANAME RDATA, per [RFC3597]. 155 No more than one ANAME resource record SHALL be present at any DNS 156 node. 158 3. Authoritative Server Behavior 160 When an ANAME record is present at a DNS node and a query is received 161 by an authoritative server for type A or AAAA, the authoritative 162 server returns the ANAME RR in the answer section. 164 Because not all querying resolvers understand ANAME, the 165 authoritative server MUST also return address records, as described 166 below. This is conceptually similar to the synthesized CNAME record 167 included with DNAME responses [RFC6672]. 169 Authoritative servers implementing ANAME MUST be equipped to resolve 170 the ANAME on the querying resolver's behalf, either by 171 sending queries to an external recursive resolver or by implementing 172 recursive resolution logic internally, so that address records can be 173 expanded when the ANAME is in a separate zone from . 175 If a query for the ANAME returns a chaining response (i.e., 176 CNAME, DNAME, or another ANAME), then the authoritative server (or 177 the resolver tasked with resolving the ANAME on its behalf) 178 MUST attempt to follow the chain until it is able to resolve a final 179 address response, or until resolution fails. Intermediate ANAMEs, 180 CNAMEs, and DNAMEs MUST be omitted from the response. 182 3.1. Address records returned with ANAME 184 If the original query is for type A, and an RRset of type A exists at 185 the final ANAME , then that A RRset (with changed to 186 match that of the ANAME RR), MUST be appended to the answer section 187 after the ANAME RRset. If an AAAA RRset is also known to exist at 188 the ANAME , then the AAAA RRset MAY be appended to the 189 additional section (again, with changed to match that of the 190 ANAME RR). 192 Similarly, if the original query was for type AAAA, and an AAAA RRset 193 exists at the final ANAME , then it is appended to the answer 194 section (with changed), and if an A RRset also exists at the 195 final ANAME then it MAY be appended to the additional 196 section. 198 If the original query is for type ANAME, A and AAAA records MAY be 199 returned in the additional section. 201 If the original query is for type ANY and access to ANY query 202 processing is not restricted, then the answer section MUST contain 203 both the ANAME and the A and AAAA RRsets, if present and successfully 204 resolved at the ANAME . 206 How and when an authoritative server resolves the A and AAAA 207 responses from the ANAME (when it is not itself 208 authoritative for ) is unspecified. If the authoritative 209 server is capable of performing recursive resolution, then it MAY 210 resolve the query itself, or it MAY send address queries to an 211 external resolver. It MAY send address queries to the ANAME 212 when loading the zone and cache the responses locally, or it MAY 213 delay resolution of the address records until a query is received for 214 the ANAME . In either case, for performance reasons, it is 215 RECOMMENDED that address records be cached locally by the 216 authoritative server. 218 Address records cached locally MUST have a limited TTL. The initial 219 TTL for locally-cached address records MUST be set to the lesser of 220 the ANAME TTL and the TTL of the address records retrieved from the 221 ANAME . The local TTL MUST count down, just as it would in a 222 conventional resolver cache. Records with an expired TTL MUST NOT be 223 used to answer address queries until refreshed with a new query to 224 the ANAME . 226 If configured to do so, then the authoritative server MAY, when 227 sending queries to the ANAME , include an EDNS CLIENT-SUBNET 228 (ECS) option [RFC7871], either forwarding an ECS option that was sent 229 to it by the querying resolver, or generating a new ECS option from 230 the querying resolver's address. If a response from the ANAME 231 includes an ECS option with a SCOPE PREFIX-LENGTH greater 232 than zero, the response SHOULD be cached with the ECS data and should 233 only be used in response to queries from the same client subnet. 235 3.2. Coexistence with other types 237 If the zone is configured with an A or AAAA RRset at the same DNS 238 node as ANAME, then the ANAME is considered to have been pre-expanded 239 for zone transfer purposes. When a zone is being transferred to a 240 secondary server, if any address record already exists at the same 241 node as an ANAME RR, then the ANAME RR MUST NOT be further expanded 242 by the authoritative server. 244 ANAME MUST NOT coexist with CNAME or any other RR type that restricts 245 the types with which it can itself coexist. 247 Like other types, ANAME MUST NOT exist below a DNAME, but it can 248 coexist at the same node; in fact, the two can be used cooperatively 249 to redirect both the owner name (via ANAME) and everything under it 250 (via DNAME). 252 ANAME can freely coexist at the same owner name with any other RR 253 type. 255 3.3. DNSSEC signing 257 If the zone in which the ANAME resides is DNSSEC-signed, and if the 258 server has access to its private zone-signing key, then the A and 259 AAAA RRsets MUST be signed, either in advance when populating the A/ 260 AAAA answers for the ANAME records, or "on the fly" when responding 261 to a query. 263 If the server does not have access to the private zone-signing key 264 then it MAY return unsigned address records, but this is NOT 265 RECOMMENDED unless every resolver with access to the zone is known to 266 support ANAME (as might be the case in a split-horizon deployment 267 where ANAME records are only served to an internal network with its 268 own resolvers). 270 Validating resolvers which do not yet implement ANAME will not be 271 able to validate the A and AAAA responses included with an ANAME 272 response unless those responses are validly signed by a DNSKEY at the 273 apex of the zone in which the ANAME resides. Passing along the 274 RRSIGs associated with the original A and AAAA RRsets from the ANAME 275 will not be sufficient for DNSSEC validation. 277 Implementers MAY allow address records associated with the ANAME to 278 be populated and signed by the primary server, then sent along with 279 their RRSIGs to secondaries via zone transfer. In this case, the 280 master server MUST respect the TTLs of the address records, MUST 281 refresh the address records by re-resolving the ANAME when 282 their TTLs expire, SHOULD respond to address queries with TTLs that 283 count down as they would when answering from a normal DNS cache, and 284 MUST inform secondary servers via DNS NOTIFY they need to refresh the 285 zone when address records have been updated. A secondary server 286 SHOULD store address records and associated RRSIGs supplied via zone 287 transfer in such a way that their TTLs will count down, as they would 288 in a normal DNS cache, and ultimately trigger a zone refresh query 289 upon reaching zero. When a secondary server is responding to an 290 address query, it SHOULD answer with the reduced TTL, but when 291 responding to a zone transfer request, it MUST answer with the 292 original TTL received from the primary. 294 If this address record expansion and signing during zone transfer is 295 not supported, then every authoritative server providing ANAME 296 responses in a signed zone SHOULD have access to the private zone- 297 signing key for that zone. Deployment of ANAME in signed zones where 298 address records cannot be signed due to lack of access to the private 299 zone-signing key is NOT RECOMMENDED. 301 When ANAME is present in a signed DNS node and address records exist 302 at the ANAME , the type bit map in the NSEC [RFC4034] or 303 NSEC3 [RFC5155] record for that node MUST include bits for A and/or 304 AAAA as well as ANAME. This is for the benefit of validating 305 resolvers not implementing ANAME which may use a signed proof of 306 nonexistence for type A and AAAA to prevent address queries from 307 being resolved. The type bit map SHOULD only include address types 308 which are known to exist at the . 310 4. Recursive Server Behavior 312 When a recursive resolver sends a query of type A or AAAA and 313 receives a response with an ANAME RRset in the answer section, it 314 MUST re-query for the ANAME . This is necessary because, in 315 some cases, the address received will be dependent on network 316 topology and other considerations, and the resolver may find a 317 different answer than the authoritative server did. (This 318 requirement MAY be relaxed if both the ANAME and are 319 validly signed and provably in the same zone.) 321 If resolution fails -- for example, due to the local resolver being 322 nonfunctional or the ANAME zone being unreachable -- then 323 the resolver MAY use the address records that were included in the 324 authoritative response as a fallback. Otherwise, these records MUST 325 NOT be cached or returned. 327 If configured to do so, the resolver MAY include an EDNS CLIENT- 328 SUBNET option [RFC7871] both when sending the initial query to the 329 ANAME and when re-querying for the ANAME . If the 330 response includes a SCOPE PREFIX-LENGTH greater than zero, the 331 response SHOULD be cached with the ECS data and should only be used 332 in response to queries from the same client subnet. 334 5. Operational Considerations 336 When a zone containing ANAME records is transferred to a secondary 337 server, the ANAME records are transferred, but the A or AAAA records 338 retrieved from the ANAME may not be. If the primary server 339 implements ANAME but the secondary server does not, then the two will 340 return different answers for address queries. It is therefore 341 RECOMMENDED that ANAME not be deployed in a zone unless all of the 342 authoritative servers for that zone implement ANAME, or the primary 343 is able to expand the ANAME with the related address RRsets during 344 the zone transfer. 346 6. Implementation Status 348 PowerDNS currently implements a similar 349 authoritative-only feature using "ALIAS" records, which are expanded 350 by the primary server and transfered as address records to 351 secondaries. 353 [TODO: Add discussion of DNSimple, DNS Made Easy, EasyDNS, 354 Cloudflare, and Akamai.] 356 7. Security Considerations 358 An authoritative server which implements ANAME resolves address 359 queries on behalf of its clients, either internally or by querying an 360 external resolver. This resolution must be allowed to take place 361 regardless of whether the client would ordinarily have been permitted 362 by local policy to send recursive queries. 364 When a resolver that does not understand ANAME receives a response 365 containing A or AAAA records with rewritten to match that of 366 the ANAME RR, this may bypass security mechanisms based on local 367 policy limiting access to the original ANAME . 369 A validating resolver that does not understand ANAME will not be able 370 to validate A and AAAA records unless they are signed. 372 Both authoritative servers and resolvers that implement ANAME should 373 carefully check for loops and treat them as an error condition. 375 8. IANA Considerations 377 IANA is requested to assign a DNS RR data type value for the ANAME RR 378 type under the "Resource Record (RR) TYPEs" subregistry under the 379 "Domain Name System (DNS) Parameters" registry. 381 9. Acknowledgments 383 Thanks to Mukund Sivaraman, Stephen Morris, Ray Bellis, Mark Andrews, 384 Richard Salts, Job Snijders, and Hakan Lindqvist for discussion and 385 feedback. 387 10. References 389 10.1. Normative References 391 [RFC1033] Lottor, M., "Domain administrators operations guide", 392 RFC 1033, November 1987. 394 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 395 (RR) Types", RFC 3597, September 2003. 397 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 398 Rose, "Resource Records for the DNS Security Extensions", 399 RFC 4034, March 2005. 401 10.2. Informative References 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, March 1997. 406 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 407 Security (DNSSEC) Hashed Authenticated Denial of 408 Existence", RFC 5155, March 2008. 410 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 411 DNS", RFC 6672, June 2012. 413 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 414 Kumari, "Client Subnet in DNS Queries", RFC 7871, 415 DOI 10.17487/RFC7871, May 2016, 416 . 418 Authors' Addresses 419 Evan Hunt 420 ISC 421 950 Charter St 422 Redwood City, CA 94063 423 USA 425 Email: each@isc.org 427 Peter van Dijk 428 PowerDNS.COM B.V. 429 Den Haag 430 The Netherlands 432 Email: peter.van.dijk@powerdns.com 434 Anthony Eden 435 DNSimple 436 Boston, MA 437 USA 439 Email: anthony.eden@dnsimple.com 440 URI: https://dnsimple.com/