Internet DRAFT - draft-zhang-dnsop-weighted-address-records

draft-zhang-dnsop-weighted-address-records







Internet Engineering Task Force                                 H. Zhang
Internet-Draft                                                    P. Zuo
Intended status: Standards Track                                  J. Yao
Expires: March 29, 2019                                            CNNIC
                                                      September 25, 2018


          New weighted resource record for traffic scheduling
             draft-zhang-dnsop-weighted-address-records-00

Abstract

   Scheduling traffic in proportion to different nodes can optimize
   bandwidth utilization and improve user experience when the Internet
   traffic exceeds the bandwidth limit of a CDN cache node.  This
   document defines AX and AAAAX RR types by adding weight field to
   existing A and AAAA resource records.  A group of weighted records
   will be sorted in the DNS response according to the weight in AX and
   AAAAX records.

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 https://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 March 29, 2019.

Copyright Notice

   Copyright (c) 2018 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
   (https://trustee.ietf.org/license-info) 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



Zhang, et al.            Expires March 29, 2019                 [Page 1]

Internet-DraftNew weighted resource record for traffic schSeptember 2018


   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.

1.  Introduction

   Most of CDNs can bring a client to the closest cache node according
   to the source IP of the client nowadays.  However, the rapid
   development of Internet raises new challenges.  According to public
   information, Global IP traffic will increase nearly threefold over
   the next 5 years and the busy-hour Internet traffic is growing more
   rapidly than average traffic.  For some CDNs, it becomes more
   frequent that peak traffic will exceed the bandwidth limit of their
   nodes and they need new solutions to optimize traffic scheduling.

   For example, if the maximum bandwidth for a CDN node is 10G and the
   busy-hour traffic reaches 12G, it is necessary to schedule 10G
   traffic to this node and the extra 2G traffic to other adjacent
   nodes.  Scheduling traffic in proportion to different nodes can
   optimize bandwidth utilization and improve user experience.

2.  Possible solutions

   In general, there are three ways to solve this problem:

   (1) Get browsers to comply with RFC 2782

   RFC 2782 describes a DNS RR which specifies the location of the
   server for a specific protocol and provides a server selection
   mechanism.  However, getting browsers to move is a long project.  In
   practice, RFC2782 is more suitable for service discovery but not
   widely adopted for dynamic web server selection.

   (2) Serve up multiple copies of the same RR and expect that record
   shuffling will deliver a specific ratio

   The multiple IP address listings is done in practice.  However, it is
   meaningless for two records to ever have label, class, type and data
   all equal - servers should suppress such duplicates if
   encountered.(as described in [RFC2181]) . Therefore, this method is
   not recommended as some servers may remove duplicates.

   (3) Get authoritative servers and resolvers to serve weighted A/AAAA
   records and short TTL

   CDNs are actually using a similar method nowadays.  Weighted A/AAAA
   records and short TTLs brings a dynamic server selection mechanism




Zhang, et al.            Expires March 29, 2019                 [Page 2]

Internet-DraftNew weighted resource record for traffic schSeptember 2018


   that optimizes traffic scheduling.  Compared to RFC2782, this is a
   light-weight solution that can be widely adopted easily.

   This document defines AX/AAAAX resource record to standardize the
   third method.  By adding weight filed in AX/AAAAX, a DNS server can
   serve address records with weighted frequency.  The similar mechanism
   currently works well in many authoritative servers in practice but
   very few resolvers support it.  Support from resolvers further
   optimizes scheduling but also increases complexity.  If the resolver
   should support this mechanism is a problem for future discussion.
   For compatibility, the authoritative DNS server that has AX/AAAAX RRs
   must reply A/AAAA RRs to weight-RR-not-aware resolvers.

3.  AX and AAAAX resource record

   The AX RR presentation format is similar to that of A RR except the
   weight field.The weight is a 16 bit unsigned interger:

   owner ttl class AX weight address

   The AAAAX RR presentation format is similar to that of AAAA RR except
   the weight field.The weight is a 16 bit unsigned interger:

   owner ttl class AAAAX weight address

4.  Authoritative Server Behavior

4.1.  Use of AX and AAAAX

   When AX or AAAAX records are present at a DNS node and a query is
   received by an authoritative server for type AX or AAAAX, the
   authoritative server should: (1) sort AX or AAAAX RRs according to
   the weight; (2) place the AX or AAAAX RRs in the answer section.

   When AX or AAAAX records are present at a DNS node and a query is
   received by an authoritative server for type A or AAAA, the
   authoritative server should: (1) remove weight field in AX or AAAAX;
   (2) sort A or AAAA RRs according to the weight in AX or AAAAX; (3)
   place the sorted A or AAAA RRs in the answer section;

4.2.  example










Zhang, et al.            Expires March 29, 2019                 [Page 3]

Internet-DraftNew weighted resource record for traffic schSeptember 2018


   Given the following zone:

   $ORIGIN  example.com.
   @ IN  SOA  example.com hostmaster.example.com 1 7200 3600 2419200 600
   @ IN  NS  ns1
   www  IN  AX  3  1.1.1.1.
   www  IN  AX  1  2.2.2.2


   the weight filed in the above 2 AX RRs indicates 1.1.1.1 should
   account for 75% for example.com/A query and 2.2.2.2 account for 25%.

   For the example.com/A queries:
   Three quarters of responses should be:

   ;; QUESTION SECTION:
   www.example.com.  IN  A
   ;; ANSWER SECTION:
   www.example.com.  60  IN  A  1.1.1.1
   www.example.com.  60  IN  A  2.2.2.2


   one quarter of responses should be:

   ;; QUESTION SECTION:
   www.example.com.  IN  A
   ;; ANSWER SECTION:
   www.example.com.  60  IN  A  2.2.2.2
   www.example.com.  60  IN  A  1.1.1.1


   For the example.com/AX queries, the server would return:

   ;; QUESTION SECTION:
   www.example.com.  IN  A
   ;; ANSWER SECTION:
   www.example.com.  60  IN  AX  3  1.1.1.1
   www.example.com.  60  IN  AX  1  2.2.2.2


4.3.  DNSSEC consideration

   If the zone that contains AX or AAAAX is DNSSEC-signed, for each AX
   or AAAAX, there must be a corresponding A or AAAA RR that has
   identical RDATA.  The corresponding A or AAAA RR must be signed.






Zhang, et al.            Expires March 29, 2019                 [Page 4]

Internet-DraftNew weighted resource record for traffic schSeptember 2018


5.  Recursive Server Behavior

   Support from resolvers will further optimizes traffic scheduling but
   increases complexity at the same time.  As the authoritative DNS
   server that has AX/AAAAX RRs must reply A/AAAA RRs for an A/AAAA
   query, this mechanism works well even if a resolver does not support
   it.

   If a resolver does not support this mechanism, which currently
   accounts for the majority of cases, it never receives any AX/AAAAX
   RRs.  It requires no extra implementation to support the weighted RRs
   mechanism.

   If a resolver supports this mechanism, it should determine if to use
   the weighted RRs according to local configuration.  Use of weighted
   address records in resolvers is an issue for further study.

6.  Implementation Status

   PowerDNS [https://powerdns.com] currently implements a similar
   authoritative-only feature using LUA records.

   DNS service provider CloudXNS [https://www.cloudxns.net] currently
   implements a similar authoritative-only feature using AX record that
   contains a priority value.

   CDN service provider UPYUN [https://www.upyun.com] currently adopts a
   similar mechanism to schedule traffic in busy hour.

7.  IANA Considerations

   IANA is requested to assign 2 DNS RR data type values for the AX and
   AAAAX RR type.

8.  References

   [RFC2181]  Elz, R. and R. Bush, ""Clarifications to the DNS
              Specification"", July 1997,
              <https://tools.ietf.org/html/rfc2181>.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, ""A DNS RR for
              specifying the location of services (DNS SRV)"", February
              2000, <https://tools.ietf.org/html/rfc2782>.








Zhang, et al.            Expires March 29, 2019                 [Page 5]

Internet-DraftNew weighted resource record for traffic schSeptember 2018


Authors' Addresses

   Haikuo Zhang
   CNNIC
   4 South 4th Street,Zhongguancun,Haidian District
   Beijing, Beijing  100190
   China

   Phone: +86 10 5881 3163
   Email: zhanghaikuo@cnnic.cn


   Peng Zuo
   CNNIC
   4 South 4th Street,Zhongguancun,Haidian District
   Beijing, Beijing  100190
   China

   Phone: +86 10 5881 2629
   Email: zuopeng@cnnic.cn


   Jiankang yao
   CNNIC
   4 South 4th Street,Zhongguancun,Haidian District
   Beijing, Beijing  100190
   China

   Phone: +86 10 5881 3007
   Email: yaojiankang@cnnic.cn





















Zhang, et al.            Expires March 29, 2019                 [Page 6]