Network Working Group S. Bortzmeyer Internet-Draft AFNIC Intended status: Experimental February 18, 2013 Expires: August 22, 2013 JSON format to represent DNS data draft-bortzmeyer-dns-json-00 Abstract This document describes a profile of JSON to represent DNS data. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 22, 2013. Copyright Notice Copyright (c) 2013 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 (http://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 Bortzmeyer Expires August 22, 2013 [Page 1] Internet-Draft DNS in JSON February 2013 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 3. The format . . . . . . . . . . . . . . . . . . . . . . . . . 2 3.1. General rules . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Resource records . . . . . . . . . . . . . . . . . . . . 3 3.3. DNS response . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Zone file . . . . . . . . . . . . . . . . . . . . . . . . 6 3.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 3.6. Open questions . . . . . . . . . . . . . . . . . . . . . 8 4. Security considerations . . . . . . . . . . . . . . . . . . . 8 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Normative References . . . . . . . . . . . . . . . . . . 8 5.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The JavaScript Object Notation (JSON) format is specified in [RFC4627]. It is a structured data format suitable for a wide range of applications. It is specially popular on the Web, due to its JavaScript roots, but can be found in many other contexts. The Domain Name System (DNS) is specified in [RFC1034] and [RFC1035]. It is one of the most important infrastructure components of the Internet. DNS data is today typically exchanged using two formats: the "zone file" format (partially) described in section 5 of [RFC1035] and the "wire format" of the section 4 for [RFC1035]. Other formats have been suggested, for an easier exchange of data, or for using DNS in new applications, such as DNS "looking glasses" or gateways to get DNS data over protocols such as HTTP ([RFC2616]). For instance, a mechanism have been suggested for DNS data in XML, in [xml-data-schema]. This document suggests using the JSON format to represent DNS data. 2. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. The format Bortzmeyer Expires August 22, 2013 [Page 2] Internet-Draft DNS in JSON February 2013 3.1. General rules Most data is represented by JSON objects, with their named members. It is common to omit some of these members, to save bandwidth or by pure lazyness. So, clients who consume this sort of JSON objects should not assume every member is present. THIS IS AN IMPORTANT RULE (see Section 3.6, Paragraph 2 for a discussion). 3.2. Resource records DNS resource records are JSON objects. The following members are common to all record types: o Name (owner name) o Type o Class o Time to live (TTL) The other members depend on the record type. The following list gives the resource record type mnenomic and the JSON members for this type: o A: * Address o AAAA: * Address o MX: * Preference * MailExchanger o NS: * Target o PTR: * Target o CNAME: Bortzmeyer Expires August 22, 2013 [Page 3] Internet-Draft DNS in JSON February 2013 * Target o SOA: * MaintainerName * MasterServerName * Serial * Refresh * Retry * Expire * NegativeTtl o DNSKEY: * Algorithm * Length * Flags * Tag o DS: * DelegationKey * DigestType o DLV: * DelegationKey * DigestType o NSEC3PARAM: * Algorihm * Flags * Salt Bortzmeyer Expires August 22, 2013 [Page 4] Internet-Draft DNS in JSON February 2013 * Iterations o SSHFP: * Algorithm * DigestType * Fingerprint o NAPTR: * Flags * Order * Services * Preference * Regexp * Replacement o SRV: * Server * Port * Priority * Weight o LOC: * Longitude * Latitude * Altitude o SPF: * Text Note there is no concept of resource record sets (see Section 3.6, Paragraph 3 for a discussion). Bortzmeyer Expires August 22, 2013 [Page 5] Internet-Draft DNS in JSON February 2013 3.3. DNS response A DNS response is represented as a JSON object with a member named "Query". The main members of this object (the names are self- explanatory) are: o QuestionSection o AnswerSection o AdditionalSection o AuthoritySection o ReturnCode (alphabetical, e.g. NOERROR, NXDOMAIN, SERVFAIL, etc) o ID o AA (Authoritative Answer) o TC (TrunCation) o RD (Recursion Desired) o RA (Recursion Available) o AD (Authentic Data) o Query The Question Section is an object with members Qname, Qtype and Qclass. The other three sections are JSON arrays, each DNS record is an item in the array. They may be empty arrays (for instance, if the request returns NOERROR,ANSWER=0, the AnswerSection will be an empty array). The Query object has members about the query: Duration is the time taken to process the request, Server the resolver used (preferably as an IP address). 3.4. Zone file A DNS zone file is represented as a JSON object with a member named "Zone". The main member of this object is an array of resource records. The member "Name" cannot be ommitted in resource records (unlike the text format of [RFC1035], JSON does not guarantee the order of Bortzmeyer Expires August 22, 2013 [Page 6] Internet-Draft DNS in JSON February 2013 records, so the trick of "previous resource record" does not work. But you can use relative names, and @ to denote the origin. 3.5. Examples {"Query": {"Server": "127.0.0.1"}, "AnswerSection": [ {"Name": "bortzmeyer.fr.", "MasterServerName": "ns3.bortzmeyer.org.", "MaintainerName": "hostmaster.bortzmeyer.org.", "TTL": 3600, "Serial": 2012060801, "Type": "SOA"}], "ReturnCode": "NOERROR", "AD": true, "QuestionSection": {"Qtype": "SOA", "Qname": "bortzmeyer.fr."}} } An answer with a SOA resource record {"Query": {"Duration": "0.167317", "Server": "127.0.0.1"}, "AnswerSection": [ {"TTL": 6666, "Type": "AAAA", "Address": "2a03:2880:10:8f01:face:b00c::25"}, {"TTL": 6666, "Type": "AAAA", "Address": "2a03:2880:2110:3f01:face:b00c::"}, {"TTL": 6666, "Type": "AAAA", "Address": "2a03:2880:10:1f02:face:b00c::25"}], "ReturnCode": "NOERROR"} An answer with several resource records {"Zone": {"Origin": "isi.edu"}, [ {"Type": "SOA", "Name": "@", "MasterServerName": "venera", "MaintainerName": "action.domains.", "Serial": 20}, {"Type": "NS", Name": "@", "Target": "a.isi.edu"}, {"Type": "NS", Name": "@", "Target": "venera"}, {"Type": "NS", Name": "@", "Target": "vaxa"}, {"Type": "MX", Name": "@", "MailExchanger": "venera", "Preference": 10}, {"Type": "MX", Name": "@", "MailExchanger": "vaxa", "Preference": 20}, Bortzmeyer Expires August 22, 2013 [Page 7] Internet-Draft DNS in JSON February 2013 {"Type": "A", Name": "a", "Address": "26.3.0.103"}, {"Type": "A", Name": "venera", "Address": "10.1.0.52"}, {"Type": "A", Name": "venera", "Address": "128.9.0.32"} ] } The zone file of RFC 1035 3.6. Open questions Would it be a good idea to document a formal way to derive member names for the resource record JSON objects? It would allow 1) to document the rationale for the current names 2) to automatically allow representation of new DNS resource records. Should we define mandatory members for some objects, in order to have something the consumers can rely on? In resource records objects, members such as TTL are redundant (since they are actually RRset-wide). Should we have a new level of objects, for RRsets? Should we use JSON schema ([json-schema]) to define the profile? Should we add a normative reference to every RFC describing one of the RR types used here? 4. Security considerations These JSON documents are not signed and therefore not authentified, even if the original data was secured with DNSSEC. If transported over an insecure transport, they can be read by a sniffer. Also, see the security considerations of [RFC4627]. 5. References 5.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. Bortzmeyer Expires August 22, 2013 [Page 8] Internet-Draft DNS in JSON February 2013 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. 5.2. Informative References [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [xml-data-schema] Parthasarath, M. and P. Vixie, "draft-mohan-dns-query- xml-00", September 2011. [json-schema] Galiegue, F., Zyp, K., and G. Court, "draft-zyp-json- schema-04.txt: JSON Schema: core definitions and terminology", January 2013. Author's Address Stephane Bortzmeyer AFNIC Immeuble International Saint-Quentin-en-Yvelines 78181 France Phone: +33 1 39 30 83 46 Email: bortzmeyer+ietf@nic.fr URI: http://www.afnic.fr/ Bortzmeyer Expires August 22, 2013 [Page 9]