Internet DRAFT - draft-yu-dnsops-disdm
draft-yu-dnsops-disdm
Domain Name System Operations H. Yu
Internet-Draft D. Gong
Intended status: Informational Y. Song
Expires: 22 December 2022 Y. Liu
Guangzhou Root Chain International Network Research Institute Co., Ltd.
20 June 2022
Multi Distribution master
draft-yu-dnsops-disdm-04
Abstract
DM (Distribution Master) is used to transfer zone file data between
the registry and the authoritative server. The centralized DM system
has the risk of a single point of failure. The distributed DM
architecture allows nodes to join and exit at any time to solve the
single point of failure problem.
Requirements Language
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 [RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here.
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 22 December 2022.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Yu, et al. Expires 22 December 2022 [Page 1]
Internet-Draft MDM June 2022
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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. research status . . . . . . . . . . . . . . . . . . . . . . . 2
3. Multi-DM innovation . . . . . . . . . . . . . . . . . . . . . 3
4. Distributed multi-DM network management system . . . . . . . 3
5. Node consensus technology . . . . . . . . . . . . . . . . . . 4
6. Threshold signatures . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Blockchain makes up for the shortcomings of the traditional DM
system. The distributed feature improves the security of the system,
the unlimited expansion feature improves the stability of the DM
system, and the high autonomy feature brings the transparency of DNS
data management. At the same time, the blockchain is the nemesis of
DDoS attacks. Even if a certain node is attacked, other nodes can
still operate normally without causing system breakdown. This draft
is dedicated to building a distributed DM system and upgrading the
traditional centralized DM node to a DM system without a central
node. Using the existing blockchain technology, each node processes
the domain file after reaching a consensus to ensure the uniformity
and effectiveness of the domain file.
2. research status
In recent years, there have been few researches on DNS in foreign
countries, and the main research is in the direction of architecture
and innovating on the architecture. The Russian National Nuclear
Energy Research University proposed the main advantages and
disadvantages of blockchain technology in the process of implementing
a distributed DNS system, as well as the threats posed by blockchain
Yu, et al. Expires 22 December 2022 [Page 2]
Internet-Draft MDM June 2022
. South Korea proposed a method to implement DNS using distributed
ledger technology blockchain, and implement it using an Ethereum-
based platform. In addition, a qualitative analysis and performance
comparison evaluation of the existing domain name registration and
domain name servers are carried out, and the security evaluation of
the proposed system is carried out to improve the security problems
of the existing DNS . The Institute of Electrical and Electronics
Engineers puts forward a new blockchain-based decentralized DNS data
storage method by studying the principles and characteristics of the
blockchain, and implements a DNS decentralized system, establishes
multiple parallel DNS nodes and storage areas The key information of
file parsing data . Georgia State University proposes a system that
can replace the current top DNS system and certification authority,
providing higher scalability, security, and robustness. Based on
distributed hash table, and using the domain name ownership system
based on Bitcoin blockchain.
3. Multi-DM innovation
Multi-DM has the following two innovations: (1) Distributed DM system
This project is dedicated to building a distributed DM system,
upgrading the traditional centralized DM node to a DM system without
a central node. Using the existing blockchain technology, each node
processes the domain file after reaching a consensus to ensure the
uniformity and effectiveness of the domain file. (2) Elastic
contraction and expansion Traditional DM is a single node, which
leads to excessive power of this node. If it is invaded or
collapsed, it will paralyze the entire Internet. The nodes in the DM
can withdraw or join at any time to ensure that the power of each
node is consistent and dilute the power of the original single node.
4. Distributed multi-DM network management system
The distributed multi-DM network management system is the core of the
architecture, and its responsibilities are as follows; (1) Load
initial configuration, including DM static IP list, etc.;
(2) Use the election and heartbeat mechanism of the RAFT algorithm to
elect the primary node, and initiate a heartbeat to other nodes
through the primary node;
(3) Manage the joining and exit of DM. The joining of a new node
requires that all nodes can recognize the node, and the exit needs to
notify each node to delete the corresponding information and the
information stored by itself;
(4) Maintain the update of DM, including the change of node
information in the system, etc.
Yu, et al. Expires 22 December 2022 [Page 3]
Internet-Draft MDM June 2022
Each DM runs on a P2P network, where the P2P network can ensure that
each node can communicate, that is, two DMs can communicate at
random, and the heartbeat mechanism is integrated on the P2P network.
There is an IP list in each DM, which stores the IP information of
all nodes in the system, and subsequent operations on the system are
performed on this list. The addition of a new node means that the IP
information of the new node is added to this list. When the node
exits, the information about this node in this list is deleted. Node
update means that the information of this node in this list is
changed. The DM network management platform system has two states:
(1) Initialization state The initialization state is the process of
establishing the network. Each node loads a static list. After the
loading is completed, the IP of each node is recorded in each DM, and
the primary node is elected. After the primary node election is
completed, the state ends.
(2) Steady state After the election, it enters a stable state, and
the primary node sends a heartbeat detection to the ordinary node to
ensure the normal operation of each node. The joining, exiting and
updating of new nodes are only allowed in a stable state. The
joining of new nodes requires the approval of DMMC. The sign of
joining is that the IP of the new node is added to the IP list of
each node. When a node exits, it needs to completely delete its own
information, while other nodes delete related information (identity
verification information, IP information, etc.) of the node.
5. Node consensus technology
RAFT is a consensus algorithm. The so-called consensus is that
multiple nodes reach a consensus on something, even in the case of
partial node failures, network delays, and network partitions.
Consensus algorithm is the core of blockchain technology, and in
distributed systems, consensus algorithms are more used to improve
the fault tolerance of the system, such as replication in distributed
storage. The two main technical points of RAFT are problem
decomposition and state simplification. Problem decomposition is to
divide the complex problem of "node consistency in replication set"
into several sub-problems that can be independently explained,
understood, and solved. In RAFT, sub-problems include leader
election, log replication, safety, and membership changes. The state
simplification is better understood, which is to make some
restrictions on the algorithm, reduce the number of states that need
to be considered, and make the algorithm clearer and less uncertain.
PBFT provides (n-1)/3 fault tolerance on the premise of guaranteeing
availability and safety (liveness and safety), which means that if
there are n machines in the system, the maximum number of malicious/
faulty nodes that the system can tolerate is (n-1)/3 pieces. (The
Yu, et al. Expires 22 December 2022 [Page 4]
Internet-Draft MDM June 2022
malicious node may not respond or respond with wrong information).
The distributed DM system uses a new algorithm combining RAFT and
PBFT to solve the problem of trust and fault tolerance between nodes.
6. Threshold signatures
Threshold signatures introduce HSM, which is a system that provides a
low-cost and high-security solution for key storage. For sensitive
information such as keys, HSM provides logical and physical
protection to prevent unauthorized access and intrusion. HSM
provides tamper evidence (tamper evidence) and tamper resistance
(tamper evidence) in two ways to prevent tampering. It is used in
threshold signatures and is responsible for generating and storing
the keys used to sign DNS zone files. The management of HSM is
rotated by DMMC, and two HSMs are set up to achieve high availability
of the system. HSM has the following functions:
Security key generation Security key storage and management Encrypt
sensitive information Uninstall symmetric and asymmetric encryption
calculations of the application server
The specific process is as follows: A. Leader node enters the
signing status. B. Leader obtains the secret key from HSM, and
generates the corresponding number of private key shares SKI
according to the number of nodes. C. Leader will distribute the
generated private key share to each node, and the node will reply the
confirmation message after receiving it to ensure the success of
distribution. D. Other nodes use private key shares to sign zone
file data. E. After the node signs, the signed data is sent to the
leader. F. When the Leader splits the private key shares according
to the threshold, and the number is greater than the threshold value
set, the signature is successful. G. Leader node sends the complete
signature file to each node.
Each node uses the private key share to sign, and returns the digest
with the signature to the HSM to form a complete signature, and the
signature file is stored in the Primary node.
7. Security Considerations
8. IANA Considerations
This document does not include an IANA request.
9. Acknowledgements
The authors would like to acknowledge XXX for their valuable review
and comments.
Yu, et al. Expires 22 December 2022 [Page 5]
Internet-Draft MDM June 2022
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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>.
10.2. Informative 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>.
Authors' Addresses
Haisheng Yu
Guangzhou Root Chain International Network Research Institute Co., Ltd.
Xiangjiang International Technology Innovation Center, 41 Jinlong Road, Nansha District, Guangzhou
Guangzhou
China
Email: hsyu@biigroup.cn
Daobiao Gong
Guangzhou Root Chain International Network Research Institute Co., Ltd.
Xiangjiang International Technology Innovation Center, 41 Jinlong Road, Nansha District, Guangzhou
Guangzhou
China
Email: dbgong@biigroup.cn
Yang Song
Guangzhou Root Chain International Network Research Institute Co., Ltd.
Xiangjiang International Technology Innovation Center, 41 Jinlong Road, Nansha District, Guangzhou
Guangzhou
China
Email: ysong@biigroup.cn
Yu, et al. Expires 22 December 2022 [Page 6]
Internet-Draft MDM June 2022
Yan Liu
Guangzhou Root Chain International Network Research Institute Co., Ltd.
Xiangjiang International Technology Innovation Center, 41 Jinlong Road, Nansha District, Guangzhou
Guangzhou
China
Email: yliu@cfiec.net
Yu, et al. Expires 22 December 2022 [Page 7]
