YDT 4546-2023基于区块链的域名注册数据访问协议 HTTP应用技术要求

ICS33.040.40

CCSL78

YD/TXXXXXXXX

YD—

中华人民共和国通信行业标准

YD/TXXXX—XXXX

基于区块链的域名注册数据访问协议

HTTP应用技术要求

TechnicalrequirementsforHTTPapplicationofblockchainbaseddomain

nameregistrationdataaccessprotocol

（报批稿）

XXXX-XX-XX发布XXXX-XX-XX实施

中华人民共和国工业和信息化部发布1

YD/TXXXX—XXXX

前言

本文件按照GB/T1.1—2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定起

草。

本文件是基于区块链的域名注册数据访问技术要求系列标准之一。该系列标准的结构和名称如下：

——基于区块链的域名注册数据访问协议总体技术要求

——基于区块链的域名注册数据访问协议HTTP应用技术要求

——基于区块链的域名注册数据访问协议查询数据格式定义

——基于区块链的域名注册数据访问协议响应数据格式定义

——基于区块链的域名注册数据访问协议权威数据存储与访问技术要求

——基于区块链的域名注册数据访问协议安全技术要求

请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。

本文件由中国通信标准化协会提出并归口。

本文件起草单位：中国互联网络信息中心（CNNIC）、暨南大学、中国科学院计算机网络信息中心。

本文件主要起草人：曾宇、李洪涛、姚健康、延志伟、董科军、张曼、周琳琳、耿光刚、翁健、杨

学、王伟、吴双力、张志勇。

3

YD/TXXXX—XXXX

引言

WHOIS协议作为一种简单的无数据模型协议，随着计算机和网络通信技术的发展，在许多方面已无

法满足用户需求，例如，不能支持国际化域名（IDN）、无结构化数据模型对显示信息的内容和格式无

法进行统一以及无法为用户提供分级服务等。

区块链技术是一种去中心化的分布式数据账本，其通过链式区块结构、共识机制、智能合约等机制

能够让各节点参与者在无需建立信任关系的前提下保证数据的安全完整，分布式，以及不可篡改的特性。

根据参与节点范围区块链分为公有链，联盟链，私有链三大类。

基于区块链的域名注册数据访问技术采用区块链存储域名注册数据，可防止注册数据被篡改、伪造，

保证数据一致性，使得域名注册数据的存储和访问更加安全可靠。同时其基于表述性状态转移

（RepresentationStateTransfer，REST）架构实现，解决了WHOIS协议存在的问题，提供了标准化的

格式，增加了访问和请求数据的安全方式，支持国际化数据格式，及对注册数据的不同访问能力。

4

YD/TXXXX—XXXX

基于区块链的域名注册数据访问协议HTTP应用技术要求

1范围

本文件规定了基于区块链的域名注册数据访问协议中利用HTTP协议发送请求和响应时的总体技术

要求和规范。

本文件适用于域名注册数据访问相关业务，用于替代改进WHOIS协议。

2规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，

仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本

文件。

YD/TAAAA-AAAA基于区块链的域名注册数据访问协议查询数据格式定义；

YD/TBBBB-BBBB基于区块链的域名注册数据访问协议响应数据格式定义；

IETFRFC7480注册数据访问协议HTTP应用技术要求（HTTPUsageintheRegistrationData

AccessProtocol）

3术语和定义

本文件没有需要界定的术语和定义。

4缩略语

下列缩略语适用于本文件。

HTTP超文本传输协议HyperTextTransferProtocol

HTTPGET超文本传输协议GETHTTPGETMethod

方法

IANA互联网数字分配机构TheInternetAssignedNumbers

Authority

JSONJS对象标识法TheJavaScriptObjectNotation

REST表述性状态转移RepresentationalStateTransfer

TLD顶级域Top-levelDomain

URI统一资源标识符UniformResourceIdentifier

URL统一资源定位符UniformResourceLocator

Web全球广域网WorldWideWeb

WHOIS域名信息查询协议WHOISProtocol

5

YD/TXXXX—XXXX

5概述

本文件定义基于区块链的域名注册数据访问协议中超文本传输协议（HTTP）的使用方法。本文件

的目标是使用表述性状态转移(RepresentationalStateTransfer，REST)体系结构风格的做法，将HTTP的

使用模式组合到适用于提供注册数据的各类目录服务的通用配置文件中，HTTP协议的使用规范应遵循

IETFRFC7480第4章的要求。通过赋予各种目录服务相同的行为，单个客户端可以更好地从遵循该行

为的目录服务中检索数据。

由该服务提供的注册数据是互联网资源注册数据——域名和互联网号码资源的注册。该数据通常由

WHOIS服务提供，但是WHOIS协议不足以满足现代注册数据服务的要求。替代协议期望保留WHOIS

的简单性质，同时提供查询和响应规范，重定向到权威源，支持国际化域名，并支持本地化注册数据（例

如地址，组织或个人名称）。

在设计这些常用用法模式时，本文件介绍了使用HTTP的注意事项。在可能存在复杂性的地方，本

文件的目标是将其放在服务器上，并使客户端尽可能简单。使用常见的操作系统脚本工具（例如bash

和wget）应可以实现客户端。

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

——客户端应确定要查询的合适的服务器，以及在此类查询中使用的适当的基础统一资源定位符。

有关更多信息，请参见附录C。具体查询数据源为基于区块链的新型域名注册数据管理平台。

——客户端可使用GET发出HTTP（或HTTPS）查询。例如，网络注册的查询URL可能是：

/rdap/ip/

构造查询请求时应遵循YD/TAAAA-AAAA第6章中规定的查询路径段格式要求。

——如果接收服务器具有查询的信息，它应检查查询的“Accept”头字段，并返回200响应以及适

合于所请求格式的响应实体。应遵循YD/TBBBB-BBBB第8章中规定的响应格式要求。

——如果接收服务器没有查询的信息，但是知道在哪里可以找到该信息，它应返回一个重定向响应

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

服务器。客户端应使用该HTTPURL重新查询。

——如果接收服务器不具有所请求的信息，并且不知道在哪里可以找到该信息，则它应返回404响

应。

——如果接收服务器由于策略原因不回答请求，它应返回错误响应（4xx），指示不回答的原因。

本文件的目的不是重新定义HTTP含义和语义。本文件的目的是阐明基于区块链的域名注册数据访

问协议中使用标准HTTP机制的情况。

6设计目标

本文件尝试满足一些设计准则：

首先，每个查询应只需要一个执行路径即可获得答案。响应可能包含答案，可能无答案或者重定向，

并且不应期望客户端派生多个执行路径来进行查询。

其次，请求/响应的语义应允许将来和/或非标准的响应格式。在本文件中，仅提到了JSON响应媒体

类型，响应内容应遵循YD/TBBBB-BBBB第7章中的规定。本文件仅描述域名注册数据访问协议中数

据如何使用HTTP以JSON格式传输。

第三，本文件旨在能够利用可用于HTTP的一系列机制。HTTP提供了许多本文件中未进一步描述的

机制。运营商可以根据其本地策略使用这些机制，包括缓存控制，授权，压缩和重定向等。HTTP还得

6

YD/TXXXX—XXXX

益于在可伸缩性，可靠性和性能方面的广泛投资，以及研发人员对基于REST风格的Web服务的客户端

行为具有广泛理解，从而降低了注册数据目录服务和客户端的部署成本。该协议与HTTP2.0向前兼容。

7查询

7.1HTTP方法

客户端使用GET方法获取响应主体，并使用HEAD方法确定服务器上数据的存在。客户端应该使用

HTTPGET或HEAD方法，这些方法的规范参见IETFRFC7231第4.3节。服务器没有义务支持其他HTTP

方法。因此，使用其他方法的客户端可能无法正确互操作。

客户端和服务器应支持HTTPS以支持安全服务。

7.2Accept头字段

为了向服务器表示需要注册数据访问协议响应，客户端应设置Accept头字段，其中包括特定于注册

数据访问协议的JSON媒体类型，或通用JSON媒体类型或以上两者。接收注册数据访问协议请求的服务

器应返回一个带有Content-Type头字段的实体，其包含特定于注册数据访问协议的JSON媒体类型。

该标准未定义“Accept”头字段中任何其他媒体类型或没有“Accept”头字段时服务器返回的响应。

一种可能性是以适合在Web浏览器中渲染的媒体类型返回响应。

7.3查询参数

服务器应忽略未知的查询参数。附录B中介绍了如何使用未知查询参数进行缓存破坏（cache

busting）。

当前查询请求中对可用标识符的范围进行了限制，标识符的扩展设置参见附录D。

8HTTP响应的类型

8.1肯定的回答

如果服务器具有客户端请求的信息，并希望根据其策略对客户端进行响应，则服务器应在200（OK）

响应的正文中返回该答案。

8.2重定向

如果服务器希望通知客户端给定查询的答案可以在其他地方找到，则它返回301（永久移动）响应

代码以指示永久移动，或者返回302（找到），303（查看其他），或者307（临时重定向）响应代码以

表示非永久重定向，并且在“Location”头字段中包含HTTP（S）URL，响应代码的使用参见IETFRFC

7231第6章。客户端会使用给定的URL发出后续请求以满足原始查询，而无需对该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否定的回答

如果服务器想要响应某个查询有一个空结果集（即没有合适的数据满足查询条件），它应返回404

（未找到）响应代码。可选地，它可以在HTTP实体主体中包含有关否定答案的附加信息。

如果服务器希望通知客户端有关该查询的信息是可用的，但由于策略原因而不能将该信息包含在对

客户端的响应中，则服务器应使用HTTP的4xx范围以外的适当响应代码进行响应。如果重试查询适合于

对应的响应代码，客户端可以重新查询。

8.4格式错误的查询

如果服务器收到无法解释为注册数据访问协议请求的查询，则它应返回400（错误请求）响应代码。

（可选地）它可以在HTTP实体主体中包含有关此否定答案的其他信息。

8.5速度限制

一些服务器应用速率限制来阻止地址抓取和其他滥用。当服务器由于速率限制而拒绝回答查询时，

它应返回429（请求过多）响应代码，该响应代码的使用说明参见IETFRFC6585第4章。收到429响应

的客户端应该降低其查询速率，并遵守Retry-After首部字段（如果存在）。服务器可能会对不遵守

Retry-After首部字段的客户端施加更严格的限制。可选地，服务器可以在HTTP实体主体中包含有关速

率限制的附加信息。

请注意，这并不是针对拒绝服务（DoS）攻击的防御措施，因为恶意客户端可能会忽略代码并继续

以高速率发送查询。如果服务器不希望向客户端透露速率限制是拒绝回复的原因，则可以使用其他响应

代码。

8.6跨域资源共享（CORS）

响应查询时，建议服务器使用指定的Access-Control-Allow-Origin首部字段。当注册数据访问协议用

于公共资源时，值“*”是合适的。

此首部（通常称为CORS首部）通过解除“同源”限制来帮助浏览器中的Web应用程序（即浏览器

可以从一个Web服务器加载注册数据访问协议客户端代码，但从其他Web服务器查询注册数据访问协议

数据）。

默认情况下，当允许跨源请求时，浏览器不发送cookie。Access-Control-Allow-Credentials首部字段

设置为“true”将发送cookie。不过不建议使用Access-Control-Allow-Credentials首部字段。

9国际化考虑

9.1唯一资源定位符(URIs)和国际化资源标识符(IRIS)

客户可以根据需要在内部使用国际化资源标识符，其结构定义参见IETFRFC3987第2章，但应将

其转换为URI以与注册数据访问协议服务器进行交互。注册数据访问协议服务器应在所有响应中使用

URI，并且客户端可以再次将这些URI转换为国际化资源标识符以供内部使用。

9.2查询和响应中的语言标识符

在大多数情况下，请求数据的客户端不会发出以特定语言或脚本返回数据的信号。另一方面，当服

务器返回数据并知道该数据是某种语言或脚本时，应在可用时用语言标识符对数据进行注释，从而允许

客户端相应地处理和显示数据。

8

YD/TXXXX—XXXX

9.3HTTP首部中的语言标识符

鉴于第9.2节中对语言标识符的使用的说明，除非另有说明，否则服务器在制定HTTP实体响应时应

忽略HTTPAccept-Language首部字段，这样客户就不会将该字段与实体主体中的“lang”值混淆。

但是，服务器可在Content-Language首部字段中返回语言标识符，以便通知客户端HTTP层消息的预

期语言。

附录A

（资料性）

协议示例

为了演示注册数据访问协议客户端和服务器的典型行为，下面是一个包括重定向的交互示例。为了

简洁起见，已省略了响应中的数据，因为本文件中未描述数据格式。此处使用的媒体类型应遵循YD/T

BBBB-BBBB第8章中的规定。

注册数据访问协议客户端和服务器交换的示例：

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缓存基础结构未充分遵守缓存标准，并且缓存响应的时间可能比服务器预期的要长。为

了克服这些问题，客户端可以使用一个临时的、不太可能使用的查询参数，并选择一个随机值。正如第

7.3节指示服务器忽略未知参数一样，它与注册数据访问协议定义兼容。

使用未知查询参数破坏缓存的示例：

——/ip/?__fuhgetaboutit=xyz123

使用未知参数来克服缓存异常的行为不属于任何规范的一部分，此处提供此信息仅供参考。

11

YD/TXXXX—XXXX

附录C

（资料性）

引导和重定向

WHOIS的传统部署模型没有提供确定信息权威来源的机制。

过去已经实施了一些方法，最值得注意的是联合WHOIS倡议。但是，除其他缺陷外，联合WHOIS

是使用代理和服务器端推荐来实现的。

在注册数据访问协议中，使用HTTP重定向和引导解决了这些问题。引导信息参见IETFRFC7484第

3章内容。在受限的环境中，常规过程可能不可行，需要服务器充当“重定向器”。

重定向服务器使用重定向表向客户端发出HTTP重定向，重定向表信息参见IETFRFC7484第3章。

图C.1描绘了使用重定向器进行引导的客户端。

图C.1.查询的注册数据访问协议数据

在某些情况下，特别是在称为“ERX空间”的地区性互联网注册管理机构（RIR）与网络传输之间

进行的子授权中，将发出多个HTTP重定向。图C.2显示了这种情况。

12

YD/TXXXX—XXXX

图C.2：查询注册数据访问协议数据以获取已传输的数据

13

YD/TXXXX—XXXX

附录D

（资料性）

可扩展性

D.1扩展标识符产生规则

出于扩展目的，本文件为JSON数据序列化和URI路径段中使用的前缀定义了IANA注册表。

前缀和标识符应仅由US-ASCII字符大写和小写字母A到Z，数字0到9和下划线字符组成，并且不应

以下划线字符，数字或字符“xml”开头。扩展的巴科斯范式中JSON名字的产生范式为：name=ALPHA

*(ALPHA/DIGIT/"_")。

此限制是Ruby编程语言标识符语法和XML元素名称语法的结合，并具有两个目的。首先，使用诸

如Ruby或Java之类的现代编程语言的客户端实现者可以使用自动将JSON名字提升为一阶对象属性或成

员的库。其次，使用这些规则很容易实现JSON和XML之间的清晰映射。

D.2扩展标识符注册

IANA在协议注册表中创建了一个新类别，标记为“注册数据访问协议”，并且在该类别中，建立

了一个URL引用的独立注册表，标记为“注册数据访问协议扩展”。该注册表的目的是确保扩展标识符

的唯一性。扩展标识符在JSON名字中用作前缀以及在RDAPURL中用作路径段的前缀。

这些标识符的产生规则在第D.1节中指定。

用于分配新值的IANA策略应为需要规范：值及其含义应记录在RFC或其他永久易用的参考文件中，

其详细程度应足以确保独立实现之间的互操作性是可能的。

以下是注册数据访问协议扩展的模板：

——扩展标识符：扩展的标识符

——注册运营商：注册运营商的名称

——发布的规范：RFC编号，参考书目或指向永久易用规范的URL

——要联系以获取更多信息的人员和电子邮件地址：有关此注册表项的联系人的姓名和电子邮件地

址

——预期用途：此注册表项的简要原因。

本文件中，可以通过定义新的扩展标识符来标识获取数据的区块链相关信息，以下是在注册数据访

问协议扩展注册表中注册的示例：

——扩展标识符：blockRecord

——注册运营商：any

——发布的规范：http：//www.example/rdap/block_info

——要联系以获取更多信息的人员和电子邮件地址：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规范性引用文件.....................................................................5

3术语和定义.........................................................................5

4缩略语.............................................................................5

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

6设计目标...........................................................................6

7查询...............................................................................6

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

7.2Accept头字段...................................................................7

7.3查询参数.......................................................................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（资料性）协议示例........................................................9

附录B（资料性）缓存破坏........................................................9

附录C（资料性）引导和重定向...................................................10

附录D（资料性）可扩展性.......................................................11

参考文献............................................................................13

2

YD/TXXXX—XXXX

基于区块链的域名注册数据访问协议HTTP应用技术要求

1范围

本文件规定了基于区块链的域名注册数据访问协议中利用HTTP协议发送请求和响应时的总体技术

要求和规范。

本文件适用于域名注册数据访问相关业务，用于替代改进WHOIS协议。

2规范性引用文件

下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，

仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本

文件。

YD/TAAAA-AAAA基于区块链的域名注册数据访问协议查询数据格式定义；

YD/TBBBB-BBBB基于区块链的域名注册数据访问协议响应数据格式定义；

IETFRFC7480注册数据访问协议HTTP应用技术要求（HTTPUsageintheRegistrationData

AccessProtocol）

3术语和定义

本文件没有需要界定的术语和定义。

4缩略语

下列缩略语适用于本文件。

HTTP超文本传输协议HyperTextTransferProtocol

HTTPGET超文本传输协议GETHTTPGETMethod

方法

IANA互联网数字分配机构TheInternetAssignedNumbers

Authority

JSONJS对象标识法TheJavaScriptObjectNotation

REST表述性状态转移RepresentationalStateTransfer

TLD顶级域Top-levelDomain

URI统一资源标识符UniformResourceIdentifier

URL统一资源定位符UniformResourceLocator

Web全球广域网WorldWideWeb

WHOIS域名信息查询协议WHOISProtocol

5

YD/TXXXX—XXXX

5概述

本文件定义基于区块链的域名注册数据访问协议中超文本传输协议（HTTP）的使用方法。本文件

的目标是使用表述性状态转移(RepresentationalStateTransfer，REST)体系结构风格的做法，将HTTP的

使用模式组合到适用于提供注册数据的各类目录服务的通用配置文件中，HTTP协议的使用规范应遵循

IETFRFC7480第4章的要求。通过赋予各种目录服务相同的行为，单个客户端可以更好地从遵循该行

为的目录服务中检索数据。

由该服务提供的注册数据是互联网资源注册数据——域名和互联网号码资源的注册。该数据通常由

WHOIS服务提供，但是WHOIS协议不足以满足现代注册数据服务的要求。替代协议期望保留WHOIS

的简单性质，同时提供查询和响应规范，重定向到权威源，支持国际化域名，并支持本地化注册数据（例

如地址，组织或个人名称）。

在设计这些常用用法模式时，本文件介绍了使用HTTP的注意事项。在可能存在复杂性的地方，本

文件的目标是将其放在服务器上，并使客户端尽可能简单。使用常见的操作系统脚本工具（例如bash

和wget）应可以实现客户端。

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

——客户端应确定要查询的合适的服务器，以及在此类查询中使用的适当的基础统一资源定位符。

有关更多信息，请参见附录C。具体查询数据源为基于区块链的新型域名注册数据管理平台。

——客户端可使用GET发出HTTP（或HTTPS）查询。例如，网络注册的查询URL可能是：

/rdap/ip/

构造查询请求时应遵循YD/TAAAA-AAAA第6章中规定的查询路径段格式要求。

——如果接收服务器具有查询的信息，它应检查查询的“Accept”头字段，并返回200响应以及适

合于所请求格式的响应实体。应遵循YD/TBBBB-BBBB第8章中规定的响应格式要求。

——如果接收服务器没有查询的信息，但是知道在哪里可以找到该信息，它应返回一个重定向响应

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

服务器。客户端应使用该HTTPURL重新查询。

——如果接收服务器不具有所请求的信息，并且不知道在哪里可以找到该信息，则它应返回404响

应。

——如果接收服务器由于策略原因不回答请求，它应返回错误响应（4xx），指示不回答的原因。

本文件的目的不是重新定义HTTP含义和语义。本文件的目的是阐明基于区块链的域名注册数据访

问协议中使用标准HTTP机制的情况。

6设计目标

本文件尝试满足一些设计准则：

首先，每个查询应只需要一个执行路径即可获得答案。响应可能包含答案，可能无答案或者重定向，

并且不应期望客户端派生多个执行路径来进行查询。

其次，请求/响应的语义应允许将来和/或非标准的响应格式。在本文件中，仅提到了JSON响应媒体

类型，响应内容应遵循YD/TBBBB-BBBB第7章中的规定。本文件仅描述域名注册数据访问协议中数

据如何使用HTTP以JSON格式传输。

第三，本文件旨在能够利用可用于HTTP的一系列机制。HTTP提供了许多本文件中未进一步描述的

机制。运营商可以根据其本地策略使用这些机制，包括缓存控制，授权，压缩和重定向等。HTTP还得

6

YD/TXXXX—XXXX

益于在可伸缩性，可靠性和性能方面的广泛投资，以及研发人员对基于REST风格的Web服务的客户端

行为具有广泛理解，从而降低了注册数据目录服务和客户端的部署成本。该协议与HTTP2.0向前兼容。

7查询

7.1HTTP方法

客户端使用GET方法获取响应主体，并使用HEAD方法确定服务器上数据的存在。客户端应该使用

HTTPGET或HEAD方法，这些方法的规范参见IETFRFC7231第4.3节。服务器没有义务支持其他HTTP

方法。因此，使用其他方法的客户端可能无法正确互操作。

客户端和服务器应支持HTTPS以支持安全服务。

7.2Accept头字段

为了向服务器表示需要注册数据访问协议响应，客户端应设置Accept头字段，其中包括特定于注册

数据访问协议的JSON媒体类型，或通用JSON媒体类型或以上两者。接收注册数据访问协议请求的服务

器应返回一个带有Content-Type头字段的实体，其包含特定于注册数据访问协议的JSON媒体类型。

该标准未定义“Accept”头字段中任何其他媒体类型或没有“Accept”头字段时服务器返回的响应。

一种可能性是以适合在Web浏览器中渲染的媒体类型返回响应。

7.3查询参数

服务器应忽略未知的查询参数。附录B中介绍了如何使用未知查询参数进行缓存破坏（cache

busting）。

当前查询请求中对可用标识符的范围进行了限制，标识符的扩展设置参见附录D。

8HTTP响应的类型

8.1肯定的回答

如果服务器具有客户端请求的信息，并希望根据其策略对客户端进行响应，则服务器应在200（OK）

响应的正文中返回该答案。

8.2重定向

如果服务器希望通知客户端给定查询的答案可以在其他地方找到，则它返回301（永久移动）响应

代码以指示永久移动，或者返回302（找到），303（查看其他），或者307（临时重定向）响应代码以

表示非永久重定向，并且在“Location”头字段中包含HTTP（S）URL，响应代码的使用参见IETFRFC

7231第6章。客户端会使用给定的URL发出后续请求以满足原始查询，而无需对该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否定的回答

如果服务器想要响应某个查询有一个空结果集（即没有合适的数据满足查询条件），它应返回404

（未找到）响应代码。可选地，它可以在HTTP实体主体中包含有关否定答案的附加信息。

如果服务器希望通知客户端有关该查询的信息是可用的，但由于策略原因而不能将该信息包含在对

客户端的响应中，则服务器应使用HTTP的4xx范围以外的适当响应代码进行响应。如果重试查询适合于

对应的响应代码，客户端可以重新查询。

8.4格式错误的查询

如果服务器收到无法解释为注册数据访问协议请求的查询，则它应返回400（错误请求）响应代码。

（可选地）它可以在HTTP实体主体中包含有关此否定答案的其他信息。

8.5速度限制

一些服务器应用速率限制来阻止地址抓取和其他滥用。当服务器由于速率限制而拒绝回答查询时，

它应返回429（请求过多）响应代码，该响应代码的使用说明参见IETFRFC6585第4章。收到429响应

的客户端应该降低其查询速率，并遵守Retry-After首部字段（如果存在）。服务器可能会对不遵守

Retry-After首部字段的客户端施加更严格的限制。可选地，服务器可以在HTTP实体主体中包含有关速

率限制的附加信息。

请注意，这并不是针对拒绝服务（DoS）攻击的防御措施，因为恶意客户端可能会忽略代码并继续

以高速率发送查询。如果服务器不希望向客户端透露速率限制是拒绝回复的原因，则可以使用其他响应

代码。

8.6跨域资源共享（CORS）

响应查询时，建议服务