Internet Engineering Task Force (IETF) P. Hoffman Request for Comments: 8427 ICANN Category: Informational July 2018 ISSN: 2070-1721 Representing DNS Messages in JSON
AbstractSome 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. 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. 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.
Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 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. 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
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". 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. 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. Section 6 of [RFC8259] for more detail on JSON numbers. 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 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 All field names in this format are used as in [RFC1035], including their capitalization. Names not defined in [RFC1035] generally use "camel case". 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 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 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: * 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) * a DNS message whose QDCOUNT is 0 * a DNS message whose ANCOUNT is large but there are insufficient bytes after the header * a DNS message whose length is less than 12 octets, meaning it doesn't even have a full header 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 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. RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
o ARCOUNT - Integer whose value is 0 to 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 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 QTYPE - Integer whose value is 0 to 65535, of the QTYPE of the first Question section of the message 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 QCLASS - Integer whose value is 0 to 65535, of the QCLASS of the first Question section of the message o QCLASSname - String whose value is "IN", "CH", or "HS" or that has the format in [RFC3597] o questionRRs - Array of zero or more resource records or rrSet objects in the Question section o answerRRs - Array of zero or more resource records or rrSet objects in the Answer section o authorityRRs - Array of zero or more resource records or rrSet objects in the Authority section o additionalRRs - Array of zero or more resource records or rrSet objects in the Additional section Section 2.6 for a description of the contents 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 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 CLASS - Integer whose value is 0 to 65535 o CLASSname - String whose value is "IN", "CH", or "HS" or has the format in [RFC3597] o TTL - Integer whose value is -2147483648 to 2147483647 (it will only be 0 to 2147483647 in normal circumstances) 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 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 rrSet - List of objects that have RDLENGTH and RDATA members A Question section can be expressed as a resource record. When doing so, the TTL, RDLENGTH, and RDATA members make no sense. RFC5952] o rdataCNAME - A domain name o rdataDNAME - A domain name o rdataNS - A domain name o rdataPTR - A domain name 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. rdataCDNSKEY, rdataCDS, rdataCSYNC, rdataDNSKEY, rdataHIP, rdataIPSECKEY, rdataKEY, rdataMX, rdataNSEC, rdataNSEC3, rdataNSEC3PARAM, rdataOPENPGPKEY, rdataRRSIG, rdataSMIMEA, rdataSPF, rdataSRV, rdataSSHFP, rdataTLSA RFC4648]. All these items are strings. o messageOctetsHEX - The octets of the message o headerOctetsHEX - The first 12 octets of the message (or fewer, if the message is truncated) o questionOctetsHEX - The octets of the Question section o answerOctetsHEX - The octets of the Answer section o authorityOctetsHEX - The octets of the Authority section o additionalOctetsHEX - The octets of the Additional section The following can be a member of a resource record object. o rrOctetsHEX - The octets of a particular resource record 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. RFC3339] and refined by Section 3.3 of [RFC4287].
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 comment - An unstructured comment as a string. 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. 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 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]. RFC7464].
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. 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".
Additional information: Deprecated alias names for this type: 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, email@example.com Intended usage: COMMON Restrictions on usage: N/A Author: Paul Hoffman, firstname.lastname@example.org Change controller: Paul Hoffman, email@example.com 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. 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. 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.
[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>. [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>. [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>. [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>. [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>. [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>. [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>. [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>.