YDT 4546-2023基于區(qū)塊鏈的域名注冊數(shù)據訪問協(xié)議 HTTP應用技術要求

ICS33.040.40

CCSL78

YD/TXXXXXXXX

YD—

中華人民共和國通信行業(yè)標準

YD/TXXXX—XXXX

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

HTTP應用技術要求

TechnicalrequirementsforHTTPapplicationofblockchainbaseddomain

nameregistrationdataaccessprotocol

（報批稿）

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

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

YD/TXXXX—XXXX

前言

本文件按照GB/T1.1—2020《標準化工作導則第1部分：標準化文件的結構和起草規(guī)則》的規(guī)定起

草。

本文件是基于區(qū)塊鏈的域名注冊數(shù)據訪問技術要求系列標準之一。該系列標準的結構和名稱如下：

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

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

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

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

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

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

請注意本文件的某些內容可能涉及專利。本文件的發(fā)布機構不承擔識別這些專利的責任。

本文件由中國通信標準化協(xié)會提出并歸口。

本文件起草單位：中國互聯(lián)網絡信息中心（CNNIC）、暨南大學、中國科學院計算機網絡信息中心。

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

學、王偉、吳雙力、張志勇。

3

YD/TXXXX—XXXX

引言

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

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

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

區(qū)塊鏈技術是一種去中心化的分布式數(shù)據賬本，其通過鏈式區(qū)塊結構、共識機制、智能合約等機制

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

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

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

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

（RepresentationStateTransfer，REST）架構實現(xiàn)，解決了WHOIS協(xié)議存在的問題，提供了標準化的

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

4

YD/TXXXX—XXXX

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

1范圍

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

要求和規(guī)范。

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

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

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

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

文件。

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

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

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

AccessProtocol）

3術語和定義

本文件沒有需要界定的術語和定義。

4縮略語

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

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

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

方法

IANA互聯(lián)網數(shù)字分配機構TheInternetAssignedNumbers

Authority

JSONJS對象標識法TheJavaScriptObjectNotation

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

TLD頂級域Top-levelDomain

URI統(tǒng)一資源標識符UniformResourceIdentifier

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

Web全球廣域網WorldWideWeb

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

5

YD/TXXXX—XXXX

5概述

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

的目標是使用表述性狀態(tài)轉移(RepresentationalStateTransfer，REST)體系結構風格的做法，將HTTP的

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

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

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

由該服務提供的注冊數(shù)據是互聯(lián)網資源注冊數(shù)據——域名和互聯(lián)網號碼資源的注冊。該數(shù)據通常由

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

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

如地址，組織或個人名稱）。

在設計這些常用用法模式時，本文件介紹了使用HTTP的注意事項。在可能存在復雜性的地方，本

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

和wget）應可以實現(xiàn)客戶端。

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

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

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

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

/rdap/ip/

構造查詢請求時應遵循YD/TAAAA-AAAA第6章中規(guī)定的查詢路徑段格式要求。

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

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

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

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

服務器。客戶端應使用該HTTPURL重新查詢。

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

應。

——如果接收服務器由于策略原因不回答請求，它應返回錯誤響應（4xx），指示不回答的原因。

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

問協(xié)議中使用標準HTTP機制的情況。

6設計目標

本文件嘗試滿足一些設計準則：

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

并且不應期望客戶端派生多個執(zhí)行路徑來進行查詢。

其次，請求/響應的語義應允許將來和/或非標準的響應格式。在本文件中，僅提到了JSON響應媒體

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

據如何使用HTTP以JSON格式傳輸。

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

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

6

YD/TXXXX—XXXX

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

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

7查詢

7.1HTTP方法

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

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

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

客戶端和服務器應支持HTTPS以支持安全服務。

7.2Accept頭字段

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

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

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

該標準未定義“Accept”頭字段中任何其他媒體類型或沒有“Accept”頭字段時服務器返回的響應。

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

7.3查詢參數(shù)

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

busting）。

當前查詢請求中對可用標識符的范圍進行了限制，標識符的擴展設置參見附錄D。

8HTTP響應的類型

8.1肯定的回答

如果服務器具有客戶端請求的信息，并希望根據其策略對客戶端進行響應，則服務器應在200（OK）

響應的正文中返回該答案。

8.2重定向

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

代碼以指示永久移動，或者返回302（找到），303（查看其他），或者307（臨時重定向）響應代碼以

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

7231第6章?？蛻舳藭褂媒o定的URL發(fā)出后續(xù)請求以滿足原始查詢，而無需對該URL進行任何處理。

換句話說，服務器應交回完整的URL，客戶端不必轉換URL即可使用它。包括重定向的交互示例參見附

錄A。

永久轉移的一個例子可能是TLD運營商告知客戶端其請求的信息可以從另一個TLD運營商那得到。

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

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

服務器重新定向到/weirds2/

其應設置Location字段的值為/weirds2/domain/

7

YD/TXXXX—XXXX

8.3否定的回答

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

（未找到）響應代碼?？蛇x地，它可以在HTTP實體主體中包含有關否定答案的附加信息。

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

客戶端的響應中，則服務器應使用HTTP的4xx范圍以外的適當響應代碼進行響應。如果重試查詢適合于

對應的響應代碼，客戶端可以重新查詢。

8.4格式錯誤的查詢

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

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

8.5速度限制

一些服務器應用速率限制來阻止地址抓取和其他濫用。當服務器由于速率限制而拒絕回答查詢時，

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

的客戶端應該降低其查詢速率，并遵守Retry-After首部字段（如果存在）。服務器可能會對不遵守

Retry-After首部字段的客戶端施加更嚴格的限制?？蛇x地，服務器可以在HTTP實體主體中包含有關速

率限制的附加信息。

請注意，這并不是針對拒絕服務（DoS）攻擊的防御措施，因為惡意客戶端可能會忽略代碼并繼續(xù)

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

代碼。

8.6跨域資源共享（CORS）

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

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

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

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

數(shù)據）。

默認情況下，當允許跨源請求時，瀏覽器不發(fā)送cookie。Access-Control-Allow-Credentials首部字段

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

9國際化考慮

9.1唯一資源定位符(URIs)和國際化資源標識符(IRIS)

客戶可以根據需要在內部使用國際化資源標識符，其結構定義參見IETFRFC3987第2章，但應將

其轉換為URI以與注冊數(shù)據訪問協(xié)議服務器進行交互。注冊數(shù)據訪問協(xié)議服務器應在所有響應中使用

URI，并且客戶端可以再次將這些URI轉換為國際化資源標識符以供內部使用。

9.2查詢和響應中的語言標識符

在大多數(shù)情況下，請求數(shù)據的客戶端不會發(fā)出以特定語言或腳本返回數(shù)據的信號。另一方面，當服

務器返回數(shù)據并知道該數(shù)據是某種語言或腳本時，應在可用時用語言標識符對數(shù)據進行注釋，從而允許

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

8

YD/TXXXX—XXXX

9.3HTTP首部中的語言標識符

鑒于第9.2節(jié)中對語言標識符的使用的說明，除非另有說明，否則服務器在制定HTTP實體響應時應

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

但是，服務器可在Content-Language首部字段中返回語言標識符，以便通知客戶端HTTP層消息的預

期語言。

附錄A

（資料性）

協(xié)議示例

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

簡潔起見，已省略了響應中的數(shù)據，因為本文件中未描述數(shù)據格式。此處使用的媒體類型應遵循YD/T

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

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

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緩存基礎結構未充分遵守緩存標準，并且緩存響應的時間可能比服務器預期的要長。為

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

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

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

——/ip/?__fuhgetaboutit=xyz123

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

11

YD/TXXXX—XXXX

附錄C

（資料性）

引導和重定向

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

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

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

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

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

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

圖C.1描繪了使用重定向器進行引導的客戶端。

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

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

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

12

YD/TXXXX—XXXX

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

13

YD/TXXXX—XXXX

附錄D

（資料性）

可擴展性

D.1擴展標識符產生規(guī)則

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

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

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

*(ALPHA/DIGIT/"_")。

此限制是Ruby編程語言標識符語法和XML元素名稱語法的結合，并具有兩個目的。首先，使用諸

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

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

D.2擴展標識符注冊

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

了一個URL引用的獨立注冊表，標記為“注冊數(shù)據訪問協(xié)議擴展”。該注冊表的目的是確保擴展標識符

的唯一性。擴展標識符在JSON名字中用作前綴以及在RDAPURL中用作路徑段的前綴。

這些標識符的產生規(guī)則在第D.1節(jié)中指定。

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

其詳細程度應足以確保獨立實現(xiàn)之間的互操作性是可能的。

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

——擴展標識符：擴展的標識符

——注冊運營商：注冊運營商的名稱

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

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

址

——預期用途：此注冊表項的簡要原因。

本文件中，可以通過定義新的擴展標識符來標識獲取數(shù)據的區(qū)塊鏈相關信息，以下是在注冊數(shù)據訪

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

——擴展標識符：blockRecord

——注冊運營商：any

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

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

——預期用途：COMMON

14

YD/TXXXX—XXXX

參考文獻

[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術語和定義.........................................................................5

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

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

6設計目標...........................................................................6

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

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

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

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

8HTTP響應的類型.....................................................................7

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

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

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

8.4格式錯誤的查詢.................................................................7

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

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

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

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

9.2查詢和響應中的語言標識符.......................................................8

9.3HTTP首部中的語言標識符.........................................................8

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

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

附錄C（資料性）引導和重定向...................................................10

附錄D（資料性）可擴展性.......................................................11

參考文獻............................................................................13

2

YD/TXXXX—XXXX

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

1范圍

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

要求和規(guī)范。

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

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

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

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

文件。

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

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

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

AccessProtocol）

3術語和定義

本文件沒有需要界定的術語和定義。

4縮略語

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

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

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

方法

IANA互聯(lián)網數(shù)字分配機構TheInternetAssignedNumbers

Authority

JSONJS對象標識法TheJavaScriptObjectNotation

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

TLD頂級域Top-levelDomain

URI統(tǒng)一資源標識符UniformResourceIdentifier

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

Web全球廣域網WorldWideWeb

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

5

YD/TXXXX—XXXX

5概述

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

的目標是使用表述性狀態(tài)轉移(RepresentationalStateTransfer，REST)體系結構風格的做法，將HTTP的

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

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

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

由該服務提供的注冊數(shù)據是互聯(lián)網資源注冊數(shù)據——域名和互聯(lián)網號碼資源的注冊。該數(shù)據通常由

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

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

如地址，組織或個人名稱）。

在設計這些常用用法模式時，本文件介紹了使用HTTP的注意事項。在可能存在復雜性的地方，本

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

和wget）應可以實現(xiàn)客戶端。

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

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

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

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

/rdap/ip/

構造查詢請求時應遵循YD/TAAAA-AAAA第6章中規(guī)定的查詢路徑段格式要求。

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

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

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

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

服務器?？蛻舳藨褂迷揌TTPURL重新查詢。

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

應。

——如果接收服務器由于策略原因不回答請求，它應返回錯誤響應（4xx），指示不回答的原因。

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

問協(xié)議中使用標準HTTP機制的情況。

6設計目標

本文件嘗試滿足一些設計準則：

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

并且不應期望客戶端派生多個執(zhí)行路徑來進行查詢。

其次，請求/響應的語義應允許將來和/或非標準的響應格式。在本文件中，僅提到了JSON響應媒體

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

據如何使用HTTP以JSON格式傳輸。

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

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

6

YD/TXXXX—XXXX

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

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

7查詢

7.1HTTP方法

客戶端使用GET方法獲取響應主體，并使用HEAD方法確定服務器上數(shù)據的存在?？蛻舳藨撌褂?/p>

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

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

客戶端和服務器應支持HTTPS以支持安全服務。

7.2Accept頭字段

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

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

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

該標準未定義“Accept”頭字段中任何其他媒體類型或沒有“Accept”頭字段時服務器返回的響應。

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

7.3查詢參數(shù)

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

busting）。

當前查詢請求中對可用標識符的范圍進行了限制，標識符的擴展設置參見附錄D。

8HTTP響應的類型

8.1肯定的回答

如果服務器具有客戶端請求的信息，并希望根據其策略對客戶端進行響應，則服務器應在200（OK）

響應的正文中返回該答案。

8.2重定向

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

代碼以指示永久移動，或者返回302（找到），303（查看其他），或者307（臨時重定向）響應代碼以

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

7231第6章?？蛻舳藭褂媒o定的URL發(fā)出后續(xù)請求以滿足原始查詢，而無需對該URL進行任何處理。

換句話說，服務器應交回完整的URL，客戶端不必轉換URL即可使用它。包括重定向的交互示例參見附

錄A。

永久轉移的一個例子可能是TLD運營商告知客戶端其請求的信息可以從另一個TLD運營商那得到。

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

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

服務器重新定向到/weirds2/

其應設置Location字段的值為/weirds2/domain/

7

YD/TXXXX—XXXX

8.3否定的回答

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

（未找到）響應代碼?？蛇x地，它可以在HTTP實體主體中包含有關否定答案的附加信息。

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

客戶端的響應中，則服務器應使用HTTP的4xx范圍以外的適當響應代碼進行響應。如果重試查詢適合于

對應的響應代碼，客戶端可以重新查詢。

8.4格式錯誤的查詢

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

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

8.5速度限制

一些服務器應用速率限制來阻止地址抓取和其他濫用。當服務器由于速率限制而拒絕回答查詢時，

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

的客戶端應該降低其查詢速率，并遵守Retry-After首部字段（如果存在）。服務器可能會對不遵守

Retry-After首部字段的客戶端施加更嚴格的限制?？蛇x地，服務器可以在HTTP實體主體中包含有關速

率限制的附加信息。

請注意，這并不是針對拒絕服務（DoS）攻擊的防御措施，因為惡意客戶端可能會忽略代碼并繼續(xù)

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

代碼。

8.6跨域資源共享（CORS）

響應查詢時，建議服務