Exclusive RR type for multi-CDN support

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.

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.

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

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

| resolver | +-------+ | |<-------------------| | +------+ address of CDN C +------------+ +-------+ | A | A | A | CDN A | +------------+ | | | | | +-----------+ +-------+ | +------------+ | | | +--| Multi-CDN | V | | | +--->| provider | +-----------+ V | +-----------+ +-------+ | CDN C DNS | +-------------+ | CDN B | +-----------+ | example.com.| +-------+ | DNS | +-------------+ ]]> 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).

| resolver | +-------+ | |<---------------------| | +------+ address of CDN C +------------+ +-------+ | A | A | CDN A | +-------------+ | | | +-------+ | +-------------+ | | V | | | +-----------+ V | +-------+ | CDN C DNS | +-----------------------+ | CDN B | +-----------+ | example.com. DNS | +-------+ | integrated CDN | | balancing | +-----------------------+ ]]> 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.

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 section 10.1:

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.

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.

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 . The <target> field MUST be present. The presentation format of <target> is that of a domain name . The presentation format of the RR is as follows:

CDNNAME ]]>

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.

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.

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.

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.

There are several issues to be aware of about the use of 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.

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.

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.

Both authoritative servers and resolvers that implement CDNNAME should carefully check for loops and treat them as an error condition.

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

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. The resolver send the query to "flipd.cedexis.net.", one of the name servers of domain "cedexis.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.

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.

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