idnits 2.17.1 draft-sonoda-dnsop-lb-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Mar 24, 2019) is 1860 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Domain Name System Operations Sonoda, Ed. 3 Internet-Draft Internet Initiative Japan Inc. 4 Intended status: Informational Mar 24, 2019 5 Expires: September 25, 2019 7 IP Location Load Balancing Resource Record 8 draft-sonoda-dnsop-lb-01 10 Abstract 12 This document defines a new DNS load balance function that is able to 13 transfer information in zone transfer and not need online signing. 14 DNS base load balance is popular technology. It provides weight base 15 response and location base response. It have become an indispensable 16 part of traffic engineering. However, DNS base load balance can't 17 transfer load balance information in zone transfer and need online 18 singing because it is not standardized. This document defines a new 19 DNS resource record called "LB". LB RR provides the balancing 20 information weight, location and target domain name. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 25, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 1. Introduction 56 1.1. Current DNS load balancing 58 Current DNS load balancing provides traffic engineering.It use 59 special authoritative name server. It response is one address record 60 that is dynamic changes using network location and weight. It's used 61 for large traffic WEB site domain name that is important domain name. 62 Important domain name should be secure. 64 But Current DNS load balancing is not secure. Because Current DNS 65 load balancing can't send zone data by zone transfer. It's mean very 66 difficult to use multi service providers. That means weak for DDoS 67 Attack. If zone is signed, All name servers require private key for 68 dynamic signing because response is dynamic changes. Distributing 69 private key is not secure, It is increased risk of leakage private 70 key. 72 1.2. Propose new DNS load balancing 74 Propose new DNS load balancing concept is that Authoritative name 75 server uses "LB" RR to provide load balancing information and Clients 76 application uses "LB" RR to select target name. 78 "LB" RR defines load balancing settings that is network location and 79 weight and target domain name. Network location is string that 80 meaningful name of network. For example Country code (ex. 81 JP),subdivision code(ex. US-CA) and Autonomous System Number (ex. 82 AS65536). Weight is ratio value to use select target name. Target 83 name is pointer to address record. 85 "location.server" is special TXT record that is location information 86 at full service resolver. Application can use this value for 87 location selection. 89 2. The LB Resource Record 91 The LB RR has mnemonic LB. LB RR define load balancing information. 93 LB format below. 95 LB 97 The format is not class-sensitive. All fields are required. 99 field is a 2 octets, 1 or more natural number. 101 field is a "" [RFC1035]. 103 field is a "" [RFC1035]. 105 2.1. Define location 107 ::= "*" | | | 108 | | 110 ::= "AF" | "NA" | "AS" | "EU" | "NA" | "OC" | "SA" 112 ::= ISO 3166-1 alpha-2 Country code. 114 ::= ISO 3166-2 Codes for the representation of 115 names of countries and their subdivisions. 117 ::= "AS" [ ":" ] 119 ::= "+" 121 ::= 123 ::= any one of the ten digits 1 through 9 125 ::= any one of the ten digits 0 through 9 127 ::= any one of the 26 alphabetic characters A through Z in 128 upper case or any one of the ten digits 0 through 9. 130 2.2. Record example 132 example.jp. 3600 IN LB 1 * www.example.com. ; for any region 133 example.jp. 3600 IN LB 1 AS as.example.com. ; for ASIA region 134 example.jp. 3600 IN LB 1 JP jp1.example.jp. ; for JP region, weight 1 135 example.jp. 3600 IN LB 3 JP jp2.example.jp. ; for JP region, weight 3 136 example.jp. 3600 IN LB 1 JP-13 tokyo.example.jp. ; for tokyo region 137 example.jp. 3600 IN LB 1 AS2496 as65536.example.jp. ; for AS2496 138 example.jp. 3600 IN LB 1 AS2496:1 as65536.example.jp. ; for AS2496 139 example.jp. 3600 IN LB 1 +BEER beer.example.jp. ; private use 141 3. Full service resolver's location 143 "location.server" is special TXT record that is locations at full 144 service resolver. Locations in order of priority location that 145 resolver administrator like it. Apiplcation can use it for selecting 146 location. 148 3.1. Record example 150 location.server 0 CH TXT "AS2479" "JP-13" "JP" "AS" "*" 152 4. IANA Considerations 154 IANA is requested to assign a DNS RR data type value for the LB RR 155 type under the "Resource Record (RR) TYPEs" sub-registry under the 156 "Domain Name System (DNS) Parameters" registry. 158 5. Normative References 160 [RFC1035] Mockapetris, P., "Domain names - implementation and 161 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 162 November 1987, . 164 Author's Address 166 Manabu Sonoda (editor) 167 Internet Initiative Japan Inc. 169 Email: manabu-s@iij.ad.jp