1 Internet Engineering Task Force (IETF) P. Hoffman
2 Request for Comments: 8427 ICANN
3 Category: Informational July 2018
4 ISSN: 2070-1721
5
6
7 Representing DNS Messages in JSON
8
9 Abstract
10
11 Some applications use DNS messages, or parts of DNS messages, as
12 data. For example, a system that captures DNS queries and responses
13 might want to be able to easily search them without having to decode
14 the messages each time. Another example is a system that puts
15 together DNS queries and responses from message parts. This document
16 describes a general format for DNS message data in JSON. Specific
17 profiles of the format in this document can be described in other
18 documents for specific applications and usage scenarios.
19
20 Status of This Memo
21
22 This document is not an Internet Standards Track specification; it is
23 published for informational purposes.
24
25 This document is a product of the Internet Engineering Task Force
26 (IETF). It represents the consensus of the IETF community. It has
27 received public review and has been approved for publication by the
28 Internet Engineering Steering Group (IESG). Not all documents
29 approved by the IESG are candidates for any level of Internet
30 Standard; see Section 2 of RFC 7841.
31
32 Information about the current status of this document, any errata,
33 and how to provide feedback on it may be obtained at
34 https://www.rfc-editor.org/info/rfc8427.
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Hoffman Informational [Page 1]
53 RFC 8427 DNS in JSON July 2018
54
55
56 Copyright Notice
57
58 Copyright (c) 2018 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (https://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 Table of Contents
72
73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
74 1.1. Design of the Format . . . . . . . . . . . . . . . . . . 3
75 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
76 2. JSON Format for DNS Messages . . . . . . . . . . . . . . . . 5
77 2.1. Message Object Members . . . . . . . . . . . . . . . . . 5
78 2.2. Resource Record Object Members . . . . . . . . . . . . . 6
79 2.3. Specific RDATA Field Members . . . . . . . . . . . . . . 7
80 2.4. The Message and Its Parts as Octets . . . . . . . . . . . 8
81 2.5. Additional Message Object Members . . . . . . . . . . . . 8
82 2.6. Name Fields . . . . . . . . . . . . . . . . . . . . . . . 9
83 3. JSON Format for a Paired DNS Query and Response . . . . . . . 9
84 4. Streaming DNS Objects . . . . . . . . . . . . . . . . . . . . 9
85 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
86 5.1. Example of the Format of a DNS Query . . . . . . . . . . 10
87 5.2. Example of the Format of a Paired DNS Query and Response 11
88 6. Local Format Policy . . . . . . . . . . . . . . . . . . . . . 12
89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
90 7.1. Media Type Registration of application/dns+json . . . . . 12
91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
92 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
94 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
95 10.2. Informative References . . . . . . . . . . . . . . . . . 15
96 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
98
99
100
101
102
103
104
105
106
107 Hoffman Informational [Page 2]
108 RFC 8427 DNS in JSON July 2018
109
110
111 1. Introduction
112
113 The DNS message format is defined in [RFC1035]. DNS queries and DNS
114 responses have exactly the same structure. Many of the field names
115 and data type names given in [RFC1035] are commonly used in
116 discussions of DNS. For example, it is common to hear things like
117 "the query had a QNAME of 'example.com'" or "the RDATA has a simple
118 structure".
119
120 There are hundreds of data-interchange formats for serializing
121 structured data. Currently, JSON [RFC8259] is quite popular for many
122 types of data, particularly data that has named subfields and
123 optional parts.
124
125 This document uses JSON to describe DNS messages. It also defines
126 how to describe a paired DNS query and response and how to stream DNS
127 objects.
128
129 1.1. Design of the Format
130
131 There are many ways to design a data format. This document uses a
132 specific design methodology based on the DNS format.
133
134 o The format is based on JSON objects in order to allow a writer to
135 include or exclude parts of the format at will. No object members
136 are ever required.
137
138 o This format is purposely overly general. A protocol or
139 application that uses this format is expected to use only a subset
140 of the items defined here; it is expected to define its own
141 profile from this format.
142
143 o The format allows transformation through JSON that would permit
144 re-creation of the wire content of the message.
145
146 o All members whose values are always 16 bits or shorter are
147 represented by JSON numbers with no minus sign, no fractional part
148 (except in fields that are specifically noted below), and no
149 exponent part. One-bit values are represented as JSON numbers
150 whose values are either 0 or 1. See Section 6 of [RFC8259] for
151 more detail on JSON numbers.
152
153 o The JSON representation of the objects described in this document
154 is limited to the UTF-8 codepoints from U+0000 to U+007F. This is
155 done to prevent an attempt to use a different encoding such as
156 UTF-8 for octets in names or data.
157
158
159
160
161
162 Hoffman Informational [Page 3]
163 RFC 8427 DNS in JSON July 2018
164
165
166 o Items that have string values can have "HEX" appended to their
167 names to indicate a non-ASCII encoding of the value. Names that
168 end in "HEX" have values stored in base16 encoding (hex with
169 uppercase letters) defined in [RFC4648]. This is particularly
170 useful for RDATA that is binary.
171
172 o All field names in this format are used as in [RFC1035], including
173 their capitalization. Names not defined in [RFC1035] generally
174 use "camel case".
175
176 o The same data may be represented in multiple object members
177 multiple times. For example, there is a member for the octets of
178 the DNS message header, and there are members for each named part
179 of the header. A message object can thus inadvertently have
180 inconsistent data, such as a header member whose value does not
181 match the value of the first bits in the entire message member.
182
183 o It is acceptable that there are multiple ways to represent the
184 same data. This is done so that application designers can choose
185 what fields are best for them and even so that they are able to
186 allow multiple representations. That is, there is no "better" way
187 to represent DNS data, so this design doesn't prefer specific
188 representations.
189
190 o The design explicitly allows for the description of malformed DNS
191 messages. This is important for systems that are logging messages
192 seen on the wire, particularly messages that might be used as part
193 of an attack. A few examples of malformed DNS messages include:
194
195 * a resource record (RR) that has an RDLENGTH of 4 but an RDATA
196 whose length is longer than 4 (if it is the last RR in a
197 message)
198
199 * a DNS message whose QDCOUNT is 0
200
201 * a DNS message whose ANCOUNT is large but there are insufficient
202 bytes after the header
203
204 * a DNS message whose length is less than 12 octets, meaning it
205 doesn't even have a full header
206
207 o An object in this format can have zero or more of the members
208 defined here; that is, no members are required by the format
209 itself. Instead, profiles that use this format might have
210 requirements for mandatory members, optional members, and
211 prohibited members from the format. Also, this format does not
212 prohibit members that are not defined in this format; profiles of
213 the format are free to add new members in the profile.
214
215
216
217 Hoffman Informational [Page 4]
218 RFC 8427 DNS in JSON July 2018
219
220
221 o This document defines DNS messages, not the zone files described
222 in [RFC1035]. A different specification could be written to
223 extend it to represent zone files. Note that DNS zone files allow
224 escaping of octet values using "\DDD" notation, but this
225 specification does not allow that; when encoding from a zone file
226 to this JSON format, you need to do a conversion for many types of
227 values.
228
229 1.2. Terminology
230
231 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
232 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
233 "OPTIONAL" in this document are to be interpreted as described in
234 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
235 capitals, as shown here.
236
237 2. JSON Format for DNS Messages
238
239 The following gives all of the members defined for a DNS message. It
240 is organized approximately by levels of the DNS message.
241
242 2.1. Message Object Members
243
244 o ID - Integer whose value is 0 to 65535
245
246 o QR - Boolean
247
248 o Opcode - Integer whose value is 0 to 15
249
250 o AA - Boolean
251
252 o TC - Boolean
253
254 o RD - Boolean
255
256 o RA - Boolean
257
258 o AD - Boolean
259
260 o CD - Boolean
261
262 o RCODE - Integer whose value is 0 to 15
263
264 o QDCOUNT - Integer whose value is 0 to 65535
265
266 o ANCOUNT - Integer whose value is 0 to 65535
267
268 o NSCOUNT - Integer whose value is 0 to 65535
269
270
271
272 Hoffman Informational [Page 5]
273 RFC 8427 DNS in JSON July 2018
274
275
276 o ARCOUNT - Integer whose value is 0 to 65535
277
278 o QNAME - String of the name of the first Question section of the
279 message; see Section 2.6 for a description of the contents
280
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
281 o compressedQNAME - Object that describes the name with two optional
282 values: "isCompressed" (with a value of 0 for no and 1 for yes)
283 and "length" (with an integer giving the length in the message)
284
285 o QTYPE - Integer whose value is 0 to 65535, of the QTYPE of the
286 first Question section of the message
287
288 o QTYPEname - String whose value is from the IANA "Resource Record
289 (RR) TYPEs" registry or has the format in [RFC3597]; this is case
290 sensitive, so "AAAA", not "aaaa"
291
292 o QCLASS - Integer whose value is 0 to 65535, of the QCLASS of the
293 first Question section of the message
294
295 o QCLASSname - String whose value is "IN", "CH", or "HS" or that has
296 the format in [RFC3597]
297
298 o questionRRs - Array of zero or more resource records or rrSet
299 objects in the Question section
300
301 o answerRRs - Array of zero or more resource records or rrSet
302 objects in the Answer section
303
304 o authorityRRs - Array of zero or more resource records or rrSet
305 objects in the Authority section
306
307 o additionalRRs - Array of zero or more resource records or rrSet
308 objects in the Additional section
309
310 2.2. Resource Record Object Members
311
312 A resource record is represented as an object with the following
313 members.
314
315 o NAME - String of the NAME field of the resource record; see
316 Section 2.6 for a description of the contents
317
2.1. Message Object Members
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)
2.1. Message Object Members
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
an integer giving the count of octets of the name in
the message, including but not following compression pointers)
318 o compressedNAME - Object that describes the name with two optional
319 values: "isCompressed" (with a value of 0 for no and 1 for yes)
320 and "length" (with an integer giving the length in the message)
321
322 o TYPE - Integer whose value is 0 to 65535
323
324
325
326
327 Hoffman Informational [Page 6]
328 RFC 8427 DNS in JSON July 2018
329
330
331 o TYPEname - String whose value is from the IANA "Resource Record
332 (RR) TYPEs" registry or has the format in [RFC3597]; this is case
333 sensitive, so "AAAA", not "aaaa"
334
335 o CLASS - Integer whose value is 0 to 65535
336
337 o CLASSname - String whose value is "IN", "CH", or "HS" or has the
338 format in [RFC3597]
339
340 o TTL - Integer whose value is -2147483648 to 2147483647 (it will
341 only be 0 to 2147483647 in normal circumstances)
342
343 o RDLENGTH - Integer whose value is 0 to 65535. Applications using
344 this format are unlikely to use this value directly, and instead
345 calculate the value from the RDATA.
346
347 o RDATAHEX - Hex-encoded string (base16 encoding, described in
348 [RFC4648]) of the octets of the RDATA field of the resource
349 record. The data in some common RDATA fields are also described
350 in their own members; see Section 2.3
351
352 o rrSet - List of objects that have RDLENGTH and RDATA members
353
354 A Question section can be expressed as a resource record. When doing
355 so, the TTL, RDLENGTH, and RDATA members make no sense.
356
2.2. Resource Record Object Members
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)
2.2. Resource Record Object Members
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
an integer giving the count of octets of the name in
the message, including but not following compression pointers)
357 2.3. Specific RDATA Field Members
358
359 The following are common RDATA types and how to specify them as JSON
360 members. The name of the member contains the name of the RDATA type.
361 The data type for each of these members is a string. Each name is
362 prefaced with "rdata" to prevent a name collision with fields that
363 might later be defined that have the same name as the raw type name.
364
365 o rdataA - IPv4 address, such as "192.168.33.44"
366
367 o rdataAAAA - IPv6 address, such as "fe80::a65e:60ff:fed6:8aaf", as
368 defined in [RFC5952]
369
370 o rdataCNAME - A domain name
371
372 o rdataDNAME - A domain name
373
374 o rdataNS - A domain name
375
376 o rdataPTR - A domain name
377
378 o rdataTXT - A text value
379
380
381
382 Hoffman Informational [Page 7]
383 RFC 8427 DNS in JSON July 2018
384
385
386 In addition, each of the following members has a value that is a
387 space-separated string that matches the display format definition in
388 the RFC that defines that RDATA type. It is not expected that every
389 receiving application will know how to parse these values.
390
391 rdataCDNSKEY, rdataCDS, rdataCSYNC, rdataDNSKEY, rdataHIP,
392 rdataIPSECKEY, rdataKEY, rdataMX, rdataNSEC, rdataNSEC3,
393 rdataNSEC3PARAM, rdataOPENPGPKEY, rdataRRSIG, rdataSMIMEA, rdataSPF,
394 rdataSRV, rdataSSHFP, rdataTLSA
395
396 2.4. The Message and Its Parts as Octets
397
398 The following can be members of a message object. These members are
399 all encoded in base16 encoding, described in [RFC4648]. All these
400 items are strings.
401
402 o messageOctetsHEX - The octets of the message
403
404 o headerOctetsHEX - The first 12 octets of the message (or fewer, if
405 the message is truncated)
406
407 o questionOctetsHEX - The octets of the Question section
408
409 o answerOctetsHEX - The octets of the Answer section
410
411 o authorityOctetsHEX - The octets of the Authority section
412
413 o additionalOctetsHEX - The octets of the Additional section
414
415 The following can be a member of a resource record object.
416
417 o rrOctetsHEX - The octets of a particular resource record
418
419 The items in this section are useful in applications to canonically
420 reproduce what appeared on the wire. For example, an application
421 that is converting wire-format requests and responses might do
422 decompression of names, but the system reading the converted data may
423 want to be sure the decompression was done correctly. Such a system
424 would need to see the part of the message where the decompressed
425 labels resided, such as in one of the items in this section.
426
427 2.5. Additional Message Object Members
428
429 The following are members that might appear in a message object:
430
431 o dateString - The date that the message was sent or received, given
432 as a string in the standard format described in [RFC3339] and
433 refined by Section 3.3 of [RFC4287].
434
435
436
437 Hoffman Informational [Page 8]
438 RFC 8427 DNS in JSON July 2018
439
440
441 o dateSeconds - The date that the message was sent or received,
442 given as a JSON number that is the number of seconds since
443 1970-01-01T00:00Z in UTC time; this number can be fractional.
444 This number must have no minus sign, can have an optional
445 fractional part, and can have no exponent part.
446
447 o comment - An unstructured comment as a string.
448
449 2.6. Name Fields
450
451 Names are represented by JSON strings. The rules for how names are
452 encoded are described in Section 1.1. (To recap: it is limited to
453 the UTF-8 codepoints from U+0000 to U+007F.) The contents of these
454 fields are always uncompressed; that is, after [RFC1035], name
455 compression has been removed.
456
457 There are two encodings for names:
458
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
o rdataCNAME - A domain name o rdataDNAME - A domain name o rdataNS - A domain name o rdataPTR - A domain name In addition, each of the following members has a value that is a space-separated string that matches the presentation 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, rdataTXT
"A text value" is insufficiently clear to describe the contents of a TXT record, which consists of "One or mores". However, the immediately following description relying upon "display format" (corrected to "presentation format" per RFC 4034 and draft-ietf-dnsop- terminology-bis) _does_ cover it, so rdataTXT should move into the undifferentiated list. --VERIFIER NOTES-- This is a request for a technical change, and is outside the scope of errata reports. The change from "matches the display format" to "matches the presentation format" is a reasonable change in an errata report.
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
o rdataCNAME - A domain name o rdataDNAME - A domain name o rdataNS - A domain name o rdataPTR - A domain name o rdataTXT - An array of text values
Errata 5438 (https://www.rfc-editor.org/errata/eid5438) correctly notes that “A text value” is an improper definition of TXT records’ data; however, that errata incorrectly states that TXT record values are space-separated. While the individual character-strings in a TXT record may be represented as space-separated in an RFC-1035-style zone file, that’s not germane to the RDATA itself. --VERIFIER NOTES-- As this report is based on errata report 5438 and that report has been Rejected, this one is also. They are both discussing a technical change to the document, outside the scope of an errata report.
459 o If the member name does not end in "HEX", the value is a domain
460 name encoded as DNS labels consisting of UTF-8 codepoints from
461 U+0000 to U+007F. Within a label, codepoints above U+007F and the
462 codepoint U+002E (ASCII period) MUST be expressed using JSON's
463 escaping rules within this set of codepoints. Separation between
464 labels is indicated with a period (codepoint U+002E).
465 Internationalized Domain Name (IDN) labels are always expressed in
466 their A-label form, as described in [RFC5890].
467
468 o If the member name ends in "HEX", the value is the wire format for
469 an entire domain name stored in base16 encoding, which is
470 described in [RFC4648].
471
472 3. JSON Format for a Paired DNS Query and Response
473
474 A paired DNS query and response is represented as an object. Two
475 optional members of this object are named "queryMessage" and
476 "responseMessage", and each has a value that is a message object.
477 This design was chosen (as compared to the more obvious array of two
478 values) so that a paired DNS query and response could be
479 differentiated from a stream of DNS messages whose length happens to
480 be two.
481
482 4. Streaming DNS Objects
483
484 Streaming of DNS objects is performed using JSON text sequences
485 [RFC7464].
486
487
488
489
490
491
492 Hoffman Informational [Page 9]
493 RFC 8427 DNS in JSON July 2018
494
495
496 5. Examples
497
498 5.1. Example of the Format of a DNS Query
499
500 The following is an example of a query for the A record of
501 example.com.
502
503 { "ID": 19678, "QR": 0, "Opcode": 0,
504 "AA": 0, "TC": 0, "RD": 0, "RA": 0, "AD": 0, "CD": 0, "RCODE": 0,
505 "QDCOUNT": 1, "ANCOUNT": 0, "NSCOUNT": 0, "ARCOUNT": 0,
506 "QNAME": "example.com", "QTYPE": 1, "QCLASS": 1
507 }
508
509 As stated earlier, all members of an object are optional. This
510 example object could have one or more of the following members as
511 well:
512
513 "answerRRs": []
514 "authorityOctetsHEX": ""
515 "comment": "Something pithy goes here"
516 "dateSeconds": 1408504748.657783
517 "headerOctetsHEX": "4CDE00000001000000000000"
518 "QNAMEHEX": "076578616D706C6503636F6D00",
519 "compressedQNAME": { "isCompressed": 0 },
520 "messageOctetsHEX":
521 "4CDE00000001000000000000076578616D706C6503636F6D0000010001"
522 "questionOctetsHEX": "076578616D706C6503636F6D0000010001"
523 "questionRRs": [ { "NAMEHEX": "076578616D706C6503636F6D00",
524 "TYPE": 1, "CLASS": 1, "hostNAME" : "example.com." } ]
525 "questionRRs": [ { "NAME": "example.com.", "TYPE": 1,
526 "CLASS": 1, } ]
527
528 (Note that this is an incomplete list of what else could be in the
529 object.)
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547 Hoffman Informational [Page 10]
548 RFC 8427 DNS in JSON July 2018
549
550
551 5.2. Example of the Format of a Paired DNS Query and Response
552
553 The following is a paired DNS query and response for a query for the
554 A record of example.com.
555
556 {
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 does not end in "HEX", the value is a domain
name encoded in common display format as DNS labels separated by
U+002E "." characters. Internationalized Domain Name (IDN) labels
are always expressed in their A-label form, as described in
[RFC5890]. Label characters with code points equal to U+0022
QUOTATION MARK or U+005C REVERSE SOLIDUS or less than U+0020 SPACE
MUST be expressed using the JSON escaping rules of [RFC8259].
U+002E "." and U+005C "\" characters within labels MUST be
preceded by a backslash escape as specified by [RFC1035] (and that
backslash must itself be escaped for use in a JSON string,
resulting in either the three-character sequence "\\." or the
four-character sequence "\\\\", respectively).
557 "queryMessage": { "ID": 32784, "QR": 0, "Opcode": 0, "AA": 0,
558 "TC": 0, "RD": 0, "RA": 0, "AD": 0, "CD": 0,
559 "RCODE": 0, "QDCOUNT": 1, "ANCOUNT": 0,
560 "NSCOUNT": 0, "ARCOUNT": 0,
561 "QNAME": "example.com.",
562 "QTYPE": 1, "QCLASS": 1 },
563 "responseMessage": { "ID": 32784, "QR": 1, "AA": 1, "RCODE": 0,
564 "QDCOUNT": 1, "ANCOUNT": 1, "NSCOUNT": 1,
565 "ARCOUNT": 0,
566 "answerRRs": [ { "NAME": "example.com.",
567 "TYPE": 1, "CLASS": 1,
568 "TTL": 3600,
569 "RDATAHEX": "C0000201" },
570 { "NAME": "example.com.",
571 "TYPE": 1, "CLASS": 1,
572 "TTL": 3600,
573 "RDATAHEX": "C000AA01" } ],
574 "authorityRRs": [ { "NAME": "ns.example.com.",
575 "TYPE": 1, "CLASS": 1,
576 "TTL": 28800,
577 "RDATAHEX": "CB007181" } ]
578 }
579 }
580
581 The Answer section could instead be given with an rrSet:
582
583 "answerRRs": [ { "NAME": "example.com.",
584 "TYPE": 1, "CLASS": 1,
585 "TTL": 3600,
586 "rrSet": [ { "RDATAHEX": "C0000201" },
587 { "RDATAHEX": "C000AA01" } ] } ],
588
589 (Note that this is an incomplete list of what else could be in the
590 Answer section.)
591
592
593
594
595
596
597
598
599
600
601
602 Hoffman Informational [Page 11]
603 RFC 8427 DNS in JSON July 2018
604
605
606 6. Local Format Policy
607
608 Systems using the format in this document will likely have policy
609 about what must be in the objects. Those policies are outside the
610 scope of this document.
611
612 For example, passive DNS systems such as those described in
613 [PASSIVE-DNS] cover just DNS responses. Such a system might have a
614 policy that makes QNAME, QTYPE, and answerRRs mandatory. That
615 document also describes two mandatory times that are not in this
616 format, so the policy would possibly also define those members and
617 make them mandatory. The policy could also define additional members
618 that might appear in a record.
619
620 As another example, a program that uses this format for configuring
621 what a test client sends on the wire might have a policy of "each
622 record object can have as few members as it wants; all unstated
623 members are filled in from previous records".
624
625 7. IANA Considerations
626
627 7.1. Media Type Registration of application/dns+json
628
629 Type name: application
630
631 Subtype name: dns+json
632
633 Required parameters: N/A
634
635 Optional parameters: N/A
636
637 Encoding considerations: Encoding considerations are identical to
638 those specified for the "application/json" media type.
639
640 Security considerations: This document specifies the security
641 considerations for the format.
642
643 Interoperability considerations: This document specifies format of
644 conforming messages and the interpretation thereof.
645
646 Published specification: This document
647
648 Applications that use this media type: Systems that want to exchange
649 DNS messages
650
651 Fragment identifier considerations: None
652
653
654
655
656
657 Hoffman Informational [Page 12]
658 RFC 8427 DNS in JSON July 2018
659
660
661 Additional information:
662
663 Deprecated alias names for this type: N/A
664
665 Magic number(s): N/A
666
667 File extension(s): This document uses the media type to refer to
668 protocol messages and thus does not require a file extension.
669
670 Macintosh file type code(s): N/A
671
672 Person & email address to contact for further information:
673 Paul Hoffman, paul.hoffman@icann.org
674
675 Intended usage: COMMON
676
677 Restrictions on usage: N/A
678
679 Author: Paul Hoffman, paul.hoffman@icann.org
680
681 Change controller: Paul Hoffman, paul.hoffman@icann.org
682
683 8. Security Considerations
684
685 As described in Section 1.1, a message object can have inconsistent
686 data, such as a message with an ANCOUNT of 1 but that has either an
687 empty answerRRs array or an answerRRs array that has two or more RRs.
688 Other examples of inconsistent data would be resource records whose
689 RDLENGTH does not match the length of the decoded value in the
690 RDATAHEX member, a record whose various header fields do not match
691 the value in headerOctetsHEX, and so on. A reader of this format
692 must never assume that all of the data in an object are all
693 consistent with each other.
694
695 This document describes a format, not a profile of that format. Lack
696 of profile can lead to security issues. For example, if a system has
697 a filter for JSON representations of DNS packets, that filter needs
698 to have the same semantics for the output JSON as the consumer has.
699 Unless the profile is quite tight, this can lead to the producer
700 being able to create fields with different contents (using the HEX
701 and regular formats), fields with malformed lengths, and so on.
702
703 Numbers in JSON do not have any bounds checking. Thus, integer
704 values in a record might have invalid values, such as an ID field
705 whose value is greater than or equal to 2^16, a QR field that has a
706 value of 2, and so on.
707
708
709
710
711
712 Hoffman Informational [Page 13]
713 RFC 8427 DNS in JSON July 2018
714
715
716 9. Privacy Considerations
717
718 The values that can be contained in this format may contain privacy-
719 sensitive information. For example, a profile of this format that is
720 used for logging queries sent to recursive resolvers might have
721 source IP addresses that could identify the location of the person
722 who sent the DNS query.
723
724 10. References
725
726 10.1. Normative References
727
728 [RFC1035] Mockapetris, P., "Domain names - implementation and
729 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
730 November 1987, <https://www.rfc-editor.org/info/rfc1035>.
731
732 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
733 Requirement Levels", BCP 14, RFC 2119,
734 DOI 10.17487/RFC2119, March 1997,
735 <https://www.rfc-editor.org/info/rfc2119>.
736
737 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
738 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
739 <https://www.rfc-editor.org/info/rfc3339>.
740
741 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
742 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
743 2003, <https://www.rfc-editor.org/info/rfc3597>.
744
745 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
746 Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
747 December 2005, <https://www.rfc-editor.org/info/rfc4287>.
748
749 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
750 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
751 <https://www.rfc-editor.org/info/rfc4648>.
752
753 [RFC5890] Klensin, J., "Internationalized Domain Names for
754 Applications (IDNA): Definitions and Document Framework",
755 RFC 5890, DOI 10.17487/RFC5890, August 2010,
756 <https://www.rfc-editor.org/info/rfc5890>.
757
758 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
759 Address Text Representation", RFC 5952,
760 DOI 10.17487/RFC5952, August 2010,
761 <https://www.rfc-editor.org/info/rfc5952>.
762
763
764
765
766
767 Hoffman Informational [Page 14]
768 RFC 8427 DNS in JSON July 2018
769
770
771 [RFC7464] Williams, N., "JavaScript Object Notation (JSON) Text
772 Sequences", RFC 7464, DOI 10.17487/RFC7464, February 2015,
773 <https://www.rfc-editor.org/info/rfc7464>.
774
775 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
776 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
777 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
778
779 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
780 Interchange Format", STD 90, RFC 8259,
781 DOI 10.17487/RFC8259, December 2017,
782 <https://www.rfc-editor.org/info/rfc8259>.
783
784 10.2. Informative References
785
786 [DNS-QUERY]
787 Parthasarathy, M. and P. Vixie, "Representing DNS messages
788 using XML", Work in Progress,
789 draft-mohan-dns-query-xml-00, September 2011.
790
791 [DNSXML] Daley, J., Morris, S., and J. Dickinson, "dnsxml - A
792 standard XML representation of DNS data", Work in
793 Progress, draft-daley-dnsxml-00, July 2013.
794
795 [PASSIVE-DNS]
796 Dulaunoy, A., Kaplan, A., Vixie, P., and H. Stern,
797 "Passive DNS - Common Output Format", Work in Progress,
798 draft-dulaunoy-dnsop-passive-dns-cof-04, June 2018.
799
800 Acknowledgements
801
802 Some of the ideas in this document were inspired by earlier,
803 abandoned work such as [DNSXML], [DNS-QUERY], and [PASSIVE-DNS]. The
804 document was also inspired by early ideas from Stephane Bortzmeyer.
805 Many people in the Domain Name System Operations (DNSOP) and DNS Over
806 HTTPS (DOH) working groups contributed very useful ideas (even though
807 this was not a WG work item).
808
809 Author's Address
810
811 Paul Hoffman
812 ICANN
813
814 Email: paul.hoffman@icann.org
815
816
817
818
819
820
821
822 Hoffman Informational [Page 15]
823
"responseMessage": { "ID": 32784, "QR": 1, "AA": 1, "RCODE": 0,
"QDCOUNT": 1, "ANCOUNT": 1, "NSCOUNT": 1,
"responseMessage": { "ID": 32784, "QR": 1, "AA": 1, "RCODE": 0,
"QDCOUNT": 1, "ANCOUNT": 12, "NSCOUNT": 1,