| dnsop | D. Gong |
| Internet-Draft | P. Zhang |
| Intended status: Informational | CFIEC-Guangzhou |
| Expires: November 23, 2020 | May 22, 2020 |
Optimal Retrieval Process for DNS Based on EDNS
draft-gong-dnsop-optimal-retrieval-edns-00
This document specifies a mechanism for query-response protocol to improve DNS retrieval efficiency,which makes the resolver always look for the best authoritative servers to ask for the required data.Based on the extension mechanisms for DNS,optimal-result using OPT pseudo-RR can be added to the addtional data section of either a request or a response,which contains the information of optimal authoritative servers by testing.
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 November 23, 2020.
Copyright (c) 2020 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 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.
At present,the resolver undertaking the actual resolution either responds to queries from the local cache or sends queries to the authoritative server in order to get corresponding answers to the original queries.But how to find the best authoritative servers to ask without cached date is very important,that it determines the performance of resolution.In particular,service quality of IPv6 servers is unstable during the transition from IPv4 to IPv6.
As a result,this document is meant to optimize the retrieval process between the resolver and the authoritative servers.The authoritative servers with the best service quality are determined by periodically testing the connectivity of specific authoritative servers,that there are also corresponding priority orders.Hence,the resolver can receive the priority information embedded in the message to pursue queries.And the Optimal-result format with priority information is designed,which is a new format compatible with existing DNS message format.
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 [RFC8174].
This document is applicable to the recursive resolver that pursues queries and the authoritative server that supports the detection of next-level authoritative servers.
Optimal root servers are often determined by the resolver,that the general strategy is to look for locally-available root servers or test the service quality of specific root servers periodically.In order to improve the reliability of retrieval process,Yeti-root servers and local mirror servers with the root zone are optional.
As the following Figure 1,DNS is a hierarchy,recursive resolver starts with root server.TLD server can be found using the contents the root server konws,that the second-level domain server is below the TLD server.In order to respond optimal-result,each authoritative server needs to know the priority information by testing service quality of next-level authoritative servers at regular intervals.
+----------------+
Query | Root |
----------+ Server |
/ Response +-------+--------+
/ |Test for QoS
/ |
+---------------+ +-------+--------+
| Recursive | Query | TLD |
| Server +-------------+ Server |
+---------------+ Response +-------+--------+
\ |Test for QoS
\ |
\ Query +-------+--------+
----------+ Second-level |
Response | Domain Server |
+----------------+
Figure 1: The Architecture of DNS
For the authoritative server that supports the detection,it needs to test Qos of next-level server cluster periodically as above.In the following Figure 2,load balancer which implements test function can integrate with the authoritative service through plug-ins,based on the existing condition of the authoritative server.Load balancer contains respond module,test module,prefetch module and local cached module. And the prefetch module get the authoritative data from the authoritative service according to TTL of cached data and store in the local cached module,so that the respond module can answer the query service's quries using cached data with the priority informaiton through the detection of the test module.
+----------------+ +----------------+
| Query | | next-level |
| service | | server cluster |
+-------+--------+ +--------+-------+
Query|Response |Test for Qos
+-----------|--------------------|-------------------------------+
| +-------+--------+ +--------+-------+ +----------------+ |
| | Respond | | Test | | Prefetch | |
| | Module | | Module | | Module | |
| +--------------+-+ +--------+-------+ +--+-----------+-+ |
| \ | / | |
| \ | / | |
| +---+----------+----------+---------+ | |
| Load Balancer | Local | | |
| | Cached module | | |
| +-----------------------------------+ | |
+----------------------------------------------------------|-----+
|Prefetch
+-------------------+-----+
| Authoritative |
| service |
+-------------------------+
Figure 2: The Architecture of Detection
As described in [RFC1035],All communications inside of the domain protocol are carried in a single format called a message. The top level format of message is divided into 5 sections,which consists of header section,question section,answer section,authority section and additional section.
However,above message includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders.So opt pseudo-RR added to the additional section is used to provide a backward-compatible mechanism for embedding control information,detailed format is described in [RFC6891].
Based on opt pseudo-RR,the resolver can deliver the request about optimal-result and receive the response which can refer to the best server.And the optimal-result is added to the OPTION-DATA section of the opt pseudo-RR marked by OPTION-CODE.The optimal-result has a fixed part and a variable part,as shown in the following Figure 3.
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTIMAL-ANSWER-COUNT |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTIMAL-AUTHORITY-COUNT |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | OPTIMAL-ADDITIONAL-COUNT |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: | |
/ RRS-Number /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 3: Optimal-result Format
The presence of optimal-result in a request should be taken as an indication that the resolver needs to find the best authoritative servers,and that compliant authoritative server can respond the priority information embedded in the optimal-result based on the detection itself.But the authoritative server that does not support the protocol extensions defined in this document can ignore the optimal-result section.
Lack of presence of optimal-result in a request should be taken as an indication that the resolver does not need priority information or does not support the optimal-result format,and that corresponding authoritative server can implement standard responses.
The security considerations about EDNS is described in [RFC6891].
Additional consideration is that the resource records in the answer section,authority section and additional section of responses need to be retained.
The IANA has assigned RR type code 41 for OPT.
This document assigns option-code 18 for Optimal-result.
| [RFC1035] | Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987. |
| [RFC6891] | Damas, J., Graff, M. and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |