Domain Name System Operations Y. Zeng
Internet-Draft H. Zhang
Intended status: Best Current Practice N. Wang
Expires: November 2, 2017 J. Yao
May 2017

Exclusive RR type for multi-CDN support


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

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 ( in effect on the date of 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

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.

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:

Multi-CDN user examples
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
Microsoft 2 CDNs

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):

    +-------+     +------+ +------------+
    | CDN C |<----| user |------------------->|  resolver  |
    +-------+     |      |<-------------------|            |
                  +------+  address of CDN C  +------------+
    +-------+                                  | A  | A  | A
    | CDN A |                     +------------+ |  | |  | |  +-----------+          
    +-------+                     | +------------+  | |  | +--| Multi-CDN |
                                  V |               | |  +--->|  provider |
                            +-----------+           V |       +-----------+
    +-------+               | CDN C DNS |      +-------------+
    | CDN B |               +-----------+      ||
    +-------+                                  |     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, the recursive server retrieves the answer from authoritative DNS server and is redirected to the DNS server for "". DNS server receives the query, identifies the subscribing customer ( and based on the traffic management logic configured for, determines which of the CDNs 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 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 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).

    +-------+     +------+   +------------+
    | CDN C |<----| user |--------------------->|  resolver  |
    +-------+     |      |<---------------------|            |
                  +------+  address of CDN C    +------------+
    +-------+                                   | A  | A  
    | CDN A |                     +-------------+ |  | |            
    +-------+                     | +-------------+  | |  
                                  V |                | |  
                            +-----------+            V |         
    +-------+               | CDN C DNS |      +-----------------------+
    | CDN B |               +-----------+      | 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.

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:    IN    CDNNAME    cdn1.service.
                        IN    CDNNAME    cdn2.service.
                        IN    CDNNAME    cdn3.service.

    ;;Question    IN    CDNNAME

    ;;Answer    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.

    ;;Zone cut:    IN    CDNNAME    cdn1.service.
                        IN    CDNNAME    cdn2.service.
                        IN    CDNNAME    cdn3.service.

    ;;Question    IN    A/AAAA

    ;;Answer    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 "* 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.

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:, 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 "", one of the name servers of domain "" depending on a number of factors, most importantly the shortest Round Trip Time(RTT):

	;;Question    IN    A
	;;redirected to Multi-CDN provider Cedexis    IN    CNAME 

We can see that the domain "" has been CNAMEd to the Multi-CDN provider "Cedexis". The resolver replaces the query name by "" and restarts a recursive query. The resolver send the query to "", one of the name servers of domain ""

	;;Question    IN    A
	;;redirected to Akamai CDN    IN    CNAME 

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    IN    A
	;;Answer    IN    CNAME       IN    CNAME
	;;address of Akamai's edge server            IN    A

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.

	;;Question    IN    A
	;;redirected to Highwinds CDN    IN    CNAME 

With the CDNNAME RR type, the example can be configured at the authoritative DNS server side as following:

    ;;Zone cut:    IN    CDNNAME
                        IN    CDNNAME

4. References

4.1. Normative References

[I-D.hunt-dnsop-aname] Hunt, E., Dijk, P. and A. Eden, "Address-specific DNS Name Redirection (ANAME)", Internet-Draft draft-hunt-dnsop-aname-00, 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:
Haikuo Zhang CNNIC 4 South 4th Street,Zhongguancun,Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3163 EMail:
Nan Wang CNNIC 4 South 4th Street,Zhongguancun,Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3275 EMail:
Jiankang Yao CNNIC 4 South 4th Street,Zhongguancun,Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3007 EMail: