[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]



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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/