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



dnsop                                                            Y. Song
Internet-Draft                                                   Y. Long
Intended status: Informational                           CFIEC-Guangzhou
Expires: November 23, 2020                                  May 22, 2020


        DNS Authoritative server Management Based on Blockchain
                   draft-song-dnsop-dns-blockchain-00

Abstract

   This document specifies a mechanism for managing authoritative server
   such as root server,thereby implement decentralized management of the
   authoritative server.Through distributed decision and distributed
   storage,encrypted inforamtion and records are stored adding the block
   to the blockchain.And the distributed authoritative servers share
   common blockchain which has detailed retrieval data for answering
   queries from the resolvers.

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



Song & Long             Expires November 23, 2020               [Page 1]


Internet-Draft           Blockchain Oriented DNS                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 . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Authoritative server  . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Root server . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Top-Level Domain Server . . . . . . . . . . . . . . . . .   3
     2.3.  Others  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Deployment of authoritative server  . . . . . . . . . . . . .   3
   4.  Distributed Management  . . . . . . . . . . . . . . . . . . .   4
     4.1.  Country Code Top-level Domains  . . . . . . . . . . . . .   5
     4.2.  Generic Top-level Domains . . . . . . . . . . . . . . . .   5
   5.  Features  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The Domain Name System(DNS) is a simple query-response protocol,At
   present,DNS adopts centralized resolution system,that authoritative
   server is deployed by the independent entity and any modification
   requires the approval of the independent entity also.But there exists
   many risks for above-mentioned architecture,such as risk of
   disappearance, risk of blindness, risk of
   isolation,etc..Therefore,decentralized architecture for DNS is
   developing as a alternative option.

   This document describes a new architecture for DNS,multiple
   authoritative servers in the same layer(e.g. root servers)as server
   nodes make up a node group.All server nodes in the same node group
   are peers,by which corresponding operations are governed together.And
   information and records stored in the server nodes can only be
   changed by reaching a consensus within the node group.Update from any
   server node can be automatically distributed to the other server
   nodes which provide redundant service for the data.Hence,there is no
   affect even though some server nodes are corrupted.

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].



Song & Long             Expires November 23, 2020               [Page 2]


Internet-Draft           Blockchain Oriented DNS                May 2020


1.2.  Applicability

   This document is applicable to authoritative server
   management,especially managing root server.A scheme to decentralize
   the architecture of authoritative server makes the trust from peer-
   to-peer to collective,thereby ensuring data consistency.

2.  Authoritative server

   As described in [RFC8499],authoritative server is a server that knows
   the content of a DNS zone from local knowledge,and thus can answer
   queries about that zone without needing to query other servers.

2.1.  Root server

   As described in [RSSAC026],root server is a particular anycast
   instance,as an authoritative server that answers queries for the
   contents of the root zone which contains all the information needed
   to find top-level domains.

2.2.  Top-Level Domain Server

   Top-level domain(TLD) server contains corresponding top-level domain
   zone that is one layer below the root server,such as "cn" or
   "com".TLDs are often divided into sub-groups such as country code
   top-level domains(ccTLDs),generic top-level domains(gTLDs).

2.3.  Others

   There are many other authoritative servers below the TLD server
   according to the actual condition.As one of the authoritative
   servers,there is nothing special from the point of view of the
   DNS,they are also used to find next-level domains or web servers.

3.  Deployment of authoritative server

   The DNS is a hierarchy,recursive resolver usually starts with root
   server when performing queries.Take root server as an example,root
   server stands at the top of the DNS hierarchy as shown in Figure 1.By
   requesting root server,related resource records of the TLD server can
   be found.Thus,the recursive resolver is referred to the specified TLD
   server to pursue the query.









Song & Long             Expires November 23, 2020               [Page 3]


Internet-Draft           Blockchain Oriented DNS                May 2020


                             +---------------+
                             |      root     |
                             |     server    |
                             +-------+-------+
                                     |
                             +-------+-------+
                             |      TLD      |
                             |     server    |
                             +---------------+

              Figure 1: Architecture Between root and TLD

   In the decentralized architecture as shown in Figure 2,root servers
   in the same layer make up a autonomous group,which can communicate
   with each other.Every root server in the autonomous group stores
   consistent data such as resource records through automatic
   synchronization.  Meanwhile,above-mentioned root servers have peer
   administrative rights,that any update needs to be approved by all
   root servers.

                  +---------------+      +----------------+
                  |      root     |      |      root      |
                  |     server    |      |     server     |
                  +---------------+      +----------------+
                                   \    /
                                    +--+
                                   /    \
                  +---------------+      +----------------+
                  |      root     |      |      root      |
                  |     server    |      |     server     |
                  +---------------+      +----------------+

               Figure 2: Architecture of the same layer Server

   For autonomous group,it supports adding new server and removing
   expired server.About adding new server,every server in the autonomous
   group must make a descision by vote based on the identity of the
   newly added server within a valid time.On the other hand,the offline
   server can be removed from the autonomous group through a timeout
   mechanism.

4.  Distributed Management

   Authoritative server has zone which contains authoritative data
   organized into units.Root server,for example,has root zone which is
   used to refer the resolver to TLD server and let the resolver pursue
   the query.In order to keep the resource records about TLD server up
   to date,authoritative data needs to be constantly updated.And



Song & Long             Expires November 23, 2020               [Page 4]


Internet-Draft           Blockchain Oriented DNS                May 2020


   underlying terms represent the distributed management for differnet
   types of update data.

4.1.  Country Code Top-level Domains

   For ccTLDs such as "cn",it is often governed by the specified
   nation.Therefore,when data about ccTLD is modified,update is
   submitted by the country-specific node server,and synchronized to all
   servers in the identical autonomous group.

4.2.  Generic Top-level Domains

   For gTLDs such as "com",it can be regarded as common management
   object.And any update about gTLD needs to be verified firstly using
   smart contract based on the modified constraint of protocol and
   format.After verification,a vote on whether to distribute update data
   to the servers in the autonomous group is triggered.Only through the
   approval of the servers in the identical autonomous group within a
   valid time,update data can be synchronized to all servers.

5.  Features

   o  Autonomy

   o  Openness

   o  Equality

   o  Transparency

6.  Security Considerations

   The upadate information and records are stroed in the specific block
   based on blockchain,that corresponding information and records are
   encrypted by hashing and signing techniques,so that all information
   and records are immutable.

7.  IANA Considerations

   This document has no IANA actions.

8.  References

   [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>.





Song & Long             Expires November 23, 2020               [Page 5]


Internet-Draft           Blockchain Oriented DNS                May 2020


   [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
              January 2019, <https://www.rfc-editor.org/info/rfc8499>.

   [RSSAC026]
              Root Server System Advisory Committee(RSSAC), "RSSAC
              Lexicon", 2017,
              <https://www.icann.org/en/system/files/files/rssac-
              026-14mar17-en.pdf>.

Authors' Addresses

Yang Song
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: ysong@biigroup.cn


Yu Long
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: ylong@biigroup.cn























Song & Long             Expires November 23, 2020               [Page 6]


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