One document matched: draft-bortzmeyer-dns-json-00.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY info-references SYSTEM "informative-references.xml">
<!ENTITY norm-references SYSTEM "normative-references.xml">
]>
<rfc docName="draft-bortzmeyer-dns-json-00" category="exp" ipr="trust200902">
<?rfc toc="yes"?>
<?rfc strict="yes"?> 
<front>
<title abbrev="DNS in JSON">JSON format to represent DNS data</title>
<author fullname="Stephane Bortzmeyer" initials="S." surname="Bortzmeyer">
<organization>AFNIC</organization>
<address><postal><street>Immeuble International</street><code>78181</code><city>Saint-Quentin-en-Yvelines</city><country>France</country></postal> <phone>+33 1 39 30 83 46</phone><email>bortzmeyer+ietf@nic.fr</email><uri>http://www.afnic.fr/</uri></address>
</author>
<date month="February" year="2013"/>
<abstract>
<t>This document describes a profile of JSON to represent DNS data.</t>
</abstract>
</front>

<middle>
<section title="Introduction">
<t>The JavaScript Object Notation (JSON) format is specified in <xref target="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.</t>
<t>The Domain Name System (DNS) is specified in <xref target="RFC1034"/> and <xref target="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 <xref target="RFC1035"/> and the "wire format" of the
section 4 for <xref target="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 (<xref target="RFC2616"/>).</t>
<t>For instance, a mechanism have been suggested for DNS
data in XML, in <xref target="xml-data-schema"/>.</t>
<t>This document suggests using the JSON format to represent DNS
data.</t>
</section>

<section title="Requirements notation">
<t>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 <xref target="RFC2119"/>.</t>
</section>

<section title="The format">

<section title="General rules">
<t>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 <xref target="mandatory_members"/> for a discussion).</t>
</section>

<section title="Resource records">
<t>
DNS resource records are JSON objects. The following members are common to
all record types:
<list style="symbols">
<t>Name (owner name)</t>
<t>Type</t>
<t>Class</t>
<t>Time to live (TTL)</t>
</list>
The other members depend on the record type. The following list gives
the resource record type mnenomic and the JSON members for this type:
<list style="symbols">
<t>A: 
<list style="symbols">
<t>Address</t>
</list>
</t>
<t>AAAA:
<list style="symbols">
<t>Address</t>
</list></t>
<t>MX:
<list style="symbols">
<t>Preference</t>
<t>MailExchanger</t>
</list>
</t>
<t>NS: 
<list style="symbols">
<t>Target</t>
</list>
</t>
<t>PTR:
<list style="symbols">
<t>Target</t>
</list></t>
<t>CNAME:
<list style="symbols">
<t>Target</t>
</list></t>
<t>SOA:
<list style="symbols">
<t>MaintainerName</t>
<t>MasterServerName</t>
<t>Serial</t>
<t>Refresh</t>
<t>Retry</t>
<t>Expire</t>
<t>NegativeTtl</t>
</list></t>
<t>DNSKEY:
<list style="symbols">
<t>Algorithm</t>
<t>Length</t>
<t>Flags</t>
<t>Tag</t>
</list>
</t>
<t>DS:
<list style="symbols">
<t>DelegationKey</t>
<t>DigestType</t>
</list>
</t>
<t>DLV:
<list style="symbols">
<t>DelegationKey</t>
<t>DigestType</t>
</list></t>
<t>NSEC3PARAM:
<list style="symbols">
<t>Algorihm</t>
<t>Flags</t>
<t>Salt</t>
<t>Iterations</t>
</list></t>
<t>SSHFP:
<list style="symbols">
<t>Algorithm</t>
<t>DigestType</t>
<t>Fingerprint</t>
</list>
</t>
<t>NAPTR:
<list style="symbols">
<t>Flags</t>
<t>Order</t>
<t>Services</t>
<t>Preference</t>
<t>Regexp</t>
<t>Replacement</t>
</list></t>
<t>SRV:
<list style="symbols">
<t>Server</t>
<t>Port</t>
<t>Priority</t>
<t>Weight</t>
</list>
</t>
<t>LOC:
<list style="symbols">
<t>Longitude</t>
<t>Latitude</t>
<t>Altitude</t>
</list>
</t>
<t>SPF:
<list style="symbols">
<t>Text</t>
</list>
</t>
</list>
</t>
<t>Note there is no concept of resource record sets (see <xref target="rrsets"/> for a discussion).
</t>
</section>

<section title="DNS response">
<t>
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:
<list style="symbols">
<t>QuestionSection</t>
<t>AnswerSection</t>
<t>AdditionalSection</t>
<t>AuthoritySection</t>
<t>ReturnCode (alphabetical, e.g. NOERROR, NXDOMAIN, SERVFAIL, etc)</t>
<t>ID</t>
<t>AA (Authoritative Answer)</t>
<t>TC (TrunCation)</t>
<t>RD (Recursion Desired)</t>
<t>RA (Recursion Available)</t>
<t>AD (Authentic Data)</t>
<t>Query</t>
</list>
</t>
<t>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).
</t>
<t>
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).
</t>
</section>

<section title="Zone file">
<t>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.</t>
<t>The member "Name" cannot be ommitted in resource records (unlike the text format of
<xref target="RFC1035"/>, JSON does not guarantee the order of records,
so the trick of "previous resource record" does not work. But you can
use relative names, and @ to denote the origin.</t>
</section>

<section title="Examples">
<t>

<figure title="An answer with a SOA resource record">
<artwork>
{"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."}}
}
</artwork>
</figure>

<figure title="An answer with several resource records">
<artwork>
{"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"}
</artwork>
</figure>

<figure title="The zone file of RFC 1035">
<artwork>
{"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},
     {"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"}
 ]
}
</artwork>
</figure>

</t>
</section>

<section title="Open questions">
<t>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.</t>
<t anchor="mandatory_members">
Should we define mandatory members for some objects, in order to have
something the consumers can rely on?
</t>
<t anchor="rrsets">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?</t>
<t>Should we use JSON schema (<xref target="json-schema"/>) to define
the profile?</t>
<t>Should we add a normative reference to every RFC describing one of
the RR types used here?</t>

</section>

</section>

<section title="Security considerations">
<t>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.</t>
<t>Also, see the security considerations of <xref target="RFC4627"/>.</t>
</section>

</middle>

<back>

<references title="Normative References">

<reference anchor="RFC1034">

<front>
<title abbrev="Domain Concepts and Facilities">Domain names - concepts and facilities</title>
<author initials="P." surname="Mockapetris" fullname="P. Mockapetris">
<organization>Information Sciences Institute (ISI)</organization></author>
<date year="1987" day="1" month="November"/></front>

<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1034"/>
<format type="TXT" octets="129180" target="ftp://ftp.isi.edu/in-notes/rfc1034.txt"/>
</reference>


<reference anchor="RFC1035">

<front>
<title abbrev="Domain Implementation and Specification">Domain names - implementation and specification</title>
<author initials="P." surname="Mockapetris" fullname="P. Mockapetris">
<organization>USC/ISI</organization>
<address>
<postal>
<street>4676 Admiralty Way</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90291</code>
<country>US</country></postal>
<phone>+1 213 822 1511</phone></address></author>
<date year="1987" day="1" month="November"/></front>

<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1035"/>
<format type="TXT" octets="125626" target="ftp://ftp.isi.edu/in-notes/rfc1035.txt"/>
</reference>


<reference anchor="RFC2119">

<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year="1997" month="March"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list>
<t>
      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
      RFC 2119.
</t></list></t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t></abstract></front>

<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format type="TXT" octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"/>
<format type="HTML" octets="16553" target="http://xml.resource.org/public/rfc/html/rfc2119.html"/>
<format type="XML" octets="5703" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/>
</reference>


<reference anchor="RFC4627">

<front>
<title>The application/json Media Type for JavaScript Object Notation (JSON)</title>
<author initials="D." surname="Crockford" fullname="D. Crockford">
<organization/></author>
<date year="2006" month="July"/>
<abstract>
<t><p>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This memo provides information for the Internet community.</p></t></abstract></front>

<seriesInfo name="RFC" value="4627"/>
<format type="TXT" octets="16319" target="ftp://ftp.isi.edu/in-notes/rfc4627.txt"/>
</reference>


</references>

<references title="Informative References">

<reference anchor="RFC2616">

<front>
<title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
<organization abbrev="UC Irvine">Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code></postal>
<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email></address></author>
<author initials="J." surname="Gettys" fullname="James Gettys">
<organization abbrev="Compaq/W3C">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>jg@w3.org</email></address></author>
<author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
<organization abbrev="Compaq">Compaq Computer Corporation</organization>
<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94305</code></postal>
<email>mogul@wrl.dec.com</email></address></author>
<author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>frystyk@w3.org</email></address></author>
<author initials="L." surname="Masinter" fullname="Larry Masinter">
<organization abbrev="Xerox">Xerox Corporation</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code></postal>
<email>masinter@parc.xerox.com</email></address></author>
<author initials="P." surname="Leach" fullname="Paul J. Leach">
<organization abbrev="Microsoft">Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code></postal>
<email>paulle@microsoft.com</email></address></author>
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email></address></author>
<date year="1999" month="June"/>
<abstract>
<t>
   The Hypertext Transfer Protocol (HTTP) is an application-level
   protocol for distributed, collaborative, hypermedia information
   systems. It is a generic, stateless, protocol which can be used for
   many tasks beyond its use for hypertext, such as name servers and
   distributed object management systems, through extension of its
   request methods, error codes and headers . A feature of HTTP is
   the typing and negotiation of data representation, allowing systems
   to be built independently of the data being transferred.
</t>
<t>
   HTTP has been in use by the World-Wide Web global information
   initiative since 1990. This specification defines the protocol
   referred to as "HTTP/1.1", and is an update to RFC 2068 .
</t></abstract></front>

<seriesInfo name="RFC" value="2616"/>
<format type="TXT" octets="422317" target="ftp://ftp.isi.edu/in-notes/rfc2616.txt"/>
<format type="PS" octets="5529857" target="ftp://ftp.isi.edu/in-notes/rfc2616.ps"/>
<format type="PDF" octets="550558" target="ftp://ftp.isi.edu/in-notes/rfc2616.pdf"/>
<format type="HTML" octets="620835" target="http://xml.resource.org/public/rfc/html/rfc2616.html"/>
<format type="XML" octets="490204" target="http://xml.resource.org/public/rfc/xml/rfc2616.xml"/>
</reference>

 

<reference anchor="xml-data-schema">
<front>
<title>draft-mohan-dns-query-xml-00</title>
<author fullname="M. Parthasarath" initials="M" surname="Parthasarath"><organization>Apple</organization></author>
<author fullname="P. Vixie" initials="P" surname="Vixie"><organization>ISC</organization></author>
<date month="September" year="2011"/>
<abstract>
<t>
This memo presents a technique for representing DNS messages using XML.  This enables DNS query transactions to be transported over HTTP/HTTPS
</t>
</abstract>
</front>
</reference>

<reference anchor="json-schema">
<front>
<title>draft-zyp-json-schema-04.txt: JSON Schema: core definitions and terminology</title>
<author fullname="Francis Galiegue" initials="F" surname="Galiegue"><organization/></author>
<author fullname="Kris Zyp" initials="K" surname="Zyp"><organization>SitePen</organization></author>
<author fullname="G. Court" initials="G" surname="Court"><organization/></author>
<date month="January" year="2013"/>
<abstract>
<t>JSON Schema defines the media type "application/schema+json", a JSON
   based format for defining the structure of JSON data.  JSON Schema
   provides a contract for what JSON data is required for a given
   application and how to interact with it.  JSON Schema is intended to
   define validation, documentation, hyperlink navigation, and
   interaction control of JSON data.</t>
</abstract>
</front>
</reference>

</references>
</back>

</rfc>