ICS33.040.40

CCSL78

YD/TXXXXXXXX

YD—

中華人民共和國通信行業(yè)標(biāo)準(zhǔn)

YD/TXXXX—XXXX

基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問協(xié)議

HTTP應(yīng)用技術(shù)要求

TechnicalrequirementsforHTTPapplicationofblockchainbaseddomain

nameregistrationdataaccessprotocol

（報(bào)批稿）

XXXX-XX-XX發(fā)布XXXX-XX-XX實(shí)施

中華人民共和國工業(yè)和信息化部發(fā)布1

YD/TXXXX—XXXX

前言

本文件按照GB/T1.1—2020《標(biāo)準(zhǔn)化工作導(dǎo)則第1部分：標(biāo)準(zhǔn)化文件的結(jié)構(gòu)和起草規(guī)則》的規(guī)定起

草。

本文件是基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問技術(shù)要求系列標(biāo)準(zhǔn)之一。該系列標(biāo)準(zhǔn)的結(jié)構(gòu)和名稱如下：

——基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問協(xié)議總體技術(shù)要求

——基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問協(xié)議HTTP應(yīng)用技術(shù)要求

——基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問協(xié)議查詢數(shù)據(jù)格式定義

——基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問協(xié)議響應(yīng)數(shù)據(jù)格式定義

——基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問協(xié)議權(quán)威數(shù)據(jù)存儲(chǔ)與訪問技術(shù)要求

——基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問協(xié)議安全技術(shù)要求

請(qǐng)注意本文件的某些內(nèi)容可能涉及專利。本文件的發(fā)布機(jī)構(gòu)不承擔(dān)識(shí)別這些專利的責(zé)任。

本文件由中國通信標(biāo)準(zhǔn)化協(xié)會(huì)提出并歸口。

本文件起草單位：中國互聯(lián)網(wǎng)絡(luò)信息中心（CNNIC）、暨南大學(xué)、中國科學(xué)院計(jì)算機(jī)網(wǎng)絡(luò)信息中心。

本文件主要起草人：曾宇、李洪濤、姚健康、延志偉、董科軍、張曼、周琳琳、耿光剛、翁健、楊

學(xué)、王偉、吳雙力、張志勇。

3

YD/TXXXX—XXXX

引言

WHOIS協(xié)議作為一種簡單的無數(shù)據(jù)模型協(xié)議，隨著計(jì)算機(jī)和網(wǎng)絡(luò)通信技術(shù)的發(fā)展，在許多方面已無

法滿足用戶需求，例如，不能支持國際化域名（IDN）、無結(jié)構(gòu)化數(shù)據(jù)模型對(duì)顯示信息的內(nèi)容和格式無

法進(jìn)行統(tǒng)一以及無法為用戶提供分級(jí)服務(wù)等。

區(qū)塊鏈技術(shù)是一種去中心化的分布式數(shù)據(jù)賬本，其通過鏈?zhǔn)絽^(qū)塊結(jié)構(gòu)、共識(shí)機(jī)制、智能合約等機(jī)制

能夠讓各節(jié)點(diǎn)參與者在無需建立信任關(guān)系的前提下保證數(shù)據(jù)的安全完整，分布式，以及不可篡改的特性。

根據(jù)參與節(jié)點(diǎn)范圍區(qū)塊鏈分為公有鏈，聯(lián)盟鏈，私有鏈三大類。

基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問技術(shù)采用區(qū)塊鏈存儲(chǔ)域名注冊(cè)數(shù)據(jù)，可防止注冊(cè)數(shù)據(jù)被篡改、偽造，

保證數(shù)據(jù)一致性，使得域名注冊(cè)數(shù)據(jù)的存儲(chǔ)和訪問更加安全可靠。同時(shí)其基于表述性狀態(tài)轉(zhuǎn)移

（RepresentationStateTransfer，REST）架構(gòu)實(shí)現(xiàn)，解決了WHOIS協(xié)議存在的問題，提供了標(biāo)準(zhǔn)化的

格式，增加了訪問和請(qǐng)求數(shù)據(jù)的安全方式，支持國際化數(shù)據(jù)格式，及對(duì)注冊(cè)數(shù)據(jù)的不同訪問能力。

4

YD/TXXXX—XXXX

基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問協(xié)議HTTP應(yīng)用技術(shù)要求

1范圍

本文件規(guī)定了基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問協(xié)議中利用HTTP協(xié)議發(fā)送請(qǐng)求和響應(yīng)時(shí)的總體技術(shù)

要求和規(guī)范。

本文件適用于域名注冊(cè)數(shù)據(jù)訪問相關(guān)業(yè)務(wù)，用于替代改進(jìn)WHOIS協(xié)議。

2規(guī)范性引用文件

下列文件中的內(nèi)容通過文中的規(guī)范性引用而構(gòu)成本文件必不可少的條款。其中，注日期的引用文件，

僅該日期對(duì)應(yīng)的版本適用于本文件；不注日期的引用文件，其最新版本（包括所有的修改單）適用于本

文件。

YD/TAAAA-AAAA基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問協(xié)議查詢數(shù)據(jù)格式定義；

YD/TBBBB-BBBB基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問協(xié)議響應(yīng)數(shù)據(jù)格式定義；

IETFRFC7480注冊(cè)數(shù)據(jù)訪問協(xié)議HTTP應(yīng)用技術(shù)要求（HTTPUsageintheRegistrationData

AccessProtocol）

3術(shù)語和定義

本文件沒有需要界定的術(shù)語和定義。

4縮略語

下列縮略語適用于本文件。

HTTP超文本傳輸協(xié)議HyperTextTransferProtocol

HTTPGET超文本傳輸協(xié)議GETHTTPGETMethod

方法

IANA互聯(lián)網(wǎng)數(shù)字分配機(jī)構(gòu)TheInternetAssignedNumbers

Authority

JSONJS對(duì)象標(biāo)識(shí)法TheJavaScriptObjectNotation

REST表述性狀態(tài)轉(zhuǎn)移RepresentationalStateTransfer

TLD頂級(jí)域Top-levelDomain

URI統(tǒng)一資源標(biāo)識(shí)符UniformResourceIdentifier

URL統(tǒng)一資源定位符UniformResourceLocator

Web全球廣域網(wǎng)WorldWideWeb

WHOIS域名信息查詢協(xié)議WHOISProtocol

5

YD/TXXXX—XXXX

5概述

本文件定義基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問協(xié)議中超文本傳輸協(xié)議（HTTP）的使用方法。本文件

的目標(biāo)是使用表述性狀態(tài)轉(zhuǎn)移(RepresentationalStateTransfer，REST)體系結(jié)構(gòu)風(fēng)格的做法，將HTTP的

使用模式組合到適用于提供注冊(cè)數(shù)據(jù)的各類目錄服務(wù)的通用配置文件中，HTTP協(xié)議的使用規(guī)范應(yīng)遵循

IETFRFC7480第4章的要求。通過賦予各種目錄服務(wù)相同的行為，單個(gè)客戶端可以更好地從遵循該行

為的目錄服務(wù)中檢索數(shù)據(jù)。

由該服務(wù)提供的注冊(cè)數(shù)據(jù)是互聯(lián)網(wǎng)資源注冊(cè)數(shù)據(jù)——域名和互聯(lián)網(wǎng)號(hào)碼資源的注冊(cè)。該數(shù)據(jù)通常由

WHOIS服務(wù)提供，但是WHOIS協(xié)議不足以滿足現(xiàn)代注冊(cè)數(shù)據(jù)服務(wù)的要求。替代協(xié)議期望保留WHOIS

的簡單性質(zhì)，同時(shí)提供查詢和響應(yīng)規(guī)范，重定向到權(quán)威源，支持國際化域名，并支持本地化注冊(cè)數(shù)據(jù)（例

如地址，組織或個(gè)人名稱）。

在設(shè)計(jì)這些常用用法模式時(shí)，本文件介紹了使用HTTP的注意事項(xiàng)。在可能存在復(fù)雜性的地方，本

文件的目標(biāo)是將其放在服務(wù)器上，并使客戶端盡可能簡單。使用常見的操作系統(tǒng)腳本工具（例如bash

和wget）應(yīng)可以實(shí)現(xiàn)客戶端。

以下是本文件的基本使用模式：

——客戶端應(yīng)確定要查詢的合適的服務(wù)器，以及在此類查詢中使用的適當(dāng)?shù)幕A(chǔ)統(tǒng)一資源定位符。

有關(guān)更多信息，請(qǐng)參見附錄C。具體查詢數(shù)據(jù)源為基于區(qū)塊鏈的新型域名注冊(cè)數(shù)據(jù)管理平臺(tái)。

——客戶端可使用GET發(fā)出HTTP（或HTTPS）查詢。例如，網(wǎng)絡(luò)注冊(cè)的查詢URL可能是：

/rdap/ip/

構(gòu)造查詢請(qǐng)求時(shí)應(yīng)遵循YD/TAAAA-AAAA第6章中規(guī)定的查詢路徑段格式要求。

——如果接收服務(wù)器具有查詢的信息，它應(yīng)檢查查詢的“Accept”頭字段，并返回200響應(yīng)以及適

合于所請(qǐng)求格式的響應(yīng)實(shí)體。應(yīng)遵循YD/TBBBB-BBBB第8章中規(guī)定的響應(yīng)格式要求。

——如果接收服務(wù)器沒有查詢的信息，但是知道在哪里可以找到該信息，它應(yīng)返回一個(gè)重定向響應(yīng)

（3xx），該消息的Location頭字段包含指向該信息的HTTP（S）URL或已知知道該信息位置的另一臺(tái)

服務(wù)器。客戶端應(yīng)使用該HTTPURL重新查詢。

——如果接收服務(wù)器不具有所請(qǐng)求的信息，并且不知道在哪里可以找到該信息，則它應(yīng)返回404響

應(yīng)。

——如果接收服務(wù)器由于策略原因不回答請(qǐng)求，它應(yīng)返回錯(cuò)誤響應(yīng)（4xx），指示不回答的原因。

本文件的目的不是重新定義HTTP含義和語義。本文件的目的是闡明基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪

問協(xié)議中使用標(biāo)準(zhǔn)HTTP機(jī)制的情況。

6設(shè)計(jì)目標(biāo)

本文件嘗試滿足一些設(shè)計(jì)準(zhǔn)則：

首先，每個(gè)查詢應(yīng)只需要一個(gè)執(zhí)行路徑即可獲得答案。響應(yīng)可能包含答案，可能無答案或者重定向，

并且不應(yīng)期望客戶端派生多個(gè)執(zhí)行路徑來進(jìn)行查詢。

其次，請(qǐng)求/響應(yīng)的語義應(yīng)允許將來和/或非標(biāo)準(zhǔn)的響應(yīng)格式。在本文件中，僅提到了JSON響應(yīng)媒體

類型，響應(yīng)內(nèi)容應(yīng)遵循YD/TBBBB-BBBB第7章中的規(guī)定。本文件僅描述域名注冊(cè)數(shù)據(jù)訪問協(xié)議中數(shù)

據(jù)如何使用HTTP以JSON格式傳輸。

第三，本文件旨在能夠利用可用于HTTP的一系列機(jī)制。HTTP提供了許多本文件中未進(jìn)一步描述的

機(jī)制。運(yùn)營商可以根據(jù)其本地策略使用這些機(jī)制，包括緩存控制，授權(quán)，壓縮和重定向等。HTTP還得

6

YD/TXXXX—XXXX

益于在可伸縮性，可靠性和性能方面的廣泛投資，以及研發(fā)人員對(duì)基于REST風(fēng)格的Web服務(wù)的客戶端

行為具有廣泛理解，從而降低了注冊(cè)數(shù)據(jù)目錄服務(wù)和客戶端的部署成本。該協(xié)議與HTTP2.0向前兼容。

7查詢

7.1HTTP方法

客戶端使用GET方法獲取響應(yīng)主體，并使用HEAD方法確定服務(wù)器上數(shù)據(jù)的存在。客戶端應(yīng)該使用

HTTPGET或HEAD方法，這些方法的規(guī)范參見IETFRFC7231第4.3節(jié)。服務(wù)器沒有義務(wù)支持其他HTTP

方法。因此，使用其他方法的客戶端可能無法正確互操作。

客戶端和服務(wù)器應(yīng)支持HTTPS以支持安全服務(wù)。

7.2Accept頭字段

為了向服務(wù)器表示需要注冊(cè)數(shù)據(jù)訪問協(xié)議響應(yīng)，客戶端應(yīng)設(shè)置Accept頭字段，其中包括特定于注冊(cè)

數(shù)據(jù)訪問協(xié)議的JSON媒體類型，或通用JSON媒體類型或以上兩者。接收注冊(cè)數(shù)據(jù)訪問協(xié)議請(qǐng)求的服務(wù)

器應(yīng)返回一個(gè)帶有Content-Type頭字段的實(shí)體，其包含特定于注冊(cè)數(shù)據(jù)訪問協(xié)議的JSON媒體類型。

該標(biāo)準(zhǔn)未定義“Accept”頭字段中任何其他媒體類型或沒有“Accept”頭字段時(shí)服務(wù)器返回的響應(yīng)。

一種可能性是以適合在Web瀏覽器中渲染的媒體類型返回響應(yīng)。

7.3查詢參數(shù)

服務(wù)器應(yīng)忽略未知的查詢參數(shù)。附錄B中介紹了如何使用未知查詢參數(shù)進(jìn)行緩存破壞（cache

busting）。

當(dāng)前查詢請(qǐng)求中對(duì)可用標(biāo)識(shí)符的范圍進(jìn)行了限制，標(biāo)識(shí)符的擴(kuò)展設(shè)置參見附錄D。

8HTTP響應(yīng)的類型

8.1肯定的回答

如果服務(wù)器具有客戶端請(qǐng)求的信息，并希望根據(jù)其策略對(duì)客戶端進(jìn)行響應(yīng)，則服務(wù)器應(yīng)在200（OK）

響應(yīng)的正文中返回該答案。

8.2重定向

如果服務(wù)器希望通知客戶端給定查詢的答案可以在其他地方找到，則它返回301（永久移動(dòng)）響應(yīng)

代碼以指示永久移動(dòng)，或者返回302（找到），303（查看其他），或者307（臨時(shí)重定向）響應(yīng)代碼以

表示非永久重定向，并且在“Location”頭字段中包含HTTP（S）URL，響應(yīng)代碼的使用參見IETFRFC

7231第6章?？蛻舳藭?huì)使用給定的URL發(fā)出后續(xù)請(qǐng)求以滿足原始查詢，而無需對(duì)該URL進(jìn)行任何處理。

換句話說，服務(wù)器應(yīng)交回完整的URL，客戶端不必轉(zhuǎn)換URL即可使用它。包括重定向的交互示例參見附

錄A。

永久轉(zhuǎn)移的一個(gè)例子可能是TLD運(yùn)營商告知客戶端其請(qǐng)求的信息可以從另一個(gè)TLD運(yùn)營商那得到。

（即，在foo.example中查詢域名bar可在http：//foo.example/domain/bar中找到）。

例如，如果客戶端使用/weirds/domain/

服務(wù)器重新定向到/weirds2/

其應(yīng)設(shè)置Location字段的值為/weirds2/domain/

7

YD/TXXXX—XXXX

8.3否定的回答

如果服務(wù)器想要響應(yīng)某個(gè)查詢有一個(gè)空結(jié)果集（即沒有合適的數(shù)據(jù)滿足查詢條件），它應(yīng)返回404

（未找到）響應(yīng)代碼?？蛇x地，它可以在HTTP實(shí)體主體中包含有關(guān)否定答案的附加信息。

如果服務(wù)器希望通知客戶端有關(guān)該查詢的信息是可用的，但由于策略原因而不能將該信息包含在對(duì)

客戶端的響應(yīng)中，則服務(wù)器應(yīng)使用HTTP的4xx范圍以外的適當(dāng)響應(yīng)代碼進(jìn)行響應(yīng)。如果重試查詢適合于

對(duì)應(yīng)的響應(yīng)代碼，客戶端可以重新查詢。

8.4格式錯(cuò)誤的查詢

如果服務(wù)器收到無法解釋為注冊(cè)數(shù)據(jù)訪問協(xié)議請(qǐng)求的查詢，則它應(yīng)返回400（錯(cuò)誤請(qǐng)求）響應(yīng)代碼。

（可選地）它可以在HTTP實(shí)體主體中包含有關(guān)此否定答案的其他信息。

8.5速度限制

一些服務(wù)器應(yīng)用速率限制來阻止地址抓取和其他濫用。當(dāng)服務(wù)器由于速率限制而拒絕回答查詢時(shí)，

它應(yīng)返回429（請(qǐng)求過多）響應(yīng)代碼，該響應(yīng)代碼的使用說明參見IETFRFC6585第4章。收到429響應(yīng)

的客戶端應(yīng)該降低其查詢速率，并遵守Retry-After首部字段（如果存在）。服務(wù)器可能會(huì)對(duì)不遵守

Retry-After首部字段的客戶端施加更嚴(yán)格的限制。可選地，服務(wù)器可以在HTTP實(shí)體主體中包含有關(guān)速

率限制的附加信息。

請(qǐng)注意，這并不是針對(duì)拒絕服務(wù)（DoS）攻擊的防御措施，因?yàn)閻阂饪蛻舳丝赡軙?huì)忽略代碼并繼續(xù)

以高速率發(fā)送查詢。如果服務(wù)器不希望向客戶端透露速率限制是拒絕回復(fù)的原因，則可以使用其他響應(yīng)

代碼。

8.6跨域資源共享（CORS）

響應(yīng)查詢時(shí)，建議服務(wù)器使用指定的Access-Control-Allow-Origin首部字段。當(dāng)注冊(cè)數(shù)據(jù)訪問協(xié)議用

于公共資源時(shí)，值“*”是合適的。

此首部（通常稱為CORS首部）通過解除“同源”限制來幫助瀏覽器中的Web應(yīng)用程序（即瀏覽器

可以從一個(gè)Web服務(wù)器加載注冊(cè)數(shù)據(jù)訪問協(xié)議客戶端代碼，但從其他Web服務(wù)器查詢注冊(cè)數(shù)據(jù)訪問協(xié)議

數(shù)據(jù)）。

默認(rèn)情況下，當(dāng)允許跨源請(qǐng)求時(shí)，瀏覽器不發(fā)送cookie。Access-Control-Allow-Credentials首部字段

設(shè)置為“true”將發(fā)送cookie。不過不建議使用Access-Control-Allow-Credentials首部字段。

9國際化考慮

9.1唯一資源定位符(URIs)和國際化資源標(biāo)識(shí)符(IRIS)

客戶可以根據(jù)需要在內(nèi)部使用國際化資源標(biāo)識(shí)符，其結(jié)構(gòu)定義參見IETFRFC3987第2章，但應(yīng)將

其轉(zhuǎn)換為URI以與注冊(cè)數(shù)據(jù)訪問協(xié)議服務(wù)器進(jìn)行交互。注冊(cè)數(shù)據(jù)訪問協(xié)議服務(wù)器應(yīng)在所有響應(yīng)中使用

URI，并且客戶端可以再次將這些URI轉(zhuǎn)換為國際化資源標(biāo)識(shí)符以供內(nèi)部使用。

9.2查詢和響應(yīng)中的語言標(biāo)識(shí)符

在大多數(shù)情況下，請(qǐng)求數(shù)據(jù)的客戶端不會(huì)發(fā)出以特定語言或腳本返回?cái)?shù)據(jù)的信號(hào)。另一方面，當(dāng)服

務(wù)器返回?cái)?shù)據(jù)并知道該數(shù)據(jù)是某種語言或腳本時(shí)，應(yīng)在可用時(shí)用語言標(biāo)識(shí)符對(duì)數(shù)據(jù)進(jìn)行注釋，從而允許

客戶端相應(yīng)地處理和顯示數(shù)據(jù)。

8

YD/TXXXX—XXXX

9.3HTTP首部中的語言標(biāo)識(shí)符

鑒于第9.2節(jié)中對(duì)語言標(biāo)識(shí)符的使用的說明，除非另有說明，否則服務(wù)器在制定HTTP實(shí)體響應(yīng)時(shí)應(yīng)

忽略HTTPAccept-Language首部字段，這樣客戶就不會(huì)將該字段與實(shí)體主體中的“l(fā)ang”值混淆。

但是，服務(wù)器可在Content-Language首部字段中返回語言標(biāo)識(shí)符，以便通知客戶端HTTP層消息的預(yù)

期語言。

附錄A

（資料性）

協(xié)議示例

為了演示注冊(cè)數(shù)據(jù)訪問協(xié)議客戶端和服務(wù)器的典型行為，下面是一個(gè)包括重定向的交互示例。為了

簡潔起見，已省略了響應(yīng)中的數(shù)據(jù)，因?yàn)楸疚募形疵枋鰯?shù)據(jù)格式。此處使用的媒體類型應(yīng)遵循YD/T

BBBB-BBBB第8章中的規(guī)定。

注冊(cè)數(shù)據(jù)訪問協(xié)議客戶端和服務(wù)器交換的示例：

9

YD/TXXXX—XXXX

客戶端:

<TCPconnecttoport80>

GET/rdap/ip//24HTTP/1.1

Host:

Accept:application/rdap+json

:

HTTP/1.1301MovedPermanently

Location:/rdap/ip//24

Content-Length:0

Content-Type:application/rdap+json

<TCPdisconnect>

客戶端:

<TCPconnecttoport80>

GET/rdap/ip//24HTTP/1.1

Host:

Accept:application/rdap+json

:

HTTP/1.1200OK

Content-Type:application/rdap+json

Content-Length:9001

{...}

<TCPdisconnect>

10

YD/TXXXX—XXXX

附錄B

（資料性）

緩存破壞

某些HTTP緩存基礎(chǔ)結(jié)構(gòu)未充分遵守緩存標(biāo)準(zhǔn)，并且緩存響應(yīng)的時(shí)間可能比服務(wù)器預(yù)期的要長。為

了克服這些問題，客戶端可以使用一個(gè)臨時(shí)的、不太可能使用的查詢參數(shù)，并選擇一個(gè)隨機(jī)值。正如第

7.3節(jié)指示服務(wù)器忽略未知參數(shù)一樣，它與注冊(cè)數(shù)據(jù)訪問協(xié)議定義兼容。

使用未知查詢參數(shù)破壞緩存的示例：

——/ip/?__fuhgetaboutit=xyz123

使用未知參數(shù)來克服緩存異常的行為不屬于任何規(guī)范的一部分，此處提供此信息僅供參考。

11

YD/TXXXX—XXXX

附錄C

（資料性）

引導(dǎo)和重定向

WHOIS的傳統(tǒng)部署模型沒有提供確定信息權(quán)威來源的機(jī)制。

過去已經(jīng)實(shí)施了一些方法，最值得注意的是聯(lián)合WHOIS倡議。但是，除其他缺陷外，聯(lián)合WHOIS

是使用代理和服務(wù)器端推薦來實(shí)現(xiàn)的。

在注冊(cè)數(shù)據(jù)訪問協(xié)議中，使用HTTP重定向和引導(dǎo)解決了這些問題。引導(dǎo)信息參見IETFRFC7484第

3章內(nèi)容。在受限的環(huán)境中，常規(guī)過程可能不可行，需要服務(wù)器充當(dāng)“重定向器”。

重定向服務(wù)器使用重定向表向客戶端發(fā)出HTTP重定向，重定向表信息參見IETFRFC7484第3章。

圖C.1描繪了使用重定向器進(jìn)行引導(dǎo)的客戶端。

圖C.1.查詢的注冊(cè)數(shù)據(jù)訪問協(xié)議數(shù)據(jù)

在某些情況下，特別是在稱為“ERX空間”的地區(qū)性互聯(lián)網(wǎng)注冊(cè)管理機(jī)構(gòu)（RIR）與網(wǎng)絡(luò)傳輸之間

進(jìn)行的子授權(quán)中，將發(fā)出多個(gè)HTTP重定向。圖C.2顯示了這種情況。

12

YD/TXXXX—XXXX

圖C.2：查詢注冊(cè)數(shù)據(jù)訪問協(xié)議數(shù)據(jù)以獲取已傳輸?shù)臄?shù)據(jù)

13

YD/TXXXX—XXXX

附錄D

（資料性）

可擴(kuò)展性

D.1擴(kuò)展標(biāo)識(shí)符產(chǎn)生規(guī)則

出于擴(kuò)展目的，本文件為JSON數(shù)據(jù)序列化和URI路徑段中使用的前綴定義了IANA注冊(cè)表。

前綴和標(biāo)識(shí)符應(yīng)僅由US-ASCII字符大寫和小寫字母A到Z，數(shù)字0到9和下劃線字符組成，并且不應(yīng)

以下劃線字符，數(shù)字或字符“xml”開頭。擴(kuò)展的巴科斯范式中JSON名字的產(chǎn)生范式為：name=ALPHA

*(ALPHA/DIGIT/"_")。

此限制是Ruby編程語言標(biāo)識(shí)符語法和XML元素名稱語法的結(jié)合，并具有兩個(gè)目的。首先，使用諸

如Ruby或Java之類的現(xiàn)代編程語言的客戶端實(shí)現(xiàn)者可以使用自動(dòng)將JSON名字提升為一階對(duì)象屬性或成

員的庫。其次，使用這些規(guī)則很容易實(shí)現(xiàn)JSON和XML之間的清晰映射。

D.2擴(kuò)展標(biāo)識(shí)符注冊(cè)

IANA在協(xié)議注冊(cè)表中創(chuàng)建了一個(gè)新類別，標(biāo)記為“注冊(cè)數(shù)據(jù)訪問協(xié)議”，并且在該類別中，建立

了一個(gè)URL引用的獨(dú)立注冊(cè)表，標(biāo)記為“注冊(cè)數(shù)據(jù)訪問協(xié)議擴(kuò)展”。該注冊(cè)表的目的是確保擴(kuò)展標(biāo)識(shí)符

的唯一性。擴(kuò)展標(biāo)識(shí)符在JSON名字中用作前綴以及在RDAPURL中用作路徑段的前綴。

這些標(biāo)識(shí)符的產(chǎn)生規(guī)則在第D.1節(jié)中指定。

用于分配新值的IANA策略應(yīng)為需要規(guī)范：值及其含義應(yīng)記錄在RFC或其他永久易用的參考文件中，

其詳細(xì)程度應(yīng)足以確保獨(dú)立實(shí)現(xiàn)之間的互操作性是可能的。

以下是注冊(cè)數(shù)據(jù)訪問協(xié)議擴(kuò)展的模板：

——擴(kuò)展標(biāo)識(shí)符：擴(kuò)展的標(biāo)識(shí)符

——注冊(cè)運(yùn)營商：注冊(cè)運(yùn)營商的名稱

——發(fā)布的規(guī)范：RFC編號(hào)，參考書目或指向永久易用規(guī)范的URL

——要聯(lián)系以獲取更多信息的人員和電子郵件地址：有關(guān)此注冊(cè)表項(xiàng)的聯(lián)系人的姓名和電子郵件地

址

——預(yù)期用途：此注冊(cè)表項(xiàng)的簡要原因。

本文件中，可以通過定義新的擴(kuò)展標(biāo)識(shí)符來標(biāo)識(shí)獲取數(shù)據(jù)的區(qū)塊鏈相關(guān)信息，以下是在注冊(cè)數(shù)據(jù)訪

問協(xié)議擴(kuò)展注冊(cè)表中注冊(cè)的示例：

——擴(kuò)展標(biāo)識(shí)符：blockRecord

——注冊(cè)運(yùn)營商：any

——發(fā)布的規(guī)范：http：//www.example/rdap/block_info

——要聯(lián)系以獲取更多信息的人員和電子郵件地址：XXX

——預(yù)期用途：COMMON

14

YD/TXXXX—XXXX

參考文獻(xiàn)

[1]IETFRFC3987InternationalizedResourceIdentifiers(IRIs)

[2]IETFRFC6585AdditionalHTTPStatusCodes

[3]IETFRFC7231HypertextTransferProtocol(HTTP/1.1):SemanticsandContent

[4]IETFRFC7484FindingtheAuthoritativeRegistrationData(RDAP)Service

_________________________________

15

YD/TXXXX—XXXX

目次

前言.................................................................................3

引言.................................................................................4

1范圍...............................................................................5

2規(guī)范性引用文件.....................................................................5

3術(shù)語和定義.........................................................................5

4縮略語.............................................................................5

5概述...............................................................................5

6設(shè)計(jì)目標(biāo)...........................................................................6

7查詢...............................................................................6

7.1HTTP方法.......................................................................6

7.2Accept頭字段...................................................................7

7.3查詢參數(shù).......................................................................7

8HTTP響應(yīng)的類型.....................................................................7

8.1肯定的回答.....................................................................7

8.2重定向.........................................................................7

8.3否定的回答.....................................................................7

8.4格式錯(cuò)誤的查詢.................................................................7

8.5速度限制.......................................................................8

8.6跨域資源共享（CORS）...........................................................8

9國際化考慮.........................................................................8

9.1唯一資源定位符(URIs)和國際化資源標(biāo)識(shí)符(IRIS)...................................8

9.2查詢和響應(yīng)中的語言標(biāo)識(shí)符.......................................................8

9.3HTTP首部中的語言標(biāo)識(shí)符.........................................................8

附錄A（資料性）協(xié)議示例........................................................9

附錄B（資料性）緩存破壞........................................................9

附錄C（資料性）引導(dǎo)和重定向...................................................10

附錄D（資料性）可擴(kuò)展性.......................................................11

參考文獻(xiàn)............................................................................13

2

YD/TXXXX—XXXX

基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問協(xié)議HTTP應(yīng)用技術(shù)要求

1范圍

本文件規(guī)定了基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問協(xié)議中利用HTTP協(xié)議發(fā)送請(qǐng)求和響應(yīng)時(shí)的總體技術(shù)

要求和規(guī)范。

本文件適用于域名注冊(cè)數(shù)據(jù)訪問相關(guān)業(yè)務(wù)，用于替代改進(jìn)WHOIS協(xié)議。

2規(guī)范性引用文件

下列文件中的內(nèi)容通過文中的規(guī)范性引用而構(gòu)成本文件必不可少的條款。其中，注日期的引用文件，

僅該日期對(duì)應(yīng)的版本適用于本文件；不注日期的引用文件，其最新版本（包括所有的修改單）適用于本

文件。

YD/TAAAA-AAAA基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問協(xié)議查詢數(shù)據(jù)格式定義；

YD/TBBBB-BBBB基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問協(xié)議響應(yīng)數(shù)據(jù)格式定義；

IETFRFC7480注冊(cè)數(shù)據(jù)訪問協(xié)議HTTP應(yīng)用技術(shù)要求（HTTPUsageintheRegistrationData

AccessProtocol）

3術(shù)語和定義

本文件沒有需要界定的術(shù)語和定義。

4縮略語

下列縮略語適用于本文件。

HTTP超文本傳輸協(xié)議HyperTextTransferProtocol

HTTPGET超文本傳輸協(xié)議GETHTTPGETMethod

方法

IANA互聯(lián)網(wǎng)數(shù)字分配機(jī)構(gòu)TheInternetAssignedNumbers

Authority

JSONJS對(duì)象標(biāo)識(shí)法TheJavaScriptObjectNotation

REST表述性狀態(tài)轉(zhuǎn)移RepresentationalStateTransfer

TLD頂級(jí)域Top-levelDomain

URI統(tǒng)一資源標(biāo)識(shí)符UniformResourceIdentifier

URL統(tǒng)一資源定位符UniformResourceLocator

Web全球廣域網(wǎng)WorldWideWeb

WHOIS域名信息查詢協(xié)議WHOISProtocol

5

YD/TXXXX—XXXX

5概述

本文件定義基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪問協(xié)議中超文本傳輸協(xié)議（HTTP）的使用方法。本文件

的目標(biāo)是使用表述性狀態(tài)轉(zhuǎn)移(RepresentationalStateTransfer，REST)體系結(jié)構(gòu)風(fēng)格的做法，將HTTP的

使用模式組合到適用于提供注冊(cè)數(shù)據(jù)的各類目錄服務(wù)的通用配置文件中，HTTP協(xié)議的使用規(guī)范應(yīng)遵循

IETFRFC7480第4章的要求。通過賦予各種目錄服務(wù)相同的行為，單個(gè)客戶端可以更好地從遵循該行

為的目錄服務(wù)中檢索數(shù)據(jù)。

由該服務(wù)提供的注冊(cè)數(shù)據(jù)是互聯(lián)網(wǎng)資源注冊(cè)數(shù)據(jù)——域名和互聯(lián)網(wǎng)號(hào)碼資源的注冊(cè)。該數(shù)據(jù)通常由

WHOIS服務(wù)提供，但是WHOIS協(xié)議不足以滿足現(xiàn)代注冊(cè)數(shù)據(jù)服務(wù)的要求。替代協(xié)議期望保留WHOIS

的簡單性質(zhì)，同時(shí)提供查詢和響應(yīng)規(guī)范，重定向到權(quán)威源，支持國際化域名，并支持本地化注冊(cè)數(shù)據(jù)（例

如地址，組織或個(gè)人名稱）。

在設(shè)計(jì)這些常用用法模式時(shí)，本文件介紹了使用HTTP的注意事項(xiàng)。在可能存在復(fù)雜性的地方，本

文件的目標(biāo)是將其放在服務(wù)器上，并使客戶端盡可能簡單。使用常見的操作系統(tǒng)腳本工具（例如bash

和wget）應(yīng)可以實(shí)現(xiàn)客戶端。

以下是本文件的基本使用模式：

——客戶端應(yīng)確定要查詢的合適的服務(wù)器，以及在此類查詢中使用的適當(dāng)?shù)幕A(chǔ)統(tǒng)一資源定位符。

有關(guān)更多信息，請(qǐng)參見附錄C。具體查詢數(shù)據(jù)源為基于區(qū)塊鏈的新型域名注冊(cè)數(shù)據(jù)管理平臺(tái)。

——客戶端可使用GET發(fā)出HTTP（或HTTPS）查詢。例如，網(wǎng)絡(luò)注冊(cè)的查詢URL可能是：

/rdap/ip/

構(gòu)造查詢請(qǐng)求時(shí)應(yīng)遵循YD/TAAAA-AAAA第6章中規(guī)定的查詢路徑段格式要求。

——如果接收服務(wù)器具有查詢的信息，它應(yīng)檢查查詢的“Accept”頭字段，并返回200響應(yīng)以及適

合于所請(qǐng)求格式的響應(yīng)實(shí)體。應(yīng)遵循YD/TBBBB-BBBB第8章中規(guī)定的響應(yīng)格式要求。

——如果接收服務(wù)器沒有查詢的信息，但是知道在哪里可以找到該信息，它應(yīng)返回一個(gè)重定向響應(yīng)

（3xx），該消息的Location頭字段包含指向該信息的HTTP（S）URL或已知知道該信息位置的另一臺(tái)

服務(wù)器?？蛻舳藨?yīng)使用該HTTPURL重新查詢。

——如果接收服務(wù)器不具有所請(qǐng)求的信息，并且不知道在哪里可以找到該信息，則它應(yīng)返回404響

應(yīng)。

——如果接收服務(wù)器由于策略原因不回答請(qǐng)求，它應(yīng)返回錯(cuò)誤響應(yīng)（4xx），指示不回答的原因。

本文件的目的不是重新定義HTTP含義和語義。本文件的目的是闡明基于區(qū)塊鏈的域名注冊(cè)數(shù)據(jù)訪

問協(xié)議中使用標(biāo)準(zhǔn)HTTP機(jī)制的情況。

6設(shè)計(jì)目標(biāo)

本文件嘗試滿足一些設(shè)計(jì)準(zhǔn)則：

首先，每個(gè)查詢應(yīng)只需要一個(gè)執(zhí)行路徑即可獲得答案。響應(yīng)可能包含答案，可能無答案或者重定向，

并且不應(yīng)期望客戶端派生多個(gè)執(zhí)行路徑來進(jìn)行查詢。

其次，請(qǐng)求/響應(yīng)的語義應(yīng)允許將來和/或非標(biāo)準(zhǔn)的響應(yīng)格式。在本文件中，僅提到了JSON響應(yīng)媒體

類型，響應(yīng)內(nèi)容應(yīng)遵循YD/TBBBB-BBBB第7章中的規(guī)定。本文件僅描述域名注冊(cè)數(shù)據(jù)訪問協(xié)議中數(shù)

據(jù)如何使用HTTP以JSON格式傳輸。

第三，本文件旨在能夠利用可用于HTTP的一系列機(jī)制。HTTP提供了許多本文件中未進(jìn)一步描述的

機(jī)制。運(yùn)營商可以根據(jù)其本地策略使用這些機(jī)制，包括緩存控制，授權(quán)，壓縮和重定向等。HTTP還得

6

YD/TXXXX—XXXX

益于在可伸縮性，可靠性和性能方面的廣泛投資，以及研發(fā)人員對(duì)基于REST風(fēng)格的Web服務(wù)的客戶端

行為具有廣泛理解，從而降低了注冊(cè)數(shù)據(jù)目錄服務(wù)和客戶端的部署成本。該協(xié)議與HTTP2.0向前兼容。

7查詢

7.1HTTP方法

客戶端使用GET方法獲取響應(yīng)主體，并使用HEAD方法確定服務(wù)器上數(shù)據(jù)的存在?？蛻舳藨?yīng)該使用

HTTPGET或HEAD方法，這些方法的規(guī)范參見IETFRFC7231第4.3節(jié)。服務(wù)器沒有義務(wù)支持其他HTTP

方法。因此，使用其他方法的客戶端可能無法正確互操作。

客戶端和服務(wù)器應(yīng)支持HTTPS以支持安全服務(wù)。

7.2Accept頭字段

為了向服務(wù)器表示需要注冊(cè)數(shù)據(jù)訪問協(xié)議響應(yīng)，客戶端應(yīng)設(shè)置Accept頭字段，其中包括特定于注冊(cè)

數(shù)據(jù)訪問協(xié)議的JSON媒體類型，或通用JSON媒體類型或以上兩者。接收注冊(cè)數(shù)據(jù)訪問協(xié)議請(qǐng)求的服務(wù)

器應(yīng)返回一個(gè)帶有Content-Type頭字段的實(shí)體，其包含特定于注冊(cè)數(shù)據(jù)訪問協(xié)議的JSON媒體類型。

該標(biāo)準(zhǔn)未定義“Accept”頭字段中任何其他媒體類型或沒有“Accept”頭字段時(shí)服務(wù)器返回的響應(yīng)。

一種可能性是以適合在Web瀏覽器中渲染的媒體類型返回響應(yīng)。

7.3查詢參數(shù)

服務(wù)器應(yīng)忽略未知的查詢參數(shù)。附錄B中介紹了如何使用未知查詢參數(shù)進(jìn)行緩存破壞（cache

busting）。

當(dāng)前查詢請(qǐng)求中對(duì)可用標(biāo)識(shí)符的范圍進(jìn)行了限制，標(biāo)識(shí)符的擴(kuò)展設(shè)置參見附錄D。

8HTTP響應(yīng)的類型

8.1肯定的回答

如果服務(wù)器具有客戶端請(qǐng)求的信息，并希望根據(jù)其策略對(duì)客戶端進(jìn)行響應(yīng)，則服務(wù)器應(yīng)在200（OK）

響應(yīng)的正文中返回該答案。

8.2重定向

如果服務(wù)器希望通知客戶端給定查詢的答案可以在其他地方找到，則它返回301（永久移動(dòng)）響應(yīng)

代碼以指示永久移動(dòng)，或者返回302（找到），303（查看其他），或者307（臨時(shí)重定向）響應(yīng)代碼以

表示非永久重定向，并且在“Location”頭字段中包含HTTP（S）URL，響應(yīng)代碼的使用參見IETFRFC

7231第6章?？蛻舳藭?huì)使用給定的URL發(fā)出后續(xù)請(qǐng)求以滿足原始查詢，而無需對(duì)該URL進(jìn)行任何處理。

換句話說，服務(wù)器應(yīng)交回完整的URL，客戶端不必轉(zhuǎn)換URL即可使用它。包括重定向的交互示例參見附

錄A。

永久轉(zhuǎn)移的一個(gè)例子可能是TLD運(yùn)營商告知客戶端其請(qǐng)求的信息可以從另一個(gè)TLD運(yùn)營商那得到。

（即，在foo.example中查詢域名bar可在http：//foo.example/domain/bar中找到）。

例如，如果客戶端使用/weirds/domain/

服務(wù)器重新定向到/weirds2/

其應(yīng)設(shè)置Location字段的值為/weirds2/domain/

7

YD/TXXXX—XXXX

8.3否定的回答

如果服務(wù)器想要響應(yīng)某個(gè)查詢有一個(gè)空結(jié)果集（即沒有合適的數(shù)據(jù)滿足查詢條件），它應(yīng)返回404

（未找到）響應(yīng)代碼?？蛇x地，它可以在HTTP實(shí)體主體中包含有關(guān)否定答案的附加信息。

如果服務(wù)器希望通知客戶端有關(guān)該查詢的信息是可用的，但由于策略原因而不能將該信息包含在對(duì)

客戶端的響應(yīng)中，則服務(wù)器應(yīng)使用HTTP的4xx范圍以外的適當(dāng)響應(yīng)代碼進(jìn)行響應(yīng)。如果重試查詢適合于

對(duì)應(yīng)的響應(yīng)代碼，客戶端可以重新查詢。

8.4格式錯(cuò)誤的查詢

如果服務(wù)器收到無法解釋為注冊(cè)數(shù)據(jù)訪問協(xié)議請(qǐng)求的查詢，則它應(yīng)返回400（錯(cuò)誤請(qǐng)求）響應(yīng)代碼。

（可選地）它可以在HTTP實(shí)體主體中包含有關(guān)此否定答案的其他信息。

8.5速度限制

一些服務(wù)器應(yīng)用速率限制來阻止地址抓取和其他濫用。當(dāng)服務(wù)器由于速率限制而拒絕回答查詢時(shí)，

它應(yīng)返回429（請(qǐng)求過多）響應(yīng)代碼，該響應(yīng)代碼的使用說明參見IETFRFC6585第4章。收到429響應(yīng)

的客戶端應(yīng)該降低其查詢速率，并遵守Retry-After首部字段（如果存在）。服務(wù)器可能會(huì)對(duì)不遵守

Retry-After首部字段的客戶端施加更嚴(yán)格的限制?？蛇x地，服務(wù)器可以在HTTP實(shí)體主體中包含有關(guān)速

率限制的附加信息。

請(qǐng)注意，這并不是針對(duì)拒絕服務(wù)（DoS）攻擊的防御措施，因?yàn)閻阂饪蛻舳丝赡軙?huì)忽略代碼并繼續(xù)

以高速率發(fā)送查詢。如果服務(wù)器不希望向客戶端透露速率限制是拒絕回復(fù)的原因，則可以使用其他響應(yīng)

代碼。

8.6跨域資源共享（CORS）

響應(yīng)查詢時(shí)，建議服務(wù)