idnits 2.17.1 draft-ietf-dnsop-aname-03.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 826 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 (April 15, 2019) is 1809 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 203, but not defined -- Looks like a reference, but probably isn't: '1' on line 571 ** Downref: Normative reference to an Unknown state RFC: RFC 1033 ** 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: 2 errors (**), 0 flaws (~~), 4 warnings (==), 6 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: October 17, 2019 ISC 6 P. van Dijk 7 PowerDNS 8 A. Eden 9 DNSimple 10 W. Mekking 11 ISC 12 April 15, 2019 14 Address-specific DNS aliases (ANAME) 15 draft-ietf-dnsop-aname-03 17 Abstract 19 This document defines the "ANAME" DNS RR type, to provide similar 20 functionality to CNAME, but only for type A and AAAA queries. Unlike 21 CNAME, an ANAME can coexist with other record types. The ANAME RR 22 allows zone owners to make an apex domain name into an alias in a 23 standards 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 October 17, 2019. 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. Additional section processing 66 3.1. Address queries 67 3.2. ANAME queries 68 4. Substituting ANAME sibling address records 69 5. ANAME processing by primary masters 70 5.1. Zone transfers 71 5.2. DNSSEC 72 5.3. TTLs 73 6. ANAME processing by resolvers 74 7. IANA considerations 75 8. Security considerations 76 9. Acknowledgments 77 10. Changes since the last revision 78 10.1. Version -03 79 10.2. Version -02 80 11. References 81 11.1. Normative References 82 11.2. Informative References 83 11.3. URIs 84 Appendix A. Implementation status 85 Appendix B. Historical note 86 Appendix C. On preserving TTLs 87 C.1. Query bunching 88 C.2. Upstream caches 89 C.3. ANAME chains 90 C.4. TTLs and zone transfers 91 Appendix D. Answer vs Additional sections 92 Appendix E. Alternative setups 93 Authors' Addresses 95 1. Introduction 97 It can be desirable to provide web sites (and other services) at a 98 bare domain name (such as "example.com") as well as a service- 99 specific subdomain ("www.example.com"). 101 If the web site is hosted by a third-party provider, the ideal way to 102 provision its name in the DNS is using a CNAME record, so that the 103 third party provider retains control over the mapping from names to 104 IP address(es). It is now common for name-to-address mappings to be 105 highly dynamic, dependent on client location, server load, etc. 107 However, CNAME records cannot coexist with other records with the 108 same owner name. (The reason why is explored in Appendix B). This 109 restriction means they cannot appear at a zone apex (such as 110 "example.com") because of the SOA, NS, and other records that have to 111 be present there. CNAME records can also conflict at subdomains, for 112 example, if "department.example.edu" has separately hosted mail and 113 web servers. 115 Redirecting website lookups to an alternate domain name via SRV or 116 URI resource records would be an effective solution from the DNS 117 point of view, but to date, browser vendors have not accepted this 118 approach. 120 As a result, the only widely supported and standards-compliant way to 121 publish a web site at a bare domain is to place A and/or AAAA records 122 at the zone apex. The flexibility afforded by CNAME is not 123 available. 125 This document specifies a new RR type "ANAME", which provides similar 126 functionality to CNAME, but only for address queries (i.e., for type 127 A or AAAA). The basic idea is that the address records next to an 128 ANAME record are automatically copied from and kept in sync with the 129 ANAME target's address records. The ANAME record can be present at 130 any DNS node, and can coexist with most other RR types, enabling it 131 to be present at a zone apex, or any other name where the presence of 132 other records prevents the use of a CNAME record. 134 Similar authoritative functionality has been implemented and deployed 135 by a number of DNS software vendors and service providers, using 136 names such as ALIAS, ANAME, apex CNAME, CNAME flattening, and top- 137 level redirection. These mechanisms are proprietary, which hinders 138 the ability of zone owners to have the same data served from multiple 139 providers or to move from one provider to another. None of these 140 proprietary implementations includes a mechanism for resolvers to 141 follow the redirection chain themselves. 143 1.1. Overview 145 The core functionality of this mechanism allows zone administrators 146 to start using ANAME records unilaterally, without requiring 147 secondary servers or resolvers to be upgraded. 149 o The resource record definition in Section 2 is intended to provide 150 zone data portability between standards-compliant DNS servers and 151 the common core functionality of existing proprietary ANAME-like 152 facilities. 154 o The zone maintenance mechanism described in Section 5 keeps the 155 ANAME's sibling address records in sync with the ANAME target. 157 This definition is enough to be useful by itself. However, it can be 158 less than optimal in certain situations: for instance, when the ANAME 159 target uses clever tricks to provide different answers to different 160 clients to improve latency or load balancing. 162 o The Additional section processing rules in Section 3 inform 163 resolvers that an ANAME record is in play. 165 o Resolvers can use this ANAME information as described in Section 6 166 to obtain answers that are tailored to the resolver rather than to 167 the zone's primary master. 169 Resolver support for ANAME is not necessary, since ANAME-oblivious 170 resolvers can get working answers from authoritative servers. It's 171 just an optimization that can be rolled out incrementally, and that 172 will help ANAME to work better the more widely it is deployed. 174 1.2. Terminology 176 An "address record" is a DNS resource record whose type is A or AAAA. 177 These are referred to as "address types". "Address query" refers to 178 a DNS query for any address type. 180 When talking about "address records" we mean the entire RRset, 181 including owner name and TTL. We treat missing address records (i.e. 182 NXDOMAIN or NODATA) the same successfully resolving as a set of zero 183 address records, and distinct from "failure" which covers error 184 responses such as SERVFAIL or REFUSED. 186 The "sibling address records" of an ANAME record are the address 187 records at the same owner name as the ANAME, which are subject to 188 ANAME substitution. 190 The "target address records" of an ANAME record are the address 191 records obtained by resolving the ultimate target of the ANAME (see 192 Section 4). 194 Other DNS-related terminology can be found in [RFC8499]. 196 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 197 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 198 interpreted as described in [RFC2119]. 200 2. The ANAME resource record 202 This document defines the "ANAME" DNS resource record type, with RR 203 TYPE value [TBD]. 205 2.1. Presentation and wire format 207 The ANAME presentation format is identical to that of CNAME 208 [RFC1033]: 210 owner ttl class ANAME target 212 The wire format is also identical to CNAME [RFC1035], except that 213 name compression is not permitted in ANAME RDATA, per [RFC3597]. 215 2.2. Coexistence with other types 217 Only one ANAME can be defined per . An ANAME RRset 218 MUST NOT contain more than one resource record. 220 An ANAME's sibling address records are under the control of ANAME 221 processing (see Section 5) and are not first-class records in their 222 own right. They MAY exist in zone files, but they can subsequently 223 be altered by ANAME processing. 225 ANAME records MAY freely coexist at the same owner name with other RR 226 types, except they MUST NOT coexist with CNAME or any other RR type 227 that restricts the types with which it can itself coexist. 229 Like other types, ANAME records can coexist with DNAME records at the 230 same owner name; in fact, the two can be used cooperatively to 231 redirect both the owner name address records (via ANAME) and 232 everything under it (via DNAME). 234 3. Additional section processing 236 The requirements in this section apply to both recursive and 237 authoritative servers. 239 An ANAME target MAY resolve to address records via a chain of CNAME 240 and/or ANAME records; any CNAME/ANAME chain MUST be included when 241 adding target address records to a response's Additional section. 243 3.1. Address queries 245 When a server receives an address query for a name that has an ANAME 246 record, the response's Additional section: 248 o MUST contain the ANAME record; 250 o MAY contain the target address records that match the query type 251 (or the corresponding proof of nonexistence), if they are 252 available and the target address RDATA fields differ from the 253 sibling address RRset. 255 The ANAME record indicates to a client that it might wish to resolve 256 the target address records itself. The target address records might 257 not be available if the server is authoritative and does not include 258 out-of-zone or non-authoritative data in its answers, or if the 259 server is recursive and the records are not in the cache. 261 3.2. ANAME queries 263 When a server receives an query for type ANAME, there are three 264 possibilities: 266 o The query resolved to an ANAME record, and the server has the 267 target address records; any target address records SHOULD be added 268 to the Additional section. 270 o The query resolved to an ANAME record, and the server does not 271 have the target address records; any sibling address records 272 SHOULD be added to the Additional section. 274 o The query did not resolve to an ANAME record; any address records 275 with the same owner name SHOULD be added to the Additional section 276 of the NOERROR response. 278 When adding address records to the Additional section, if not all 279 address types are present and the zone is signed, the server SHOULD 280 include a DNSSEC proof of nonexistence for the missing address types. 282 4. Substituting ANAME sibling address records 284 This process is used by both primary masters (see Section 5) and 285 resolvers (see Section 6), though they vary in how they apply the 286 edit described in the final step. 288 The following steps MUST be performed for each address type: 290 1. Starting at the ANAME owner, follow the chain of ANAME and/or 291 CNAME records as far as possible to find the ultimate target. 293 2. If a loop is detected, continue with an empty RRset, otherwise 294 get the ultimate target's address records. (Ignore any sibling 295 address records of intermediate ANAMEs.) 297 3. Stop if resolution failed. (Note that NXDOMAIN and NODATA count 298 as successfully resolving an empty RRset.) 300 4. Replace the owner of the target address records with the owner of 301 the ANAME record. Reduce the TTL to match the ANAME record if it 302 is greater. Drop any RRSIG records. 304 5. Stop if this modified RRset is the same as the sibling RRset 305 (ignoring any RRSIG records). The comparison MAY treat nearly- 306 equal TTLs as the same. 308 6. Delete the sibling address RRset and replace it with the modified 309 RRset. 311 At this point, the substituted RRset is not signed. A primary master 312 will proceed to sign the substituted RRset, whereas resolvers can 313 only use the substituted RRset when an unsigned answer is 314 appropriate. This is explained in more detail in the following 315 sections. 317 5. ANAME processing by primary masters 319 Each ANAME's sibling address records are kept up-to-date as if by the 320 following process, for each address type: 322 o Perform ANAME sibling address record substitution as described in 323 Section 4. Any edit performed in the final step is applied to the 324 ANAME's zone. A primary server MAY use Dynamic Updates (DNS 325 UPDATE) [RFC2136] to update the zone. 327 o If resolution failed, wait for a period before trying again. This 328 retry time SHOULD be configurable. 330 o Otherwise, wait until the target address record TTL has expired, 331 then repeat. 333 It may be more efficient to manage the polling per ANAME target 334 rather than per ANAME as specified (for example if the same ANAME 335 target is used by multiple zones). 337 Sibling address records are committed to the zone and stored in 338 nonvolatile storage. This allows a server to restart without delays 339 due to ANAME processing, use offline DNSSEC signing, and not 340 implement special ANAME processing logic when handling a DNS query. 342 Appendix E describes how ANAME would fit in different DNS 343 architectures that use online signing or tailored responses. 345 5.1. Zone transfers 347 ANAME is no more special than any other RRtype and does not introduce 348 any special processing related to zone transfers. 350 A zone containing ANAME records that point to frequently-changing 351 targets will itself change frequently, and may see an increased 352 number of zone transfers. Or if a very large number of zones are 353 sharing the same ANAME target, and that changes address, that may 354 cause a great volume of zone transfers. Guidance on dealing with 355 ANAME in large scale implementations is provided Appendix E. 357 Secondary servers that rely on zone transfers to obtain sibling 358 address records, just like the rest of the zone, and serve them in 359 the usual way (with Section 3 Additional section processing if they 360 support it). A working DNS NOTIFY [RFC1996] setup is recommended to 361 avoid extra delays propagating updated sibling address records when 362 they change. 364 5.2. DNSSEC 366 A zone containing ANAME records that will update A and AAAA records 367 has to do so before signing the zone with DNSSEC [RFC4033] [RFC4034] 368 [RFC4035]. 370 DNSSEC signatures on sibling address records are generated in the 371 same way as for normal (dynamic) updates. 373 5.3. TTLs 375 Sibling address records are served from authoritative servers with a 376 fixed TTL. Normally this TTL is expected to be the same as the 377 target address records' TTL (or the ANAME TTL if that is smaller); 378 however the exact mechanism for obtaining the target is unspecified, 379 so cache effects or deliberate policies might make the sibling TTL 380 smaller. There is a more extended discussion of TTL handling in 381 {#ttls}. 383 6. ANAME processing by resolvers 385 When a resolver makes an address query in the usual way, it might 386 receive a response containing ANAME information in the additional 387 section, as described in Section 3. This informs the resolver that 388 it MAY resolve the ANAME target address records to get answers that 389 are tailored to the resolver rather than the ANAME's primary master. 390 It SHOULD include the target address records in the Additional 391 section of its responses as described in Section 3. 393 In order to provide tailored answers to clients that are ANAME- 394 oblivious, the resolver MAY perform sibling address record 395 substitution in the following situations: 397 o The resolver's client queries with DO=0. (As discussed in 398 Section 8, if the resolver finds it would downgrade a secure 399 answer to insecure, it MAY choose not to substitute the sibling 400 address records.) 402 o The resolver's client queries with DO=1 and the ANAME and sibling 403 address records are unsigned. (Note that this situation does not 404 apply when the records are signed but insecure: the resolver might 405 not be able to validate them because of a broken chain of trust, 406 but its client could have an extra trust anchor that does allow it 407 to validate them; if the resolver substitutes the sibling address 408 records they will become bogus.) 410 In these first two cases, the resolver MAY perform ANAME sibling 411 address record substitution as described in Section 4. Any edit 412 performed in the final step is applied to the Answer section of the 413 response. The resolver SHOULD then perform Additional section 414 processing as described in Section 3. 416 If the resolver's client is querying using an API such as 417 "getaddrinfo" [RFC3493] that does not support DNSSEC validation, the 418 resolver MAY perform ANAME sibling address record substitution as 419 described in Section 4. Any edits performed in the final step are 420 applied to the addresses returned by the API. (This case is for 421 validating stub resolvers that query an upstream recursive server 422 with DO=1, so they cannot rely on the recursive server to do ANAME 423 substitution for them.) 425 7. IANA considerations 427 IANA is requested to assign a DNS RR TYPE value for ANAME resource 428 records under the "Resource Record (RR) TYPEs" subregistry under the 429 "Domain Name System (DNS) Parameters" registry. 431 IANA might wish to consider the creation of a registry of address 432 types; addition of new types to such a registry would then implicitly 433 update this specification. 435 8. Security considerations 437 When a primary master updates an ANAME's sibling address records to 438 match its target address records, it uses its own best information as 439 to the correct answer. The primary master might sign the updated 440 records, but that is not a guarantee of the actual correctness of the 441 answer. This signing can have the effect of promoting an insecure 442 response from the ANAME to a signed response from the 443 , which can then appear to clients to be more trustworthy than 444 it should. DNSSEC validation SHOULD be used when resolving the ANAME 445 to mitigate this possible harm. Primary masters MAY refuse 446 to substitute ANAME sibling address records unless the node 447 is both signed and validated. 449 When a resolver substitutes an ANAME's sibling address records, it 450 can find that the sibling address records are secure but the target 451 address records are insecure. Going ahead with the substitution will 452 downgrade a secure answer to an insecure one. However this is likely 453 to be the counterpart of the situation described in the previous 454 paragraph, so the resolver is downgrading an answer that the ANAME's 455 primary master upgraded. A resolver will only downgrade an answer in 456 this way when its client is security-oblivious; however the client's 457 path to the resolver is likely to be practically safer than the 458 resolver's path to the ANAME target's servers. Resolvers MAY choose 459 not to substitute sibling address records when they are more secure 460 than the target address records. 462 9. Acknowledgments 464 Thanks to Mark Andrews, Ray Bellis, Stefan Buehler, Paul Ebersman, 465 Richard Gibson, Tatuya JINMEI, Hakan Lindqvist, Mattijs Mekking, 466 Stephen Morris, Bjorn Mott, Richard Salts, Mukund Sivaraman, Job 467 Snijders, Jan Vcelak, Paul Vixie, Duane Wessels, and Paul Wouters, 468 Olli Vanhoja for discussion and feedback. 470 10. Changes since the last revision 472 [This section is to be removed before publication as an RFC.] 474 The full history of this draft and its issue tracker can be found at 475 https://github.com/each/draft-aname [1] 477 10.1. Version -03 479 o Grammar improvements (Olli Vanhoja) 481 o Split up Implications section, clarify text on zone transfers and 482 dynamic updates. 484 o Rewrite Alternative setup section and move to Appendix, add text 485 on zone transfer scalibility concerns and GeoIP. 487 10.2. Version -02 489 Major revamp, so authoritative servers (other than primary masters) 490 now do not do any special ANAME processing, just Additional section 491 processing. 493 11. References 495 11.1. Normative References 497 [RFC1033] Lottor, M., "Domain Administrators Operations Guide", 498 RFC 1033, DOI 10.17487/RFC1033, November 1987, 499 . 501 [RFC1035] Mockapetris, P., "Domain names - implementation and 502 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 503 November 1987, . 505 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 506 Requirement Levels", BCP 14, RFC 2119, 507 DOI 10.17487/RFC2119, March 1997, 508 . 510 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 511 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 512 RFC 2136, DOI 10.17487/RFC2136, April 1997, 513 . 515 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 516 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 517 2003, . 519 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 520 Rose, "DNS Security Introduction and Requirements", 521 RFC 4033, DOI 10.17487/RFC4033, March 2005, 522 . 524 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 525 Rose, "Resource Records for the DNS Security Extensions", 526 RFC 4034, DOI 10.17487/RFC4034, March 2005, 527 . 529 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 530 Rose, "Protocol Modifications for the DNS Security 531 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 532 . 534 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 535 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 536 January 2019, . 538 11.2. Informative References 540 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 541 RFC 882, DOI 10.17487/RFC0882, November 1983, 542 . 544 [RFC0973] Mockapetris, P., "Domain system changes and observations", 545 RFC 973, DOI 10.17487/RFC0973, January 1986, 546 . 548 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 549 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 550 . 552 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 553 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 554 August 1996, . 556 [RFC2065] Eastlake 3rd, D. and C. Kaufman, "Domain Name System 557 Security Extensions", RFC 2065, DOI 10.17487/RFC2065, 558 January 1997, . 560 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 561 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 562 . 564 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 565 Stevens, "Basic Socket Interface Extensions for IPv6", 566 RFC 3493, DOI 10.17487/RFC3493, February 2003, 567 . 569 11.3. URIs 571 [1] https://github.com/each/draft-aname 573 Appendix A. Implementation status 575 PowerDNS currently implements a similar authoritative-only feature 576 using "ALIAS" records, which are expanded by the primary server and 577 transfered as address records to secondaries. 579 [TODO: Add discussion of DNSimple, DNS Made Easy, EasyDNS, 580 Cloudflare, Amazon, Dyn, and Akamai.] 582 Appendix B. Historical note 584 In the early DNS [RFC0882], CNAME records were allowed to coexist 585 with other records. However this led to coherency problems: if a 586 resolver had no cache entries for a given name, it would resolve 587 queries for un-cached records at that name in the usual way; once it 588 had cached a CNAME record for a name, it would resolve queries for 589 un-cached records using CNAME target instead. 591 For example, given the zone contents below, the original CNAME 592 behaviour meant that if you asked for "alias.example.com TXT" first, 593 you would get the answer "owner", but if you asked for 594 "alias.example.com A" then "alias.example.com TXT" you would get the 595 answer "target". 597 alias.example.com. TXT "owner" 598 alias.example.com. CNAME canonical.example.com. 599 canonical.example.com. TXT "target" 600 canonical.example.com. A 192.0.2.1 602 This coherency problem was fixed in [RFC0973] which introduced the 603 inconvenient rule that a CNAME acts as an alias for all other RR 604 types at a name, which prevents the coexistence of CNAME with other 605 records. 607 A better fix might have been to improve the cache's awareness of 608 which records do and do not coexist with a CNAME record. However 609 that would have required a negative cache mechanism which was not 610 added to the DNS until later [RFC1034] [RFC2308]. 612 While [RFC2065] relaxed the restriction by allowing coexistence of 613 CNAME with DNSSEC records, this exception is still not applicable to 614 other resource records. RRSIG and NSEC exist to prove the integrity 615 of the CNAME record; they are not intended to associate arbitrary 616 data with the domain name. DNSSEC records avoid interoperability 617 problems by being largely invisible to security-oblivious resolvers. 619 Now that the DNS has negative caching, it is tempting to amend the 620 algorithm for resolving with CNAME records to allow them to coexist 621 with other types. Although an amended resolver will be compatible 622 with the rest of the DNS, it will not be of much practical use 623 because authoritative servers which rely on coexisting CNAMEs will 624 not interoperate well with older resolvers. Practical experiments 625 show that the problems are particularly acute when CNAME and MX try 626 to coexist. 628 Appendix C. On preserving TTLs 630 An ANAME's sibling address records are in an unusual situation: they 631 are authoritative data in the owner's zone, so from that point of 632 view the owner has the last say over what their TTL should be; on the 633 other hand, ANAMEs are supposed to act as aliases, in which case the 634 target should control the address record TTLs. 636 However there are some technical constraints that make it difficult 637 to preserve the target address record TTLs. 639 The following subsections conclude that the end-to-end TTL (from the 640 authoritative servers for the target address records to end-user DNS 641 caches) should be set as the target address record TTL plus the 642 sibling address record TTL. 644 [MM: Discuss: I think it should be just the ANAME record TTL perhaps 645 the minimum of ANAME and sibling address RRset TTL. We should 646 provide some guidance on TTL settings for ANAME). 648 [TF: see issue #30] 650 C.1. Query bunching 652 If the times of end-user queries for a domain name are well 653 distributed, then (typically) queries received by the authoritative 654 servers for that domain are also well distributed. If the domain is 655 popular, a recursive server will re-query for it once every TTL 656 seconds, but the periodic queries from all the various recursive 657 servers will not be aligned, so the queries remain well distributed. 659 However, imagine that the TTLs of an ANAME's sibling address records 660 are decremented in the same way as cache entries in recursive 661 servers. Then all the recursive servers querying for the name would 662 try to refresh their caches at the same time when the TTL reaches 663 zero. They would become synchronized, and all the queries for the 664 domain would be bunched into periodic spikes. 666 This specification says that ANAME sibling address records have a 667 normal fixed TTL derived from (e.g. equal or nearly equal to) the 668 target address records' original TTL. There is no cache-like 669 decrementing TTL, so there is no bunching of queries. 671 C.2. Upstream caches 673 There are two straightforward ways to get an RRset's original TTL: 675 o by directly querying an authoritative server; 677 o using the original TTL field from the RRset's RRGIG record(s). 679 However, not all zones are signed, and a primary master might not be 680 able to query other authoritative servers directly (e.g. if it is a 681 hidden primary behind a strict firewall). Instead it might have to 682 obtain an ANAME's target address records via some other recursive 683 server. 685 Querying via a separate recursive server means the primary master 686 cannot trivially obtain the target address records' original TTLs. 687 Fortunately this is likely to be a self-correcting problem for 688 similar reasons to the query-bunching discussed in the previous 689 subsection. The primary master re-checks the target address records 690 just after the TTL expires when its upstream cache has just refreshed 691 them, so the TTL will be nearly equal to the original TTL. 693 A related consideration is that the primary master cannot in general 694 refresh its copies of an ANAME's target address records more 695 frequently than their TTL, without privileged control over its 696 resolver cache. 698 Combined with the requirement that sibling address records are served 699 with a fixed TTL, this means that the end-to-end TTL will be the 700 target address record TTL (which determines when the sibling address 701 records are updated) plus the sibling address record TTL (which 702 determines when end-user caches are updated). 704 C.3. ANAME chains 706 ANAME sibling address record substitution is made slightly more 707 complicated by the requirement to follow chains of ANAME and/or CNAME 708 records. This stops the end-to-end TTL from being inflated by each 709 ANAME in the chain. 711 C.4. TTLs and zone transfers 713 When things are working properly (with secondary name servers 714 responding to NOTIFY messages promptly) the authoritative servers 715 will follow changes to ANAME target address records according to 716 their TTLs. As a result the end-to-end TTL is unchanged from the 717 previous subsection. 719 If NOTIFY doesn't work, the TTLs can be stretched by the zone's SOA 720 refresh timer. More serious breakage can stretch them up to the zone 721 expiry time. 723 Appendix D. Answer vs Additional sections 725 [MM: Discuss what should be in the additional section: ANAME makes 726 sense, but differs from CNAME logic (where the CNAME is in the answer 727 section). Additional target records that match the query type in my 728 opinion should go in the answer section. Additional target address 729 records that do not match the query type can go in the additional 730 section]. 732 [TF: from experience with DNAME I think there's a risk of interop 733 problems if we put unexpected records in the answer section, so I 734 said everything should go in additional. We'll expand this appendix 735 to explain the rationale.] 737 Appendix E. Alternative setups 739 If you are a large scale DNS provider, ANAME may introduce some 740 scalability concerns. A frequently changing ANAME target, or a ANAME 741 target that changes its address and is used for many zones, can lead 742 to an increased number of zone transfers. Such DNS architectures may 743 want to consider a zone transfer mechanism outside the DNS. 745 Another way to deal with zone transfer scalability is to move the 746 ANAME processing (Section 4) inside the name server daemon. This is 747 not a requirement for ANAME to work, but may be a better solution in 748 large scale implementations. These implementations usually already 749 rely on online DNSSEC signing for similar reasons. If ANAME 750 processing occurs inside the name server daemon, it MUST be done 751 before any DNSSEC online signing happens. 753 For example, some existing ANAME-like implementations are based on a 754 DNS server architecture, in which a zone's published authoritative 755 servers all perform the duties of a primary master in a distributed 756 manner: provisioning records from a non-DNS back-end store, 757 refreshing DNSSEC signatures, and so forth. They don't use standard 758 standard zone transfers, and already implement their ANAME-like 759 processing inside the name server daemon, substituting ANAME sibling 760 address records on demand. 762 Also, some DNS providers will tailor responses based on information 763 in the client request. Such implementations will use the source IP 764 address or EDNS Client Subnet information and use geographical data 765 (GeoIP) or network latency measurements to decide what the best 766 answer is for a given query. Such setups won't work with traditional 767 DNSSEC and provide DNSSEC support usually through online signing. 768 Similar such setups should provide ANAME support through substituting 769 ANAME sibling records on demand. 771 The exact mechanism for obtaining the target address records in such 772 setups is unspecified; typically they will be resolved in the DNS in 773 the usual way, but if an ANAME implementation has special knowledge 774 of the target it can short-cut the substitution process, or it can 775 use clever tricks such as client-dependant answers. 777 Authors' Addresses 779 Tony Finch 780 University of Cambridge 781 University Information Services 782 Roger Needham Building 783 7 JJ Thomson Avenue 784 Cambridge CB3 0RB 785 England 787 Email: dot@dotat.at 789 Evan Hunt 790 ISC 791 950 Charter St 792 Redwood City, CA 94063 793 USA 795 Email: each@isc.org 797 Peter van Dijk 798 PowerDNS.COM B.V. 799 Den Haag 800 The Netherlands 802 Email: peter.van.dijk@powerdns.com 804 Anthony Eden 805 DNSimple 806 Boston, MA USA 808 Email: anthony.eden@dnsimple.com 809 URI: https://dnsimple.com/ 811 Matthijs Mekking 812 ISC 813 950 Charter St 814 Redwood City, CA 94063 815 USA 817 Email: matthijs@isc.org