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, <target>, which contains a
fully qualified domain name that MUST be sent in uncompressed form
[RFC1035] [RFC3597]. The <target> field MUST be present. The
presentation format of <target> is that of a domain name [RFC1035].
The presentation format of the RR is as follows:
<owner> <ttl> <class> CDNNAME <target>
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, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<http://www.rfc-editor.org/info/rfc2181>.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
2003, <http://www.rfc-editor.org/info/rfc3597>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<http://www.rfc-editor.org/info/rfc6672>.
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,
<http://www.rfc-editor.org/info/rfc2119>.
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]