idnits 2.17.1 draft-zeng-dnsop-exclusive-rr-type-for-multi-cdn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 12 characters in excess of 72. == There are 12 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 2017) is 2538 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 237, but not defined == Unused Reference: 'I-D.hunt-dnsop-aname' is defined on line 415, but no explicit reference was found in the text == Unused Reference: 'RFC6672' is defined on line 432, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Operations Y. Zeng 3 Internet-Draft H. Zhang 4 Intended status: Best Current Practice N. Wang 5 Expires: November 2, 2017 J. Yao 6 CNNIC 7 May 2017 9 Exclusive RR type for multi-CDN support 10 draft-zeng-dnsop-exclusive-rr-type-for-multi-cdn-00 12 Abstract 14 With the boom of Multi-CDN services, more enterprises tend to apply 15 Multi-CDN service to deliver better end user experience to online 16 global audiences. However, the current Multi-CDN strategy has some 17 defects. Different Multi-CDN providers have various implementations 18 of CDN balancing, yet there is no such unified DNS protocol because 19 that multiple CNAMEs violates DNS standards. Some Multi-CDN 20 implementations MAY have extra lookups for CDN redirection which 21 causes longer query latency. This document aims to provide an 22 exclusive DNS RR type CDNNAME(CDN name) for Multi-CDN implementation. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 2, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. What is Multi-CDN . . . . . . . . . . . . . . . . . . . . 2 60 1.2. Multi-CDN providers . . . . . . . . . . . . . . . . . . . 2 61 1.3. Multi-CDN users . . . . . . . . . . . . . . . . . . . . . 3 62 1.4. Cons of current Multi-CDN strategy . . . . . . . . . . . 3 63 1.4.1. Extra query time . . . . . . . . . . . . . . . . . . 3 64 1.4.2. Lack of protocol support . . . . . . . . . . . . . . 5 65 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5 66 2. The CDNNAME Resource Record . . . . . . . . . . . . . . . . . 6 67 2.1. Authoritative Server Behavior . . . . . . . . . . . . . . 6 68 2.2. Recursive Server Behavior . . . . . . . . . . . . . . . . 7 69 2.3. Other issues with CDNNAME . . . . . . . . . . . . . . . . 7 70 2.3.1. Zone Transfer and CDNNAME . . . . . . . . . . . . . . 7 71 2.3.2. Dynamic Update and CDNNAME . . . . . . . . . . . . . 8 72 2.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 8 73 2.5. Security Considerations . . . . . . . . . . . . . . . . . 8 74 3. Implementation examples . . . . . . . . . . . . . . . . . . . 8 75 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 4.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 1.1. What is Multi-CDN 84 A Multi-CDN solution is an alternative to using a single CDN from one 85 provider. Enterprises offering Multi-CDN solution distribute user 86 traffic between CDN providers by certain CDN balancing technologies. 87 With the CDN balancing technology, the fastest CDN provider is 88 selected for the end user to maximize the web performance. 90 1.2. Multi-CDN providers 92 Companies like AWS route53, Cedexis, NS1, Dyn offer the Multi-CDN 93 service with an integration of the DNS service needed to manage 94 traffic and a pool of performance data to base decisions on. The 95 integration helps route traffic based on certain variables such as a 96 web user's country of origin, their ISP, or any other data source. 98 Other companies like Catchpoint, Deepfield, New Relic and Dynatrace 99 provide only monitoring services which can be used to evaluate the 100 performance of CDN providers. 102 1.3. Multi-CDN users 104 The multi-CDN strategy has been in play for only a few years, here 105 are some Multi-CDN user examples mentioned in the report of Bizety 106 Technologies: 108 +-------------------+-----------------------------------------------+ 109 | Company | CDNs used | 110 +-------------------+-----------------------------------------------+ 111 | Netflix | 4 CDNs: Akamai, Level 3, EdgeCast and | 112 | | Limelight | 113 | Facebook | 3 CDNs: Akamai + 2 others | 114 | LinkedIn | 3 CDNs | 115 | Twitter | 3 CDNs | 116 | World of Warcraft | 3 CDNs: Akamai + 2 others | 117 | Hulu | 2 CDNs | 118 | Overstock | 2 CDNs | 119 | Walmart | 2 CDNs | 120 | eBay | 2 CDNs | 121 | Oracle | 2 CDNs | 122 | SAP | 2 CDNs | 123 | Microsoft | 2 CDNs | 124 | AVG | 2 CDNs | 125 | ESPN | 2 CDNs | 126 +-------------------+-----------------------------------------------+ 128 Table 1: Multi-CDN user examples 130 1.4. Cons of current Multi-CDN strategy 132 1.4.1. Extra query time 134 Some Multi-CDN providers offer authoritative DNS service fully 135 integrated performance and business logic based CDN balancing traffic 136 management, while other providers require combining services from 137 separate vendors to create a solution that enables the Multi-CDN 138 strategies in industry. The differences between them have an impact 139 on performance. The multiple vendor solutions work as follows (see 140 figure 1): 142 +-------+ +------+ www.example.com.? +------------+ 143 | CDN C |<----| user |------------------->| resolver | 144 +-------+ | |<-------------------| | 145 +------+ address of CDN C +------------+ 146 +-------+ | A | A | A 147 | CDN A | +------------+ | | | | | +-----------+ 148 +-------+ | +------------+ | | | +--| Multi-CDN | 149 V | | | +--->| provider | 150 +-----------+ V | +-----------+ 151 +-------+ | CDN C DNS | +-------------+ 152 | CDN B | +-----------+ | example.com.| 153 +-------+ | DNS | 154 +-------------+ 156 Figure 1: Complexity of multi-vendor solutions for Multi-CDN 157 management 159 Customer creates a CNAME entry in their authoritative DNS pointing to 160 the 3rd party Multi-CDN provider with traffic monitoring solution. 161 When an end user queries the address of www.example.com, the 162 recursive server retrieves the answer from example.com authoritative 163 DNS server and is redirected to the DNS server for 164 "Multicdn.service.com". Multicdn.service.com DNS server receives the 165 query, identifies the subscribing customer (example.com) and based on 166 the traffic management logic configured for example.com, determines 167 which of the CDNs example.com is using will provide the best service 168 for the requesting end user. The answer is another CNAME, this time 169 it is the CNAME of the CDN selected by Multicdn.service.com. This 170 results in another DNS lookup to find the actual A record (IP 171 address) of the CDN. That information is returned to the user's 172 device and their browser makes the connection to the web page. In 173 short, the request for www.example.com requires 3 look-ups on 3 174 different authoritative DNS systems, run by 3 different providers. 176 This complexity has significant downsides. The extra DNS lookups 177 take extra query time. 179 The integrated approach avoids these complexities and response 180 delays. Traffic management logic and performance data associated 181 with DNS records are integrated within the platform (see figure 2). 183 +-------+ +------+ www.example.com.? +------------+ 184 | CDN C |<----| user |--------------------->| resolver | 185 +-------+ | |<---------------------| | 186 +------+ address of CDN C +------------+ 187 +-------+ | A | A 188 | CDN A | +-------------+ | | | 189 +-------+ | +-------------+ | | 190 V | | | 191 +-----------+ V | 192 +-------+ | CDN C DNS | +-----------------------+ 193 | CDN B | +-----------+ | example.com. DNS | 194 +-------+ | integrated CDN | 195 | balancing | 196 +-----------------------+ 198 Figure 2: Complexity of integrated solutions for Multi-CDN management 200 This reduces the number of DNS look-ups required to direct users to 201 the optimal CDN. In some cases, the entire process can be reduced to 202 just one look-up. This integrated approach not only reduces response 203 time latency, it makes configuration, management and troubleshooting 204 of a complex multi-CDN infrastructure far easier. 206 1.4.2. Lack of protocol support 208 From the analysis in the previous section, the Multi-CDN management 209 integrates the authoritative DNS service with CDN balancing is a 210 better solution. However, the Multi-CDN management needs multiple 211 CNAMEs to be configured in the DNS, while multiple CNAMEs violates 212 current DNS standards, as described in [RFC2181] section 10.1: 214 ...The DNS CNAME ("canonical name") record exists to 215 provide the canonical name associated with an alias 216 name. There may be only one such canonical name for 217 any one alias. 219 In addition, DNS servers strictly enforce the CNAME rules. Since 220 there is no such unified DNS standard protocol supporting multiple 221 CNAMEs, Multi-CDN providers have their own implementations. 223 1.5. Requirements Language 225 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 226 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 227 document are to be interpreted as described in RFC 2119 [RFC2119]. 229 2. The CDNNAME Resource Record 231 The CDNNAME RR is exclusively used for CDN service implementation in 232 DNS. Each CDNNAME RR indicates a CDN service of the RR owner, 233 multiple CDNNAME RRs can be present at a DNS node for multi-CDN 234 implementation. The CDNNAME supports integrated solutions of Multi- 235 CDN management from DNS protocol standard level. 237 The CDNNAME RR has mnemonic CDNNAME and type code [TBD]. It is 238 CLASS-insensitive. 240 Its RDATA is comprised of a single field, , which contains a 241 fully qualified domain name that MUST be sent in uncompressed form 242 [RFC1035] [RFC3597]. The field MUST be present. The 243 presentation format of is that of a domain name [RFC1035]. 244 The presentation format of the RR is as follows: 246 CDNNAME 248 2.1. Authoritative Server Behavior 250 When a CDNNAME RRset is present at a DNS node and a query is received 251 by an authoritative server for type CDNNAME, the authoritative server 252 returns the CDNNAME RRset in the answer section. 254 ;;Zone cut: 255 www.example.com. IN CDNNAME cdn1.service. 256 IN CDNNAME cdn2.service. 257 IN CDNNAME cdn3.service. 259 ;;Question 260 www.example.com. IN CDNNAME 262 ;;Answer 263 www.example.com. CDNNAME cdn1.service. 264 CDNNAME cdn2.service. 265 CDNNAME cdn3.service. 267 When a CDNNAME RRset is present at a DNS node and a query is received 268 by an authoritative server for type A or AAAA, the authoritative 269 server returns a synthesized CNAME RR in the answer section. 271 ;;Zone cut: 272 www.example.com. IN CDNNAME cdn1.service. 273 IN CDNNAME cdn2.service. 274 IN CDNNAME cdn3.service. 276 ;;Question 277 www.example.com. IN A/AAAA 279 ;;Answer 280 www.example.com. CNAME cdn2.service. 282 To synthesize the CNAME RR in the answer section, authoritative 283 server selects one CDNNAME RR randomly from CDNNAME RRset or 284 according self-specified CDN balancing strategies. 286 The owner of a CDNNAME record MAY, if DNSSEC is in use, have SIG, 287 NXT, and KEY RRs, but MUST have no other type data. 289 The use of CDNNAME in conjunction with wildcards is discouraged. 290 Thus, records of the form "*.example.com CDNNAME cdn.service" SHOULD 291 NOT be used. A server MAY give a warning that the behavior is 292 unspecified if such a wildcarded CDNNAME is loaded. The server MAY 293 refuse it, refuse to load the zone, or refuse dynamic updates. 295 2.2. Recursive Server Behavior 297 Recursive caching name servers can encounter both CNAME record and 298 CDNNAME record at the same node, due to a change at the authoritative 299 server where data from before and after the change resides in the 300 cache. This conflict situation is a transitional phase that ends 301 when the old data times out. 303 Recursive caching name servers MUST perform CNAME synthesis on behalf 304 of clients. 306 2.3. Other issues with CDNNAME 308 There are several issues to be aware of about the use of CDNNAME. 310 2.3.1. Zone Transfer and CDNNAME 312 When a zone containing CDNNAME records is transferred to a secondary 313 server, the CDNNAME records are transferred; it is therefore 314 RECOMMENDED that CDNNAME not be deployed in a zone unless all of the 315 authoritative servers for that zone implement CDNNAME. 317 2.3.2. Dynamic Update and CDNNAME 319 CDNNAME records can be added, changed, and removed in a zone using 320 dynamic update transactions. Adding a CDNNAME RR to a domain node 321 occludes the CNAME RR that may exist under the node. 323 If a dynamic update message attempts to add a CDNNAME with a given 324 owner name, but a CNAME is associated with that name, then the server 325 MUST ignore the CDNNAME. If a CDNNAME is already associated with 326 that name, add the CDNNAME. If a CNAME is added with a given owner 327 name, but a DNAME is associated with that name, then the CNAME MUST 328 be ignored. 330 2.4. IANA Considerations 332 IANA is requested to assign a DNS RR data type value for the CDNNAME 333 RR type under the "Resource Record (RR) TYPEs" sub-registry under the 334 "Domain Name System (DNS) Parameters" registry. 336 2.5. Security Considerations 338 Both authoritative servers and resolvers that implement CDNNAME 339 should carefully check for loops and treat them as an error 340 condition. 342 3. Implementation examples 344 Taking one of the Multi-CDN providers Cedexis as an example: 346 When we access any domain(ex: tags.tiqcdn.com.), the browser first 347 checks its local cache for the result. If local cache does not have 348 the result, a query is sent to ISP's resolver to initiate a recursive 349 query. The resolver queries "ns4.p08.dynect.net.", one of the name 350 servers of domain "tiqcdn.com." depending on a number of factors, 351 most importantly the shortest Round Trip Time(RTT): 353 @204.13.251.8:53[ns4.p08.dynect.net.] 354 ;;Question 355 tags.tiqcdn.com. IN A 357 ;;Answer 358 ;;redirected to Multi-CDN provider Cedexis 359 tags.tiqcdn.com. IN CNAME 2-01-2f1f-0001.cdx.cedexis.net. 361 We can see that the domain "tags.tiqcdn.com." has been CNAMEd to the 362 Multi-CDN provider "Cedexis". The resolver replaces the query name 363 by "2-01-2f1f-0001.cdx.cedexis.net." and restarts a recursive query. 365 The resolver send the query to "flipd.cedexis.net.", one of the name 366 servers of domain "cedexis.net." 368 @69.28.180.4:53[flipd.cedexis.net.] 369 ;;Question 370 2-01-2f1f-0001.cdx.cedexis.net. IN A 372 ;;Answer 373 ;;redirected to Akamai CDN 374 2-01-2f1f-0001.cdx.cedexis.net. IN CNAME tags.tiqcdn.com.edgekey.net. 376 The query is sent to the Multi-CDN host and this is where the Multi- 377 CDN provider decides to which CDN the request should be route, based 378 on some performance data produced by their monitoring system. The 379 resolver will then go through the process of resolving the Akamai 380 host until it reaches the edge server which will eventually store the 381 content. 383 ;;Question 384 2-01-2f1f-0001.cdx.cedexis.net. IN A 386 ;;Answer 387 2-01-2f1f-0001.cdx.cedexis.net. IN CNAME tags.tiqcdn.com.edgekey.net. 388 tags.tiqcdn.com.edgekey.net. IN CNAME e8091.b.akamaiedge.net. 389 ;;address of Akamai's edge server 390 e8091.b.akamaiedge.net. IN A 184.28.15.181 392 The CDN decision can vary from one request to another, for a 393 different scenario where the Multi-CDN provider redirects the request 394 to a different CDN provider, Highwinds. 396 @69.28.180.4:53[flipd.cedexis.net.] 397 ;;Question 398 2-01-2f1f-0001.cdx.cedexis.net. IN A 400 ;;Answer 401 ;;redirected to Highwinds CDN 402 2-01-2f1f-0001.cdx.cedexis.net. IN CNAME vip0x07f.ssl.hwcdn.net. 404 With the CDNNAME RR type, the example can be configured at the 405 authoritative DNS server side as following: 407 ;;Zone cut: 408 tags.tiqcdn.com. IN CDNNAME vip0x07f.ssl.hwcdn.net. 409 IN CDNNAME tags.tiqcdn.com.edgekey.net. 411 4. References 413 4.1. Normative References 415 [I-D.hunt-dnsop-aname] 416 Hunt, E., Dijk, P., and A. Eden, "Address-specific DNS 417 Name Redirection (ANAME)", draft-hunt-dnsop-aname-00 (work 418 in progress), April 2017. 420 [RFC1035] Mockapetris, P., "Domain names - implementation and 421 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 422 November 1987, . 424 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 425 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 426 . 428 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 429 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 430 2003, . 432 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 433 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 434 . 436 4.2. Informative References 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, 440 DOI 10.17487/RFC2119, March 1997, 441 . 443 Authors' Addresses 445 Yu Zeng 446 CNNIC 447 4 South 4th Street,Zhongguancun,Haidian District 448 Beijing, Beijing 100190 449 China 451 Phone: +86 10 5881 3020 452 Email: zengyu@cnnic.cn 453 Haikuo Zhang 454 CNNIC 455 4 South 4th Street,Zhongguancun,Haidian District 456 Beijing, Beijing 100190 457 China 459 Phone: +86 10 5881 3163 460 Email: zhanghaikuo@cnnic.cn 462 Nan Wang 463 CNNIC 464 4 South 4th Street,Zhongguancun,Haidian District 465 Beijing, Beijing 100190 466 China 468 Phone: +86 10 5881 3275 469 Email: wangnan@cnnic.cn 471 Jiankang Yao 472 CNNIC 473 4 South 4th Street,Zhongguancun,Haidian District 474 Beijing, Beijing 100190 475 China 477 Phone: +86 10 5881 3007 478 Email: yaojk@cnnic.cn