Internet DRAFT - draft-zeng-dinrg-blockchain-based-rdap
draft-zeng-dinrg-blockchain-based-rdap
Network Working Group Y. Zeng
Internet-Draft M. Zhang
Intended status: Standards Track CNNIC
Expires: 28 December 2022 W. Wang
CNIC
26 June 2022
A registry/registrar blockchain architecture for domain name
registration data access protocol
draft-zeng-dinrg-blockchain-based-rdap-01
Abstract
This document defines a registry/registrar blockchain architecture
for domain name registration data access protocol.
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 28 December 2022.
Copyright Notice
Copyright (c) 2022 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 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.
Zeng, et al. Expires 28 December 2022 [Page 1]
Internet-Draft DNRD-AP June 2022
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overall process . . . . . . . . . . . . . . . . . . . . . . . 3
3. Blockchain layer . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Bootstrap Service data . . . . . . . . . . . . . . . . . 5
3.2. The bootstrap service chain of registries . . . . . . . . 6
3.3. The bootstrap service chain of registrars . . . . . . . . 7
4. Data service access node . . . . . . . . . . . . . . . . . . 8
4.1. The data source . . . . . . . . . . . . . . . . . . . . . 8
4.2. Data consolidation and update . . . . . . . . . . . . . . 9
4.3. The path segment of query and search . . . . . . . . . . 10
4.4. Data access process . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 11
8. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
WHOIS is a transmission protocol that is used to query the IP and
owner of a domain name. It can be used to query whether a domain
name has been registered, and the detailed information of the
registered domain name. Early WHOIS queries existed in the form of
command lines, and now there are also ways to query through web
pages. The query tools of the web interface still rely on the WHOIS
protocol to send query requests to the server, and the tools of the
command line interface are still widely used by system
administrators.
WHOIS service is a free and open directory system that includes the
registration information, such as contact information and technical
information of registered domain name holders. Anyone who needs to
query the relevant information of the website and domain name can
obtain it by querying the WHOIS directory information. Registrars
and registries collect data and publish them publicly in accordance
with the content of the agreement signed with ICANN.
The shortcomings of the WHOIS protocol that have been discovered over
time include:
lack of standardized command structure;
lack of standardized output and error structure;
lack of support for internationalization and localization;
Zeng, et al. Expires 28 December 2022 [Page 2]
Internet-Draft DNRD-AP June 2022
lack of support for user identification, authentication, and
access control.
REST (Representation State Transfer) is a software architecture.
REST observes the entire network from the perspective of resources.
The distributed resources are determined by the URI (Uniform Resource
Identifier). The client application obtains the representation of
the resource through the URI, and can perform CRUD (Create, Read,
Update, Delete, and create) operations on these resources. Restful
Web Service is an http service based on the REST architecture. RDAP
uses the Restful architecture to improve the WHOIS protocol. The
main idea is to look up domain names, registrars, and host
information as resources. It uses an architecture based on the HTTP
protocol, queries through URIs, and can use XML, JSON or HTML to
return structured WHOIS information, thereby improving the defects of
the WHOIS protocol([RFC7480]).
Blockchain technology is a decentralized distributed database, which
can ensure the security, integrity, distribution, and non-tampering
characteristics of data through chain block structure, consensus
mechanism, smart contracts, etc.
This document designs a blockchain-based domain name registration
data access protocol, which uses the blockchain architecture to
maintain and manage domain name registration data.
2. Overall process
The blockchain-based RDAP mainly includes modules such as the
blockchain layer, storage layer, and data service access node layer.
The blockchain layer includes two chains which are registry bootstrap
service chain and the registrar bootstrap service chain. The storage
layer includes databases where registries and registrars store
registration data. The data service access node is responsible for
receiving user query requests, obtaining service data through the
registry bootstrap service chain and registrar bootstrap service
chain, integrating modules of query and response technical
requirements, HTTP technical requirements, security technical
requirements, and returning the final response data to the user.
Figure 1 shows the registry/registrar blockchain architecture for
domain name registration data access protocol .
Zeng, et al. Expires 28 December 2022 [Page 3]
Internet-Draft DNRD-AP June 2022
data consolidation
+-----------------+----------------+
| | |
+-------v-------+ +-----+-----+ +------v------+
| registry | | IANA | | registrar |
+--+ | | | | +--+
| | | | | | | |
| | chain | | ICANN | | chain | |
| +-------^-------+ +-----------+ +------^------+ |
| | blockchain nodes | |
| +-------+-------------------+ +-----------+------+ |
| | | | | |
| | registries | | registrars | |
| | | | | |
| +-------+-------------------+ +-----------+------+ |
| | write the registration data | |
| +-------v-------------------+ +-----------v------+ |
| | | | databases of | |
| | databases of registries | | | |
| | | | registrars | |
| +---------------------------+ +------------------+ |
| |
| +-------------------------------------------------+ |
| | | |
| | | |
+--> The data service access node <--+
| |
| |
+-------^----------------------------------^------+
| |
+-------v----------------------------------v------+
| users and clients |
+-------------------------------------------------+
Figure 1: The Overall Architecture
3. Blockchain layer
The blockchain layer includes the registry bootstrap service chain
and the registrar bootstrap service chain. Both chains are
consortium chains with access mechanisms. They manage members based
on the PKI certificate system, and issue signature certificates to
participating registries, registrars and other nodes through CA
services. Only when nodes hold certificates can they join the
blockchain network and manage the addition, modification and deletion
of their own resources.
Zeng, et al. Expires 28 December 2022 [Page 4]
Internet-Draft DNRD-AP June 2022
3.1. Bootstrap Service data
Top-level domains (TLDs), autonomous system (AS) numbers and network
blocks are entrusted by IANA to Internet registries, such as TLD
registries and regional Internet registries (RIRs), which are
subsequently released further commission and maintain information
about registered resources. Domain name registration data is not a
single centralized management database. On the contrary, multiple
registries and registrars in different regions are responsible for
the management of their respective registration data. They formulate
their own policies for WHOIS services in accordance with the minimum
requirements stipulated in the contract they signed with ICANN.
The registrant submits a domain name registration application to the
domain name registrar. After the registration is successful, the
registrar will store the registration data in its own WHOIS database,
and send the corresponding registration data to the TLD registry at
the same time according to the requirements of the TLD registry.
When the client initiates a WHOIS query, the WHOIS backend service
needs to initiate a query request to the corresponding TLD registry
to obtain registration data information. The query service itself
does not store the registration data of the domain name. The query
tool on the web page encapsulates this process.
Regarding the gTLD registries, ICANN clearly stipulates the service
requirements of WHOIS in the "Registry Agreements", including two
common modes "thick" and "thin". Although all current new gTLD
registries adopt an "thick" operating model, there are still some
existing registries (such as ".COM" and ".NET") that operate under a
"thin" registration model. The thin registry only saves enough data
in its WHOIS data repository to confirm the relevant registrar,
registration status, the generation and expiration date of each
registration, domain name server information and the last update time
of the data in the WHOIS database. In addition to providing the
above information, the "thick" registry is also responsible for
maintaining the registrant's contact information and designated
management and technical contact information.
IANA created a new registry based on the specified JSON format, named
the Bootstrap Service Registry. The bootstrap service data specifies
a method to find which server is authoritative to answer the query of
the request range, which can be specified through an HTTP request.
For the detailed definition of the data structure of the bootstrap
service data, please refer to RFC 7484.
Zeng, et al. Expires 28 December 2022 [Page 5]
Internet-Draft DNRD-AP June 2022
The blockchain-based domain name RDAP uses the registry service chain
and the registrar service chain to store the data access service
information of the registrar and the registrar respectively, and
integrate with the IANA data source to obtain the final bootstrap
data.
3.2. The bootstrap service chain of registries
The registry service chain is divided into the data layer, consensus
layer and application layer. The application layer is responsible
for the processing of business logic, including binding of top-level
domains, and addition, modification and deletion of the registry
service data. The consensus layer includes smart contracts and
consensus algorithms to ensure the orderliness and effectiveness of
blocks and the consistency of data. It is recommended to adopt a
hybrid consensus mechanism of DPOA and PBFT. For each top-level
domain, the registration data query service information provided by
the registry responsible for the top-level domain is stored on the
chain.
The participating nodes of the registry service chain are divided
into common registry nodes and consensus nodes elected by each node.
The registry node can publish the guidance information of the TLD
that it is responsible for management, and it will sign the message,
then other nodes can verify its identity and information format. The
management node is mainly responsible for node admission management
and publishes the changed information on the blockchain.
The management node manages the registration of the registry through
smart contracts. When a registry node joins, it verifies the binding
relationship between the registry and the top-level domain, and
writes the relationship between the registry and the TLD into the
blockchain. The registry node also uses smart contract for data
release and update.
The functions of the registry node include adding, modifying, and
deleting entries of the bootstrap service of the TLD under its own
management. When the registry initiates an application for data
release and update, it verifies the encrypted information and
identity certification through smart contracts, and writes the data
to the blockchain after being reviewed by the management node. Only
the registry that manages a TLD has the authority to publish and
change the corresponding top-level domain data records.
Zeng, et al. Expires 28 December 2022 [Page 6]
Internet-Draft DNRD-AP June 2022
3.3. The bootstrap service chain of registrars
The participating nodes of the registrar service chain are each
registrar. It uses a hybrid consensus mechanism of DPOA and PBFT.
The nodes added to the blockchain are divided into consensus nodes
and ordinary nodes. Ordinary nodes do not participate in the
consensus, but can participate in the election to become a consensus
node. The K nodes with the highest votes are elected by ordinary
nodes to form a consensus node set. Consensus nodes participate in
the consensus process and are divided into main verification nodes
and other consensus nodes. The main verification node is the current
management node, responsible for generating blocks, and then
broadcasting to other consensus nodes for block confirmation. At the
same time, in order to prevent external attacks, there can also be
multiple master verification nodes to form an endorsement committee,
and everyone sign transactions through a multi-signature mechanism.
After receiving the data change request, the management node will
pass it to other consensus nodes for voting after verification. Only
if the number of votes exceeds the set threshold, the update will be
approved. After a certain round, the consensus nodes will be re-
elected. At the same time, the consensus nodes implement a regular
rotation mechanism of management nodes.
The participating nodes of the registrar service chain are divided
into registrar nodes and consensus nodes elected by each node. The
registrar service chain is a consortium chain, and participating
nodes need to pass identity verification in the admission mechanism
stage before they can join. The management node is mainly
responsible for reviewing the application of the registrar to join
the blockchain, key management and publishing the changed information
on the blockchain. The registrar node can publish the bootstrap
information of the domain name registration information query service
provided by itself, and it will sign the message, then other nodes
will verify its identity and information format.
Only registrars approved by ICANN can join the registrar service
chain, and the management node will synchronize ICANN-approved
registrar list information as the judging criteria for node joining.
After the registrar submits the application for joining the chain,
the management node will review, verify its identity information.
The registrar can join the blockchain after passing the access
mechanism.
The data stored on the chain includes the base address of the
registration data access service provided by each registrar. For a
specific registrar, the data format is shown in Table 1.
Zeng, et al. Expires 28 December 2022 [Page 7]
Internet-Draft DNRD-AP June 2022
+============+========================================+
| Field Name | Description |
+============+========================================+
| ID | Registrar ID |
+------------+----------------------------------------+
| Name | Registrar Name |
+------------+----------------------------------------+
| Country | Country/Territory |
+------------+----------------------------------------+
| Contact | Public contact |
+------------+----------------------------------------+
| status | Status(Accredited/Reserved/Terminated) |
+------------+----------------------------------------+
| Link | Registrar website link |
+------------+----------------------------------------+
| serviceURL | Service URL |
+------------+----------------------------------------+
Table 1: Block Fields Description
The functions of the registrar node include the ability to add,
modify, and delete the service information provided by itself.
After the registrar submits the data change application, the
management node verifies the legality of the application, and writes
it into the blockchain after the verification is passed and reaching
a consensus.
4. Data service access node
The data access node includes a presentation module, a business
module, and a data access module. Representation module is
responsible for processing request distribution from different
clients; business module includes user authentication, information
query, data model definition and some other auxiliary support
functions, such as rate limit, connection time limit, online user
number limit and error code definition; data access module is
responsible for processing the interaction with the database by the
data access object, and returns the data content to the upper layer.
4.1. The data source
The data source of the data service access nodes is divided into two
parts: one is the registrar and registrar service chain data, and the
second is the data provided by IANA and ICANN.
Zeng, et al. Expires 28 December 2022 [Page 8]
Internet-Draft DNRD-AP June 2022
IANA's bootstrap service registry for domain name space provides the
service information of each top-level domain registry, and the data
access node can obtain the file content from the IANA official
website.
IANA's registrar ID list and ICANN's list of accredited registrars
provide registrar-related information, which can be accessed and
downloaded through the official website. The data service access
node obtains the name, number, country, contact number, email
address, and registration data access service interface information
of ICANN-accredited registrars from the above list.
4.2. Data consolidation and update
a) The registry bootstrap data
The system regularly obtains the data in the registry service chain
and the IANA bootstrap service registry. If the blockchain data
update timestamp or the timestamp published by the IANA data is
inconsistent with the current node data timestamp, it means that the
two data sources have been updated.
Data update in the registry service chain is directly loaded to the
data access node; for records that do not exist in the registry
chain, the data content in the IANA bootstrap files is used.
The data access nodes extract, merge and clean data from different
data sources to complete the data integration operation.
b) The registrar bootstrap data
The system regularly obtains the data of the registrar guide service
chain, registrar IDs list in IANA and the ICANN accredited registrars
list. Through processing operations such as format conversion and
splicing of the original data of the two data sources, the
registrar's name, number, country, contact number, e-mail address,
and registration data access service interface provided by the
registrar are obtained.
The data update in the registrar-guided service chain is directly
loaded to the data access node. For records that do not exist in the
registrar chain, the content integrated in the IANA and ICANN data
sources will be used.
Zeng, et al. Expires 28 December 2022 [Page 9]
Internet-Draft DNRD-AP June 2022
4.3. The path segment of query and search
Typically, a registry or other service provider will provide a basic
URL that identifies the protocol, host, and port. The basic URL used
to construct the registration data access protocol query is
maintained in the blockchain layer. The query is formed by
retrieving the appropriate base URL from the registry and appending
the specified path segment according to the query or search pattern
category.
For detailed definitions of specific categories and specifications of
path segments, please refer to [RFC9082].
4.4. Data access process
The data service access node is responsible for receiving the user's
request, obtaining the requested data content, fulfilling the
security and authority requirements, the application technical
requirements of HTTP query and response, and returning the response
to the user. Specific steps are as follows:
(1) The user sends a request to the data service access node. In
addition to the query path segment and other parameters, there is an
optional parameter, which means that registry only, registrar only,
or registry and registrar data are both queried at the same time.
The default option can be set to query the registry and registrar at
the same time.
(2) After receiving the user query request, the data service access
node first makes a verification according to the content of the user
request. If it is to query the registry and the registrar at the
same time, it will obtain the corresponding interface information
from the registry service blockchain. The data service access node
adds the corresponding request path segment, and then realizes the
query, response and HTTP technical requirements, and sends the query
request to the back-end service. It completes the user identity
authorization verification at the same time, and obtains the response
data returned by the registry.
(3) The data service access node obtains the registrar information of
the domain name from the response data in step 2, and at the same
time obtains the query interface information provided by the
registrar from the registrar service chain or the link field in the
response in step 2. Then, the data service access node adds the
corresponding path segment to form a complete query request, and
finally obtains the registrar response data.
Zeng, et al. Expires 28 December 2022 [Page 10]
Internet-Draft DNRD-AP June 2022
(4) Return the data obtained in step 2 and step 3 to the user; in
addition, the user can also choose to only query the data content of
the registry or registrar according to the type of registry.
5. IANA Considerations
There are no actions needed.
6. Security Considerations
The blockchain system needs to maintain the overall security of the
system at the levels of data content, consensus algorithms, smart
contracts, and peer-to-peer networks through technologies such as
cryptography and network security. Possible security problems in
cryptography include improper key management, vulnerabilities in
cryptographic algorithms or components. At the network level,
attackers can use peer-to-peer network security vulnerabilities and
node network topology to launch attacks. In addition, security
considerations also include the consistency problem of the consensus
algorithm, code vulnerability, privacy protection and so on. In
terms of storage, computing, and data interfaces, the blockchain
architecture faces security threats similar to other information
systems. In the deployment process, each module should meet the
corresponding security requirements.
7. Acknowledgment
The authors would like to thank CNNIC RDAP team for their careful
review and valuable comments.
8. Normative References
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7480, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/info/rfc7480>.
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc9082>.
Authors' Addresses
Zeng, et al. Expires 28 December 2022 [Page 11]
Internet-Draft DNRD-AP June 2022
Yu Zeng
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing
Beijing, 100190
China
Email: zengyu@cnnic.cn
Man Zhang
CNNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing
Beijing, 100190
China
Email: zhangman@cnnic.cn
Wei Wang
CNIC
4 South 4th Street, Zhongguancun, Haidian District
Beijing
Beijing, 100190
China
Email: wangwei@cnic.cn
Zeng, et al. Expires 28 December 2022 [Page 12]
