idnits 2.17.1 draft-bortzmeyer-dns-json-00.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 18, 2013) is 4079 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) Summary: 2 errors (**), 0 flaws (~~), 2 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 18, 2013 5 Expires: August 22, 2013 7 JSON format to represent DNS data 8 draft-bortzmeyer-dns-json-00 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 22, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3.1. General rules . . . . . . . . . . . . . . . . . . . . . . 3 52 3.2. Resource records . . . . . . . . . . . . . . . . . . . . 3 53 3.3. DNS response . . . . . . . . . . . . . . . . . . . . . . 6 54 3.4. Zone file . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 56 3.6. Open questions . . . . . . . . . . . . . . . . . . . . . 8 57 4. Security considerations . . . . . . . . . . . . . . . . . . . 8 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 5.1. Normative References . . . . . . . . . . . . . . . . . . 8 60 5.2. Informative References . . . . . . . . . . . . . . . . . 9 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 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 [xml-data-schema]. 82 This document suggests using the JSON format to represent DNS data. 84 2. Requirements notation 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 3. The format 91 3.1. General rules 93 Most data is represented by JSON objects, with their named members. 94 It is common to omit some of these members, to save bandwidth or by 95 pure lazyness. So, clients who consume this sort of JSON objects 96 should not assume every member is present. THIS IS AN IMPORTANT RULE 97 (see Section 3.6, Paragraph 2 for a discussion). 99 3.2. Resource records 101 DNS resource records are JSON objects. The following members are 102 common to all record types: 104 o Name (owner name) 106 o Type 108 o Class 110 o Time to live (TTL) 112 The other members depend on the record type. The following list 113 gives the resource record type mnenomic and the JSON members for this 114 type: 116 o A: 118 * Address 120 o AAAA: 122 * Address 124 o MX: 126 * Preference 128 * MailExchanger 130 o NS: 132 * Target 134 o PTR: 136 * Target 138 o CNAME: 140 * Target 142 o SOA: 144 * MaintainerName 146 * MasterServerName 148 * Serial 150 * Refresh 152 * Retry 154 * Expire 156 * NegativeTtl 158 o DNSKEY: 160 * Algorithm 162 * Length 164 * Flags 166 * Tag 168 o DS: 170 * DelegationKey 172 * DigestType 174 o DLV: 176 * DelegationKey 178 * DigestType 180 o NSEC3PARAM: 182 * Algorihm 184 * Flags 186 * Salt 187 * Iterations 189 o SSHFP: 191 * Algorithm 193 * DigestType 195 * Fingerprint 197 o NAPTR: 199 * Flags 201 * Order 203 * Services 205 * Preference 207 * Regexp 209 * Replacement 211 o SRV: 213 * Server 215 * Port 217 * Priority 219 * Weight 221 o LOC: 223 * Longitude 225 * Latitude 227 * Altitude 229 o SPF: 231 * Text 233 Note there is no concept of resource record sets (see Section 3.6, 234 Paragraph 3 for a discussion). 236 3.3. DNS response 238 A DNS response is represented as a JSON object with a member named 239 "Query". The main members of this object (the names are self- 240 explanatory) are: 242 o QuestionSection 244 o AnswerSection 246 o AdditionalSection 248 o AuthoritySection 250 o ReturnCode (alphabetical, e.g. NOERROR, NXDOMAIN, SERVFAIL, etc) 252 o ID 254 o AA (Authoritative Answer) 256 o TC (TrunCation) 258 o RD (Recursion Desired) 260 o RA (Recursion Available) 262 o AD (Authentic Data) 264 o Query 266 The Question Section is an object with members Qname, Qtype and 267 Qclass. The other three sections are JSON arrays, each DNS record is 268 an item in the array. They may be empty arrays (for instance, if the 269 request returns NOERROR,ANSWER=0, the AnswerSection will be an empty 270 array). 272 The Query object has members about the query: Duration is the time 273 taken to process the request, Server the resolver used (preferably as 274 an IP address). 276 3.4. Zone file 278 A DNS zone file is represented as a JSON object with a member named 279 "Zone". The main member of this object is an array of resource 280 records. 282 The member "Name" cannot be ommitted in resource records (unlike the 283 text format of [RFC1035], JSON does not guarantee the order of 284 records, so the trick of "previous resource record" does not work. 285 But you can use relative names, and @ to denote the origin. 287 3.5. Examples 289 {"Query": {"Server": "127.0.0.1"}, 290 "AnswerSection": [ 291 {"Name": "bortzmeyer.fr.", 292 "MasterServerName": "ns3.bortzmeyer.org.", 293 "MaintainerName": "hostmaster.bortzmeyer.org.", "TTL": 3600, 294 "Serial": 2012060801, "Type": "SOA"}], 295 "ReturnCode": "NOERROR", 296 "AD": true, 297 "QuestionSection": {"Qtype": "SOA", "Qname": "bortzmeyer.fr."}} 298 } 300 An answer with a SOA resource record 302 {"Query": {"Duration": "0.167317", "Server": "127.0.0.1"}, 303 "AnswerSection": [ 304 {"TTL": 6666, "Type": "AAAA", 305 "Address": "2a03:2880:10:8f01:face:b00c::25"}, 306 {"TTL": 6666, "Type": "AAAA", 307 "Address": "2a03:2880:2110:3f01:face:b00c::"}, 308 {"TTL": 6666, "Type": "AAAA", 309 "Address": "2a03:2880:10:1f02:face:b00c::25"}], 310 "ReturnCode": "NOERROR"} 312 An answer with several resource records 314 {"Zone": {"Origin": "isi.edu"}, 315 [ 316 {"Type": "SOA", "Name": "@", 317 "MasterServerName": "venera", 318 "MaintainerName": "action.domains.", 319 "Serial": 20}, 320 {"Type": "NS", Name": "@", 321 "Target": "a.isi.edu"}, 322 {"Type": "NS", Name": "@", 323 "Target": "venera"}, 324 {"Type": "NS", Name": "@", 325 "Target": "vaxa"}, 326 {"Type": "MX", Name": "@", 327 "MailExchanger": "venera", 328 "Preference": 10}, 329 {"Type": "MX", Name": "@", 330 "MailExchanger": "vaxa", 331 "Preference": 20}, 333 {"Type": "A", Name": "a", 334 "Address": "26.3.0.103"}, 335 {"Type": "A", Name": "venera", 336 "Address": "10.1.0.52"}, 337 {"Type": "A", Name": "venera", 338 "Address": "128.9.0.32"} 339 ] 340 } 342 The zone file of RFC 1035 344 3.6. Open questions 346 Would it be a good idea to document a formal way to derive member 347 names for the resource record JSON objects? It would allow 1) to 348 document the rationale for the current names 2) to automatically 349 allow representation of new DNS resource records. 351 Should we define mandatory members for some objects, in order to have 352 something the consumers can rely on? 354 In resource records objects, members such as TTL are redundant (since 355 they are actually RRset-wide). Should we have a new level of 356 objects, for RRsets? 358 Should we use JSON schema ([json-schema]) to define the profile? 360 Should we add a normative reference to every RFC describing one of 361 the RR types used here? 363 4. Security considerations 365 These JSON documents are not signed and therefore not authentified, 366 even if the original data was secured with DNSSEC. If transported 367 over an insecure transport, they can be read by a sniffer. 369 Also, see the security considerations of [RFC4627]. 371 5. References 373 5.1. Normative References 375 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 376 STD 13, RFC 1034, November 1987. 378 [RFC1035] Mockapetris, P., "Domain names - implementation and 379 specification", STD 13, RFC 1035, November 1987. 381 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 382 Requirement Levels", BCP 14, RFC 2119, March 1997. 384 [RFC4627] Crockford, D., "The application/json Media Type for 385 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 387 5.2. Informative References 389 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 390 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 391 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 393 [xml-data-schema] 394 Parthasarath, M. and P. Vixie, "draft-mohan-dns-query- 395 xml-00", September 2011. 397 [json-schema] 398 Galiegue, F., Zyp, K., and G. Court, "draft-zyp-json- 399 schema-04.txt: JSON Schema: core definitions and 400 terminology", January 2013. 402 Author's Address 404 Stephane Bortzmeyer 405 AFNIC 406 Immeuble International 407 Saint-Quentin-en-Yvelines 78181 408 France 410 Phone: +33 1 39 30 83 46 411 Email: bortzmeyer+ietf@nic.fr 412 URI: http://www.afnic.fr/