Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 8427 ICANN
Category: Informational July 2018
ISSN: 2070-1721
Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 8427 ICANN
Category: Informational July 2018
ISSN: 2070-1721
Representing DNS Messages in JSON
用JSON表示DNS消息
Abstract
摘要
Some applications use DNS messages, or parts of DNS messages, as data. For example, a system that captures DNS queries and responses might want to be able to easily search them without having to decode the messages each time. Another example is a system that puts together DNS queries and responses from message parts. This document describes a general format for DNS message data in JSON. Specific profiles of the format in this document can be described in other documents for specific applications and usage scenarios.
某些应用程序使用DNS消息或部分DNS消息作为数据。例如，捕获DNS查询和响应的系统可能希望能够轻松搜索它们，而无需每次解码消息。另一个例子是将DNS查询和来自消息部分的响应放在一起的系统。本文档描述了JSON格式的DNS消息数据的通用格式。本文档中格式的特定配置文件可在其他文档中针对特定应用程序和使用场景进行描述。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8427.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8427.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Design of the Format . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. JSON Format for DNS Messages . . . . . . . . . . . . . . . . 5
2.1. Message Object Members . . . . . . . . . . . . . . . . . 5
2.2. Resource Record Object Members . . . . . . . . . . . . . 6
2.3. Specific RDATA Field Members . . . . . . . . . . . . . . 7
2.4. The Message and Its Parts as Octets . . . . . . . . . . . 8
2.5. Additional Message Object Members . . . . . . . . . . . . 8
2.6. Name Fields . . . . . . . . . . . . . . . . . . . . . . . 9
3. JSON Format for a Paired DNS Query and Response . . . . . . . 9
4. Streaming DNS Objects . . . . . . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Example of the Format of a DNS Query . . . . . . . . . . 10
5.2. Example of the Format of a Paired DNS Query and Response 11
6. Local Format Policy . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.1. Media Type Registration of application/dns+json . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Design of the Format . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. JSON Format for DNS Messages . . . . . . . . . . . . . . . . 5
2.1. Message Object Members . . . . . . . . . . . . . . . . . 5
2.2. Resource Record Object Members . . . . . . . . . . . . . 6
2.3. Specific RDATA Field Members . . . . . . . . . . . . . . 7
2.4. The Message and Its Parts as Octets . . . . . . . . . . . 8
2.5. Additional Message Object Members . . . . . . . . . . . . 8
2.6. Name Fields . . . . . . . . . . . . . . . . . . . . . . . 9
3. JSON Format for a Paired DNS Query and Response . . . . . . . 9
4. Streaming DNS Objects . . . . . . . . . . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Example of the Format of a DNS Query . . . . . . . . . . 10
5.2. Example of the Format of a Paired DNS Query and Response 11
6. Local Format Policy . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7.1. Media Type Registration of application/dns+json . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
The DNS message format is defined in [RFC1035]. DNS queries and DNS responses have exactly the same structure. Many of the field names and data type names given in [RFC1035] are commonly used in discussions of DNS. For example, it is common to hear things like "the query had a QNAME of 'example.com'" or "the RDATA has a simple structure".
DNS消息格式在[RFC1035]中定义。DNS查询和DNS响应具有完全相同的结构。[RFC1035]中给出的许多字段名和数据类型名通常用于DNS讨论。例如，经常听到“查询的QNAME为'example.com'”或“RDATA的结构很简单”之类的话。
There are hundreds of data-interchange formats for serializing structured data. Currently, JSON [RFC8259] is quite popular for many types of data, particularly data that has named subfields and optional parts.
有数百种用于序列化结构化数据的数据交换格式。目前，JSON[RFC8259]对于许多类型的数据非常流行，特别是具有命名子字段和可选部分的数据。
This document uses JSON to describe DNS messages. It also defines how to describe a paired DNS query and response and how to stream DNS objects.
本文档使用JSON描述DNS消息。它还定义了如何描述成对的DNS查询和响应以及如何流式传输DNS对象。
There are many ways to design a data format. This document uses a specific design methodology based on the DNS format.
设计数据格式的方法有很多种。本文档使用基于DNS格式的特定设计方法。
o The format is based on JSON objects in order to allow a writer to include or exclude parts of the format at will. No object members are ever required.
o 该格式基于JSON对象，以允许编写器随意包含或排除部分格式。不需要任何对象成员。
o This format is purposely overly general. A protocol or application that uses this format is expected to use only a subset of the items defined here; it is expected to define its own profile from this format.
o 这种格式故意过于笼统。使用此格式的协议或应用程序预期仅使用此处定义的项的子集；预计它将从此格式定义自己的配置文件。
o The format allows transformation through JSON that would permit re-creation of the wire content of the message.
o 该格式允许通过JSON进行转换，从而允许重新创建消息的有线内容。
o All members whose values are always 16 bits or shorter are represented by JSON numbers with no minus sign, no fractional part (except in fields that are specifically noted below), and no exponent part. One-bit values are represented as JSON numbers whose values are either 0 or 1. See Section 6 of [RFC8259] for more detail on JSON numbers.
o 值始终为16位或更短的所有成员都由JSON数字表示，这些数字不带减号、不带小数部分（下面特别指出的字段除外），也不带指数部分。一位值表示为值为0或1的JSON数字。有关JSON编号的更多详细信息，请参见[RFC8259]第6节。
o The JSON representation of the objects described in this document is limited to the UTF-8 codepoints from U+0000 to U+007F. This is done to prevent an attempt to use a different encoding such as UTF-8 for octets in names or data.
o 本文档中描述的对象的JSON表示仅限于从U+0000到U+007F的UTF-8代码点。这样做是为了防止尝试对名称或数据中的八位字节使用不同的编码，如UTF-8。
o Items that have string values can have "HEX" appended to their names to indicate a non-ASCII encoding of the value. Names that end in "HEX" have values stored in base16 encoding (hex with uppercase letters) defined in [RFC4648]. This is particularly useful for RDATA that is binary.
o 具有字符串值的项可以在其名称后附加“十六进制”，以指示该值的非ASCII编码。以“十六进制”结尾的名称的值存储在[RFC4648]中定义的base16编码（十六进制加大写字母）中。这对于二进制的RDATA特别有用。
o All field names in this format are used as in [RFC1035], including their capitalization. Names not defined in [RFC1035] generally use "camel case".
o 此格式中的所有字段名均按[RFC1035]中的格式使用，包括其大小写。[RFC1035]中未定义的名称通常使用“驼峰大小写”。
o The same data may be represented in multiple object members multiple times. For example, there is a member for the octets of the DNS message header, and there are members for each named part of the header. A message object can thus inadvertently have inconsistent data, such as a header member whose value does not match the value of the first bits in the entire message member.
o 相同的数据可以在多个对象成员中多次表示。例如，DNS消息头的八位字节有一个成员，头的每个命名部分都有成员。因此，消息对象可能无意中具有不一致的数据，例如其值与整个消息成员中的第一位的值不匹配的头成员。
o It is acceptable that there are multiple ways to represent the same data. This is done so that application designers can choose what fields are best for them and even so that they are able to allow multiple representations. That is, there is no "better" way to represent DNS data, so this design doesn't prefer specific representations.
o 可以接受的是，有多种方式来表示相同的数据。这样做是为了让应用程序设计人员可以选择最适合他们的字段，甚至让他们能够允许多个表示。也就是说，没有“更好”的方式来表示DNS数据，所以这种设计不喜欢特定的表示。
o The design explicitly allows for the description of malformed DNS messages. This is important for systems that are logging messages seen on the wire, particularly messages that might be used as part of an attack. A few examples of malformed DNS messages include:
o 该设计明确允许描述格式错误的DNS消息。这对于记录在线路上看到的消息的系统非常重要，特别是可能被用作攻击一部分的消息。格式错误的DNS消息的一些示例包括：
* a resource record (RR) that has an RDLENGTH of 4 but an RDATA whose length is longer than 4 (if it is the last RR in a message)
* 一种资源记录（RR），其RDLENGTH为4，但RDATA的长度大于4（如果它是消息中的最后一个RR）
* a DNS message whose QDCOUNT is 0
* QDCOUNT为0的DNS消息
* a DNS message whose ANCOUNT is large but there are insufficient bytes after the header
* 一种DNS消息，其ANCOUNT较大，但标头后的字节不足
* a DNS message whose length is less than 12 octets, meaning it doesn't even have a full header
* 长度小于12个八位字节的DNS消息，这意味着它甚至没有完整的头
o An object in this format can have zero or more of the members defined here; that is, no members are required by the format itself. Instead, profiles that use this format might have requirements for mandatory members, optional members, and prohibited members from the format. Also, this format does not prohibit members that are not defined in this format; profiles of the format are free to add new members in the profile.
o 此格式的对象可以具有此处定义的零个或多个成员；也就是说，格式本身不需要任何成员。相反，使用此格式的配置文件可能对格式中的强制成员、可选成员和禁止成员有要求。此外，此格式不禁止未在此格式中定义的成员；该格式的配置文件可在配置文件中自由添加新成员。
o This document defines DNS messages, not the zone files described in [RFC1035]. A different specification could be written to extend it to represent zone files. Note that DNS zone files allow escaping of octet values using "\DDD" notation, but this specification does not allow that; when encoding from a zone file to this JSON format, you need to do a conversion for many types of values.
o 本文档定义的是DNS消息，而不是[RFC1035]中描述的区域文件。可以编写不同的规范来扩展它以表示区域文件。请注意，DNS区域文件允许使用“\DDD”符号转义八位字节值，但本规范不允许这样做；当从区域文件编码到此JSON格式时，需要对多种类型的值进行转换。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The following gives all of the members defined for a DNS message. It is organized approximately by levels of the DNS message.
下面给出了为DNS消息定义的所有成员。它大致按DNS消息的级别组织。
o ID - Integer whose value is 0 to 65535
o ID-值为0到65535的整数
o QR - Boolean
o QR-布尔
o Opcode - Integer whose value is 0 to 15
o 操作码-值为0到15的整数
o AA - Boolean
o AA-布尔
o TC - Boolean
o TC-布尔
o RD - Boolean
o RD-布尔
o RA - Boolean
o RA-布尔
o AD - Boolean
o AD-布尔
o CD - Boolean
o CD-布尔
o RCODE - Integer whose value is 0 to 15
o RCODE-值为0到15的整数
o QDCOUNT - Integer whose value is 0 to 65535
o QDCOUNT-值为0到65535的整数
o ANCOUNT - Integer whose value is 0 to 65535
o ANCOUNT—值为0到65535的整数
o NSCOUNT - Integer whose value is 0 to 65535
o NSCOUNT-值为0到65535的整数
o ARCOUNT - Integer whose value is 0 to 65535
o ARCOUNT-值为0到65535的整数
o QNAME - String of the name of the first Question section of the message; see Section 2.6 for a description of the contents
o QNAME—消息第一个问题部分的名称字符串；内容说明见第2.6节
o compressedQNAME - Object that describes the name with two optional values: "isCompressed" (with a value of 0 for no and 1 for yes) and "length" (with an integer giving the length in the message)
o compressedQNAME—使用两个可选值描述名称的对象：“isCompressed”（0表示否，1表示是）和“length”（整数表示消息中的长度）
o QTYPE - Integer whose value is 0 to 65535, of the QTYPE of the first Question section of the message
o QTYPE—消息第一个问题部分的QTYPE的值为0到65535的整数
o QTYPEname - String whose value is from the IANA "Resource Record (RR) TYPEs" registry or has the format in [RFC3597]; this is case sensitive, so "AAAA", not "aaaa"
o QTYPEname—其值来自IANA“资源记录（RR）类型”注册表或格式为[RFC3597]的字符串；这是区分大小写的，所以是“AAAA”，而不是“AAAA”
o QCLASS - Integer whose value is 0 to 65535, of the QCLASS of the first Question section of the message
o QCLASS—消息第一个问题部分的QCLASS的值为0到65535的整数
o QCLASSname - String whose value is "IN", "CH", or "HS" or that has the format in [RFC3597]
o QCLASSname—值为“IN”、“CH”或“HS”或格式为[RFC3597]的字符串
o questionRRs - Array of zero or more resource records or rrSet objects in the Question section
o questionRRs-问题部分中零个或多个资源记录或rrSet对象的数组
o answerRRs - Array of zero or more resource records or rrSet objects in the Answer section
o answerRRs—应答部分中零个或多个资源记录或rrSet对象的数组
o authorityRRs - Array of zero or more resource records or rrSet objects in the Authority section
o authorityrs-权限部分中零个或多个资源记录或rrSet对象的数组
o additionalRRs - Array of zero or more resource records or rrSet objects in the Additional section
o additionalRRs—附加部分中零个或多个资源记录或rrSet对象的数组
A resource record is represented as an object with the following members.
资源记录表示为具有以下成员的对象。
o NAME - String of the NAME field of the resource record; see Section 2.6 for a description of the contents
o NAME—资源记录名称字段的字符串；内容说明见第2.6节
o compressedNAME - Object that describes the name with two optional values: "isCompressed" (with a value of 0 for no and 1 for yes) and "length" (with an integer giving the length in the message)
o compressedNAME—使用两个可选值描述名称的对象：“isCompressed”（0表示否，1表示是）和“length”（整数表示消息中的长度）
o TYPE - Integer whose value is 0 to 65535
o 类型-值为0到65535的整数
o TYPEname - String whose value is from the IANA "Resource Record (RR) TYPEs" registry or has the format in [RFC3597]; this is case sensitive, so "AAAA", not "aaaa"
o TYPEname—其值来自IANA“资源记录（RR）类型”注册表或格式为[RFC3597]的字符串；这是区分大小写的，所以是“AAAA”，而不是“AAAA”
o CLASS - Integer whose value is 0 to 65535
o 类-值为0到65535的整数
o CLASSname - String whose value is "IN", "CH", or "HS" or has the format in [RFC3597]
o CLASSname—值为“IN”、“CH”或“HS”或格式为[RFC3597]的字符串
o TTL - Integer whose value is -2147483648 to 2147483647 (it will only be 0 to 2147483647 in normal circumstances)
o TTL-值为-2147483648到2147483647的整数（正常情况下仅为0到2147483647）
o RDLENGTH - Integer whose value is 0 to 65535. Applications using this format are unlikely to use this value directly, and instead calculate the value from the RDATA.
o RDLENGTH—值为0到65535的整数。使用此格式的应用程序不太可能直接使用此值，而是从RDATA计算值。
o RDATAHEX - Hex-encoded string (base16 encoding, described in [RFC4648]) of the octets of the RDATA field of the resource record. The data in some common RDATA fields are also described in their own members; see Section 2.3
o RDATAHEX—资源记录的RDATA字段的八位字节的十六进制编码字符串（base16编码，在[RFC4648]中描述）。一些常见RDATA字段中的数据也在它们自己的成员中描述；见第2.3节
o rrSet - List of objects that have RDLENGTH and RDATA members
o rrSet—具有RDLENGTH和RDATA成员的对象列表
A Question section can be expressed as a resource record. When doing so, the TTL, RDLENGTH, and RDATA members make no sense.
问题部分可以表示为资源记录。这样做时，TTL、RDLENGTH和RDATA成员没有意义。
The following are common RDATA types and how to specify them as JSON members. The name of the member contains the name of the RDATA type. The data type for each of these members is a string. Each name is prefaced with "rdata" to prevent a name collision with fields that might later be defined that have the same name as the raw type name.
以下是常见的RDATA类型以及如何将它们指定为JSON成员。成员的名称包含RDATA类型的名称。每个成员的数据类型都是字符串。每个名称都以“rdata”开头，以防止名称与以后可能定义的与原始类型名称同名的字段发生冲突。
o rdataA - IPv4 address, such as "192.168.33.44"
o rdataA—IPv4地址，如“192.168.33.44”
o rdataAAAA - IPv6 address, such as "fe80::a65e:60ff:fed6:8aaf", as defined in [RFC5952]
o rdataAAAA—IPv6地址，如[RFC5952]中定义的“fe80:：a65e:60ff:fed6:8aaf”
o rdataCNAME - A domain name
o rdataCNAME-域名
o rdataDNAME - A domain name
o rdataDNAME-域名
o rdataNS - A domain name
o rdataNS-域名
o rdataPTR - A domain name
o rdataPTR-域名
o rdataTXT - A text value
o RDATATTXT-文本值
In addition, each of the following members has a value that is a space-separated string that matches the display format definition in the RFC that defines that RDATA type. It is not expected that every receiving application will know how to parse these values.
此外，以下每个成员都有一个值，该值是一个空格分隔的字符串，与定义该RDATA类型的RFC中的显示格式定义相匹配。不希望每个接收应用程序都知道如何解析这些值。
rdataCDNSKEY, rdataCDS, rdataCSYNC, rdataDNSKEY, rdataHIP, rdataIPSECKEY, rdataKEY, rdataMX, rdataNSEC, rdataNSEC3, rdataNSEC3PARAM, rdataOPENPGPKEY, rdataRRSIG, rdataSMIMEA, rdataSPF, rdataSRV, rdataSSHFP, rdataTLSA
rdataCDNSKEY、rdataCDS、rdataCSYNC、rdataDNSKEY、rdataHIP、rdataIPSECKEY、rdataKEY、rdataMX、rdataNSEC、rdataNSEC3、rdataNSEC3PARAM、rdataOPENPGPKEY、rdataRRSIG、rdatasmemea、rdataSPF、rdataSRV、rdataSSHFP、rdataTLSA
The following can be members of a message object. These members are all encoded in base16 encoding, described in [RFC4648]. All these items are strings.
以下内容可以是消息对象的成员。这些成员都采用base16编码，如[RFC4648]所述。所有这些项目都是字符串。
o messageOctetsHEX - The octets of the message
o messageOctetsHEX—消息的八位字节
o headerOctetsHEX - The first 12 octets of the message (or fewer, if the message is truncated)
o HeaderRoctetShex—消息的前12个八位字节（如果消息被截断，则不超过12个八位字节）
o questionOctetsHEX - The octets of the Question section
o 问题八位字节X-问题部分的八位字节
o answerOctetsHEX - The octets of the Answer section
o 答案八位组-答案部分的八位组
o authorityOctetsHEX - The octets of the Authority section
o authorityOctetsHEX-权限部分的八位字节
o additionalOctetsHEX - The octets of the Additional section
o additionalOctetsHEX-附加部分的八位字节
The following can be a member of a resource record object.
以下内容可以是资源记录对象的成员。
o rrOctetsHEX - The octets of a particular resource record
o 特定资源记录的八位字节
The items in this section are useful in applications to canonically reproduce what appeared on the wire. For example, an application that is converting wire-format requests and responses might do decompression of names, but the system reading the converted data may want to be sure the decompression was done correctly. Such a system would need to see the part of the message where the decompressed labels resided, such as in one of the items in this section.
本节中的项目在应用程序中非常有用，可以规范地再现导线上出现的内容。例如，正在转换wire格式请求和响应的应用程序可能会对名称进行解压缩，但读取转换数据的系统可能希望确保正确执行解压缩。这样的系统需要查看消息中解压缩标签所在的部分，如本节中的一个项。
The following are members that might appear in a message object:
以下是可能出现在消息对象中的成员：
o dateString - The date that the message was sent or received, given as a string in the standard format described in [RFC3339] and refined by Section 3.3 of [RFC4287].
o dateString—消息发送或接收的日期，以[RFC3339]中所述标准格式的字符串形式给出，并根据[RFC4287]第3.3节进行细化。
o dateSeconds - The date that the message was sent or received, given as a JSON number that is the number of seconds since 1970-01-01T00:00Z in UTC time; this number can be fractional. This number must have no minus sign, can have an optional fractional part, and can have no exponent part.
o dateSeconds—消息发送或接收的日期，以JSON数字形式给出，该数字是UTC时间1970-01-01T00:00Z之后的秒数；这个数字可以是小数。此数字必须没有减号，可以有可选的小数部分，也可以没有指数部分。
o comment - An unstructured comment as a string.
o 注释-作为字符串的非结构化注释。
Names are represented by JSON strings. The rules for how names are encoded are described in Section 1.1. (To recap: it is limited to the UTF-8 codepoints from U+0000 to U+007F.) The contents of these fields are always uncompressed; that is, after [RFC1035], name compression has been removed.
名称由JSON字符串表示。名称编码规则见第1.1节。（重述：仅限于U+0000到U+007F的UTF-8码点。）这些字段的内容始终未压缩；也就是说，在[RFC1035]之后，名称压缩已被删除。
There are two encodings for names:
名称有两种编码：
o If the member name does not end in "HEX", the value is a domain name encoded as DNS labels consisting of UTF-8 codepoints from U+0000 to U+007F. Within a label, codepoints above U+007F and the codepoint U+002E (ASCII period) MUST be expressed using JSON's escaping rules within this set of codepoints. Separation between labels is indicated with a period (codepoint U+002E). Internationalized Domain Name (IDN) labels are always expressed in their A-label form, as described in [RFC5890].
o 如果成员名称不以“十六进制”结尾，则该值是编码为DNS标签的域名，由U+0000到U+007F的UTF-8代码点组成。在一个标签中，U+007F以上的代码点和U+002E（ASCII句点）必须在这组代码点中使用JSON的转义规则来表示。标签之间的间隔用句点（代码点U+002E）表示。国际化域名（IDN）标签始终以A标签形式表示，如[RFC5890]所述。
o If the member name ends in "HEX", the value is the wire format for an entire domain name stored in base16 encoding, which is described in [RFC4648].
o 如果成员名称以“十六进制”结尾，则该值是以base16编码存储的整个域名的有线格式，如[RFC4648]所述。
A paired DNS query and response is represented as an object. Two optional members of this object are named "queryMessage" and "responseMessage", and each has a value that is a message object. This design was chosen (as compared to the more obvious array of two values) so that a paired DNS query and response could be differentiated from a stream of DNS messages whose length happens to be two.
成对的DNS查询和响应表示为对象。此对象的两个可选成员命名为“queryMessage”和“responseMessage”，每个成员都有一个作为消息对象的值。选择此设计（与更明显的两个值数组相比），以便将成对的DNS查询和响应与长度恰好为两个的DNS消息流区分开来。
Streaming of DNS objects is performed using JSON text sequences [RFC7464].
DNS对象的流使用JSON文本序列[RFC7464]执行。
The following is an example of a query for the A record of example.com.
下面是example.com的a记录的查询示例。
{ "ID": 19678, "QR": 0, "Opcode": 0,
"AA": 0, "TC": 0, "RD": 0, "RA": 0, "AD": 0, "CD": 0, "RCODE": 0,
"QDCOUNT": 1, "ANCOUNT": 0, "NSCOUNT": 0, "ARCOUNT": 0,
"QNAME": "example.com", "QTYPE": 1, "QCLASS": 1
}
{ "ID": 19678, "QR": 0, "Opcode": 0,
"AA": 0, "TC": 0, "RD": 0, "RA": 0, "AD": 0, "CD": 0, "RCODE": 0,
"QDCOUNT": 1, "ANCOUNT": 0, "NSCOUNT": 0, "ARCOUNT": 0,
"QNAME": "example.com", "QTYPE": 1, "QCLASS": 1
}
As stated earlier, all members of an object are optional. This example object could have one or more of the following members as well:
如前所述，对象的所有成员都是可选的。此示例对象还可以具有以下一个或多个成员：
"answerRRs": []
"authorityOctetsHEX": ""
"comment": "Something pithy goes here"
"dateSeconds": 1408504748.657783
"headerOctetsHEX": "4CDE00000001000000000000"
"QNAMEHEX": "076578616D706C6503636F6D00",
"compressedQNAME": { "isCompressed": 0 },
"messageOctetsHEX":
"4CDE00000001000000000000076578616D706C6503636F6D0000010001"
"questionOctetsHEX": "076578616D706C6503636F6D0000010001"
"questionRRs": [ { "NAMEHEX": "076578616D706C6503636F6D00",
"TYPE": 1, "CLASS": 1, "hostNAME" : "example.com." } ]
"questionRRs": [ { "NAME": "example.com.", "TYPE": 1,
"CLASS": 1, } ]
"answerRRs": []
"authorityOctetsHEX": ""
"comment": "Something pithy goes here"
"dateSeconds": 1408504748.657783
"headerOctetsHEX": "4CDE00000001000000000000"
"QNAMEHEX": "076578616D706C6503636F6D00",
"compressedQNAME": { "isCompressed": 0 },
"messageOctetsHEX":
"4CDE00000001000000000000076578616D706C6503636F6D0000010001"
"questionOctetsHEX": "076578616D706C6503636F6D0000010001"
"questionRRs": [ { "NAMEHEX": "076578616D706C6503636F6D00",
"TYPE": 1, "CLASS": 1, "hostNAME" : "example.com." } ]
"questionRRs": [ { "NAME": "example.com.", "TYPE": 1,
"CLASS": 1, } ]
(Note that this is an incomplete list of what else could be in the object.)
（请注意，这是对象中其他内容的不完整列表。）
The following is a paired DNS query and response for a query for the A record of example.com.
以下是针对example.com的a记录的查询的成对DNS查询和响应。
{
"queryMessage": { "ID": 32784, "QR": 0, "Opcode": 0, "AA": 0,
"TC": 0, "RD": 0, "RA": 0, "AD": 0, "CD": 0,
"RCODE": 0, "QDCOUNT": 1, "ANCOUNT": 0,
"NSCOUNT": 0, "ARCOUNT": 0,
"QNAME": "example.com.",
"QTYPE": 1, "QCLASS": 1 },
"responseMessage": { "ID": 32784, "QR": 1, "AA": 1, "RCODE": 0,
"QDCOUNT": 1, "ANCOUNT": 1, "NSCOUNT": 1,
"ARCOUNT": 0,
"answerRRs": [ { "NAME": "example.com.",
"TYPE": 1, "CLASS": 1,
"TTL": 3600,
"RDATAHEX": "C0000201" },
{ "NAME": "example.com.",
"TYPE": 1, "CLASS": 1,
"TTL": 3600,
"RDATAHEX": "C000AA01" } ],
"authorityRRs": [ { "NAME": "ns.example.com.",
"TYPE": 1, "CLASS": 1,
"TTL": 28800,
"RDATAHEX": "CB007181" } ]
}
}
{
"queryMessage": { "ID": 32784, "QR": 0, "Opcode": 0, "AA": 0,
"TC": 0, "RD": 0, "RA": 0, "AD": 0, "CD": 0,
"RCODE": 0, "QDCOUNT": 1, "ANCOUNT": 0,
"NSCOUNT": 0, "ARCOUNT": 0,
"QNAME": "example.com.",
"QTYPE": 1, "QCLASS": 1 },
"responseMessage": { "ID": 32784, "QR": 1, "AA": 1, "RCODE": 0,
"QDCOUNT": 1, "ANCOUNT": 1, "NSCOUNT": 1,
"ARCOUNT": 0,
"answerRRs": [ { "NAME": "example.com.",
"TYPE": 1, "CLASS": 1,
"TTL": 3600,
"RDATAHEX": "C0000201" },
{ "NAME": "example.com.",
"TYPE": 1, "CLASS": 1,
"TTL": 3600,
"RDATAHEX": "C000AA01" } ],
"authorityRRs": [ { "NAME": "ns.example.com.",
"TYPE": 1, "CLASS": 1,
"TTL": 28800,
"RDATAHEX": "CB007181" } ]
}
}
The Answer section could instead be given with an rrSet:
答案部分可以使用rrSet给出：
"answerRRs": [ { "NAME": "example.com.",
"TYPE": 1, "CLASS": 1,
"TTL": 3600,
"rrSet": [ { "RDATAHEX": "C0000201" },
{ "RDATAHEX": "C000AA01" } ] } ],
"answerRRs": [ { "NAME": "example.com.",
"TYPE": 1, "CLASS": 1,
"TTL": 3600,
"rrSet": [ { "RDATAHEX": "C0000201" },
{ "RDATAHEX": "C000AA01" } ] } ],
(Note that this is an incomplete list of what else could be in the Answer section.)
（请注意，这是答案部分中其他内容的不完整列表。）
Systems using the format in this document will likely have policy about what must be in the objects. Those policies are outside the scope of this document.
使用本文档中格式的系统可能有关于对象中必须包含的内容的策略。这些政策不在本文件的范围内。
For example, passive DNS systems such as those described in [PASSIVE-DNS] cover just DNS responses. Such a system might have a policy that makes QNAME, QTYPE, and answerRRs mandatory. That document also describes two mandatory times that are not in this format, so the policy would possibly also define those members and make them mandatory. The policy could also define additional members that might appear in a record.
例如，被动DNS系统（如[passive-DNS]中所述）仅涵盖DNS响应。这样的系统可能有一个策略，使QNAME、QTYPE和answerRRs成为强制性的。该文档还描述了两个非此格式的强制时间，因此该策略可能还将定义这些成员并使其成为强制时间。该策略还可以定义可能出现在记录中的其他成员。
As another example, a program that uses this format for configuring what a test client sends on the wire might have a policy of "each record object can have as few members as it wants; all unstated members are filled in from previous records".
另一个例子是，使用此格式配置测试客户端在线路上发送的内容的程序可能有一个策略“每个记录对象可以有它想要的尽可能少的成员；所有未声明的成员都是从以前的记录中填充的”。
Type name: application
类型名称：应用程序
Subtype name: dns+json
子类型名称：dns+json
Required parameters: N/A
所需参数：不适用
Optional parameters: N/A
可选参数：不适用
Encoding considerations: Encoding considerations are identical to those specified for the "application/json" media type.
编码注意事项：编码注意事项与为“application/json”媒体类型指定的注意事项相同。
Security considerations: This document specifies the security considerations for the format.
安全注意事项：此文档指定了格式的安全注意事项。
Interoperability considerations: This document specifies format of conforming messages and the interpretation thereof.
互操作性注意事项：本文件规定了一致性消息的格式及其解释。
Published specification: This document
已发布规范：本文件
Applications that use this media type: Systems that want to exchange DNS messages
使用此媒体类型的应用程序：希望交换DNS消息的系统
Fragment identifier considerations: None
片段标识符注意事项：无
Additional information:
其他信息：
Deprecated alias names for this type: N/A
此类型的已弃用别名：不适用
Magic number(s): N/A
Magic number(s): N/A
File extension(s): This document uses the media type to refer to protocol messages and thus does not require a file extension.
文件扩展名：本文档使用媒体类型引用协议消息，因此不需要文件扩展名。
Macintosh file type code(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information: Paul Hoffman, paul.hoffman@icann.org
联系人和电子邮件地址，以获取更多信息：Paul Hoffman，Paul。hoffman@icann.org
Intended usage: COMMON
预期用途：普通
Restrictions on usage: N/A
使用限制：不适用
Author: Paul Hoffman, paul.hoffman@icann.org
作者：保罗·霍夫曼，保罗。hoffman@icann.org
Change controller: Paul Hoffman, paul.hoffman@icann.org
变更控制员：保罗·霍夫曼，保罗。hoffman@icann.org
As described in Section 1.1, a message object can have inconsistent data, such as a message with an ANCOUNT of 1 but that has either an empty answerRRs array or an answerRRs array that has two or more RRs. Other examples of inconsistent data would be resource records whose RDLENGTH does not match the length of the decoded value in the RDATAHEX member, a record whose various header fields do not match the value in headerOctetsHEX, and so on. A reader of this format must never assume that all of the data in an object are all consistent with each other.
如第1.1节所述，消息对象可能具有不一致的数据，例如ANCOUNT为1但具有空应答RRs数组或具有两个或多个RRs的应答RRs数组的消息。不一致数据的其他示例包括RDLENGTH与RDATAHEX成员中解码值的长度不匹配的资源记录、各种头字段与HeaderRoctetShex中的值不匹配的记录，等等。这种格式的读取器决不能假设对象中的所有数据都彼此一致。
This document describes a format, not a profile of that format. Lack of profile can lead to security issues. For example, if a system has a filter for JSON representations of DNS packets, that filter needs to have the same semantics for the output JSON as the consumer has. Unless the profile is quite tight, this can lead to the producer being able to create fields with different contents (using the HEX and regular formats), fields with malformed lengths, and so on.
本文档描述的是一种格式，而不是该格式的概要文件。缺少配置文件可能会导致安全问题。例如，如果系统有一个用于DNS数据包的JSON表示的过滤器，那么该过滤器需要具有与使用者相同的输出JSON语义。除非配置文件非常紧凑，否则这可能导致生产者能够创建具有不同内容的字段（使用十六进制和常规格式）、长度格式不正确的字段，等等。
Numbers in JSON do not have any bounds checking. Thus, integer values in a record might have invalid values, such as an ID field whose value is greater than or equal to 2^16, a QR field that has a value of 2, and so on.
JSON中的数字没有任何边界检查。因此，记录中的整数值可能具有无效值，例如值大于或等于2^16的ID字段、值为2的QR字段，等等。
The values that can be contained in this format may contain privacy-sensitive information. For example, a profile of this format that is used for logging queries sent to recursive resolvers might have source IP addresses that could identify the location of the person who sent the DNS query.
此格式中包含的值可能包含隐私敏感信息。例如，用于记录发送到递归解析程序的查询的此格式的配置文件可能具有可以标识发送DNS查询的人的位置的源IP地址。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[RFC3339]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，DOI 10.17487/RFC3339，2002年7月<https://www.rfc-editor.org/info/rfc3339>.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 2003, <https://www.rfc-editor.org/info/rfc3597>.
[RFC3597]Gustafsson，A.，“未知DNS资源记录（RR）类型的处理”，RFC 3597，DOI 10.17487/RFC3597，2003年9月<https://www.rfc-editor.org/info/rfc3597>.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, DOI 10.17487/RFC4287, December 2005, <https://www.rfc-editor.org/info/rfc4287>.
[RFC4287]诺丁汉，M.，Ed.和R.Sayre，Ed.，“原子联合格式”，RFC 4287，DOI 10.17487/RFC4287，2005年12月<https://www.rfc-editor.org/info/rfc4287>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<https://www.rfc-editor.org/info/rfc4648>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 5890，DOI 10.17487/RFC5890，2010年8月<https://www.rfc-editor.org/info/rfc5890>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 5952，DOI 10.17487/RFC5952，2010年8月<https://www.rfc-editor.org/info/rfc5952>.
[RFC7464] Williams, N., "JavaScript Object Notation (JSON) Text Sequences", RFC 7464, DOI 10.17487/RFC7464, February 2015, <https://www.rfc-editor.org/info/rfc7464>.
[RFC7464]Williams，N.，“JavaScript对象表示法（JSON）文本序列”，RFC 7464，DOI 10.17487/RFC7464，2015年2月<https://www.rfc-editor.org/info/rfc7464>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，STD 90，RFC 8259，DOI 10.17487/RFC8259，2017年12月<https://www.rfc-editor.org/info/rfc8259>.
[DNS-QUERY] Parthasarathy, M. and P. Vixie, "Representing DNS messages using XML", Work in Progress, draft-mohan-dns-query-xml-00, September 2011.
[DNS-QUERY]Parthasarathy，M.和P.Vixie，“使用XML表示DNS消息”，正在进行的工作，草稿-mohan-DNS-QUERY-XML-00，2011年9月。
[DNSXML] Daley, J., Morris, S., and J. Dickinson, "dnsxml - A standard XML representation of DNS data", Work in Progress, draft-daley-dnsxml-00, July 2013.
[DNSXML]Daley，J.，Morris，S.和J.Dickinson，“DNSXML-DNS数据的标准XML表示法”，正在进行的工作，draft-Daley-DNSXML-00，2013年7月。
[PASSIVE-DNS] Dulaunoy, A., Kaplan, A., Vixie, P., and H. Stern, "Passive DNS - Common Output Format", Work in Progress, draft-dulaunoy-dnsop-passive-dns-cof-04, June 2018.
[PASSIVE-DNS]Dulaunoy，A.，Kaplan，A.，Vixie，P.，和H.Stern，“被动式DNS-通用输出格式”，正在进行的工作，草稿-Dulaunoy-dnsop-PASSIVE-DNS-cof-042018年6月。
Acknowledgements
致谢
Some of the ideas in this document were inspired by earlier, abandoned work such as [DNSXML], [DNS-QUERY], and [PASSIVE-DNS]. The document was also inspired by early ideas from Stephane Bortzmeyer. Many people in the Domain Name System Operations (DNSOP) and DNS Over HTTPS (DOH) working groups contributed very useful ideas (even though this was not a WG work item).
本文档中的一些想法受到了早期废弃工作的启发，如[DNSXML]、[DNS-QUERY]和[PASSIVE-DNS]。该文件的灵感也来自斯蒂芬·博茨迈耶（Stephane Bortzmeyer）的早期想法。域名系统操作（DNSOP）和DNS Over HTTPS（DOH）工作组中的许多人提供了非常有用的想法（尽管这不是工作组的工作项目）。
Author's Address
作者地址
Paul Hoffman ICANN
保罗·霍夫曼·伊坎
Email: paul.hoffman@icann.org
Email: paul.hoffman@icann.org