One document matched: draft-levine-dnsextlang-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2782 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
<!ENTITY RFC3548 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3548.xml">
<!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4398 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4398.xml">
<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc toc="yes" ?>
<?rfc tocindent="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<rfc category="std" docName="draft-levine-dnsextlang-05" ipr="trust200902">
<front>
<title abbrev="DNS Extension Language">An Extension Language
for the DNS</title>
<author fullname="John Levine" initials="J." surname="Levine">
<organization>Taughannock Networks</organization>
<address>
<postal>
<street>PO Box 727</street>
<city>Trumansburg</city>
<code>14886</code>
<region>NY</region>
</postal>
<phone>+1 831 480 2300</phone>
<email>standards@taugh.com</email>
<uri>http://jl.ly</uri>
</address>
</author>
<author fullname="Paul Vixie" initials="P." surname="Vixie">
<organization>Internet Systems Consortium</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA></region>
</postal>
<email>vixie@isc.org</email>
</address>
</author>
<date month="December" year="2012" />
<area>Operations and Management</area>
<keyword>DNS</keyword>
<keyword>extensions</keyword>
<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>
<middle>
<section title="Introduction">
<t>The Domain Name System<xref target="RFC1034"></xref>
<xref target="RFC1035"></xref> is designed to be extensible, with new record types, known as RRTYPEs,
added as needed. While it is straightforward in principle to add a new RRTYPE, in practice it can
be difficult due to the software changes needed to add the new RRTYPE to the master file format
read by many authoritative DNS servers, and to the provisioning software used to create and
update the master files or the local equivalent.</t>
<t>While some new RRTYPEs, notably those for <xref target="RFC4033">DNSSEC</xref>, require that DNS servers
do new special purpose processing, most new RRTYPEs are, from the point of view of the DNS, just static
data to return to queries, perhaps with some additional section records if the record includes another
domain name. This document defines an extension language to describe these RRTYPEs, so that server
and provisioning software can parse master file records for the RRTYPEs.
</t>
</section>
<section title="Typical usage">
<t>The extension language is written as strings of ASCII text that describe new RR types,
intended to be stored in the DNS itself.
(They may also be stored in a local file with a well-known name, for debugging and local
overrides, but this usage is optional.)
All of the DNS software that needs to handle
master file records fetches records from the DNS as needed. To support a new RRTYPE, one would
add suitable records to the DNS zone where the descriptions are located, or to the local file.</t>
<t>DNS servers can use the extension language to parse new RRTYPE records in master files,
and to translate them to the binary representation.
Servers that create ASCII master files from zone data retrieved via AXFR can use the extension
language to create master file records for new RRTYPEs.
</t>
<t>Provisioning software can use the
extension language to create templates for users to fill in, to create new RRTYPE records
in master files to be passed to DNS servers, and to syntax check records entered by users.
</t>
<t>In principle, provisioning software could create TYPEnn master records if the local
DNS server doesn't implement the extension language, although it would be less confusing
if both provisioning and server software both accept the same master record syntax.
</t>
<t>Some DNS servers store records in ways other than master files, such as SQL databases.
In principle, the extension language could be used to create new schema entries to handle
new RRTYPEs, although the details are too specific to particular varieties
of DNS server software
for this document to try to describe the details.
</t>
</section>
<section title="Extension language syntax">
<section title="Lexical structure">
<t>The extension language consists of "stanzas", each of which defines an RRTYPE.
In the DNS, a stanza is stored as a multi-string TXT record, with each string
conceptually being a line in the stanza.
In a file, it is stored as a series of lines.
The first line of a stanza defines the symbolic RRTYPE name.
Subsequent lines each define a field in the record.
</t>
<t>The following ABNF imports ALPHA, DIGIT, and WSP from <xref target="RFC5234" />.</t>
<figure>
<artwork>
dnsextfile = 1*stanza
stanza = rrtypeline 1*fieldline
rrtypeline = 1*ALPHA ":" 1*DIGIT 0*1(WSP freetext)
fieldline = WSP ftype 0*1qualifiers 0*1(WSP freetext)
ftype = "I1" | "I2" | "I4" | "A" | "AAAA" | "N" | "S" | "B" | "X"
qualifiers = "[" qual 0*(, qual) "]"
qual = 1*ALPHA "=" 1*DIGIT | "C" | "A" | "L" | "M"
freetext = 0*(%x20-%xfe)
</artwork>
</figure>
</section>
<section title="Storage in the DNS">
<t>Each extension language stanza stored in the DNS is stored as two identical TXT records, one
with a name based on the numeric RR type, one with a name based on the text name.
(One record MAY be aliased to the other using a CNAME.)
The numeric names are located at RRTYPE.ARPA, and the text names are located at RRNAME.ARPA.
For example, if the FOO record type were type 999, the two records would be:</t>
<figure>
<artwork>
999.RRTYPE.ARPA TXT "FOO:999 Foo record" "..."
FOO.RRNAME.ARPA TXT "FOO:999 Foo record" "..."
</artwork>
</figure>
</section>
<section title="Storage in a file">
<t>All the extension language stanzas stored in a file are stored as lines of ASCII text.
The name of the RR type starts in the first position of the first line in the stanza.
Subsequent lines in the stanza start with white space.
A line that is blank or starts with a # character is a comment and is ignored.
</t>
</section>
<section title="Stanza structure">
<t>Each stanza starts with a line containing the name of the RRTYPE, a colon, and the numeric RRTYPE.
The name of the RRTYPE must start in the first position on the line.
When stored in a file,
the RRTYPE name should not be the same as an existing RRTYPE or DNS class name (IN or CH) or bad
things will happen.
The RRTYPE may be followed by white space and a descriptive comment intended to be displayed to
human users, but not interpreted by DNS software. Provisioning software might use the comments as
prompts or labels to help a user select the desired RRTYPE.</t>
<t>The rest of the lines in the stanza start with white space and describe the fields in the record.
Each field is one or more octets long, and fields are stored sequentially in the record:
<figure>
<artwork>
FOO:999 Foo record
field description
field[qual,qual] description
field
...
</artwork>
</figure>
Some fields may be followed by a comma-separated list of qualifiers in square brackets.
The qualifiers further define the
field, e.g., in a numeric field, the qualifiers may define symbolic names for field values or
bit masks.
The field and optional qualifiers may be followed by white space and a description of the field.
The description is intended to be displayed to human users, and is not interpreted by DNS
software. Provisioning software might use the comments as
prompts or labels for templates into which users type RR data.
</t>
</section>
<section title="Field types">
<t>Each field type is defined by a token name consisting of letters and digits, starting with a letter.</t>
<section title="Integer fields">
<t>Integer fields are defined by I1, I2, and I4 tokens, for fields one, two, or four octets long.
The corresponding value in a master record is an unsigned integer number. A field may be
followed by qualifiers defining symbolic field values.</t>
<t>
A symbolic field value is represented as NAME=NN where NAME is the symbol and
NN is the numeric value to
be placed in the field. The corresponding value in a master record is the symbol.
The symbol can contain any ASCII printing character other than comma, equal sign,
vertical bar, angle braces, or backslash. For example, to define the type field
in a <xref target="RFC4398">CERT record</xref>:
<figure><artwork>
I2[PKIX=1,SPKI=2,PGP=2,IPKIX=4,ISPKI=5,IPGP=6,ACPKIX=7,\
IACPKIX=8,URI=253,OID=254] Type
</artwork></figure></t>
</section>
<section title="IP address fields">
<t>IP address fields are defined by A or AAAA tokens, for four-octet IPv4 addresses or
16-octet IPv6 addresses. The corresponding value in a master record is an IP address
written in the usual way. There are no qualifiers.</t>
</section>
<section title="Domain name fields">
<t>Domain name fields are defined by N tokens. The qualifier C means the name is compressed.
The qualifier A means that the DNS server should do the usual additional record processing,
including related A and AAAA records if available. The qualifier M means the name is
really an e-mail address, i.e., the first component is the mailbox and the rest is the
actual domain name. Multiple qualifiers are permitted, e.g. N[A,C] for a compressed name
with additional record processing.</t>
<t>The corresponding value in a master record is a domain name, written in the usual way,
with \. meaning a literal dot in a record.</t>
<t>Names are absolute if they end with a dot, otherwise relative to $ORIGIN,
the existing convention for master files.</t>
</section>
<section title="String fields">
<t>String fields are defined by S tokens. The qualifier L means that the string may be long,
more than 255 bytes, in which case it is stored in the record as multiple strings, with
the location of the boundary between the strings undefined. The qualifier M means that there
may be multiple strings, each stored as a string in the record. A string field with either
qualifier must be the last field in the record.</t>
<t>The corresponding value in a master record is a string enclosed in single or double quotes,
or multiple strings if the M qualifier is present.
Embedded quotes may be escaped with a backslash, and a double backslash represents a
backslash. If a non-null string contains no white space, quote characters, or backslashes, the
quotes may be omitted.</t>
</section>
<section title="Base-64 fields">
<t>A base64 field is defined by a B token. The qualifier C means that the field is stored
in the record as a string with a preceding length byte. A base64 field without a C
qualifier must be the last field in the record.</t>
<t>The corresponding value in a master record is a string represented as <xref target="RFC3548">base64</xref>.
The value of a base64 field without a C qualifier may include embedded spaces for readability, which
are ignored.</t>
</section>
<section title="Hex fields">
<t>A hex field is defined by an X token. There are no qualifiers. A hex field must be
the last field in the record.</t>
<t>The corresponding value in a master record is a string represented as an even number of hexadecimal
digits. The value may include embedded spaces for readability, which are ignored.</t>
</section>
</section>
</section>
<section title="Examples">
<t>
<figure>
<preamble>If a DNS server didn't already have support for MX records, they could be defined as:
</preamble>
<artwork>
MX:15 Mail exchanger
I2 Priority (lower values are higher priority)
N[A,C] Host name
</artwork>
<postamble>The name is MX, the RRTYPE is 15, and the data includes a two-octet number and a compressed domain
name, with additional section records for the domain name.
</postamble>
</figure>
</t>
<t>
<figure>
<preamble>The <xref target="RFC2782">SRV record</xref> could be defined as:</preamble>
<artwork>
SRV:33 Service location
I2 Priority
I2 Weight
I2 Port
N[A] Target host name
</artwork>
<postamble>
The name is SRV, the RRTYPE is 33. The record contains three two-octet fields for the
priority, weight,
and port, and a domain name. The domain name is not compressed, but the DNS server should include
additional section records for it.
</postamble>
</figure>
</t>
</section>
<section title="Security considerations">
<t>The extension language makes it possible to create master files that represent arbitrary DNS records.
Since most DNS servers already provide ways to represent arbitrary data, this doesn't introduce any new
security issues to the DNS and DNS servers, although it may create security issues in provisioning software
if the provisioning system is intended to limit the kinds of records its users can define.</t>
<t>Extension language files with accidentally or deliberately invalid field definitions could provoke
odd bugs in server or provisioning software that doesn't check the syntax before using it.</t>
</section>
<section title="IANA considerations">
<t>
This document requests that IANA create the RRTYPE.ARPA and RRNAME.ARPA zones.
Their initial contents are as follows: [ list of description of existing RRs here ]
</t>
<t>
When new RR types are defined, the defining documents SHOULD request IANA to add
appropriate records to RRTYPE.ARPA and RRNAME.ARPA.
</t>
<t>This document requests that IANA create a registry of DNS Extension Language Field Types.
Its initial contents are as follows</t>
<texttable
anchor="dnsextreg"
title="DNS Extension Language Field Types Registry Initial Values">
<ttcol
align="center">TYPE</ttcol>
<ttcol
align="left">REFERENCE</ttcol>
<c>I1</c> <c> (this document) </c>
<c>I2</c> <c> (this document) </c>
<c>I4</c> <c> (this document) </c>
<c>A</c> <c> (this document) </c>
<c>AAAA</c> <c> (this document) </c>
<c>N</c> <c> (this document) </c>
<c>S</c> <c> (this document) </c>
<c>B</c> <c> (this document) </c>
<c>X</c> <c> (this document) </c>
</texttable>
</section>
</middle>
<back>
<references title="References - Normative">
&RFC1034;
&RFC1035;
&RFC3548;
&RFC5234;
</references>
<references title="References - Informative">
&RFC2782;
&RFC4033;
&RFC4398;
</references>
<section title="Change Log">
<t><spanx style="strong">NOTE TO RFC EDITOR: This section may be removed
upon publication of this document as an RFC.</spanx></t>
<section title="Changes from -04 to -05">
<t>DNS publication in RRYPE.ARPA and RRNAME.ARPA.</t>
</section>
<section title="Changes from -03 to -04">
<t>More use cases.</t>
<t>Fix up BNF</t>
</section>
<section title="Changes from -02 to -03">
<t>First stab at BNF</t>
<t>Note $ORIGIN matters</t>
</section>
<section title="Changes from -01 to -02">
<t>Editorial nits</t>
</section>
<section title="Changes from -00 to -01">
<t>Switch to multi-line format. Add comments for provisioning.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 17:17:59 |