[要約] RFC 8427は、DNSメッセージをJSON形式で表現するための仕様です。このRFCの目的は、DNSメッセージをより簡潔かつ柔軟に表現することで、DNSプロトコルの実装や解析を容易にすることです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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番号で表されます。 1ビット値は、値が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 文字列値を持つアイテムには、名前に「HEX」を追加して、値の非ASCIIエンコーディングを示すことができます。 「HEX」で終わる名前は、[RFC4648]で定義されているbase16エンコーディング（大文字の16進数）で保存された値を持っています。これは、バイナリである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)
* RDLENGTHが4であるが、長さが4より長いRDATA（メッセージの最後のRRである場合）のリソースレコード（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
* ANCOUNTは大きいが、ヘッダーの後ろに十分なバイトがないDNSメッセージ
* 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 この形式のオブジェクトには、ここで定義されているメンバーを0個以上含めることができます。つまり、フォーマット自体にはメンバーは必要ありません。代わりに、このフォーマットを使用するプロファイルには、必須メンバー、オプションメンバー、およびフォーマットの禁止メンバーに対する要件がある場合があります。また、この形式では、この形式で定義されていないメンバーを禁止していません。この形式のプロファイルは、プロファイルに新しいメンバーを自由に追加できます。
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 このドキュメントでは、[RFC1035]で説明されているゾーンファイルではなく、DNSメッセージを定義しています。別の仕様を作成して、ゾーンファイルを表すように拡張することもできます。 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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、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 ら ー ぼおぇあん
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 ARCOUNT - Integer whose value is 0 to 65535
o NSCOUNT-値が0〜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-2つのオプション値で名前を記述するオブジェクト：「isCompressed」（noの場合は0、yesの場合は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）TYPEs」レジストリからの値であるか、[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-質問セクションの0個以上のリソースレコードまたはrrSetオブジェクトの配列
o answerRRs - Array of zero or more resource records or rrSet objects in the Answer section
o answerRRs-0個以上のリソースレコードの配列、またはAnswerセクションのrrSetオブジェクト
o authorityRRs - Array of zero or more resource records or rrSet objects in the Authority section
o authorityRRs-Authorityセクションの0個以上のリソースレコードまたはrrSetオブジェクトの配列
o additionalRRs - Array of zero or more resource records or rrSet objects in the Additional section
o additionalRRs-追加セクションの0個以上のリソースレコードまたは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-リソースレコードの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-2つのオプション値で名前を説明するオブジェクト：「isCompressed」（noの場合は0、yesの場合は1の値）および「length」（メッセージで長さを示す整数）
o TYPE - Integer whose value is 0 to 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 TYPE-値が0〜65535の整数o TYPEname-値がIANAの「リソースレコード（RR）TYPEs」レジストリからのものか、[RFC3597]の形式の文字列。これは大文字と小文字が区別されるため、「aaaa」ではなく「AAAA」
o CLASS - Integer whose value is 0 to 65535
o CLASS-値が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フィールドのオクテットの16進エンコードされた文字列（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-「192.168.33.44」などのIPv4アドレス
o rdataAAAA - IPv6 address, such as "fe80::a65e:60ff:fed6:8aaf", as defined in [RFC5952]
o rdataAAAA-[RFC5952]で定義されている「fe80 :: a65e：60ff：fed6：8aaf」などのIPv6アドレス
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 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.
o rdataTXT-テキスト値さらに、以下の各メンバーには、その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、rdataSMIMEA、rdataSPF、rdataSRV、rdataSSHFP、rdataTLS
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.
以下は、メッセージオブジェクトのメンバーになることができます。これらのメンバーはすべて、[RFC4648]で説明されているbase16エンコーディングでエンコードされます。これらのアイテムはすべて文字列です。
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 headerOctetsHEX-メッセージの最初の12オクテット（メッセージが切り捨てられている場合はそれより少ない）
o questionOctetsHEX - The octets of the Question section
o questionOctetsHEX-質問セクションのオクテット
o answerOctetsHEX - The octets of the Answer section
o answerOctetsHEX-回答セクションのオクテット
o authorityOctetsHEX - The octets of the Authority section
o authorityOctetsHEX-Authorityセクションのオクテット
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 rrOctetsHEX-特定のリソースレコードのオクテット
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.
このセクションの項目は、ワイヤー上に表示されたものを標準的に再現するアプリケーションで役立ちます。たとえば、ワイヤー形式の要求と応答を変換しているアプリケーションは名前の解凍を行うかもしれませんが、変換されたデータを読み取るシステムは、解凍が正しく行われたことを確認したい場合があります。このようなシステムでは、このセクションのいずれかの項目など、解凍されたラベルが存在するメッセージの部分を確認する必要があります。
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-メッセージが送信または受信された日付。1970-01-01T00：00ZからのUTC時間での秒数であるJSON番号として与えられます。この数値は小数の場合があります。この数値にはマイナス記号があってはならず、オプションの小数部を含めることができ、指数部を含めることはできません。
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:
名前には2つのエンコーディングがあります。
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 メンバー名の末尾が「HEX」でない場合、値は、U + 0000からU + 007FまでのUTF-8コードポイントで構成されるDNSラベルとしてエンコードされたドメイン名です。ラベル内では、U + 007Fを超えるコードポイントとコードポイントU + 002E（ASCIIピリオド）は、このコードポイントのセット内でJSONのエスケープルールを使用して表現する必要があります。ラベル間の分離はピリオドで示されます（コードポイントU + 002E）。国際化ドメイン名（IDN）ラベルは、[RFC5890]で説明されているように、常にAラベル形式で表現されます。
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 メンバー名が「HEX」で終わる場合、値は[RFC4648]で説明されているbase16エンコーディングで保存されたドメイン名全体のワイヤ形式です。
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クエリとDNS応答は、オブジェクトとして表されます。このオブジェクトの2つのオプションのメンバーは「queryMessage」と「responseMessage」という名前で、それぞれにメッセージオブジェクトである値があります。この設計は、ペアになっているDNSクエリと応答を、長さがたまたま2であるDNSメッセージのストリームと区別できるように（2つの値のより明白な配列と比較して）選択されました。
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
}
As stated earlier, all members of an object are optional. This example object could have one or more of the following members as well:
前述のように、オブジェクトのすべてのメンバーはオプションです。このサンプルオブジェクトには、次のメンバーも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" } ]
}
}
The Answer section could instead be given with an rrSet:
代わりにAnswerセクションにrrSetを指定できます。
"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.
たとえば、[PASSIVE-DNS]で説明されているようなパッシブDNSシステムは、DNS応答のみをカバーしています。このようなシステムには、QNAME、QTYPE、およびanswerRRを必須にするポリシーがある場合があります。このドキュメントでは、この形式ではない2つの必須の時間についても説明しているため、ポリシーではこれらのメンバーを定義して必須にすることもできます。ポリシーでは、レコードに表示される可能性のある追加のメンバーを定義することもできます。
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
オプションのパラメーター：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
このタイプの非推奨のエイリアス名：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
Person & email address to contact for further information: Paul Hoffman, paul.hoffman@icann.org
詳細について連絡する人とメールアドレス：Paul Hoffman、paul.hoffman @ icann.org
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: N/A
使用上の制限：N / A
Author: Paul Hoffman, paul.hoffman@icann.org
作成者：Paul Hoffman、paul.hoffman @ icann.org
Change controller: Paul Hoffman, paul.hoffman@icann.org
変更コントローラー：Paul Hoffman、paul.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であるが空のanswerRRs配列または2つ以上のRRを持つanswerRRs配列があるメッセージなど、一貫性のないデータが含まれる場合があります。矛盾するデータの他の例としては、RDLENGTHがRDATAHEXメンバーのデコードされた値の長さと一致しないリソースレコード、さまざまなヘッダーフィールドがheaderOctetsHEXの値と一致しないレコードなどがあります。この形式の読者は、オブジェクト内のすべてのデータが互いに一貫していると想定してはなりません。
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に持つ必要があります。プロファイルがかなりタイトでない限り、これにより、プロデューサーは異なる内容のフィールド（HEXおよび通常のフォーマットを使用）、不正な長さのフィールドなどを作成できます。
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。、「Handling of Unknown DNS Resource Record（RR）Types」、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。、エド。およびR. Sayre編、「The Atom Syndication Format」、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。、「The 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。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、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. 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> 。
[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]ウィリアムズ、N。、「JavaScript Object Notation（JSON）Text Sequences」、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。、編、「JavaScript Object Notation（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メッセージの表現」、作業中、draft-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表現」、Work in Progress、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.
[パッシブDNS] Dulaunoy、A.、Kaplan、A.、Vixie、P。、およびH. Stern、「Passive DNS-Common Output Format」、Work in Progress、draft-dulaunoy-dnsop-passive-dns-cof- 2018年6月4日。
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）ワーキンググループの多くの人々が、非常に有用なアイデアを提供しました（これはWGの作業項目ではありませんでしたが）。
Author's Address
著者のアドレス
Paul Hoffman ICANN
ポール・ホフマンICANN
Email: paul.hoffman@icann.org