Internet DRAFT - draft-gong-dnsop-optimal-retrieval-edns
draft-gong-dnsop-optimal-retrieval-edns
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
Abstract
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.
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 November 23, 2020.
Copyright Notice
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
Gong & Zhang Expires November 23, 2020 [Page 1]
Internet-Draft Optimal Retrieval Process May 2020
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 2
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 2
2. Optimal root servers . . . . . . . . . . . . . . . . . . . . 3
3. Service Quality Testing . . . . . . . . . . . . . . . . . . . 3
4. Optimal-result Format . . . . . . . . . . . . . . . . . . . . 4
5. Transport Considerations . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
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.
1.1. Requirements Notation
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].
1.2. Applicability
This document is applicable to the recursive resolver that pursues
queries and the authoritative server that supports the detection of
next-level authoritative servers.
Gong & Zhang Expires November 23, 2020 [Page 2]
Internet-Draft Optimal Retrieval Process May 2020
2. Optimal root 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.
3. Service Quality Testing
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.
Gong & Zhang Expires November 23, 2020 [Page 3]
Internet-Draft Optimal Retrieval Process May 2020
+----------------+ +----------------+
| 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
4. Optimal-result Format
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.
Gong & Zhang Expires November 23, 2020 [Page 4]
Internet-Draft Optimal Retrieval Process May 2020
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | OPTIMAL-ANSWER-COUNT |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | OPTIMAL-AUTHORITY-COUNT |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | OPTIMAL-ADDITIONAL-COUNT |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: | |
/ RRS-Number /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 3: Optimal-result Format
o OPTIMAL-ANSWER-COUNT:an unsigned 16 bit integer specifying the
number of requests or responses about the optimal RRs answering
the question.
o OPTIMAL-AUTHORITY-COUNT:an unsigned 16 bit integer specifying the
number of requests or responses about the optimal RRs pointing
toward an authority.
o OPTIMAL-ADDITIONAL-COUNT:an unsigned 16 bit integer specifying the
number of requests or responses about the optimal RRs holding
additional information.
o RRS-Number:serial numbers generated according to the order of
correspongding RRs in the answer section,authority
section,additional section and sorted by the priority of
corresponding RRs.
5. Transport Considerations
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.
Gong & Zhang Expires November 23, 2020 [Page 5]
Internet-Draft Optimal Retrieval Process May 2020
6. Security Considerations
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.
7. IANA Considerations
The IANA has assigned RR type code 41 for OPT.
This document assigns option-code 18 for Optimal-result.
8. References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Authors' Addresses
Daobiao Gong
Guangzhou Root Chain International Network Research Institute Co., Ltd.
No.96 Qingsha Road, Dongchong Town, Guangzhou, Guangdong Province, China
Guangzhou 511458
P. R. China
Email: dbgong@biigroup.cn
Peng Zhang
Guangzhou Root Chain International Network Research Institute Co., Ltd.
No.96 Qingsha Road, Dongchong Town, Guangzhou, Guangdong Province, China
Guangzhou 511458
P. R. China
Email: pzhang@cfiec.net
Gong & Zhang Expires November 23, 2020 [Page 6]
