idnits 2.17.1 draft-ietf-dnsop-aname-01.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. 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 (January 11, 2018) is 2289 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 151, but not defined ** Downref: Normative reference to an Unknown state RFC: RFC 1033 Summary: 2 errors (**), 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: July 15, 2018 PowerDNS 6 A. Eden 7 DNSimple 8 January 11, 2018 10 Address-specific DNS Name Redirection (ANAME) 11 draft-ietf-dnsop-aname-01 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 https://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 July 15, 2018. 38 Copyright Notice 40 Copyright (c) 2018 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 (https://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 . . . . . . . . . . . 5 60 3.2. Coexistence with other types . . . . . . . . . . . . . . 6 61 3.3. DNSSEC signing . . . . . . . . . . . . . . . . . . . . . 6 62 4. Recursive Server Behavior . . . . . . . . . . . . . . . . . . 8 63 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 6. Operational Considerations . . . . . . . . . . . . . . . . . 9 65 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 11.2. Informative References . . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 Websites hosted by content distribution networks are often served by 77 multiple IP addresses handling different geographic areas. In many 78 cases, an initial query for a domain name returns a CNAME record 79 whose is a name served by the CDN, and which ultimately 80 resolves to a different final answer depending on the client's IP 81 address or subnet, geographic location, or other considerations. 83 It is common practice for websites to publish content at their 84 registered domain name (sometimes referred to as a "bare domain" or 85 "zone apex": for example, "example.com" rather than 86 "www.example.com"). However, [RFC1033] forbids the use of CNAME 87 records at the same node as any other record type. Zone apex nodes 88 always contain SOA and NS RRsets, and frequently contain other types 89 such as DNSKEY, MX, TXT/SPF, etc. Consequently, a CNAME record is 90 not permitted at zone apex nodes. 92 It should be noted that [RFC4034] relaxed this restriction by 93 allowing coexistence of CNAME with RRSIG and NSEC records, but such 94 exceptions are not applicable to other resource records. RRSIG and 95 NSEC exist to prove the integrity of the CNAME record; they are not 96 intended to associate arbitrary data with the domain name. 98 DNAME [RFC6672] is also not a solution, as its function is to 99 redirect all names in the namespace below the DNAME , not the 100 DNAME itself. 102 Redirecting website lookups to an alternate domain name via SRV or 103 URI resource records would be an effective solution, but to date this 104 approach has not been accepted by browser implementations. In 105 addition, it is not possible to use SRV records with wildcard names. 107 As a result of the above, the only widely supported and standards- 108 compliant way to publish content at a zone apex is to to place A and/ 109 or AAAA records at that node. The flexibility afforded by CNAME is 110 not available. 112 This document specifies a new RR type "ANAME", which provides similar 113 functionality to CNAME, but only for address queries (i.e., for type 114 A or AAAA). The ANAME record can be present at any DNS node, and can 115 coexist with most other RR types, enabling it to be present at a zone 116 apex, or any other place where the presence of other records prevents 117 the use of CNAME. 119 Authoritative servers configured with ANAME records will answer 120 address queries for the ANAME owner with addresses found at the 121 ANAME's target, and also with the ANAME itself. Recursive resolvers 122 which understand ANAME can re-query for the ANAME target, just as if 123 they had received a CNAME response. Recursive resolvers which do not 124 understand ANAME will ignore the ANAME and consume the provided A/ 125 AAAA records directly. 127 Similar authoritative functionality has been implemented and deployed 128 by a number of DNS software vendors and service providers, using 129 names such as ALIAS, ANAME, apex CNAME, CNAME flattening, and top 130 level redirection. These approaches have all been standards- 131 noncompliant in one way or another, and none have provided a 132 mechanism for a recursive resolver to follow the redirection chain 133 itself. 135 1.1. Terminology 137 "Address type" refers to a DNS RR type that encodes a network 138 address. Currently the set of address types consists of A and AAAA. 139 (This is not an exclusive list; in the event that any new address 140 types are standardized in the future, they will be included.) 142 "Address query" refers to a DNS query for any address type. 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 2. The ANAME Resource Record 150 This document defines the "ANAME" DNS resource record type, with RR 151 TYPE value [TBD]. 153 The ANAME presentation format is identical to that of CNAME 154 [RFC1033]: 156 owner ttl class ANAME target 158 The wire format is also identical to CNAME, except that name 159 compression is not permitted in ANAME RDATA, per [RFC3597]. 161 Only one ANAME can be defined per . An ANAME RRset 162 MUST NOT contain more than one resource record. 164 3. Authoritative Server Behavior 166 When an ANAME record is present at a DNS node and a query is received 167 by an authoritative server for type A or AAAA, the authoritative 168 server returns the ANAME RR in the answer section. 170 Because not all querying resolvers understand ANAME, the 171 authoritative server MUST also return address records, as described 172 below. This is conceptually similar to the synthesized CNAME record 173 included with DNAME responses [RFC6672]. 175 Authoritative servers implementing ANAME MUST be equipped to resolve 176 the ANAME on the querying resolver's behalf, either by 177 sending queries to an external recursive resolver or by implementing 178 recursive resolution logic internally, so that address records can be 179 expanded when the ANAME is in a separate zone from . 181 If a query for the ANAME returns a chaining response (i.e., 182 CNAME, DNAME, or another ANAME), then the authoritative server (or 183 the resolver tasked with resolving the ANAME on its behalf) 184 MUST attempt to follow the chain until it is able to resolve a final 185 address response, or until resolution fails. Intermediate ANAMEs, 186 CNAMEs, and DNAMEs MUST be omitted from the response. 188 3.1. Address records returned with ANAME 190 If the original query is for type A, and an RRset of type A exists at 191 the final ANAME , then that A RRset (with changed to 192 match that of the ANAME RR), MUST be appended to the answer section 193 after the ANAME RRset. If an AAAA RRset is also known to exist at 194 the ANAME , then the AAAA RRset MAY be appended to the 195 additional section (again, with changed to match that of the 196 ANAME RR). 198 Similarly, if the original query was for type AAAA, and an AAAA RRset 199 exists at the final ANAME , then it is appended to the answer 200 section (with changed), and if an A RRset also exists at the 201 final ANAME then it MAY be appended to the additional 202 section. 204 If the original query is for type ANAME, A and AAAA records MAY be 205 returned in the additional section. 207 If the original query is for type ANY and access to ANY query 208 processing is not restricted, then the answer section MUST contain 209 both the ANAME and the A and AAAA RRsets, if present and successfully 210 resolved at the ANAME . 212 How and when an authoritative server resolves the A and AAAA 213 responses from the ANAME (when it is not itself 214 authoritative for ) is unspecified. If the authoritative 215 server is capable of performing recursive resolution, then it MAY 216 resolve the query itself, or it MAY send address queries to an 217 external resolver. It MAY send address queries to the ANAME 218 when loading the zone and cache the responses locally, or it MAY 219 delay resolution of the address records until a query is received for 220 the ANAME . In either case, for performance reasons, it is 221 RECOMMENDED that address records be cached locally by the 222 authoritative server. 224 Address records cached locally MUST have a limited TTL. The initial 225 TTL for locally-cached address records MUST be set to the minimum of 226 the ANAME TTL and the TTLs of the intermediate and address records 227 retrieved during ANAME <> resolution. The TTL of the cached address 228 records MUST count down, just as it would in a conventional resolver 229 cache. Address records with expired TTLs MUST NOT be used to answer 230 address queries until refreshed by sending a new query to the ANAME 231 . 233 If configured to do so, then the authoritative server MAY, when 234 sending queries to the ANAME , include an EDNS CLIENT-SUBNET 235 (ECS) option [RFC7871], either forwarding an ECS option that was sent 236 to it by the querying resolver, or generating a new ECS option from 237 the querying resolver's address. If a response from the ANAME 238 includes an ECS option with a SCOPE PREFIX-LENGTH greater 239 than zero, the response SHOULD be cached in such a way that it would 240 subsequently only be used in response to queries from the same client 241 subnet. 243 If resolution of the ANAME yields no address records due to 244 NODATA or NXDOMAIN, then the authoritative server MUST return only 245 the ANAME record. If the query was for a specific address type, then 246 the response MUST also include the SOA as in a normal NODATA 247 response, along with NSEC or NSEC3 if applicable. 249 If resolution of the ANAME yields no address records due to 250 some other failure, and the query was for a specific address type, 251 the response MUST include the ANAME record and set the RCODE to 252 SERVFAIL. 254 3.2. Coexistence with other types 256 If the zone is configured with an A or AAAA RRset at the same DNS 257 node as ANAME, then the ANAME is considered to have already been 258 expanded. If during query processing any address records are found 259 at the same node as an ANAME RR, then the ANAME RR MUST NOT be 260 further expanded by the authoritative server. 262 ANAME MUST NOT coexist with CNAME or any other RR type that restricts 263 the types with which it can itself coexist. 265 Like other types, ANAME MUST NOT exist below a DNAME, but it can 266 coexist at the same node; in fact, the two can be used cooperatively 267 to redirect both the owner name (via ANAME) and everything under it 268 (via DNAME). 270 ANAME can freely coexist at the same owner name with any other RR 271 type. 273 3.3. DNSSEC signing 275 If the zone in which the ANAME resides is DNSSEC-signed, and if the 276 server has access to its private zone-signing key, then the A and 277 AAAA RRsets MUST be signed, either in advance when populating the A/ 278 AAAA answers for the ANAME records, or "on the fly" when responding 279 to a query. 281 If the server does not have access to the private zone-signing key 282 then it MAY return unsigned address records, but this is NOT 283 RECOMMENDED unless every resolver with access to the zone is known to 284 support ANAME (as might be the case in a split-horizon deployment 285 where ANAME records are only served to an internal network with its 286 own resolvers). 288 Validating resolvers which do not yet implement ANAME will not be 289 able to validate the A and AAAA responses included with an ANAME 290 response unless those responses are validly signed by a DNSKEY at the 291 apex of the zone in which the ANAME resides. Passing along the 292 RRSIGs associated with the original A and AAAA RRsets from the ANAME 293 will not be sufficient for DNSSEC validation. 295 Implementers MAY allow address records associated with the ANAME to 296 be populated and signed by the primary server, then sent along with 297 their RRSIGs to secondaries via zone transfer. In this case, the 298 master server MUST respect the TTLs of the address records, MUST 299 refresh the address records by re-resolving the ANAME when 300 their TTLs expire, SHOULD respond to address queries with TTLs that 301 count down as they would when answering from a normal DNS cache, and 302 MUST inform secondary servers via DNS NOTIFY they need to refresh the 303 zone when address records have been updated. A secondary server 304 SHOULD store address records and associated RRSIGs supplied via zone 305 transfer in such a way that their TTLs will count down, as they would 306 in a normal DNS cache, and ultimately trigger a zone refresh query 307 upon reaching zero. When a secondary server is responding to an 308 address query, it SHOULD answer with the reduced TTL, but when 309 responding to a zone transfer request, it MUST answer with the 310 original TTL received from the primary. 312 If this address record expansion and signing during zone transfer is 313 not supported, then every authoritative server providing ANAME 314 responses in a signed zone SHOULD have access to the private zone- 315 signing key for that zone. Deployment of ANAME in signed zones where 316 address records cannot be signed due to lack of access to the private 317 zone-signing key is NOT RECOMMENDED. 319 When ANAME is present in a signed DNS node and address records exist 320 at the ANAME , the type bit map in the NSEC [RFC4034] or 321 NSEC3 [RFC5155] record for that node MUST include bits for A and/or 322 AAAA as well as ANAME. This is for the benefit of validating 323 resolvers not implementing ANAME which may use a signed proof of 324 nonexistence for type A and AAAA to prevent address queries from 325 being resolved. The type bit map SHOULD only include address types 326 which are known to exist at the . 328 4. Recursive Server Behavior 330 When a recursive resolver sends a query of type A or AAAA and 331 receives a response with an ANAME RRset in the answer section, it 332 MUST re-query for the ANAME . This is necessary because, in 333 some cases, the address received will be dependent on network 334 topology and other considerations, and the resolver may find a 335 different answer than the authoritative server did. (This 336 requirement MAY be relaxed if both the ANAME and are 337 validly signed and provably in the same zone.) 339 If resolution fails -- for example, due to the local resolver being 340 nonfunctional or the ANAME zone being unreachable -- then 341 the resolver MAY use the address records that were included in the 342 authoritative response as a fallback. Otherwise, these records MUST 343 NOT be cached or returned. 345 If configured to do so, the resolver MAY include an EDNS CLIENT- 346 SUBNET option [RFC7871] both when sending the initial query to the 347 ANAME and when re-querying for the ANAME . If the 348 response includes a SCOPE PREFIX-LENGTH greater than zero, the 349 response SHOULD be cached in such a way that it would subsequently 350 only be used in response to queries from the same client subnet. 352 5. Examples 354 Given the following zone: 356 $ORIGIN example.com. 357 @ IN SOA example.com hostmaster.example.com 1 7200 600 1209600 60 358 @ IN NS ns1 359 @ IN ANAME example.com.my-cdn.example.net. 360 www IN CNAME example.com.my-cdn.example.net. 362 A query for example.com/A would return the following: 364 ;; QUESTION SECTION: 365 ;example.com. IN A 367 ;; ANSWER SECTION: 368 example.com. 5 IN ANAME example.com.my-cdn.example.net. 369 example.com. 5 IN A 192.0.2.1 371 ;; ADDITIONAL SECTION: 372 example.com. 5 IN AAAA 2001:db8::1 374 Similarly, for example.com/AAAA: 376 ;; QUESTION SECTION: 377 ;example.com. IN AAAA 379 ;; ANSWER SECTION: 380 example.com. 5 IN ANAME example.com.my-cdn.example.net. 381 example.com. 5 IN AAAA 2001:db8::1 383 ;; ADDITIONAL SECTION: 384 example.com. 5 IN A 192.0.2.1 386 A query for example.com/AANME would receive only the ANAME in the 387 answer section, with the addresses for example.com.my-cdn.example.net 388 expanded in the additional section: 390 ;; QUESTION SECTION: 391 ;example.com. IN ANAME 393 ;; ANSWER SECTION: 394 example.com. 5 IN ANAME example.com.my-cdn.example.net. 396 ;; ADDITIONAL SECTION: 397 example.com.my-cdn.example.net. 5 IN A 192.0.2.1 398 example.com.my-cdn.example.net. 5 IN AAAA 2001:db8::1 400 Meanwhile, a query for a non-address type would be returned normally: 402 ;; QUESTION SECTION: 403 ;example.com. IN NS 405 ;; ANSWER SECTION: 406 example.com. 5 IN NS ns1.example.com. 408 6. Operational Considerations 410 When a zone containing ANAME records is transferred to a secondary 411 server, the ANAME records are transferred, but the A or AAAA records 412 retrieved from the ANAME may not be. If the primary server 413 implements ANAME but the secondary server does not, then the two will 414 return different answers for address queries. It is therefore 415 RECOMMENDED that ANAME not be deployed in a zone unless all of the 416 authoritative servers for that zone implement ANAME, or the primary 417 is able to expand the ANAME with the related address RRsets during 418 the zone transfer. 420 7. Implementation Status 422 PowerDNS currently implements a similar 423 authoritative-only feature using "ALIAS" records, which are expanded 424 by the primary server and transfered as address records to 425 secondaries. 427 [TODO: Add discussion of DNSimple, DNS Made Easy, EasyDNS, 428 Cloudflare, Amazon, and Akamai.] 430 8. Security Considerations 432 An authoritative server which implements ANAME resolves address 433 queries on behalf of its clients, either internally or by querying an 434 external resolver. This resolution must be allowed to take place 435 regardless of whether the client would ordinarily have been permitted 436 by local policy to send recursive queries. 438 When a resolver that does not understand ANAME receives a response 439 containing A or AAAA records with rewritten to match that of 440 the ANAME RR, this may bypass security mechanisms based on local 441 policy limiting access to the original ANAME . One possible 442 mitigation for this is to make sure the resolver being used during 443 ANAME resolution lives outside of such critical network sections. 445 If ANAME is used in a signed zone, validating resolvers that do not 446 understand ANAME will not be able to valudate the A and AAAA records 447 included in the response, unless the responding server has added 448 signatures for those records. Merely passing along signatures from 449 the is not sufficient. An authoritative server hosting a 450 secure domain that includes ANAME SHOULD therefore have access to the 451 private zone-signing key for that domain; otherwise, the operator 452 must accept that validation failures will be common until ANAME is 453 widly deployed. 455 Both authoritative servers and resolvers that implement ANAME SHOULD 456 carefully check for loops and treat them as an error condition. One 457 possible approach is to implement a hop counter and stop resolution 458 when a maximum hop count is reached. 460 An authoritative resolver returning address records which were 461 obtained by resolving the ANAME is supplying its own best 462 information to clients as to the correct answer. The response may be 463 signed by the authoritative server, but that is not a guarantee of 464 the actual correctness of the answer. This can have the effect of 465 promoting an insecure response from the ANAME to a signed 466 response from the , which may then appear to clients to be 467 more trustworthy than it should. To mitigate harm from this, DNSSEC 468 validation SHOULD be used when resolving the ANAME . 469 Authoritative servers MAY refuse to expand ANAME records unless the 470 node is both signed and validated. 472 9. IANA Considerations 474 IANA is requested to assign a DNS RR data type value for the ANAME RR 475 type under the "Resource Record (RR) TYPEs" subregistry under the 476 "Domain Name System (DNS) Parameters" registry. 478 IANA may wish to consider the creation of a registry of address 479 types; addition of new types to such a registry would then implicitly 480 update this specification. 482 10. Acknowledgments 484 Thanks to Mukund Sivaraman, Stephen Morris, Ray Bellis, Mark Andrews, 485 Richard Salts, Job Snijders, Richard Gibson, Hakan Lindqvist, Jan 486 Vcelak, Tatuya JINMEI, and Tony Finch for discussion and feedback. 488 11. References 490 11.1. Normative References 492 [RFC1033] Lottor, M., "Domain administrators operations guide", 493 RFC 1033, November 1987. 495 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 496 (RR) Types", RFC 3597, September 2003. 498 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 499 Rose, "Resource Records for the DNS Security Extensions", 500 RFC 4034, March 2005. 502 11.2. Informative References 504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", BCP 14, RFC 2119, March 1997. 507 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 508 Security (DNSSEC) Hashed Authenticated Denial of 509 Existence", RFC 5155, March 2008. 511 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 512 DNS", RFC 6672, June 2012. 514 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 515 Kumari, "Client Subnet in DNS Queries", RFC 7871, 516 DOI 10.17487/RFC7871, May 2016, 517 . 519 Authors' Addresses 521 Evan Hunt 522 ISC 523 950 Charter St 524 Redwood City, CA 94063 525 USA 527 Email: each@isc.org 529 Peter van Dijk 530 PowerDNS.COM B.V. 531 Den Haag 532 The Netherlands 534 Email: peter.van.dijk@powerdns.com 536 Anthony Eden 537 DNSimple 538 Boston, MA 539 USA 541 Email: anthony.eden@dnsimple.com 542 URI: https://dnsimple.com/