| Internet-Draft | DNRD-AP | June 2022 |
| Zeng, et al. | Expires 28 December 2022 | [Page] |
This document defines a registry/registrar blockchain architecture for domain name registration data access protocol.¶
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 (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.¶
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:¶
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.¶
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 .¶
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 |
+-------------------------------------------------+
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.¶
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.¶
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.¶
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.¶
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.¶
| 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 |
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.¶
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.¶
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.¶
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.¶
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.¶
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].¶
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.¶
(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.¶
There are no actions needed.¶
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.¶
The authors would like to thank CNNIC RDAP team for their careful review and valuable comments.¶