idnits 2.17.1 draft-ietf-dnsop-aname-02.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 : ---------------------------------------------------------------------------- -- 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 date (October 19, 2018) is 2009 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 201, but not defined -- Looks like a reference, but probably isn't: '1' on line 724 ** Downref: Normative reference to an Unknown state RFC: RFC 1033 -- 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: 1 error (**), 0 flaws (~~), 2 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: April 22, 2019 ISC 6 P. van Dijk 7 PowerDNS 8 A. Eden 9 DNSimple 10 October 19, 2018 12 Address-specific DNS aliases (ANAME) 13 draft-ietf-dnsop-aname-02 15 Abstract 17 This document defines the "ANAME" DNS RR type, to provide similar 18 functionality to CNAME, but only for type A and AAAA queries. Unlike 19 CNAME, an ANAME can coexist with other record types. The ANAME RR 20 allows zone owners to make an apex domain name into an alias in a 21 standards compliant manner. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 22, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. The ANAME resource record . . . . . . . . . . . . . . . . . . 5 61 2.1. Presentation and wire format . . . . . . . . . . . . . . 5 62 2.2. Coexistence with other types . . . . . . . . . . . . . . 5 63 3. Additional section processing . . . . . . . . . . . . . . . . 5 64 3.1. Address queries . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. ANAME queries . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Substituting ANAME sibling address records . . . . . . . . . 6 67 5. ANAME processing by primary masters . . . . . . . . . . . . . 7 68 5.1. Implications . . . . . . . . . . . . . . . . . . . . . . 8 69 5.2. Alternatives . . . . . . . . . . . . . . . . . . . . . . 8 70 6. ANAME processing by resolvers . . . . . . . . . . . . . . . . 9 71 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 72 8. Security considerations . . . . . . . . . . . . . . . . . . . 10 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 9.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12 77 Appendix B. Implementation status . . . . . . . . . . . . . . . 12 78 Appendix C. Historical note . . . . . . . . . . . . . . . . . . 12 79 Appendix D. On preserving TTLs . . . . . . . . . . . . . . . . . 13 80 D.1. Query bunching . . . . . . . . . . . . . . . . . . . . . 14 81 D.2. Upstream caches . . . . . . . . . . . . . . . . . . . . . 14 82 D.3. ANAME chains . . . . . . . . . . . . . . . . . . . . . . 15 83 D.4. TTLs and zone transfers . . . . . . . . . . . . . . . . . 15 84 Appendix E. Answer vs Additional sections . . . . . . . . . . . 15 85 Appendix F. Changes since the last revision . . . . . . . . . . 16 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 It can be desirable to provide web sites (and other services) at a 91 bare domain name (such as "example.com") as well as a service- 92 specific subdomain ("www.example.com"). 94 If the web site is hosted by a third-party provider, the ideal way to 95 provision its name in the DNS is using a CNAME record, so that the 96 third party provider retains control over the mapping from names to 97 IP address(es). It is now common for name-to-address mappings to be 98 highly dynamic, dependent on client location, server load, etc. 100 However, CNAME records cannot coexist with other records. (The 101 reason why is explored in Appendix C). This means they cannot appear 102 at a zone apex (such as "example.com") because of the SOA, NS, and 103 other records that have to be present there. CNAME records can also 104 conflict at subdomains, for example if "department.example.edu" has 105 separately hosted mail and web servers. 107 Redirecting website lookups to an alternate domain name via SRV or 108 URI resource records would be an effective solution from the DNS 109 point of view, but to date this approach has not been accepted by 110 browser implementations. 112 As a result, the only widely supported and standards-compliant way to 113 publish a web site at a bare domain is to place A and/or AAAA records 114 at the zone apex. The flexibility afforded by CNAME is not 115 available. 117 This document specifies a new RR type "ANAME", which provides similar 118 functionality to CNAME, but only for address queries (i.e., for type 119 A or AAAA). The basic idea is that the address records next to an 120 ANAME record are automatically copied from and kept in sync with the 121 ANAME target's address records. The ANAME record can be present at 122 any DNS node, and can coexist with most other RR types, enabling it 123 to be present at a zone apex, or any other name where the presence of 124 other records prevents the use of CNAME. 126 Similar authoritative functionality has been implemented and deployed 127 by a number of DNS software vendors and service providers, using 128 names such as ALIAS, ANAME, apex CNAME, CNAME flattening, and top 129 level redirection. These mechanisms are proprietary, which hinders 130 the ability of zone owners to have the same data served from multiple 131 providers, or to move from one provider to another. None of these 132 proprietary implementations includes a mechanism for resolvers to 133 follow the redirection chain themselves. 135 1.1. Overview 137 The core functionality of this mechanism allows zone administrators 138 to start using ANAME records unilaterally, without requiring 139 secondary servers or resolvers to be upgraded. 141 o The resource record definition in Section 2 is intended to provide 142 zone data portability between standards-compliant DNS servers and 143 the common core functionality of existing proprietary ANAME-like 144 facilities. 146 o The zone maintenance mechanism described in Section 5 behaves as 147 if DNS UPDATE [RFC2136] were being used to keep an ANAME's sibling 148 address records in sync with the ANAME target; this allows it to 149 interoperate with existing DNSSEC signers, secondary servers, and 150 resolvers. 152 This is enough to be useful by itself. However, it can be less than 153 optimal in certain situations: for instance, when the ANAME target 154 uses clever tricks to provide different answers to different clients 155 to improve latency or load balancing. 157 o The Additional section processing rules in Section 3 inform 158 resolvers that an ANAME record is in play. 160 o Resolvers can use this ANAME information as described in Section 6 161 to obtain answers that are tailored to the resolver rather than to 162 the zone's primary master. 164 Resolver support for ANAME is not necessary, since ANAME-oblivious 165 resolvers will get working answers from authoritative servers. It's 166 just an optimization that can be rolled out incrementally, and that 167 will help ANAME to work better the more widely it is deployed. 169 1.2. Terminology 171 An "address record" is a DNS resource record whose type is A or AAAA. 172 These are referred to as "address types". "Address query" refers to 173 a DNS query for any address type. 175 When talking about "address records" we mean the entire RRset, 176 including owner name and TTL. We treat missing address records (i.e. 177 NXDOMAIN or NODATA) the same successfully resolving as a set of zero 178 address records, and distinct from "failure" which covers error 179 responses such as SERVFAIL or REFUSED. 181 The "sibling address records" of an ANAME record are the address 182 records at the same owner name as the ANAME, which are subject to 183 ANAME substitution. 185 The "target address records" of an ANAME record are the address 186 records obtained by resolving the ultimate target of the ANAME (see 187 Section 4). 189 Other DNS-related terminology can be found in 190 [I-D.ietf-dnsop-terminology-bis]. 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 194 "OPTIONAL" in this document are to be interpreted as described in BCP 195 14 [RFC2119] [RFC8174] when, and only when, they appear in all 196 capitals, as shown here. 198 2. The ANAME resource record 200 This document defines the "ANAME" DNS resource record type, with RR 201 TYPE value [TBD]. 203 2.1. Presentation and wire format 205 The ANAME presentation format is identical to that of CNAME 206 [RFC1033]: 208 owner ttl class ANAME target 210 The wire format is also identical to CNAME [RFC1035], except that 211 name compression is not permitted in ANAME RDATA, per [RFC3597]. 213 2.2. Coexistence with other types 215 Only one ANAME can be defined per . An ANAME RRset 216 MUST NOT contain more than one resource record. 218 An ANAME's sibling address records are under the control of ANAME 219 processing (see Section 5) and are not first-class records in their 220 own right. They MAY exist in zone files, but they can subsequently 221 be altered by ANAME processing. 223 ANAME records MAY freely coexist at the same owner name with other RR 224 types, except they MUST NOT coexist with CNAME or any other RR type 225 that restricts the types with which it can itself coexist. 227 Like other types, ANAME records can coexist with DNAME records at the 228 same owner name; in fact, the two can be used cooperatively to 229 redirect both the owner name address records (via ANAME) and 230 everything under it (via DNAME). 232 3. Additional section processing 234 The requirements in this section apply to both recursive and 235 authoritative servers. 237 An ANAME target MAY resolve to address records via a chain of CNAME 238 and/or ANAME records; any CNAME/ANAME chain MUST be included when 239 adding target address records to a response's Additional section. 241 3.1. Address queries 243 When a server receives an address query for a name that has an ANAME 244 record, the response's Additional section: 246 o MUST contain the ANAME record; 248 o MAY contain the target address records that match the query type 249 (or the corresponding proof of nonexistence), if they are 250 available and the target address RDATA fields differ from the 251 sibling address RRset. 253 The ANAME record indicates to a client that it might wish to resolve 254 the target address records itself. The target address records might 255 not be available if the server is authoritative and does not include 256 out-of-zone or non-authoritative data in its answers, or if the 257 server is recursive and the records are not in the cache. 259 3.2. ANAME queries 261 When a server receives an query for type ANAME, there are three 262 possibilities: 264 o The query resolved to an ANAME record, and the server has the 265 target address records; any target address records SHOULD be added 266 to the Additional section. 268 o The query resolved to an ANAME record, and the server does not 269 have the target address records; any sibling address records 270 SHOULD be added to the Additional section. 272 o The query did not resolve to an ANAME record; any address records 273 with the same owner name SHOULD be added to the Additional section 274 of the NOERROR response. 276 When adding address records to the Additional section, if not all 277 address types are present and the zone is signed, the server SHOULD 278 include a DNSSEC proof of nonexistence for the missing address types. 280 4. Substituting ANAME sibling address records 282 This process is used by both primary masters (see Section 5) and 283 resolvers (see Section 6), though they vary in how they apply the 284 edit described in the final step. 286 The following steps MUST be performed for each address type: 288 1. Starting at the ANAME owner, follow the chain of ANAME and/or 289 CNAME records as far as possible to find the ultimate target. 291 2. If a loop is detected, continue with an empty RRset, otherwise 292 get the ultimate target's address records. (Ignore any sibling 293 address records of intermediate ANAMEs.) 295 3. Stop if resolution failed. (Note that NXDOMAIN and NODATA count 296 as successfully resolving an empty RRset.) 298 4. Replace the owner of the target address records with the owner of 299 the ANAME record. Reduce the TTL to match the ANAME record if it 300 is greater. Drop any RRSIG records. 302 5. Stop if this modified RRset is the same as the sibling RRset 303 (ignoring any RRSIG records). The comparison MAY treat nearly- 304 equal TTLs as the same. 306 6. Delete the sibling address RRset and replace it with the modified 307 RRset. 309 At this point, the substituted RRset is not signed. A primary master 310 will proceed to sign the substituted RRset, whereas resolvers can 311 only use the substituted RRset when an unsigned answer is 312 appropriate. This is explained in more detail in the following 313 sections. 315 5. ANAME processing by primary masters 317 Each ANAME's sibling address records are kept up-to-date as if by the 318 following process, for each address type: 320 o Perform ANAME sibling address record substitution as described in 321 Section 4. Any edit performed in the final step is applied to the 322 ANAME's zone in the same manner as a DNS UPDATE [RFC2136]. 324 o If resolution failed, wait for a period before trying again. This 325 retry time SHOULD be configurable. 327 o Otherwise, wait until the target address record TTL has expired, 328 then repeat. 330 The following informative subsections explore the effects of this 331 specification, to clarify how it can work in practice. 333 5.1. Implications 335 A zone containing ANAME records has to be a dynamic zone, similar to 336 automatic DNSSEC signature maintenance. 338 DNSSEC signatures on sibling address records are generated in the 339 same way as for normal DNS UPDATEs. 341 Sibling address records are committed to the zone and stored in 342 nonvolatile storage. This allows a server to restart without delays 343 due to ANAME processing. 345 A zone containing ANAME records that point to frequently-changing 346 targets will itself change frequently, which can increase the number 347 of zone transfers. 349 Sibling address records are served from authoritative servers with a 350 fixed TTL. Normally this TTL is expected to be the same as the 351 target address records' TTL (or the ANAME TTL if that is smaller); 352 however the exact mechanism for obtaining the target is unspecified, 353 so cache effects or deliberate policies might make the sibling TTL 354 smaller. There is a longer discussion of TTL handling in {#ttls}. 356 Secondary servers rely on zone transfers to obtain sibling address 357 records, just like the rest of the zone, and serve them in the usual 358 way (with Section 3 Additional section processing if they support 359 it). A working DNS NOTIFY [RFC1996] setup is necessary to avoid 360 extra delays propagating updated sibling address records when they 361 change. 363 5.2. Alternatives 365 The process at the start of this section is specified using the 366 mighty weasel words "as if", which are intended to allow a great deal 367 of latitude to implementers so long as the observed behaviour is 368 compatible. 370 For instance, it is likely to be more efficient to manage the polling 371 per ANAME target rather than per ANAME as specified. 373 More radically, some existing ANAME-like implementations are based on 374 a different DNS server architecture, in which a zone's published 375 authoritative servers all perform the duties of a primary master in a 376 distributed manner: provisioning records from a non-DNS back-end 377 store, refreshing DNSSEC signatures, and so forth. This architecture 378 does not use standard zone transfers, so there is no need for its 379 ANAME implementation to poll the target address records to ensure 380 that its secondary servers are up to date (because there are no 381 secondary servers as such). Instead the authoritative servers can do 382 ANAME sibling address substitution on demand. 384 There are other variant architectures which use zone transfers within 385 the provisioning system, but where the authoritative servers are able 386 to independently vary the zone contents. They can conform to this 387 specification provided their behaviour is consistent with it: unusual 388 behaviour can appear "as if" there were a rapidly updating zone or 389 multiple primary masters, etc. 391 The exact mechanism for obtaining the target address records is 392 unspecified; typically they will be resolved in the DNS in the usual 393 way, but if an ANAME implementation has special knowledge of the 394 target it can short-cut the substitution process, or use clever 395 tricks such as client-dependant answers. 397 6. ANAME processing by resolvers 399 When a resolver makes an address query in the usual way, it might 400 receive a response containing ANAME information in the additional 401 section, as described in Section 3. This informs the resolver that 402 it MAY resolve the ANAME target address records to get answers that 403 are tailored to the resolver rather than the ANAME's primary master. 404 It SHOULD include the target address records in the Additional 405 section of its responses as described in Section 3. 407 In order to provide tailored answers to clients that are ANAME- 408 oblivious, the resolver MAY do its own sibling address record 409 substitution in the following situations: 411 o The resolver's client queries with DO=0. (As discussed in 412 Section 8, if the resolver finds it would downgrade a secure 413 answer to insecure, it MAY choose not to substitute the sibling 414 address records.) 416 o The resolver's client queries with DO=1 and the ANAME and sibling 417 address records are unsigned. (Note that this situation does not 418 apply when the records are signed but insecure: the resolver might 419 not be able to validate them because of a broken chain of trust, 420 but its client could have an extra trust anchor that does allow it 421 to validate them; if the resolver substitutes the sibling address 422 records they will become bogus.) 424 In these first two cases, the resolver MAY perform ANAME sibling 425 address record substitution as described in Section 4. Any edit 426 performed in the final step is applied to response's Answer section. 427 The resolver SHOULD then perform Additional section processing as 428 described in Section 3. 430 If the resolver's client is querying using an API such as 431 "getaddrinfo" [RFC3493] that does not support DNSSEC validation, the 432 resolver MAY perform ANAME sibling address record substitution as 433 described in Section 4. Any edits performed in the final step are 434 applied to the addresses returned by the API. (This case is for 435 validating stub resolvers that query an upstream recursive server 436 with DO=1, so they cannot rely on the recursive server to do ANAME 437 substitution for them.) 439 7. IANA considerations 441 IANA is requested to assign a DNS RR TYPE value for ANAME resource 442 records under the "Resource Record (RR) TYPEs" subregistry under the 443 "Domain Name System (DNS) Parameters" registry. 445 IANA might wish to consider the creation of a registry of address 446 types; addition of new types to such a registry would then implicitly 447 update this specification. 449 8. Security considerations 451 When a primary master updates an ANAME's sibling address records to 452 match its target address records, it is uses its own best information 453 as to the correct answer. The updated records might be signed by the 454 primary master, but that is not a guarantee of the actual correctness 455 of the answer. This can have the effect of promoting an insecure 456 response from the ANAME to a signed response from the 457 , which can then appear to clients to be more trustworthy than 458 it should. To mitigate harm from this, DNSSEC validation SHOULD be 459 used when resolving the ANAME . Primary masters MAY refuse 460 to substitute ANAME sibling address records unless the node 461 is both signed and validated. 463 When a resolver substitutes an ANAME's sibling address records, it 464 can find that the sibling address records are secure but the target 465 address records are insecure. Going ahead with the substitution will 466 downgrade a secure answer to an insecure one. But this is likely to 467 be the counterpart of the situation described in the previous 468 paragraph, so the resolver is downgrading an answer that the ANAME's 469 primary master upgraded. A resolver will only downgrade an answer in 470 this way when its client is security-oblivious; however the client's 471 path to the resolver is likely to be practically safer than the 472 resolver's path to the ANAME target's servers. Resolvers MAY choose 473 not to substitute sibling address records when they are more secure 474 than the target address records. 476 9. References 478 9.1. Normative References 480 [I-D.ietf-dnsop-terminology-bis] 481 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 482 Terminology", draft-ietf-dnsop-terminology-bis-14 (work in 483 progress), September 2018. 485 [RFC1033] Lottor, M., "Domain Administrators Operations Guide", 486 RFC 1033, DOI 10.17487/RFC1033, November 1987, 487 . 489 [RFC1035] Mockapetris, P., "Domain names - implementation and 490 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 491 November 1987, . 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, 495 DOI 10.17487/RFC2119, March 1997, 496 . 498 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 499 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 500 RFC 2136, DOI 10.17487/RFC2136, April 1997, 501 . 503 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 504 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 505 2003, . 507 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 508 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 509 May 2017, . 511 9.2. Informative References 513 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 514 RFC 882, DOI 10.17487/RFC0882, November 1983, 515 . 517 [RFC0973] Mockapetris, P., "Domain system changes and observations", 518 RFC 973, DOI 10.17487/RFC0973, January 1986, 519 . 521 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 522 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 523 . 525 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 526 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 527 August 1996, . 529 [RFC2065] Eastlake 3rd, D. and C. Kaufman, "Domain Name System 530 Security Extensions", RFC 2065, DOI 10.17487/RFC2065, 531 January 1997, . 533 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 534 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 535 . 537 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 538 Stevens, "Basic Socket Interface Extensions for IPv6", 539 RFC 3493, DOI 10.17487/RFC3493, February 2003, 540 . 542 9.3. URIs 544 [1] https://github.com/each/draft-aname 546 Appendix A. Acknowledgments 548 Thanks to Mark Andrews, Ray Bellis, Stefan Buehler, Paul Ebersman, 549 Richard Gibson, Tatuya JINMEI, Hakan Lindqvist, Mattijs Mekking, 550 Stephen Morris, Bjorn Mott, Richard Salts, Mukund Sivaraman, Job 551 Snijders, Jan Vcelak, Paul Vixie, Duane Wessels, and Paul Wouters for 552 discussion and feedback. 554 Appendix B. Implementation status 556 PowerDNS currently implements a similar authoritative-only feature 557 using "ALIAS" records, which are expanded by the primary server and 558 transfered as address records to secondaries. 560 [TODO: Add discussion of DNSimple, DNS Made Easy, EasyDNS, 561 Cloudflare, Amazon, Dyn, and Akamai.] 563 Appendix C. Historical note 565 In the early DNS [RFC0882], CNAME records were allowed to coexist 566 with other records. However this led to coherency problems: if a 567 resolver had no cache entries for a given name, it would resolve 568 queries for un-cached records at that name in the usual way; once it 569 had cached a CNAME record for a name, it would resolve queries for 570 un-cached records using CNAME target instead. 572 For example, given the zone contents below, the original CNAME 573 behaviour meant that if you asked for "alias.example.com TXT" first, 574 you would get the answer "owner", but if you asked for 575 "alias.example.com A" then "alias.example.com TXT" you would get the 576 answer "target". 578 alias.example.com. TXT "owner" 579 alias.example.com. CNAME canonical.example.com. 580 canonical.example.com. TXT "target" 581 canonical.example.com. A 192.0.2.1 583 This coherency problem was fixed in [RFC0973] which introduced the 584 inconvenient rule that a CNAME acts as an alias for all other RR 585 types at a name, which prevents the coexistence of CNAME with other 586 records. 588 A better fix might have been to improve the cache's awareness of 589 which records do and do not coexist with a CNAME record. However 590 that would have required a negative cache mechanism which was not 591 added to the DNS until later [RFC1034] [RFC2308]. 593 While [RFC2065] relaxed the restriction by allowing coexistence of 594 CNAME with DNSSEC records, this exception is still not applicable to 595 other resource records. RRSIG and NSEC exist to prove the integrity 596 of the CNAME record; they are not intended to associate arbitrary 597 data with the domain name. DNSSEC records avoid interoperability 598 problems by being largely invisible to security-oblivious resolvers. 600 Now that the DNS has negative caching, it is tempting to amend the 601 algorithm for resolving with CNAME records to allow them to coexist 602 with other types. Although an amended resolver will be compatible 603 with the rest of the DNS, it will not be of much practical use 604 because authoritative servers which rely on coexisting CNAMEs will 605 not interoperate well with older resolvers. Practical experiments 606 show that the problems are particularly acute when CNAME and MX try 607 to coexist. 609 Appendix D. On preserving TTLs 611 An ANAME's sibling address records are in an unusual situation: they 612 are authoritative data in the owner's zone, so from that point of 613 view the owner has the last say over what their TTL should be; on the 614 other hand, ANAMEs are supposed to act as aliases, in which case the 615 target should control the address record TTLs. 617 However there are some technical constraints that make it difficult 618 to preserve the target address record TTLs. 620 The conclusion of the following subsections is that the end-to-end 621 TTL (from the authoritative servers for the target address records to 622 end-user DNS caches) will be the target address record TTL plus the 623 sibling address record TTL. 625 [MM: Discuss: I think it should be just the ANAME record TTL perhaps 626 the minimum of ANAME and sibling address RRset TTL. We should 627 provide some guidance on TTL settings for ANAME). 629 [TF: see issue #30] 631 D.1. Query bunching 633 If the times of end-user queries for a domain name are well 634 distributed, then (normally) queries received by the authoritative 635 servers for that domain are also well distributed. If the domain is 636 popular, a recursive server will re-query for it once every TTL 637 seconds, but the periodic queries from all the various recursive 638 servers will not be aligned, so the queries remain well distributed. 640 However, imagine that the TTLs of an ANAME's sibling address records 641 are decremented in the same way as cache entries in recursive 642 servers. Then all the recursive servers querying for the name will 643 try to refresh their caches at the same time, when the TTL reaches 644 zero. They will become synchronized and all the queries for the 645 domain will be bunched into periodic spikes. 647 This specification says that ANAME sibling address records have a 648 normal fixed TTL derived from (e.g. equal or nearly equal to) the 649 target address records' original TTL. There is no cache-like 650 decrementing TTL, so there is no bunching of queries. 652 D.2. Upstream caches 654 There are two straightforward ways to get an RRset's original TTL: 656 o by directly querying an authoritative server; 658 o using the original TTL field from the RRset's RRGIG record(s). 660 However, not all zones are signed, and a primary master might not be 661 able to directly query other authoritative servers (e.g. if it is a 662 hidden primary behind a strict firewall). Instead it might have to 663 obtain an ANAME's target address records via some other recursive 664 server. 666 Querying via a separate recursive server means the primary master 667 cannot trivially obtain the target address records' original TTLs. 669 Fortunately this is likely to be a self-correcting problem for 670 similar reasons to the query-bunching discussed in the previous 671 subsection. The primary master re-checks the target address records 672 just after the TTL expires, when its upstream cache has just 673 refreshed them, so the TTL will be nearly equal to the original TTL. 675 A related consideration is that the primary master cannot in general 676 refresh its copies of an ANAME's target address records more 677 frequently than their TTL, without privileged control over its 678 resolver cache. 680 Combined with the requirement that sibling address records are served 681 with a fixed TTL, this means that the end-to-end TTL will be the 682 target address record TTL (which determines when the sibling address 683 records are updated) plus the sibling address record TTL (which 684 determines when end-user caches are updated). 686 D.3. ANAME chains 688 ANAME sibling address record substitution is made slightly more 689 complicated by the requirement to follow chains of ANAME and/or CNAME 690 records. This stops the end-to-end TTL from being inflated by each 691 ANAME in the chain. 693 D.4. TTLs and zone transfers 695 When things are working properly (with secondary name servers 696 responding to NOTIFY messages promptly) the authoritative servers 697 will follow changes to ANAME target address records according to 698 their TTLs. As a result the end-to-end TTL is unchanged from the 699 previous subsection. 701 If NOTIFY doesn't work, the TTLs can be stretched by the zone's SOA 702 refresh timer. More serious breakage can stretch them up to the zone 703 expiry time. 705 Appendix E. Answer vs Additional sections 707 [MM: Discuss what should be in the additional section: ANAME makes 708 sense, but differs from CNAME logic (where the CNAME is in the answer 709 section). Additional target records that match the query type in my 710 opinion should go in the answer section. Additional target address 711 records that do not match the query type can go in the additional 712 section]. 714 [TF: from experience with DNAME I think there's a risk of interop 715 problems if we put unexpected records in the answer section, so I 716 said everything should go in additional. We'll expand this appendix 717 to explain the rationale.] 719 Appendix F. Changes since the last revision 721 [This section is to be removed before publication as an RFC.] 723 The full history of this draft and its issue tracker can be found at 724 https://github.com/each/draft-aname [1] 726 o "-02": Major revamp, so authoritative servers (other than primary 727 masters) now do not do any special ANAME processing, just 728 Additional section processing. 730 Authors' Addresses 732 Tony Finch 733 University of Cambridge 734 University Information Services 735 Roger Needham Building 736 7 JJ Thomson Avenue 737 Cambridge CB3 0RB 738 England 740 Email: dot@dotat.at 742 Evan Hunt 743 ISC 744 950 Charter St 745 Redwood City, CA 94063 746 USA 748 Email: each@isc.org 750 Peter van Dijk 751 PowerDNS.COM B.V. 752 Den Haag 753 The Netherlands 755 Email: peter.van.dijk@powerdns.com 756 Anthony Eden 757 DNSimple 758 Boston, MA USA 760 Email: anthony.eden@dnsimple.com 761 URI: https://dnsimple.com/