idnits 2.17.1 draft-bortzmeyer-dns-json-01.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 25, 2013) is 4077 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-13) exists of draft-levine-dnsextlang-05 == Outdated reference: A later version (-02) exists of draft-barnes-jose-use-cases-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bortzmeyer 3 Internet-Draft AFNIC 4 Intended status: Experimental February 25, 2013 5 Expires: August 29, 2013 7 JSON format to represent DNS data 8 draft-bortzmeyer-dns-json-01 10 Abstract 12 This document describes a profile of JSON to represent DNS data. 14 Status of This Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at http://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on August 29, 2013. 31 Copyright Notice 33 Copyright (c) 2013 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 50 3. The format . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3.1. General rules . . . . . . . . . . . . . . . . . . . . . . 3 52 3.2. Resource records . . . . . . . . . . . . . . . . . . . . 3 53 3.3. DNS response . . . . . . . . . . . . . . . . . . . . . . 6 54 3.4. Zone file . . . . . . . . . . . . . . . . . . . . . . . . 7 55 3.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 56 3.6. Open questions . . . . . . . . . . . . . . . . . . . . . 8 57 4. Security considerations . . . . . . . . . . . . . . . . . . . 9 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 5.1. Normative References . . . . . . . . . . . . . . . . . . 9 60 5.2. Informative References . . . . . . . . . . . . . . . . . 9 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 63 1. Introduction 65 The JavaScript Object Notation (JSON) format is specified in 66 [RFC4627]. It is a structured data format suitable for a wide range 67 of applications. It is specially popular on the Web, due to its 68 JavaScript roots, but can be found in many other contexts. 70 The Domain Name System (DNS) is specified in [RFC1034] and [RFC1035]. 71 It is one of the most important infrastructure components of the 72 Internet. DNS data is today typically exchanged using two formats: 73 the "zone file" format (partially) described in section 5 of 74 [RFC1035] and the "wire format" of the section 4 for [RFC1035]. 75 Other formats have been suggested, for an easier exchange of data, or 76 for using DNS in new applications, such as DNS "looking glasses" or 77 gateways to get DNS data over protocols such as HTTP ([RFC2616]). 79 For instance, a mechanism have been suggested for DNS data in XML, in 80 [I-D.mohan-dns-query-xml]. 82 This document suggests using the JSON format to represent DNS data. 83 Note that a similar JSON-like (rather than JSON) description of DNS 84 data already exists in [getdns]. 86 Also note that some representations of DNS data use a data model 87 which is quite close from the JSON one, even if the concrete syntax 88 is different (for instance [dnspython]). 90 2. Requirements notation 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. The format 98 3.1. General rules 100 Most data is represented by JSON objects, with their named members. 101 It is common to omit some of these members, to save bandwidth or by 102 pure lazyness. So, clients who consume this sort of JSON objects 103 should not assume every member is present. THIS IS AN IMPORTANT RULE 104 (see Section 3.6, Paragraph 2 for a discussion). 106 3.2. Resource records 108 DNS resource records are JSON objects. The following members are 109 common to all record types: 111 o Name (owner name) 113 o Type 115 o Class 117 o Time to live (TTL) 119 The other members depend on the record type. The following list 120 gives the resource record type mnenomic and the JSON members for this 121 type: 123 o A: 125 * Address 127 o AAAA: 129 * Address 131 o MX: 133 * Preference 135 * MailExchanger 137 o NS: 139 * Target 141 o PTR: 143 * Target 145 o CNAME: 147 * Target 149 o SOA: 151 * MaintainerName 153 * MasterServerName 155 * Serial 157 * Refresh 159 * Retry 161 * Expire 163 * NegativeTtl 165 o DNSKEY: 167 * Algorithm 169 * Length 171 * Flags 173 * Tag 175 o DS: 177 * DelegationKey 179 * DigestType 181 o DLV: 183 * DelegationKey 185 * DigestType 187 o NSEC3PARAM: 189 * Algorihm 191 * Flags 192 * Salt 194 * Iterations 196 o SSHFP: 198 * Algorithm 200 * DigestType 202 * Fingerprint 204 o NAPTR: 206 * Flags 208 * Order 210 * Services 212 * Preference 214 * Regexp 216 * Replacement 218 o SRV: 220 * Server 222 * Port 224 * Priority 226 * Weight 228 o LOC: 230 * Longitude 232 * Latitude 234 * Altitude 236 o SPF: 238 * Text 240 Note there is no concept of resource record sets (see Section 3.6, 241 Paragraph 3 for a discussion). 243 3.3. DNS response 245 A DNS response is represented as a JSON object with a member named 246 "Query". The main members of this object (the names are self- 247 explanatory) are: 249 o QuestionSection 251 o AnswerSection 253 o AdditionalSection 255 o AuthoritySection 257 o ReturnCode (alphabetical, e.g. NOERROR, NXDOMAIN, SERVFAIL, etc) 259 o ID 261 o AA (Authoritative Answer) 263 o TC (TrunCation) 265 o RD (Recursion Desired) 267 o RA (Recursion Available) 269 o AD (Authentic Data) 271 o Query 273 The Question Section is an object with members Qname, Qtype and 274 Qclass. The other three sections are JSON arrays, each DNS record is 275 an item in the array. They may be empty arrays (for instance, if the 276 request returns NOERROR,ANSWER=0, the AnswerSection will be an empty 277 array). 279 The Query object has members about the query: Duration is the time 280 taken to process the request, Server the resolver used (preferably as 281 an IP address). 283 3.4. Zone file 285 A DNS zone file is represented as a JSON object with a member named 286 "Zone". The main member of this object is an array of resource 287 records. 289 The member "Name" cannot be ommitted in resource records (unlike the 290 text format of [RFC1035], JSON does not guarantee the order of 291 records, so the trick of "previous resource record" does not work). 292 But you can use relative names, and @ to denote the origin. 294 3.5. Examples 296 {"Query": {"Server": "127.0.0.1"}, 297 "AnswerSection": [ 298 {"Name": "bortzmeyer.fr.", 299 "TTL": 3600, 300 "MasterServerName": "ns3.bortzmeyer.org.", 301 "MaintainerName": "hostmaster.bortzmeyer.org.", 302 "Serial": 2012060801, "Expire": 604800, 303 "Refresh": 10800, "Retry": 3600, 304 "NegativeTTL": 10800, 305 "Type": "SOA"}], 306 "ReturnCode": "NOERROR", 307 "AD": true, 308 "QuestionSection": {"Qtype": "SOA", "Qname": "bortzmeyer.fr."}} 309 } 311 An answer with a SOA resource record 313 {"Query": {"Duration": "0.167317", "Server": "127.0.0.1"}, 314 "AnswerSection": [ 315 {"Name": "facebook.com", "TTL": 6666, "Type": "AAAA", 316 "Address": "2a03:2880:10:8f01:face:b00c::25"}, 317 {"Name": "facebook.com", "TTL": 6666, "Type": "AAAA", 318 "Address": "2a03:2880:2110:3f01:face:b00c::"}, 319 {"Name": "facebook.com", "TTL": 6666, "Type": "AAAA", 320 "Address": "2a03:2880:10:1f02:face:b00c::25"}], 321 "ReturnCode": "NOERROR"} 323 An answer with several resource records 325 {"Zone": {"Origin": "isi.edu"}, 326 [ 327 {"Type": "SOA", "Name": "@", 328 "MasterServerName": "venera", 329 "MaintainerName": "action.domains.", 330 "Serial": 20}, 332 {"Type": "NS", Name": "@", 333 "Target": "a.isi.edu"}, 334 {"Type": "NS", Name": "@", 335 "Target": "venera"}, 336 {"Type": "NS", Name": "@", 337 "Target": "vaxa"}, 338 {"Type": "MX", Name": "@", 339 "MailExchanger": "venera", 340 "Preference": 10}, 341 {"Type": "MX", Name": "@", 342 "MailExchanger": "vaxa", 343 "Preference": 20}, 344 {"Type": "A", Name": "a", 345 "Address": "26.3.0.103"}, 346 {"Type": "A", Name": "venera", 347 "Address": "10.1.0.52"}, 348 {"Type": "A", Name": "venera", 349 "Address": "128.9.0.32"} 350 ] 351 } 353 The zone file of RFC 1035 355 3.6. Open questions 357 Would it be a good idea to document a formal way to derive member 358 names for the resource record JSON objects? It would allow 1) to 359 document the rationale for the current names 2) to automatically 360 allow representation of new DNS resource records. A possible 361 candidate for such derivation is [I-D.levine-dnsextlang]. 363 Should we define mandatory members for some objects, in order to have 364 something the consumers can rely on? It seems there is a clear 365 consensus to do so, making fields with non-default values mandatory. 367 In resource records objects, members such as TTL are redundant (since 368 they are actually RRset-wide). Should we have a new level of 369 objects, for RRsets? 371 Should we use JSON schema ([I-D.zyp-json-schema] and 372 [I-D.fge-json-schema-validation]) to define the profile? 374 Should we add a normative reference to every RFC describing one of 375 the RR types used here or simply refer to the IANA registry? 377 Should we have a way to represent unknown RR types, following 378 [RFC3597]? 379 How binary data should be represented, for types like DNSKEY? Should 380 we use Base64 or is the key value an escaped binary string? 382 4. Security considerations 384 These JSON documents are not signed (see [I-D.barnes-jose-use-cases]) 385 and therefore not authentified, even if the original data was secured 386 with DNSSEC. If transported over an insecure transport, they can be 387 read by a sniffer. 389 Also, see the security considerations of [RFC4627]. 391 5. References 393 5.1. Normative References 395 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 396 STD 13, RFC 1034, November 1987. 398 [RFC1035] Mockapetris, P., "Domain names - implementation and 399 specification", STD 13, RFC 1035, November 1987. 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, March 1997. 404 [RFC4627] Crockford, D., "The application/json Media Type for 405 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 407 5.2. Informative References 409 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 410 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 411 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 413 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 414 (RR) Types", RFC 3597, September 2003. 416 [I-D.levine-dnsextlang] 417 Levine, J. and P. Vixie, "An Extension Language for the 418 DNS", draft-levine-dnsextlang-05 (work in progress), 419 December 2012. 421 [I-D.barnes-jose-use-cases] 422 Barnes, R., "Use Cases and Requirements for JSON Object 423 Signing and Encryption (JOSE)", draft-barnes-jose-use- 424 cases-01 (work in progress), October 2012. 426 [I-D.mohan-dns-query-xml] 427 Parthasarathy, M. and P. Vixie, "Representing DNS messages 428 using XML", draft-mohan-dns-query-xml-00 (work in 429 progress), September 2011. 431 [I-D.zyp-json-schema] 432 Galiegue, F., Zyp, K., and G. Court, "JSON Schema: core 433 definitions and terminology", draft-zyp-json-schema-04 434 (work in progress), January 2013. 436 [I-D.fge-json-schema-validation] 437 Zyp, K. and G. Court, "JSON Schema: interactive and non 438 interactive validation", draft-fge-json-schema- 439 validation-00 (work in progress), January 2013. 441 [getdns] Hoffman, P., "Description of the getdns API", February 442 2013. 444 [dnspython] 445 , "dnspython: A DNS toolkit for Python", February 2013. 447 Author's Address 449 Stephane Bortzmeyer 450 AFNIC 451 Immeuble International 452 Saint-Quentin-en-Yvelines 78181 453 France 455 Phone: +33 1 39 30 83 46 456 Email: bortzmeyer+ietf@nic.fr 457 URI: http://www.afnic.fr/