One document matched: draft-bortzmeyer-dns-json-01.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-01" 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="I-D.mohan-dns-query-xml"/>.</t>
<t>This document suggests using the JSON format to represent DNS
data. Note that a similar JSON-like (rather than JSON) description of DNS data already exists in [getdns].</t>
<t>Also note that some representations of DNS data use a data model
which is quite close from the JSON one, even if the concrete syntax is
different (for instance [dnspython]).</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.", 
        "TTL": 3600, 
        "MasterServerName": "ns3.bortzmeyer.org.", 
        "MaintainerName": "hostmaster.bortzmeyer.org.", 
        "Serial": 2012060801, "Expire": 604800,
        "Refresh": 10800, "Retry": 3600,
        "NegativeTTL": 10800,
        "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": [
    {"Name": "facebook.com", "TTL": 6666, "Type": "AAAA", 
     "Address": "2a03:2880:10:8f01:face:b00c::25"}, 
    {"Name": "facebook.com", "TTL": 6666, "Type": "AAAA", 
     "Address": "2a03:2880:2110:3f01:face:b00c::"}, 
    {"Name": "facebook.com", "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. A possible candidate for such derivation is <xref target="I-D.levine-dnsextlang"/>.</t>
<t anchor="mandatory_members">
Should we define mandatory members for some objects, in order to have
something the consumers can rely on? It seems there is a clear
consensus to do so, making fields with non-default values mandatory.
</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="I-D.zyp-json-schema"/> and <xref target="I-D.fge-json-schema-validation"/>) to define
the profile?</t>
<t>Should we add a normative reference to every RFC describing one of
the RR types used here or simply refer to the IANA registry?</t>
<t>Should we have a way to represent unknown RR types, following <xref target="RFC3597"/>?</t>
<t>How binary data should be represented, for types like DNSKEY?
Should we
use Base64 or is the key value an escaped
binary string?</t>
</section>

</section>

<section title="Security considerations">
<t>These JSON documents are not signed (see <xref target="I-D.barnes-jose-use-cases"/>) 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="http://www.rfc-editor.org/rfc/rfc2616.txt"/>
<format type="PS" octets="5529857" target="http://www.rfc-editor.org/rfc/rfc2616.ps"/>
<format type="PDF" octets="550558" target="http://www.rfc-editor.org/rfc/rfc2616.pdf"/>
<format type="HTML" octets="637302" target="http://xml.resource.org/public/rfc/html/rfc2616.html"/>
<format type="XML" octets="493420" target="http://xml.resource.org/public/rfc/xml/rfc2616.xml"/>
</reference>


<reference anchor="RFC3597">

<front>
<title>Handling of Unknown DNS Resource Record (RR) Types</title>
<author initials="A." surname="Gustafsson" fullname="A. Gustafsson">
<organization/></author>
<date year="2003" month="September"/>
<abstract>
<t>Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software.  This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name="RFC" value="3597"/>
<format type="TXT" octets="17559" target="http://www.rfc-editor.org/rfc/rfc3597.txt"/>
</reference>


<reference anchor="I-D.levine-dnsextlang">
<front>
<title>An Extension Language for the DNS</title>

<author initials="J" surname="Levine" fullname="John Levine">
    <organization/>
</author>

<author initials="P" surname="Vixie" fullname="Paul Vixie">
    <organization/>
</author>

<date month="December" day="18" year="2012"/>

<abstract><t>Adding new RRTYPEs to the DNS requires that DNS servers and provisioning software be upgraded to support each new RRTYPE in Master files.  This document defines a DNS extension language intended to allow most new RRTYPEs to be supported by adding entries to configuration data read by the DNS software, with no software changes needed for each RRTYPE.</t></abstract>

</front>

<seriesInfo name="Internet-Draft" value="draft-levine-dnsextlang-05"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-levine-dnsextlang-05.txt"/>
</reference>


<reference anchor="I-D.barnes-jose-use-cases">
<front>
<title>Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)</title>

<author initials="R" surname="Barnes" fullname="Richard Barnes">
    <organization/>
</author>

<date month="October" day="22" year="2012"/>

<abstract><t>Many Internet applications have a need for object-based security mechanisms in addition to security mechanisms at the network layer or transport layer.  In the past, the Cryptographic Message Syntax has provided a binary secure object format based on ASN.1.  Over time, the use of binary object encodings such as ASN.1 has been overtaken by text-based encodings, for example JavaScript Object Notation. This document defines a set of use cases and requirements for a secure object format encoded using JavaScript Object Notation, drawn from a variety of application security mechanisms currently in development.</t></abstract>

</front>

<seriesInfo name="Internet-Draft" value="draft-barnes-jose-use-cases-01"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-barnes-jose-use-cases-01.txt"/>
</reference>


<reference anchor="I-D.mohan-dns-query-xml">
<front>
<title>Representing DNS messages using XML</title>

<author initials="M" surname="Parthasarathy" fullname="Mohan Parthasarathy">
    <organization/>
</author>

<author initials="P" surname="Vixie" fullname="Paul Vixie">
    <organization/>
</author>

<date month="September" day="27" 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>

<seriesInfo name="Internet-Draft" value="draft-mohan-dns-query-xml-00"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-mohan-dns-query-xml-00.txt"/>
</reference>


<reference anchor="I-D.zyp-json-schema">
<front>
<title>JSON Schema: core definitions and terminology</title>

<author initials="F" surname="Galiegue" fullname="Francis Galiegue">
    <organization/>
</author>

<author initials="K" surname="Zyp" fullname="Kris Zyp">
    <organization/>
</author>

<author initials="G" surname="Court" fullname="Gary Court">
    <organization/>
</author>

<date month="January" day="31" 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>

<seriesInfo name="Internet-Draft" value="draft-zyp-json-schema-04"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-zyp-json-schema-04.txt"/>
</reference>


<reference anchor="I-D.fge-json-schema-validation">
<front>
<title>JSON Schema: interactive and non interactive validation</title>

<author initials="K" surname="Zyp" fullname="Kris Zyp">
    <organization/>
</author>

<author initials="G" surname="Court" fullname="Gary Court">
    <organization/>
</author>

<date month="January" day="31" year="2013"/>

<abstract><t>JSON Schema (application/schema+json) has several purposes, one of which is instance validation.  The validation process may be interactive or non interactive.  For instance, applications may use JSON Schema to build a user interface enabling interactive content generation in addition to user input checking, or validate data retrieved from various sources.  This specification describes schema keywords dedicated to validation purposes.</t></abstract>

</front>

<seriesInfo name="Internet-Draft" value="draft-fge-json-schema-validation-00"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-fge-json-schema-validation-00.txt"/>
</reference>

 

<reference anchor="getdns">
<front>
<title>Description of the getdns API</title>
<author fullname="Paul Hoffman" initials="P" surname="Hoffman"/>
<date month="February" year="2013"/>
<abstract>
<t>This document describes a modern asynchronous DNS API. This new API is intended to be useful to application developers and operating system distributors as a way of making all types of DNS information easily available in many types of programs. <eref target="http://www.vpnc.org/getdns-api/"/></t>
</abstract>
</front>
</reference>

<reference anchor="dnspython">
<front>
<title>dnspython: A DNS toolkit for Python</title>
<author fullname="Nominum"/>
<date month="February" year="2013"/>
<abstract>
<t>dnspython is a DNS toolkit for Python. It supports almost all record types. It can be used for queries, zone transfers, and dynamic updates. It supports TSIG authenticated messages and EDNS0. <eref target="http://www.dnspython.org/"/></t>
</abstract>
</front>
</reference>

</references>

</back>

</rfc>