idnits 2.17.1 draft-ietf-dnsop-aname-04.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 950 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 8, 2019) is 1726 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 216, but not defined -- Looks like a reference, but probably isn't: '1' on line 629 -- Looks like a reference, but probably isn't: '2' on line 631 ** Downref: Normative reference to an Unknown state RFC: RFC 1033 ** Downref: Normative reference to an Informational RFC: RFC 7871 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) -- Obsolete informational reference (is this intentional?): RFC 882 (Obsoleted by RFC 1034, RFC 1035) -- Obsolete informational reference (is this intentional?): RFC 973 (Obsoleted by RFC 1034, RFC 1035) -- Obsolete informational reference (is this intentional?): RFC 2065 (Obsoleted by RFC 2535) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Operations T. Finch 3 Internet-Draft University of Cambridge 4 Intended status: Standards Track E. Hunt 5 Expires: January 9, 2020 ISC 6 P. van Dijk 7 PowerDNS 8 A. Eden 9 DNSimple 10 W. Mekking 11 ISC 12 July 8, 2019 14 Address-specific DNS aliases (ANAME) 15 draft-ietf-dnsop-aname-04 17 Abstract 19 This document defines the "ANAME" DNS RR type, to provide similar 20 functionality to CNAME, but only for address queries. Unlike CNAME, 21 an ANAME can coexist with other record types. The ANAME RR allows 22 zone owners to make an apex domain name into an alias in a standards 23 compliant manner. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 9, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction 60 1.1. Overview 61 1.2. Terminology 62 2. The ANAME resource record 63 2.1. Presentation and wire format 64 2.2. Coexistence with other types 65 3. Substituting ANAME sibling address records 66 4. ANAME processing by primary masters 67 4.1. Zone transfers 68 4.2. DNSSEC 69 4.3. TTLs 70 5. ANAME processing by resolvers 71 6. Query processing 72 6.1. Authoritative servers 73 6.1.1. Address queries 74 6.1.2. ANAME queries 75 6.2. Resolvers 76 6.2.1. Address queries 77 6.2.2. ANAME queries 78 7. IANA considerations 79 8. Security considerations 80 9. Acknowledgments 81 10. Changes since the last revision 82 10.1. Version -04 83 10.2. Version -03 84 10.3. Version -02 85 11. References 86 11.1. Normative References 87 11.2. Informative References 88 11.3. URIs 89 Appendix A. Implementation status 90 Appendix B. Historical note 91 Appendix C. On preserving TTLs 92 C.1. Query bunching 93 C.2. Upstream caches 94 C.3. ANAME chains 95 C.4. ANAME substitution inside the name server 96 C.5. TTLs and zone transfers 97 Appendix D. Alternative setups 98 D.1. Reducing query volume 99 D.2. Zone transfer scalability 100 D.3. Tailored responses 101 Appendix E. ANAME loops 102 Authors' Addresses 104 1. Introduction 106 It can be desirable to provide web sites (and other services) at a 107 bare domain name (such as "example.com") as well as a service- 108 specific subdomain ("www.example.com"). 110 If the web site is hosted by a third-party provider, the ideal way to 111 provision its name in the DNS is using a CNAME record, so that the 112 third party provider retains control over the mapping from names to 113 IP address(es). It is now common for name-to-address mappings to be 114 highly dynamic, dependent on client location, server load, etc. 116 However, CNAME records cannot coexist with other records with the 117 same owner name. (The reason why is explored in Appendix B). This 118 restriction means they cannot appear at a zone apex (such as 119 "example.com") because of the SOA, NS, and other records that have to 120 be present there. CNAME records can also conflict at subdomains, for 121 example, if "department.example.edu" has separately hosted mail and 122 web servers. 124 Redirecting website lookups to an alternate domain name via SRV or 125 URI resource records would be an effective solution from the DNS 126 point of view, but to date, browser vendors have not accepted this 127 approach. 129 As a result, the only widely supported and standards-compliant way to 130 publish a web site at a bare domain is to place address records (A 131 and/or AAAA) at the zone apex. The flexibility afforded by CNAME is 132 not available. 134 This document specifies a new RR type "ANAME", which provides similar 135 functionality to CNAME, but only for address queries (i.e., for type 136 A or AAAA). The basic idea is that the address records next to an 137 ANAME record are automatically copied from and kept in sync with the 138 ANAME target's address records. The ANAME record can be present at 139 any DNS node, and can coexist with most other RR types, enabling it 140 to be present at a zone apex, or any other name where the presence of 141 other records prevents the use of a CNAME record. 143 Similar authoritative functionality has been implemented and deployed 144 by a number of DNS software vendors and service providers, using 145 names such as ALIAS, ANAME, apex CNAME, CNAME flattening, and top- 146 level redirection. These mechanisms are proprietary, which hinders 147 the ability of zone owners to have the same data served from multiple 148 providers or to move from one provider to another. None of these 149 proprietary implementations includes a mechanism for resolvers to 150 follow the redirection chain themselves. 152 1.1. Overview 154 The core functionality of this mechanism allows zone administrators 155 to start using ANAME records unilaterally, without requiring 156 secondary servers or resolvers to be upgraded. 158 o The resource record definition in Section 2 is intended to provide 159 zone data portability between standards-compliant DNS servers and 160 the common core functionality of existing proprietary ANAME-like 161 facilities. 163 o The zone maintenance mechanism described in Section 4 keeps the 164 ANAME's sibling address records in sync with the ANAME target. 166 This definition is enough to be useful by itself. However, it can be 167 less than optimal in certain situations: for instance, when the ANAME 168 target uses clever tricks to provide different answers to different 169 clients to improve latency or load balancing. The query processing 170 rules in Section 6 require to include the ANAME record so that 171 resolvers can use this information (as described in Section 5) to 172 obtain answers that are tailored to the resolver rather than to the 173 zone's primary master. 175 Resolver support for ANAME is not necessary, since ANAME-oblivious 176 resolvers can get working answers from authoritative servers. It's 177 just an optimization that can be rolled out incrementally, and that 178 will help ANAME to work better the more widely it is deployed. 180 1.2. Terminology 182 An "address record" is a DNS resource record whose type is A or AAAA. 183 These are referred to as "address types". "Address query" refers to 184 a DNS query for any address type. 186 When talking about "address records" we mean the entire RRset, 187 including owner name and TTL. We treat missing address records (i.e. 188 NXDOMAIN or NODATA) the same successfully resolving as a set of zero 189 address records, and distinct from "failure" which covers error 190 responses such as SERVFAIL or REFUSED. 192 The "sibling address records" of an ANAME record are the address 193 records at the same owner name as the ANAME, which are subject to 194 ANAME substitution. 196 The "target address records" of an ANAME record are the address 197 records obtained by resolving the ultimate target of the ANAME (see 198 Section 3). 200 During the process of looking up the target address records, one or 201 more CNAME or ANAME records may be encountered. These records are 202 not the final target address records, and are referred in this 203 document as "intermediate records". The target name must be replaced 204 with the new name provided in the RDATA and the new target is 205 resolved. 207 Other DNS-related terminology can be found in [RFC8499]. 209 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 210 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 211 interpreted as described in [RFC2119]. 213 2. The ANAME resource record 215 This document defines the "ANAME" DNS resource record type, with RR 216 TYPE value [TBD]. 218 2.1. Presentation and wire format 220 The ANAME presentation format is identical to that of CNAME 221 [RFC1033]: 223 owner ttl class ANAME target 225 The wire format is also identical to CNAME [RFC1035], except that 226 name compression is not permitted in ANAME RDATA, per [RFC3597]. 228 2.2. Coexistence with other types 230 Only one ANAME can be defined per . An ANAME RRset 231 MUST NOT contain more than one resource record. 233 An ANAME's sibling address records are under the control of ANAME 234 processing (see Section 4) and are not first-class records in their 235 own right. They MAY exist in zone files, but they can subsequently 236 be altered by ANAME processing. 238 An ANAME record MAY freely coexist at the same owner name with other 239 RR types, except they MUST NOT coexist with CNAME or any other RR 240 type that restricts the types with which it can itself coexist. That 241 means An ANAME record can coexist at the same owner name with A and 242 AAAA records. These are the sibling address records that are updated 243 with the target addresses that are retrieved through the ANAME 244 substitution process Section 3. 246 Like other types, An ANAME record can coexist with DNAME records at 247 the same owner name; in fact, the two can be used cooperatively to 248 redirect both the owner name address records (via ANAME) and 249 everything under it (via DNAME). 251 3. Substituting ANAME sibling address records 253 This process is used by both primary masters (see Section 4) and 254 resolvers (see Section 5), though they vary in how they apply the 255 edit described in the final step. However, this process is not 256 exclusively used by primary masters and resolvers: it may be executed 257 as a bump in the wire, as part of the query lookup, or at any other 258 point during query resolution. 260 The following steps MUST be performed for each address type: 262 1. Starting at the ANAME owner, follow the chain of ANAME and/or 263 CNAME records as far as possible to find the ultimate target. 265 2. If a loop is detected, continue with an empty RRset, otherwise 266 get the ultimate target's address records. (Ignore any sibling 267 address records of intermediate ANAMEs.) 269 3. Stop if resolution failed. (Note that NXDOMAIN and NODATA count 270 as successfully resolving an empty RRset.) 272 4. If one or more address records are found, replace the owner of 273 the target address records with the owner of the ANAME record. 274 Set the TTL to the minimum of the ANAME TTL, the TTL of each 275 intermediate record, and the TTL of the target address records. 276 Drop any RRSIG records. 278 5. Stop if this modified RRset is the same as the sibling RRset 279 (ignoring any RRSIG records). The comparison MAY treat nearly- 280 equal TTLs as the same. 282 6. Delete the sibling address RRset (if any) and replace it with the 283 modified RRset. 285 At this point, the substituted RRset is not signed. A primary master 286 will proceed to sign the substituted RRset, whereas resolvers can 287 only use the substituted RRset when an unsigned answer is 288 appropriate. This is explained in more detail in the following 289 sections. 291 4. ANAME processing by primary masters 293 Each ANAME's sibling address records are kept up-to-date as if by the 294 following process, for each address type: 296 o Perform ANAME sibling address record substitution as described in 297 Section 3. Any edit performed in the final step is applied to the 298 ANAME's zone. A primary server MAY use Dynamic Updates (DNS 299 UPDATE) [RFC2136] to update the zone. 301 o If resolution failed, wait for a period before trying again. This 302 retry time SHOULD be configurable. 304 o Otherwise, wait until the target address RRset TTL has expired or 305 is close to expiring, then repeat. 307 It may be more efficient to manage the polling per ANAME target 308 rather than per ANAME as specified (for example if the same ANAME 309 target is used by multiple zones). 311 Sibling address records are committed to the zone and stored in 312 nonvolatile storage. This allows a server to restart without delays 313 due to ANAME processing, use offline DNSSEC signing, and not 314 implement special ANAME processing logic when handling a DNS query. 316 Appendix D describes how ANAME would fit in different DNS 317 architectures that use online signing or tailored responses. 319 4.1. Zone transfers 321 ANAME is no more special than any other RRtype and does not introduce 322 any special processing related to zone transfers. 324 A zone containing ANAME records that point to frequently-changing 325 targets will itself change frequently, and may see an increased 326 number of zone transfers. Or if a very large number of zones are 327 sharing the same ANAME target, and that changes address, that may 328 cause a great volume of zone transfers. Guidance on dealing with 329 ANAME in large scale implementations is provided Appendix D. 331 Secondary servers rely on zone transfers to obtain sibling address 332 records, just like the rest of the zone, and serve them in the usual 333 way (see Section 6). A working DNS NOTIFY [RFC1996] setup is 334 recommended to avoid extra delays propagating updated sibling address 335 records when they change. 337 4.2. DNSSEC 339 A zone containing ANAME records that will update address records has 340 to do so before signing the zone with DNSSEC [RFC4033] [RFC4034] 341 [RFC4035]. This means that for traditional DNSSEC signing the 342 substitution of sibling address records must be done before signing 343 and loading the zone into the name server. For servers that support 344 online signing, the substitution may happen as part of the name 345 server process, after loading the zone. 347 DNSSEC signatures on sibling address records are generated in the 348 same way as for normal (dynamic) updates. 350 4.3. TTLs 352 Sibling address records are served from authoritative servers with a 353 fixed TTL. Normally this TTL is expected to be the same as the 354 target address records' TTL; however the exact mechanism for 355 obtaining the target is unspecified, so cache effects, following 356 ANAME and CNAME chains, or deliberate policies might make the sibling 357 TTL smaller. 359 This means that when adding address records into the zone as a result 360 of ANAME processing, the TTL to use is at most that of the TTL of the 361 address target records. If you use a higher value, this will stretch 362 the TTL which is undesired. 364 TTL stretching is hard to avoid when implementing ANAME substitution 365 at the primary: The target address records' TTL influences the update 366 rate of the zone, while the sibling address records' TTL determine 367 how long a resolver may cache the address records. Thus, the end-to- 368 end TTL (from the authoritative servers for the target address 369 records to end-user DNS caches) is nearing twice the target address 370 record TTL. There is a more extended discussion of TTL handling in 371 Appendix C. 373 5. ANAME processing by resolvers 375 When a resolver makes an address query in the usual way, it might 376 receive a response containing ANAME information in the Answer 377 section, as described in Section 6. This informs the resolver that 378 it MAY resolve the ANAME target address records to get answers that 379 are tailored to the resolver rather than the ANAME's primary master. 381 In order to provide tailored answers to clients that are ANAME- 382 oblivious, the resolver MAY perform sibling address record 383 substitution in the following situations: 385 o The resolver's client queries with DO=0. (As discussed in 386 Section 8, if the resolver finds it would downgrade a secure 387 answer to insecure, it MAY choose not to substitute the sibling 388 address records.) 390 o The resolver's client queries with DO=1 and the ANAME and sibling 391 address records are unsigned. (Note that this situation does not 392 apply when the records are signed but insecure: the resolver might 393 not be able to validate them because of a broken chain of trust, 394 but its client could have an extra trust anchor that does allow it 395 to validate them; if the resolver substitutes the sibling address 396 records they will become bogus.) 398 In these first two cases, the resolver MAY perform ANAME sibling 399 address record substitution as described in Section 3. Any edit 400 performed in the final step is applied to the Answer section of the 401 response. 403 If the resolver's client is querying using an API such as 404 "getaddrinfo" [RFC3493] that does not support DNSSEC validation, the 405 resolver MAY perform ANAME sibling address record substitution as 406 described in Section 3. Any edits performed in the final step are 407 applied to the addresses returned by the API. (This case is for 408 validating stub resolvers that query an upstream recursive server 409 with DO=1, so they cannot rely on the recursive server to do ANAME 410 substitution for them.) 412 6. Query processing 414 6.1. Authoritative servers 416 6.1.1. Address queries 418 When a server receives an address query for a name that has an ANAME 419 record, the response's Answer section MUST contain the ANAME record, 420 in addition to the sibling address queries. The ANAME record 421 indicates to a client that it might wish to resolve the target 422 address records itself. 424 6.1.2. ANAME queries 426 When a server receives an query for type ANAME, regardless of whether 427 the ANAME record exists on the queried domain, any sibling address 428 records SHOULD be added to the Additional section. Note that the 429 sibling address records may have been substituted already. 431 When adding address records to the Additional section, if not all 432 address types are present and the zone is signed, the server SHOULD 433 include a DNSSEC proof of nonexistence for the missing address types. 435 6.2. Resolvers 437 6.2.1. Address queries 439 When a server receives an address query for a name that has an ANAME 440 record, the response's Answer section MUST contain the ANAME record, 441 in addition to the sibling address queries. 443 The Additional section MAY contain the target address records that 444 match the query type (or the corresponding proof of nonexistence), if 445 they are available in the cache and the target address RDATA fields 446 differ from the sibling address RRset. 448 An ANAME target MAY resolve to address records via a chain of CNAME 449 and/or ANAME records; any CNAME/ANAME chain MUST be included when 450 adding target address records to a response's Additional section. 452 6.2.2. ANAME queries 454 When a resolver receives an query for type ANAME, any sibling address 455 records SHOULD be added to the Additional section. Just like with an 456 authoritative server, when adding address records to the Additional 457 section, if not all address types are present and the zone is signed, 458 the resolver SHOULD include a DNSSEC proof of nonexistence for the 459 missing address types. 461 7. IANA considerations 463 IANA is requested to assign a DNS RR TYPE value for ANAME resource 464 records under the "Resource Record (RR) TYPEs" subregistry under the 465 "Domain Name System (DNS) Parameters" registry. 467 IANA might wish to consider the creation of a registry of address 468 types; addition of new types to such a registry would then implicitly 469 update this specification. 471 8. Security considerations 473 When a primary master updates an ANAME's sibling address records to 474 match its target address records, it uses its own best information as 475 to the correct answer. The primary master might sign the updated 476 records, but that is not a guarantee of the actual correctness of the 477 answer. This signing can have the effect of promoting an insecure 478 response from the ANAME to a signed response from the 479 , which can then appear to clients to be more trustworthy than 480 it should. DNSSEC validation SHOULD be used when resolving the ANAME 481 to mitigate this possible harm. Primary masters MAY refuse 482 to substitute ANAME sibling address records unless the node 483 is both signed and validated. 485 When a resolver substitutes an ANAME's sibling address records, it 486 can find that the sibling address records are secure but the target 487 address records are insecure. Going ahead with the substitution will 488 downgrade a secure answer to an insecure one. However this is likely 489 to be the counterpart of the situation described in the previous 490 paragraph, so the resolver is downgrading an answer that the ANAME's 491 primary master upgraded. A resolver will only downgrade an answer in 492 this way when its client is security-oblivious; however the client's 493 path to the resolver is likely to be practically safer than the 494 resolver's path to the ANAME target's servers. Resolvers MAY choose 495 not to substitute sibling address records when they are more secure 496 than the target address records. 498 9. Acknowledgments 500 Thanks to Mark Andrews, Ray Bellis, Stefan Buehler, Paul Ebersman, 501 Richard Gibson, Tatuya JINMEI, Hakan Lindqvist, Mattijs Mekking, 502 Stephen Morris, Bjorn Mott, Richard Salts, Mukund Sivaraman, Job 503 Snijders, Jan Vcelak, Paul Vixie, Duane Wessels, and Paul Wouters, 504 Olli Vanhoja, Brian Dickson for discussion and feedback. 506 10. Changes since the last revision 508 [This section is to be removed before publication as an RFC.] 510 The full history of this draft and its issue tracker can be found at 511 https://github.com/each/draft-aname [1] 513 10.1. Version -04 515 o Split up section about Additional Section processing. 517 o Update Additional Section processing requirements. 519 o Clarify when ANAME resolution may happen [#43]. 521 o Revisit TTL considerations [#30, #34]. 523 o ANAME goes into the Answer section when QTYPE=A|AAAA [#62]. 525 o Update alternative setups section with concerns (Brian Dickson) 526 [#68]. 528 o Add section on ANAME loops (open issue [#45]). 530 10.2. Version -03 532 o Grammar improvements (Olli Vanhoja) 534 o Split up Implications section, clarify text on zone transfers and 535 dynamic updates [#39]. 537 o Rewrite Alternative setup section and move to Appendix, add text 538 on zone transfer scalibility concerns and GeoIP. 540 10.3. Version -02 542 Major revamp, so authoritative servers (other than primary masters) 543 now do not do any special ANAME processing, just Additional section 544 processing. 546 11. References 548 11.1. Normative References 550 [RFC1033] Lottor, M., "Domain Administrators Operations Guide", 551 RFC 1033, DOI 10.17487/RFC1033, November 1987, 552 . 554 [RFC1035] Mockapetris, P., "Domain names - implementation and 555 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 556 November 1987, . 558 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 559 Requirement Levels", BCP 14, RFC 2119, 560 DOI 10.17487/RFC2119, March 1997, 561 . 563 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 564 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 565 RFC 2136, DOI 10.17487/RFC2136, April 1997, 566 . 568 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 569 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 570 2003, . 572 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 573 Rose, "DNS Security Introduction and Requirements", 574 RFC 4033, DOI 10.17487/RFC4033, March 2005, 575 . 577 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 578 Rose, "Resource Records for the DNS Security Extensions", 579 RFC 4034, DOI 10.17487/RFC4034, March 2005, 580 . 582 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 583 Rose, "Protocol Modifications for the DNS Security 584 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 585 . 587 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 588 Kumari, "Client Subnet in DNS Queries", RFC 7871, 589 DOI 10.17487/RFC7871, May 2016, 590 . 592 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 593 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 594 January 2019, . 596 11.2. Informative References 598 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 599 RFC 882, DOI 10.17487/RFC0882, November 1983, 600 . 602 [RFC0973] Mockapetris, P., "Domain system changes and observations", 603 RFC 973, DOI 10.17487/RFC0973, January 1986, 604 . 606 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 607 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 608 . 610 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 611 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 612 August 1996, . 614 [RFC2065] Eastlake 3rd, D. and C. Kaufman, "Domain Name System 615 Security Extensions", RFC 2065, DOI 10.17487/RFC2065, 616 January 1997, . 618 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 619 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 620 . 622 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 623 Stevens, "Basic Socket Interface Extensions for IPv6", 624 RFC 3493, DOI 10.17487/RFC3493, February 2003, 625 . 627 11.3. URIs 629 [1] https://github.com/each/draft-aname 631 [2] https://github.com/each/draft-aname/issues/45 633 Appendix A. Implementation status 635 PowerDNS currently implements a similar authoritative-only feature 636 using "ALIAS" records, which are expanded by the primary server and 637 transfered as address records to secondaries. 639 [TODO: Add discussion of DNSimple, DNS Made Easy, EasyDNS, 640 Cloudflare, Amazon, Dyn, and Akamai.] 642 Appendix B. Historical note 644 In the early DNS [RFC0882], CNAME records were allowed to coexist 645 with other records. However this led to coherency problems: if a 646 resolver had no cache entries for a given name, it would resolve 647 queries for un-cached records at that name in the usual way; once it 648 had cached a CNAME record for a name, it would resolve queries for 649 un-cached records using CNAME target instead. 651 For example, given the zone contents below, the original CNAME 652 behaviour meant that if you asked for "alias.example.com TXT" first, 653 you would get the answer "owner", but if you asked for 654 "alias.example.com A" then "alias.example.com TXT" you would get the 655 answer "target". 657 alias.example.com. TXT "owner" 658 alias.example.com. CNAME canonical.example.com. 659 canonical.example.com. TXT "target" 660 canonical.example.com. A 192.0.2.1 662 This coherency problem was fixed in [RFC0973] which introduced the 663 inconvenient rule that a CNAME acts as an alias for all other RR 664 types at a name, which prevents the coexistence of CNAME with other 665 records. 667 A better fix might have been to improve the cache's awareness of 668 which records do and do not coexist with a CNAME record. However 669 that would have required a negative cache mechanism which was not 670 added to the DNS until later [RFC1034] [RFC2308]. 672 While [RFC2065] relaxed the restriction by allowing coexistence of 673 CNAME with DNSSEC records, this exception is still not applicable to 674 other resource records. RRSIG and NSEC exist to prove the integrity 675 of the CNAME record; they are not intended to associate arbitrary 676 data with the domain name. DNSSEC records avoid interoperability 677 problems by being largely invisible to security-oblivious resolvers. 679 Now that the DNS has negative caching, it is tempting to amend the 680 algorithm for resolving with CNAME records to allow them to coexist 681 with other types. Although an amended resolver will be compatible 682 with the rest of the DNS, it will not be of much practical use 683 because authoritative servers which rely on coexisting CNAMEs will 684 not interoperate well with older resolvers. Practical experiments 685 show that the problems are particularly acute when CNAME and MX try 686 to coexist. 688 Appendix C. On preserving TTLs 690 An ANAME's sibling address records are in an unusual situation: they 691 are authoritative data in the owner's zone, so from that point of 692 view the owner has the last say over what their TTL should be; on the 693 other hand, ANAMEs are supposed to act as aliases, in which case the 694 target should control the address record TTLs. 696 However there are some technical constraints that make it difficult 697 to preserve the target address record TTLs. 699 The following subsections conclude that the end-to-end TTL (from the 700 authoritative servers for the target address records to end-user DNS 701 caches) is nearing twice the target address record TTL. 703 C.1. Query bunching 705 If the times of end-user queries for a domain name are well 706 distributed, then (typically) queries received by the authoritative 707 servers for that domain are also well distributed. If the domain is 708 popular, a recursive server will re-query for it once every TTL 709 seconds, but the periodic queries from all the various recursive 710 servers will not be aligned, so the queries remain well distributed. 712 However, imagine that the TTLs of an ANAME's sibling address records 713 are decremented in the same way as cache entries in recursive 714 servers. Then all the recursive servers querying for the name would 715 try to refresh their caches at the same time when the TTL reaches 716 zero. They would become synchronized, and all the queries for the 717 domain would be bunched into periodic spikes. 719 This specification says that ANAME sibling address records have a 720 normal fixed TTL derived from (e.g. equal or nearly equal to) the 721 target address records' original TTL. There is no cache-like 722 decrementing TTL, so there is no bunching of queries. 724 C.2. Upstream caches 726 There are two straightforward ways to get an RRset's original TTL: 728 o by directly querying an authoritative server; 730 o using the original TTL field from the RRset's RRGIG record(s). 732 However, not all zones are signed, and a primary master might not be 733 able to query other authoritative servers directly (e.g. if it is a 734 hidden primary behind a strict firewall). Instead it might have to 735 obtain an ANAME's target address records via some other recursive 736 server. 738 Querying via a separate recursive server means the primary master 739 cannot trivially obtain the target address records' original TTLs. 740 Fortunately this is likely to be a self-correcting problem for 741 similar reasons to the query-bunching discussed in the previous 742 subsection. The primary master can inspect the target address 743 records just after the TTL expires when its upstream cache has just 744 refreshed them, so the TTL will be nearly equal to the original TTL. 746 A related consideration is that the primary master cannot in general 747 refresh its copies of an ANAME's target address records more 748 frequently than their TTL, without privileged control over its 749 resolver cache. 751 Combined with the requirement that sibling address records are served 752 with a fixed TTL, this means that the end-to-end TTL will be the 753 target address record TTL (which determines when the sibling address 754 records are updated) plus the sibling address record TTL (which 755 determines when end-user caches are updated). Since the sibling 756 address record TTL is derived from the target address records' 757 original TTL, the end-to-end TTL will be nearing twice the target 758 address record TTL. 760 C.3. ANAME chains 762 ANAME sibling address record substitution is made slightly more 763 complicated by the requirement to follow chains of ANAME and/or CNAME 764 records. The TTL of the substituted address records is the minimum 765 of TTLs of the ANAME, all the intermediate records, and target 766 records. This stops the end-to-end TTL from being inflated by each 767 ANAME in the chain. 769 With CNAME records, repeat queries for "cname.example. CNAME 770 target.example." must not be fully answered from cache after its TTL 771 expires, but must instead be sent to name servers authoritative for 772 "cname.example" in case the CNAME has been updated or removed. 773 Similarly, an ANAME at "aname.example" means that repeat queries for 774 "aname.example" must not be fully answered from cache after its TTL 775 expire, but must instead be sent to name servers authoritative for 776 aname.example in case the ANAME has been updated or removed. 778 C.4. ANAME substitution inside the name server 780 When ANAME substitution is performed inside the authoritative name 781 server (as described in #alternatives) or in the resolver (as 782 described in #resolver) the end-to-end TTL will actually be just the 783 target address record TTL. 785 An authoritative server that has control over its resolver can use a 786 cached target address RRset and decremented TTL in the response to 787 the client rather than using the original target address records' 788 TTL. It SHOULD however not use TTLs in the response that are nearing 789 zero to avoid query bunching Appendix C.1. 791 A resolver that performs ANAME substitution is able to get the 792 original TTL from the authoritative name server and use its own cache 793 to store the substituted address records with the appropriate TTL, 794 thereby honoring the TTL of target address records. 796 C.5. TTLs and zone transfers 798 When things are working properly (with secondary name servers 799 responding to NOTIFY messages promptly) the authoritative servers 800 will follow changes to ANAME target address records according to 801 their TTLs. As a result the end-to-end TTL is unchanged from the 802 previous subsection. 804 If NOTIFY doesn't work, the TTLs can be stretched by the zone's SOA 805 refresh timer. More serious breakage can stretch them up to the zone 806 expiry time. 808 Appendix D. Alternative setups 810 If you are a large scale DNS provider, ANAME may introduce some 811 operational concerns. 813 D.1. Reducing query volume 815 When doing ANAME target lookups, an authoritative server might want 816 to use longer TTLs to reduce query volume, for ANAME values that do 817 not change frequently. This is the same concern a recursive resolver 818 may be exposed to when receiving answers with short TTLs. An 819 authoritative server doing ANAME target lookups therefor could use 820 the same mitigation as a recursive nameserver, that is set a 821 configured minimum TTL usage. This may however contribute to TTL 822 stretching as described in Section 4.3 so the configured minimum 823 should not be too low. 825 D.2. Zone transfer scalability 827 A frequently changing ANAME target, or a ANAME target that changes 828 its address and is used for many zones, can lead to an increased 829 number of zone transfers. Such DNS architectures may want to 830 consider a zone transfer mechanism outside the DNS. 832 Another way to deal with zone transfer scalability is to move the 833 ANAME processing (Section 3) inside the name server daemon. This is 834 not a requirement for ANAME to work, but may be a better solution in 835 large scale implementations. These implementations usually already 836 rely on online DNSSEC signing for similar reasons. If ANAME 837 processing occurs inside the name server daemon, it MUST be done 838 before any DNSSEC online signing happens. 840 For example, some existing ANAME-like implementations are based on a 841 DNS server architecture, in which a zone's published authoritative 842 servers all perform the duties of a primary master in a distributed 843 manner: provisioning records from a non-DNS back-end store, 844 refreshing DNSSEC signatures, and so forth. They don't use standard 845 standard zone transfers, and already implement their ANAME-like 846 processing inside the name server daemon, substituting ANAME sibling 847 address records on demand. 849 D.3. Tailored responses 851 Some DNS providers will tailor responses based on information in the 852 client request. Such implementations will use the source IP address 853 or EDNS Client Subnet [RFC7871] information and use geographical data 854 (GeoIP) or network latency measurements to decide what the best 855 answer is for a given query. Such setups won't work with traditional 856 DNSSEC and provide DNSSEC support usually through online signing. 857 Similar such setups should provide ANAME support through substituting 858 ANAME sibling records on demand. 860 Also, an authoritative server that uses the client address to tailor 861 the response should obviously not use its own address when looking up 862 ANAME targets, or it could direct clients to a suboptimal server 863 (e.g. a wrong language, or regional restricted content). Instead the 864 authoritative server should look up the ANAME targets on behalf of 865 the client address. It could use for example EDNS Client Subnet for 866 this. 868 In short, the exact mechanism for obtaining the target address 869 records in such setups is unspecified; typically they will be 870 resolved in the DNS in the usual way, but if an ANAME implementation 871 has special knowledge of the target it can short-cut the substitution 872 process, or it can use clever tricks such as client-dependant answers 873 to make the answer more optimal. 875 Appendix E. ANAME loops 877 The ANAME sibling address substitution algorithm in Section 3 poses a 878 challenge of detecting a loop between two or more ANAME records. 879 Imagine this setup: two authoritative servers X and Y performing 880 ANAME sibling address substition on the fly (i.e. they attempt to 881 resolve the ANAME target when the client query arrives). If server X 882 gets a query for FOO.TEST which is an ANAME to BAR.TEST, it will send 883 a query to server Y for BAR.TEST which is an ANAME to FOO.TEST. 884 Server Y will then start a new query to server X, which has no way to 885 know that it is regarding the original FOO.TEST lookup. 887 The only indicator of the presence of the loop in the described setup 888 is the network timeout. Ideally we would recognize the loop 889 explicitly based on the exchanged DNS messages. 891 On-the-fly ANAME substitution is allowed and it's just the most 892 obvious scenario where the problem can be demonstrated, but this loop 893 can also be encountered in other situations. The root cause is that 894 when the server gets a query it doesn't know why and that the server 895 always attempts to fully resolve the ANAME target before sending the 896 response. 898 TODO: Solve this issue [https://github.com/each/draft-aname/issues/45 899 [2]] 901 Authors' Addresses 903 Tony Finch 904 University of Cambridge 905 University Information Services 906 Roger Needham Building 907 7 JJ Thomson Avenue 908 Cambridge CB3 0RB 909 England 911 Email: dot@dotat.at 913 Evan Hunt 914 ISC 915 950 Charter St 916 Redwood City, CA 94063 917 USA 919 Email: each@isc.org 921 Peter van Dijk 922 PowerDNS.COM B.V. 923 Den Haag 924 The Netherlands 926 Email: peter.van.dijk@powerdns.com 928 Anthony Eden 929 DNSimple 930 Boston, MA USA 932 Email: anthony.eden@dnsimple.com 933 URI: https://dnsimple.com/ 935 Matthijs Mekking 936 ISC 937 950 Charter St 938 Redwood City, CA 94063 939 USA 941 Email: matthijs@isc.org