idnits 2.17.1 draft-gong-dnsop-optimal-retrieval-edns-00.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (May 22, 2020) is 1428 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 dnsop D. Gong 3 Internet-Draft P. Zhang 4 Intended status: Informational CFIEC-Guangzhou 5 Expires: November 23, 2020 May 22, 2020 7 Optimal Retrieval Process for DNS Based on EDNS 8 draft-gong-dnsop-optimal-retrieval-edns-00 10 Abstract 12 This document specifies a mechanism for query-response protocol to 13 improve DNS retrieval efficiency,which makes the resolver always look 14 for the best authoritative servers to ask for the required data.Based 15 on the extension mechanisms for DNS,optimal-result using OPT pseudo- 16 RR can be added to the addtional data section of either a request or 17 a response,which contains the information of optimal authoritative 18 servers by testing. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 23, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 2 56 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Optimal root servers . . . . . . . . . . . . . . . . . . . . 3 58 3. Service Quality Testing . . . . . . . . . . . . . . . . . . . 3 59 4. Optimal-result Format . . . . . . . . . . . . . . . . . . . . 4 60 5. Transport Considerations . . . . . . . . . . . . . . . . . . 5 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 At present,the resolver undertaking the actual resolution either 69 responds to queries from the local cache or sends queries to the 70 authoritative server in order to get corresponding answers to the 71 original queries.But how to find the best authoritative servers to 72 ask without cached date is very important,that it determines the 73 performance of resolution.In particular,service quality of IPv6 74 servers is unstable during the transition from IPv4 to IPv6. 76 As a result,this document is meant to optimize the retrieval process 77 between the resolver and the authoritative servers.The authoritative 78 servers with the best service quality are determined by periodically 79 testing the connectivity of specific authoritative servers,that there 80 are also corresponding priority orders.Hence,the resolver can receive 81 the priority information embedded in the message to pursue 82 queries.And the Optimal-result format with priority information is 83 designed,which is a new format compatible with existing DNS message 84 format. 86 1.1. Requirements Notation 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 89 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 90 this document are to be interpreted as described in [RFC8174]. 92 1.2. Applicability 94 This document is applicable to the recursive resolver that pursues 95 queries and the authoritative server that supports the detection of 96 next-level authoritative servers. 98 2. Optimal root servers 100 Optimal root servers are often determined by the resolver,that the 101 general strategy is to look for locally-available root servers or 102 test the service quality of specific root servers periodically.In 103 order to improve the reliability of retrieval process,Yeti-root 104 servers and local mirror servers with the root zone are optional. 106 3. Service Quality Testing 108 As the following Figure 1,DNS is a hierarchy,recursive resolver 109 starts with root server.TLD server can be found using the contents 110 the root server konws,that the second-level domain server is below 111 the TLD server.In order to respond optimal-result,each authoritative 112 server needs to know the priority information by testing service 113 quality of next-level authoritative servers at regular intervals. 115 +----------------+ 116 Query | Root | 117 ----------+ Server | 118 / Response +-------+--------+ 119 / |Test for QoS 120 / | 121 +---------------+ +-------+--------+ 122 | Recursive | Query | TLD | 123 | Server +-------------+ Server | 124 +---------------+ Response +-------+--------+ 125 \ |Test for QoS 126 \ | 127 \ Query +-------+--------+ 128 ----------+ Second-level | 129 Response | Domain Server | 130 +----------------+ 132 Figure 1: The Architecture of DNS 134 For the authoritative server that supports the detection,it needs to 135 test Qos of next-level server cluster periodically as above.In the 136 following Figure 2,load balancer which implements test function can 137 integrate with the authoritative service through plug-ins,based on 138 the existing condition of the authoritative server.Load balancer 139 contains respond module,test module,prefetch module and local cached 140 module. And the prefetch module get the authoritative data from the 141 authoritative service according to TTL of cached data and store in 142 the local cached module,so that the respond module can answer the 143 query service's quries using cached data with the priority 144 informaiton through the detection of the test module. 146 +----------------+ +----------------+ 147 | Query | | next-level | 148 | service | | server cluster | 149 +-------+--------+ +--------+-------+ 150 Query|Response |Test for Qos 151 +-----------|--------------------|-------------------------------+ 152 | +-------+--------+ +--------+-------+ +----------------+ | 153 | | Respond | | Test | | Prefetch | | 154 | | Module | | Module | | Module | | 155 | +--------------+-+ +--------+-------+ +--+-----------+-+ | 156 | \ | / | | 157 | \ | / | | 158 | +---+----------+----------+---------+ | | 159 | Load Balancer | Local | | | 160 | | Cached module | | | 161 | +-----------------------------------+ | | 162 +----------------------------------------------------------|-----+ 163 |Prefetch 164 +-------------------+-----+ 165 | Authoritative | 166 | service | 167 +-------------------------+ 168 Figure 2: The Architecture of Detection 170 4. Optimal-result Format 172 As described in [RFC1035],All communications inside of the domain 173 protocol are carried in a single format called a message. The top 174 level format of message is divided into 5 sections,which consists of 175 header section,question section,answer section,authority section and 176 additional section. 178 However,above message includes a number of fixed fields whose range 179 has been or soon will be exhausted and does not allow requestors to 180 advertise their capabilities to responders.So opt pseudo-RR added to 181 the additional section is used to provide a backward-compatible 182 mechanism for embedding control information,detailed format is 183 described in [RFC6891]. 185 Based on opt pseudo-RR,the resolver can deliver the request about 186 optimal-result and receive the response which can refer to the best 187 server.And the optimal-result is added to the OPTION-DATA section of 188 the opt pseudo-RR marked by OPTION-CODE.The optimal-result has a 189 fixed part and a variable part,as shown in the following Figure 3. 191 +0 (MSB) +1 (LSB) 192 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 193 0: | OPTIMAL-ANSWER-COUNT | 194 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 195 2: | OPTIMAL-AUTHORITY-COUNT | 196 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 197 4: | OPTIMAL-ADDITIONAL-COUNT | 198 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 199 6: | | 200 / RRS-Number / 201 / / 202 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 204 Figure 3: Optimal-result Format 206 o OPTIMAL-ANSWER-COUNT:an unsigned 16 bit integer specifying the 207 number of requests or responses about the optimal RRs answering 208 the question. 210 o OPTIMAL-AUTHORITY-COUNT:an unsigned 16 bit integer specifying the 211 number of requests or responses about the optimal RRs pointing 212 toward an authority. 214 o OPTIMAL-ADDITIONAL-COUNT:an unsigned 16 bit integer specifying the 215 number of requests or responses about the optimal RRs holding 216 additional information. 218 o RRS-Number:serial numbers generated according to the order of 219 correspongding RRs in the answer section,authority 220 section,additional section and sorted by the priority of 221 corresponding RRs. 223 5. Transport Considerations 225 The presence of optimal-result in a request should be taken as an 226 indication that the resolver needs to find the best authoritative 227 servers,and that compliant authoritative server can respond the 228 priority information embedded in the optimal-result based on the 229 detection itself.But the authoritative server that does not support 230 the protocol extensions defined in this document can ignore the 231 optimal-result section. 233 Lack of presence of optimal-result in a request should be taken as an 234 indication that the resolver does not need priority information or 235 does not support the optimal-result format,and that corresponding 236 authoritative server can implement standard responses. 238 6. Security Considerations 240 The security considerations about EDNS is described in [RFC6891]. 242 Additional consideration is that the resource records in the answer 243 section,authority section and additional section of responses need to 244 be retained. 246 7. IANA Considerations 248 The IANA has assigned RR type code 41 for OPT. 250 This document assigns option-code 18 for Optimal-result. 252 8. References 254 [RFC1035] Mockapetris, P., "Domain names - implementation and 255 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 256 November 1987, . 258 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 259 for DNS (EDNS(0))", STD 75, RFC 6891, 260 DOI 10.17487/RFC6891, April 2013, 261 . 263 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 264 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 265 May 2017, . 267 Authors' Addresses 269 Daobiao Gong 270 Guangzhou Root Chain International Network Research Institute Co., Ltd. 271 No.96 Qingsha Road, Dongchong Town, Guangzhou, Guangdong Province, China 272 Guangzhou 511458 273 P. R. China 275 Email: dbgong@biigroup.cn 277 Peng Zhang 278 Guangzhou Root Chain International Network Research Institute Co., Ltd. 279 No.96 Qingsha Road, Dongchong Town, Guangzhou, Guangdong Province, China 280 Guangzhou 511458 281 P. R. China 283 Email: pzhang@cfiec.net