Domain Name System Operations Y. Zeng Internet-Draft H. Zhang Intended status: Best Current Practice N. Wang Expires: November 2, 2017 J. Yao CNNIC May 2017 Exclusive RR type for multi-CDN support draft-zeng-dnsop-exclusive-rr-type-for-multi-cdn-00 Abstract With the boom of Multi-CDN services, more enterprises tend to apply Multi-CDN service to deliver better end user experience to online global audiences. However, the current Multi-CDN strategy has some defects. Different Multi-CDN providers have various implementations of CDN balancing, yet there is no such unified DNS protocol because that multiple CNAMEs violates DNS standards. Some Multi-CDN implementations MAY have extra lookups for CDN redirection which causes longer query latency. This document aims to provide an exclusive DNS RR type CDNNAME(CDN name) for Multi-CDN implementation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 2, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Zeng, et al. Expires November 2, 2017 [Page 1] Internet-Draft CDNNAME RR type May 2017 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. What is Multi-CDN . . . . . . . . . . . . . . . . . . . . 2 1.2. Multi-CDN providers . . . . . . . . . . . . . . . . . . . 2 1.3. Multi-CDN users . . . . . . . . . . . . . . . . . . . . . 3 1.4. Cons of current Multi-CDN strategy . . . . . . . . . . . 3 1.4.1. Extra query time . . . . . . . . . . . . . . . . . . 3 1.4.2. Lack of protocol support . . . . . . . . . . . . . . 5 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. The CDNNAME Resource Record . . . . . . . . . . . . . . . . . 6 2.1. Authoritative Server Behavior . . . . . . . . . . . . . . 6 2.2. Recursive Server Behavior . . . . . . . . . . . . . . . . 7 2.3. Other issues with CDNNAME . . . . . . . . . . . . . . . . 7 2.3.1. Zone Transfer and CDNNAME . . . . . . . . . . . . . . 7 2.3.2. Dynamic Update and CDNNAME . . . . . . . . . . . . . 8 2.4. IANA Considerations . . . . . . . . . . . . . . . . . . . 8 2.5. Security Considerations . . . . . . . . . . . . . . . . . 8 3. Implementation examples . . . . . . . . . . . . . . . . . . . 8 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Normative References . . . . . . . . . . . . . . . . . . 10 4.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction 1.1. What is Multi-CDN A Multi-CDN solution is an alternative to using a single CDN from one provider. Enterprises offering Multi-CDN solution distribute user traffic between CDN providers by certain CDN balancing technologies. With the CDN balancing technology, the fastest CDN provider is selected for the end user to maximize the web performance. 1.2. Multi-CDN providers Companies like AWS route53, Cedexis, NS1, Dyn offer the Multi-CDN service with an integration of the DNS service needed to manage traffic and a pool of performance data to base decisions on. The integration helps route traffic based on certain variables such as a web user's country of origin, their ISP, or any other data source. Zeng, et al. Expires November 2, 2017 [Page 2] Internet-Draft CDNNAME RR type May 2017 Other companies like Catchpoint, Deepfield, New Relic and Dynatrace provide only monitoring services which can be used to evaluate the performance of CDN providers. 1.3. Multi-CDN users The multi-CDN strategy has been in play for only a few years, here are some Multi-CDN user examples mentioned in the report of Bizety Technologies: +-------------------+-----------------------------------------------+ | Company | CDNs used | +-------------------+-----------------------------------------------+ | Netflix | 4 CDNs: Akamai, Level 3, EdgeCast and | | | Limelight | | Facebook | 3 CDNs: Akamai + 2 others | | LinkedIn | 3 CDNs | | Twitter | 3 CDNs | | World of Warcraft | 3 CDNs: Akamai + 2 others | | Hulu | 2 CDNs | | Overstock | 2 CDNs | | Walmart | 2 CDNs | | eBay | 2 CDNs | | Oracle | 2 CDNs | | SAP | 2 CDNs | | Microsoft | 2 CDNs | | AVG | 2 CDNs | | ESPN | 2 CDNs | +-------------------+-----------------------------------------------+ Table 1: Multi-CDN user examples 1.4. Cons of current Multi-CDN strategy 1.4.1. Extra query time Some Multi-CDN providers offer authoritative DNS service fully integrated performance and business logic based CDN balancing traffic management, while other providers require combining services from separate vendors to create a solution that enables the Multi-CDN strategies in industry. The differences between them have an impact on performance. The multiple vendor solutions work as follows (see figure 1): Zeng, et al. Expires November 2, 2017 [Page 3] Internet-Draft CDNNAME RR type May 2017 +-------+ +------+ www.example.com.? +------------+ | CDN C |<----| user |------------------->| resolver | +-------+ | |<-------------------| | +------+ address of CDN C +------------+ +-------+ | A | A | A | CDN A | +------------+ | | | | | +-----------+ +-------+ | +------------+ | | | +--| Multi-CDN | V | | | +--->| provider | +-----------+ V | +-----------+ +-------+ | CDN C DNS | +-------------+ | CDN B | +-----------+ | example.com.| +-------+ | DNS | +-------------+ Figure 1: Complexity of multi-vendor solutions for Multi-CDN management Customer creates a CNAME entry in their authoritative DNS pointing to the 3rd party Multi-CDN provider with traffic monitoring solution. When an end user queries the address of www.example.com, the recursive server retrieves the answer from example.com authoritative DNS server and is redirected to the DNS server for "Multicdn.service.com". Multicdn.service.com DNS server receives the query, identifies the subscribing customer (example.com) and based on the traffic management logic configured for example.com, determines which of the CDNs example.com is using will provide the best service for the requesting end user. The answer is another CNAME, this time it is the CNAME of the CDN selected by Multicdn.service.com. This results in another DNS lookup to find the actual A record (IP address) of the CDN. That information is returned to the user's device and their browser makes the connection to the web page. In short, the request for www.example.com requires 3 look-ups on 3 different authoritative DNS systems, run by 3 different providers. This complexity has significant downsides. The extra DNS lookups take extra query time. The integrated approach avoids these complexities and response delays. Traffic management logic and performance data associated with DNS records are integrated within the platform (see figure 2). Zeng, et al. Expires November 2, 2017 [Page 4] Internet-Draft CDNNAME RR type May 2017 +-------+ +------+ www.example.com.? +------------+ | CDN C |<----| user |--------------------->| resolver | +-------+ | |<---------------------| | +------+ address of CDN C +------------+ +-------+ | A | A | CDN A | +-------------+ | | | +-------+ | +-------------+ | | V | | | +-----------+ V | +-------+ | CDN C DNS | +-----------------------+ | CDN B | +-----------+ | example.com. DNS | +-------+ | integrated CDN | | balancing | +-----------------------+ Figure 2: Complexity of integrated solutions for Multi-CDN management This reduces the number of DNS look-ups required to direct users to the optimal CDN. In some cases, the entire process can be reduced to just one look-up. This integrated approach not only reduces response time latency, it makes configuration, management and troubleshooting of a complex multi-CDN infrastructure far easier. 1.4.2. Lack of protocol support From the analysis in the previous section, the Multi-CDN management integrates the authoritative DNS service with CDN balancing is a better solution. However, the Multi-CDN management needs multiple CNAMEs to be configured in the DNS, while multiple CNAMEs violates current DNS standards, as described in [RFC2181] section 10.1: ...The DNS CNAME ("canonical name") record exists to provide the canonical name associated with an alias name. There may be only one such canonical name for any one alias. In addition, DNS servers strictly enforce the CNAME rules. Since there is no such unified DNS standard protocol supporting multiple CNAMEs, Multi-CDN providers have their own implementations. 1.5. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Zeng, et al. Expires November 2, 2017 [Page 5] Internet-Draft CDNNAME RR type May 2017 2. The CDNNAME Resource Record The CDNNAME RR is exclusively used for CDN service implementation in DNS. Each CDNNAME RR indicates a CDN service of the RR owner, multiple CDNNAME RRs can be present at a DNS node for multi-CDN implementation. The CDNNAME supports integrated solutions of Multi- CDN management from DNS protocol standard level. The CDNNAME RR has mnemonic CDNNAME and type code [TBD]. It is CLASS-insensitive. Its RDATA is comprised of a single field, , which contains a fully qualified domain name that MUST be sent in uncompressed form [RFC1035] [RFC3597]. The field MUST be present. The presentation format of is that of a domain name [RFC1035]. The presentation format of the RR is as follows: CDNNAME 2.1. Authoritative Server Behavior When a CDNNAME RRset is present at a DNS node and a query is received by an authoritative server for type CDNNAME, the authoritative server returns the CDNNAME RRset in the answer section. ;;Zone cut: www.example.com. IN CDNNAME cdn1.service. IN CDNNAME cdn2.service. IN CDNNAME cdn3.service. ;;Question www.example.com. IN CDNNAME ;;Answer www.example.com. CDNNAME cdn1.service. CDNNAME cdn2.service. CDNNAME cdn3.service. When a CDNNAME RRset is present at a DNS node and a query is received by an authoritative server for type A or AAAA, the authoritative server returns a synthesized CNAME RR in the answer section. Zeng, et al. Expires November 2, 2017 [Page 6] Internet-Draft CDNNAME RR type May 2017 ;;Zone cut: www.example.com. IN CDNNAME cdn1.service. IN CDNNAME cdn2.service. IN CDNNAME cdn3.service. ;;Question www.example.com. IN A/AAAA ;;Answer www.example.com. CNAME cdn2.service. To synthesize the CNAME RR in the answer section, authoritative server selects one CDNNAME RR randomly from CDNNAME RRset or according self-specified CDN balancing strategies. The owner of a CDNNAME record MAY, if DNSSEC is in use, have SIG, NXT, and KEY RRs, but MUST have no other type data. The use of CDNNAME in conjunction with wildcards is discouraged. Thus, records of the form "*.example.com CDNNAME cdn.service" SHOULD NOT be used. A server MAY give a warning that the behavior is unspecified if such a wildcarded CDNNAME is loaded. The server MAY refuse it, refuse to load the zone, or refuse dynamic updates. 2.2. Recursive Server Behavior Recursive caching name servers can encounter both CNAME record and CDNNAME record at the same node, due to a change at the authoritative server where data from before and after the change resides in the cache. This conflict situation is a transitional phase that ends when the old data times out. Recursive caching name servers MUST perform CNAME synthesis on behalf of clients. 2.3. Other issues with CDNNAME There are several issues to be aware of about the use of CDNNAME. 2.3.1. Zone Transfer and CDNNAME When a zone containing CDNNAME records is transferred to a secondary server, the CDNNAME records are transferred; it is therefore RECOMMENDED that CDNNAME not be deployed in a zone unless all of the authoritative servers for that zone implement CDNNAME. Zeng, et al. Expires November 2, 2017 [Page 7] Internet-Draft CDNNAME RR type May 2017 2.3.2. Dynamic Update and CDNNAME CDNNAME records can be added, changed, and removed in a zone using dynamic update transactions. Adding a CDNNAME RR to a domain node occludes the CNAME RR that may exist under the node. If a dynamic update message attempts to add a CDNNAME with a given owner name, but a CNAME is associated with that name, then the server MUST ignore the CDNNAME. If a CDNNAME is already associated with that name, add the CDNNAME. If a CNAME is added with a given owner name, but a DNAME is associated with that name, then the CNAME MUST be ignored. 2.4. IANA Considerations IANA is requested to assign a DNS RR data type value for the CDNNAME RR type under the "Resource Record (RR) TYPEs" sub-registry under the "Domain Name System (DNS) Parameters" registry. 2.5. Security Considerations Both authoritative servers and resolvers that implement CDNNAME should carefully check for loops and treat them as an error condition. 3. Implementation examples Taking one of the Multi-CDN providers Cedexis as an example: When we access any domain(ex: tags.tiqcdn.com.), the browser first checks its local cache for the result. If local cache does not have the result, a query is sent to ISP's resolver to initiate a recursive query. The resolver queries "ns4.p08.dynect.net.", one of the name servers of domain "tiqcdn.com." depending on a number of factors, most importantly the shortest Round Trip Time(RTT): @204.13.251.8:53[ns4.p08.dynect.net.] ;;Question tags.tiqcdn.com. IN A ;;Answer ;;redirected to Multi-CDN provider Cedexis tags.tiqcdn.com. IN CNAME 2-01-2f1f-0001.cdx.cedexis.net. We can see that the domain "tags.tiqcdn.com." has been CNAMEd to the Multi-CDN provider "Cedexis". The resolver replaces the query name by "2-01-2f1f-0001.cdx.cedexis.net." and restarts a recursive query. Zeng, et al. Expires November 2, 2017 [Page 8] Internet-Draft CDNNAME RR type May 2017 The resolver send the query to "flipd.cedexis.net.", one of the name servers of domain "cedexis.net." @69.28.180.4:53[flipd.cedexis.net.] ;;Question 2-01-2f1f-0001.cdx.cedexis.net. IN A ;;Answer ;;redirected to Akamai CDN 2-01-2f1f-0001.cdx.cedexis.net. IN CNAME tags.tiqcdn.com.edgekey.net. The query is sent to the Multi-CDN host and this is where the Multi- CDN provider decides to which CDN the request should be route, based on some performance data produced by their monitoring system. The resolver will then go through the process of resolving the Akamai host until it reaches the edge server which will eventually store the content. ;;Question 2-01-2f1f-0001.cdx.cedexis.net. IN A ;;Answer 2-01-2f1f-0001.cdx.cedexis.net. IN CNAME tags.tiqcdn.com.edgekey.net. tags.tiqcdn.com.edgekey.net. IN CNAME e8091.b.akamaiedge.net. ;;address of Akamai's edge server e8091.b.akamaiedge.net. IN A 184.28.15.181 The CDN decision can vary from one request to another, for a different scenario where the Multi-CDN provider redirects the request to a different CDN provider, Highwinds. @69.28.180.4:53[flipd.cedexis.net.] ;;Question 2-01-2f1f-0001.cdx.cedexis.net. IN A ;;Answer ;;redirected to Highwinds CDN 2-01-2f1f-0001.cdx.cedexis.net. IN CNAME vip0x07f.ssl.hwcdn.net. With the CDNNAME RR type, the example can be configured at the authoritative DNS server side as following: ;;Zone cut: tags.tiqcdn.com. IN CDNNAME vip0x07f.ssl.hwcdn.net. IN CDNNAME tags.tiqcdn.com.edgekey.net. Zeng, et al. Expires November 2, 2017 [Page 9] Internet-Draft CDNNAME RR type May 2017 4. References 4.1. Normative References [I-D.hunt-dnsop-aname] Hunt, E., Dijk, P., and A. Eden, "Address-specific DNS Name Redirection (ANAME)", draft-hunt-dnsop-aname-00 (work in progress), April 2017. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, . [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 2003, . [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, . 4.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Authors' Addresses Yu Zeng CNNIC 4 South 4th Street,Zhongguancun,Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3020 Email: zengyu@cnnic.cn Zeng, et al. Expires November 2, 2017 [Page 10] Internet-Draft CDNNAME RR type May 2017 Haikuo Zhang CNNIC 4 South 4th Street,Zhongguancun,Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3163 Email: zhanghaikuo@cnnic.cn Nan Wang CNNIC 4 South 4th Street,Zhongguancun,Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3275 Email: wangnan@cnnic.cn Jiankang Yao CNNIC 4 South 4th Street,Zhongguancun,Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3007 Email: yaojk@cnnic.cn Zeng, et al. Expires November 2, 2017 [Page 11]