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, . [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, ""A DNS RR for specifying the location of services (DNS SRV)"", February 2000, . 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]