[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/