idnits 2.17.1 draft-hoffman-dns-in-json-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 381: '... (ASCII period), MUST be expressed usi...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 12, 2018) is 2174 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-dulaunoy-dnsop-passive-dns-cof-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft ICANN 4 Intended status: Experimental May 12, 2018 5 Expires: November 13, 2018 7 Representing DNS Messages in JSON 8 draft-hoffman-dns-in-json-16 10 Abstract 12 Some applications use DNS messages, or parts of DNS messages, as 13 data. For example, a system that captures DNS queries and responses 14 might want to be able to easily search those without having to decode 15 the messages each time. Another example is a system that puts 16 together DNS queries and responses from message parts. This document 17 describes a general format for DNS message data in JSON. Specific 18 profiles of this document can be described in other documents for 19 specific applications and usage scenarios. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 13, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Design of the Format . . . . . . . . . . . . . . . . . . 3 57 2. JSON Format for DNS Messages . . . . . . . . . . . . . . . . 4 58 2.1. Message Object Members . . . . . . . . . . . . . . . . . 4 59 2.2. Resource Record Object Members . . . . . . . . . . . . . 6 60 2.3. Specific RDATA Field Members . . . . . . . . . . . . . . 7 61 2.4. The Message and Its Parts as Octets . . . . . . . . . . . 7 62 2.5. Additional Message Object Members . . . . . . . . . . . . 8 63 2.6. Name Fields . . . . . . . . . . . . . . . . . . . . . . . 8 64 3. JSON Format for a Paired DNS Query and Response . . . . . . . 9 65 4. Streaming DNS Objects . . . . . . . . . . . . . . . . . . . . 9 66 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.1. Example of the Format of a DNS Query . . . . . . . . . . 9 68 5.2. Example of the Format of a Paired DNS Query and Response 10 69 6. Local Format Policy . . . . . . . . . . . . . . . . . . . . . 11 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 7.1. MIME Type Registration of application/dns+json . . . . . 11 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 77 11.2. Informative References . . . . . . . . . . . . . . . . . 14 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 The DNS message format is defined in [RFC1035]. DNS queries and DNS 83 responses have exactly the same structure. Many of the field names 84 and data type names given in [RFC1035] are commonly used in 85 discussions of DNS. For example, it is common to hear things like 86 "the query had a QNAME of 'example.com'" or "the RDATA has a simple 87 structure". 89 There are hundreds of data interchange formats for serializing 90 structured data. Currently, JSON [RFC8259] is quite popular for many 91 types of data, particularly data that has named sub-fields and 92 optional parts. 94 This document uses JSON to describe DNS messages. It also defines 95 how to describe a paired DNS query and response, and how to stream 96 DNS objects. 98 1.1. Design of the Format 100 There are many ways to design a data format. This document uses a 101 specific design methodology based on the DNS format. 103 o The format is based on JSON objects in order to allow a writer to 104 include or exclude parts of the format at will. No object members 105 are ever required. 107 o This format is purposely overly-general. A protocol or 108 application that uses this format is expected to use only a subset 109 of the items defined here, and is expected to define its own 110 profile from this format. 112 o The format allows transformation through JSON that would permit 113 recreation of the wire content of the message. 115 o All members whose values that are always 16 bits or shorter are 116 represented by JSON numbers with no minus sign, no fractional part 117 (except in fields that are specifically noted below), and no 118 exponent part. One-bit values are represented as JSON numbers 119 whose values are either 0 or 1. See Section 6 of [RFC8259] for 120 more detail on JSON numbers. 122 o The JSON representation of the objects described in this document 123 is limited to the UTF-8 codepoints from U+0000 to U+007F. This is 124 done to prevent an attempt to use a different encoding such as 125 UTF-8 for octets in names or data. 127 o Names of items that have string values can have "HEX" appended to 128 them to indicate a non-ASCII encoding of the value. Names that 129 end in "HEX" have values stored in base16 encoding (hex with 130 uppercase letters) defined in [RFC4648]. This is particularly 131 useful for RDATA that is binary. 133 o All field names used in [RFC1035] are used in this format as-is, 134 including their capitalization. Names not defined in [RFC1035] 135 generally use "camel case". 137 o The same data may be represented in multiple object members 138 multiple times. For example, there is a member for the octets of 139 the DNS message header, and there are members for each named part 140 of the header. A message object can thus inadvertently have 141 inconsistent data, such as a header member whose value does not 142 match the value of the first bits in the entire message member. 144 o It is acceptable that there are multiple ways to represent the 145 same data. This is done to allow application designers to choose 146 what fields are best for them, and to even allow them to allow 147 multiple representations. That is, there is no "better" way to 148 represent DNS data, so this design doesn't prefer specific 149 representations. 151 o The design explicitly allows for the description of malformed DNS 152 messages. This is important for systems that are logging messages 153 seen on the wire, particularly messages that might be used as part 154 of an attack. A few examples of malformed DNS messages include: 156 * an RR that has an RDLENGTH of 4 but an RDATA whose length is 157 longer than 4 (if it is the last RR in a message) 159 * a DNS message whose QDCOUNT is 0 161 * a DNS message whose ANCOUNT is large but there are insufficient 162 bytes after the header 164 * a DNS message whose length is less than 12 octets, meaning it 165 doesn't even have a full header 167 o An object in this format can have zero or more of the members 168 defined here; that is, no members are required by the format 169 itself. Instead, profiles that use this format might have 170 requirements for mandatory members, optional members, and 171 prohibited members from the format. Also, this format does not 172 prohibit members that are not defined in this format; profiles of 173 the format are free to add new members in the profile. 175 o This document defines DNS messages, not the zone files described 176 in [RFC1035]. A different specification could be written to 177 extend it to represent zone files. Note that DNS zone files allow 178 escaping of octet values using "\DDD" notation, but this 179 specification does not allow that; when encoding from a zone file 180 to this JSON format, you need to do a conversion for many types of 181 values. 183 2. JSON Format for DNS Messages 185 The following gives all of the members defined for a DNS message. It 186 is organized approximately by levels of the DNS message. 188 2.1. Message Object Members 190 o ID - Integer whose value is 0 to 65535 192 o QR - Boolean 193 o Opcode - Integer whose value is 0 to 15 195 o AA - Boolean 197 o TC - Boolean 199 o RD - Boolean 201 o RA - Boolean 203 o AD - Boolean 205 o CD - Boolean 207 o RCODE - Integer whose value is 0 to 15 209 o QDCOUNT - Integer whose value is 0 to 65535 211 o ANCOUNT - Integer whose value is 0 to 65535 213 o NSCOUNT - Integer whose value is 0 to 65535 215 o ARCOUNT - Integer whose value is 0 to 65535 217 o QNAME - String of the name of the first Question section of the 218 message; see Section 2.6 for a desciption of the contents 220 o compressedQNAME - Object that describes the name with two optional 221 values: "isCompressed" (with a value of 0 for no and 1 for yes) 222 and "length" (with an integer giving the length in the message) 224 o QTYPE - Integer whose value is 0 to 65535, of the QTYPE of the 225 first Question section of the message 227 o QTYPEname - String whose value is from the IANA RR TYPEs registry, 228 or that has the format in [RFC3597]; this is case-sensitive, so 229 "AAAA" not "aaaa" 231 o QCLASS - Integer whose value is 0 to 65535, of the QCLASS of the 232 first Question section of the message 234 o QCLASSname - String whose value is "IN", "CH", "HS", or has the 235 format in [RFC3597] 237 o questionRRs - Array of zero or more resource records or rrSet 238 obects in the Question section 240 o answerRRs - Array of zero or more resource records or rrSet obects 241 in the Answer section 243 o authorityRRs - Array of zero or more resource records or rrSet 244 obects in the Authority section 246 o additionalRRs - Array of zero or more resource records or rrSet 247 obects in the Additional section 249 2.2. Resource Record Object Members 251 A resource record is represented as an object with the following 252 members. 254 o NAME - String of the NAME field of the resource record; see 255 Section 2.6 for a description of the contents 257 o compressedNAME - Object that describes the name with two optional 258 values: "isCompressed" (with a value of 0 for no and 1 for yes) 259 and "length" (with an integer giving the length in the message) 261 o TYPE - Integer whose value is 0 to 65535 263 o TYPEname - String whose value is from the IANA RR TYPEs registry, 264 or that has the format in [RFC3597]; this is case-sensitive, so 265 "AAAA" not "aaaa" 267 o CLASS - Integer whose value is 0 to 65535 269 o CLASSname - String whose value is "IN", "CH", "HS", or has the 270 format in [RFC3597] 272 o TTL - Integer whose value is -2147483648 to 2147483647 (it will 273 only be 0 to 2147483647 in normal circumstances) 275 o RDLENGTH - Integer whose value is 0 to 65535. Applications using 276 this format are unlikely to use this value directly, and instead 277 calculate the value from the RDATA. 279 o RDATAHEX - Hex-encoded string (base16 encoding described in 280 [RFC4648]) of the octets of the RDATA field of the resource 281 record. The data in some common RDATA fields are also described 282 in their own members; see Section 2.3. 284 o rrSet - List of objects which have RDLENGTH and RDATA members. 286 A Question section can be expressed as a resource record. When doing 287 so, the TTL, RDLENGTH, and RDATA members make no sense. 289 2.3. Specific RDATA Field Members 291 The following are common RDATA types and how to specify them as JSON 292 members. The name of the member contains the name of the RDATA type. 293 The data type for each of these members is a string. Each name is 294 prefaced with "rdata" to prevent a name collision with fields that 295 might later be defined that have the same name as the raw type name. 297 o rdataA - IPv4 address, such as "192.168.33.44" 299 o rdataAAAA - IPv6 address, such as "fe80::a65e:60ff:fed6:8aaf", as 300 defined in [RFC5952] 302 o rdataCNAME - A domain name 304 o rdataDNAME - A domain name 306 o rdataNS - A domain name 308 o rdataPTR - A domain name 310 o rdataTXT - A text value 312 In addition, the following members each has a value that is a space- 313 separated string that matches the display format definition in the 314 RFC that defines that RDATA type. It is not expected that every 315 receiving application will know how to parse these values. 317 rdataCDNSKEY, rdataCDS, rdataCSYNC, rdataDNSKEY, rdataHIP, 318 rdataIPSECKEY, rdataKEY, rdataMX, rdataNSEC, rdataNSEC3, 319 rdataNSEC3PARAM, rdataOPENPGPKEY, rdataRRSIG, rdataSMIMEA, rdataSPF, 320 rdataSRV, rdataSSHFP, rdataTLSA 322 2.4. The Message and Its Parts as Octets 324 The following can be members of a message object. These members are 325 all encoded in base16 encoding described in [RFC4648]. All these 326 items are strings. 328 o messageOctetsHEX - The octets of the message 330 o headerOctetsHEX - The first 12 octets of the message (or fewer, if 331 the message is truncated) 333 o questionOctetsHEX - The octets of the Question section 335 o answerOctetsHEX - The octets of the Answer section 336 o authorityOctetsHEX - The octets of the Authority section 338 o additionalOctetsHEX - The octets of the Additional section 340 The following can be a member of a resource record object. 342 o rrOctetsHEX - The octets of a particular resource record 344 The items in this section are useful in applications to canonically 345 reproduce what appeared on the wire. For example, an application 346 that is converting wire-format requests and responses might do 347 decompression of names, but the system reading the converted data may 348 want to be sure the decompression was done correctly. Such a system 349 would need to see the part of the message where the decompressed 350 labels resided, such as in one of the items in this section. 352 2.5. Additional Message Object Members 354 The following are members that might appear in a message object: 356 o dateString - The date that the message was sent or received, given 357 as a string in the standard format described in [RFC3339], as 358 refined by Section 3.3 of [RFC4287] 360 o dateSeconds - The date that the message was sent or received, 361 given as a JSON number that is the number of seconds since 362 1970-01-01T00:00Z in UTC time; this number can be fractional. 363 This number must have no minus sign, can have an optional 364 fractional part, and no exponent part. 366 o comment - An unstructured comment as a string 368 2.6. Name Fields 370 Names are represented by JSON strings. The rules for how names are 371 encoded are described in Section 1.1. (To recap: it is limited to 372 the UTF-8 codepoints from U+0000 to U+007F.) The contents of these 373 fields are always uncompressed, that is after [RFC1035] name 374 compression has been removed. 376 There are two encodings for names: 378 o If the member name does not end in "HEX", the value is a domain 379 name encoded as DNS labels consisting of UTF-8 codepoints from 380 U+0000 to U+007F. Within a label, codepoints above U+007F, and 381 the codepoint U+002E (ASCII period), MUST be expressed using 382 JSON's escaping rules within this set of codepoints. Separation 383 between labels is indicated with a period (codepoint U+002E). IDN 384 labels are always expressed in their A-label form as described in 385 [RFC5890]. 387 o If the member name ends in "HEX", the value is the wire format for 388 an entire domain name stored in base16 encoding described in 389 [RFC4648]. 391 3. JSON Format for a Paired DNS Query and Response 393 A paired DNS query and response is represented as an object. Two 394 optional members of this object are names "queryMessage" and 395 "responseMessage", and each has a value that is a message object. 396 This design was chosen (as compared to the more obvious array of two 397 values) so that a paired DNS query and response could be 398 differentiated from a stream of DNS messages whose length happens to 399 be two. 401 4. Streaming DNS Objects 403 Streaming DNS objects is performed using [RFC7464]. 405 5. Examples 407 5.1. Example of the Format of a DNS Query 409 The following is an example of a query for the A record of 410 example.com. 412 { "ID": 19678, "QR": 0, "Opcode": 0, 413 "AA": 0, "TC": 0, "RD": 0, "RA": 0, "AD": 0, "CD": 0, "RCODE": 0, 414 "QDCOUNT": 1, "ANCOUNT": 0, "NSCOUNT": 0, "ARCOUNT": 0, 415 "QNAME": "example.com", "QTYPE": 1, "QCLASS": 1 416 } 418 As stated earlier, all members of an object are optional. This 419 example object could have one or more of the following members as 420 well: 422 "answerRRs": [] 423 "authorityOctetsHEX": "" 424 "comment": "Something pithy goes here" 425 "dateSeconds": 1408504748.657783 426 "headerOctetsHEX": "4CDE00000001000000000000" 427 "QNAMEHEX": "076578616D706C6503636F6D00", 428 "compressedQNAME": { "isCompressed": 0 }, 429 "messageOctetsHEX": 430 "4CDE00000001000000000000076578616D706C6503636F6D0000010001" 431 "questionOctetsHEX": "076578616D706C6503636F6D0000010001" 432 "questionRRs": [ { "NAMEHEX": "076578616D706C6503636F6D00", 433 "TYPE": 1, "CLASS": 1, "hostNAME" : "example.com." } ] 434 "questionRRs": [ { "NAME": "example.com.", "TYPE": 1, 435 "CLASS": 1, } ] 437 (Note that this is an incomplete list of what else could be in the 438 object.) 440 5.2. Example of the Format of a Paired DNS Query and Response 442 The following is a paired DNS query and response for a query for the 443 A record of example.com. 445 { 446 "queryMessage": { "ID": 32784, "QR": 0, "Opcode": 0, "AA": 0, 447 "TC": 0, "RD": 0, "RA": 0, "AD": 0, "CD": 0, 448 "RCODE": 0, "QDCOUNT": 1, "ANCOUNT": 0, 449 "NSCOUNT": 0, "ARCOUNT": 0, 450 "QNAME": "example.com.", 451 "QTYPE": 1, "QCLASS": 1 }, 452 "responseMessage": { "ID": 32784, "QR": 1, "AA": 1, "RCODE": 0, 453 "QDCOUNT": 1, "ANCOUNT": 1, "NSCOUNT": 1, 454 "ARCOUNT": 0, 455 "answerRRs": [ { "NAME": "example.com.", 456 "TYPE": 1, "CLASS": 1, 457 "TTL": 3600, 458 "RDATAHEX": "C0000201" }, 459 { "NAME": "example.com.", 460 "TYPE": 1, "CLASS": 1, 461 "TTL": 3600, 462 "RDATAHEX": "C000AA01" } ], 463 "authorityRRs": [ { "NAME": "ns.example.com.", 464 "TYPE": 1, "CLASS": 1, 465 "TTL": 28800, 466 "RDATAHEX": "CB007181" } ] 467 } 468 } 469 The Answer section could instead be given with an rrSet: 471 "answerRRs": [ { "NAME": "example.com.", 472 "TYPE": 1, "CLASS": 1, 473 "TTL": 3600, 474 "rrSet": [ { "RDATAHEX": "C0000201" }, 475 { "RDATAHEX": "C000AA01" } ] } ], 477 (Note that this is an incomplete list of what else could be in the 478 Answer section.) 480 6. Local Format Policy 482 Systems using this format in this document will likely have policy 483 about what must be in the objects. Those policies are outside the 484 scope of this document. 486 For example, private DNS systems such as those described in 487 [I-D.dulaunoy-dnsop-passive-dns-cof] cover just DNS responses. Such 488 a system might have a policy that makes QNAME, QTYPE, and answerRRs 489 mandatory. That document also describes two mandatory times that are 490 not in this format, so the policy would possibly also define those 491 members and make them mandatory. The policy could also define 492 additional members that might appear in a record. 494 As another example, a program that uses this format for configuring 495 what a test client sends on the wire might have a policy of "each 496 record object can have as few members as it wants; all unstated 497 members are filled in from previous records". 499 7. IANA Considerations 501 7.1. MIME Type Registration of application/dns+json 502 To: ietf-types@iana.org 503 Subject: Registration of MIME media type application/dns+json 505 MIME media type name: application 507 MIME subtype name: dns+json 509 Required parameters: n/a 511 Optional parameters: n/a 513 Encoding considerations: Encoding considerations are identical to 514 those specified for the "application/json" media type. 516 Security considerations: This document specifies the security 517 considerations for the format. 519 Interoperability considerations: This document specifies format of 520 conforming messages and the interpretation thereof. 522 Published specification: This document 524 Applications that use this media type: Systems that want to exchange 525 DNS messages 527 Fragment identifier considerations: None 529 Additional information: None 531 Magic number(s): n/a 533 File extension(s): This document uses the media type to refer to 534 protocol messages and thus does not require a file extension. 536 Macintosh file type code(s): n/a 538 Person & email address to contact for further information: 539 Paul Hoffman, paul.hoffman@icann.org 541 Intended usage: COMMON 543 Restrictions on usage: n/a 545 Author: Paul Hoffman, paul.hoffman@icann.org 547 Change controller: Paul Hoffman, paul.hoffman@icann.org 549 8. Security Considerations 551 As described in Section 1.1, a message object can have inconsistent 552 data, such as a message with an ANCOUNT of 1 but that has either an 553 empty answerRRs array or an answerRRs array that has 2 or more RRs. 554 Other examples of inconsistent data would be resource records whose 555 RDLENGTH does not match the length of the decoded value in the 556 RDATAHEX member, or a record whose various header fields do not match 557 the value in headerOctetsHEX, and so on. A reader of this format 558 must never assume that all of the data in an object are all 559 consistent with each other. 561 This document describes a format, not a profile of that format. The 562 lack of profile can lead to security issues. For example, if a 563 system has a filter for JSON representations of DNS packets, that 564 filter needs to share the same semantics for the output JSON as the 565 consumer has. Unless the profile is quite tight, this can lead to 566 the producer being able to create fields with different contents 567 (using the HEX and regular formats), fields with malformed lengths, 568 and so on. 570 Numbers in JSON do not have any bounds checking. Thus, integer 571 values in a record might have invalid values, such as an ID field 572 whose value is greater than or equal to 2^16, or a QR field that has 573 a value of 2, and so on. 575 9. Privacy Considerations 577 The values that can be contained in this format may contain privacy- 578 sensitive information. For example, a profile of this format that is 579 used for logging queries sent to recursive resolvers might have 580 source IP addresses that could identify the location of the person 581 who sent the DNS query. 583 10. Acknowledgements 585 Some of the ideas in this document were inspired by earlier, 586 abandoned work such as ([I-D.daley-dnsxml], 587 [I-D.mohan-dns-query-xml], and [I-D.dulaunoy-dnsop-passive-dns-cof]. 588 The document was also inspired by early ideas from Stephane 589 Bortzmeyer. Many people in the DNSOP WG and DOH WG contributed very 590 useful ideas (even though this was not a WG work item). 592 11. References 593 11.1. Normative References 595 [RFC1035] Mockapetris, P., "Domain names - implementation and 596 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 597 November 1987, . 599 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 600 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 601 . 603 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 604 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 605 2003, . 607 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 608 Syndication Format", RFC 4287, DOI 10.17487/RFC4287, 609 December 2005, . 611 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 612 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 613 . 615 [RFC5890] Klensin, J., "Internationalized Domain Names for 616 Applications (IDNA): Definitions and Document Framework", 617 RFC 5890, DOI 10.17487/RFC5890, August 2010, 618 . 620 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 621 Address Text Representation", RFC 5952, 622 DOI 10.17487/RFC5952, August 2010, 623 . 625 [RFC7464] Williams, N., "JavaScript Object Notation (JSON) Text 626 Sequences", RFC 7464, DOI 10.17487/RFC7464, February 2015, 627 . 629 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 630 Interchange Format", STD 90, RFC 8259, 631 DOI 10.17487/RFC8259, December 2017, 632 . 634 11.2. Informative References 636 [I-D.daley-dnsxml] 637 Daley, J., Morris, S., and J. Dickinson, "dnsxml - A 638 standard XML representation of DNS data", draft-daley- 639 dnsxml-00 (work in progress), July 2013. 641 [I-D.dulaunoy-dnsop-passive-dns-cof] 642 Dulaunoy, A., Kaplan, A., Vixie, P., and H. Stern, 643 "Passive DNS - Common Output Format", draft-dulaunoy- 644 dnsop-passive-dns-cof-03 (work in progress), June 2017. 646 [I-D.mohan-dns-query-xml] 647 Parthasarathy, M. and P. Vixie, "Representing DNS messages 648 using XML", draft-mohan-dns-query-xml-00 (work in 649 progress), September 2011. 651 Author's Address 653 Paul Hoffman 654 ICANN 656 Email: paul.hoffman@icann.org