An Extension Language for the
DNSTaughannock NetworksPO Box 727Trumansburg14886NYstandards@taugh.comhttp://jl.ly950 Charter StreetRedwood CityCAvixie@fsi.io
Operations and Management
DNSextensionsAdding new RRTYPEs to the DNS has required 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.The Domain Name System 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.While some new RRTYPEs, notably those for DNSSEC, 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 any RRTYPEs, so
that provisioning software can parse master file records for
the RRTYPEs.
DNS servers can use the extension language to implement RRTYPEs that
do not require special purpose processing.
The extension language can also be useful in provisioning software, to
create input forms and validate the syntax of entered records.
The extension language is written as strings of UTF-8 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.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.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.
The extension language includes natural language field descriptions intended
to be used as prompts in fill-in templates, and can handle versions of
prompts in multiple languages.
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.Some DNS servers store records in ways other than master files, such
as SQL databases. 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.The extension language can describe all existing RRTYPEs, which may
be useful in table driven provisioning software.
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, which must start
with white space, each define a field in the record. Blank lines and
comment lines where the first nonblank character is "#" are ignored.The following ABNF imports ALPHA, DIGIT, and WSP from .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.
The first string in the TXT record are the identification tag "RRTYPE=1" to
identify the record as an RRTYPE definition.
Each line of the stanza
is a string in the TXT records. The leading spaces used in the file
format (described below) are not used.
The record name may also have a language
tag prefix that identifies the language in which the descriptive text
is written.
There should always be an unprefixed record for each type, to be the default
if there is no record in the desired languge, which might be aliased to a prefixed
record with CNAME.
For example, if the FOO record
type were type 999, the two records for an English language description would be:
If there are descriptions in multiple languages, they are stored with
name prefixes, and applications can choose the most suitable one.A directory of all of the available RR names is stored at _LIST.RRTYPE.ARPA.
It is a TXT record containing RRTYPE=1 followed by each name as a separate string, e.g.:
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 where the first
nonblank character is a # is a comment and is ignored.Descriptions in different languages are stored in separate files.
A directory of names can be created by scanning the file.
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 a colon and letters, to indicate options
for the RRTYPE. The letter is "X" means that
implementing the RRTYPE requires extra processing by DNS servers,
e.g., the extra processing for DNAME or DNSSEC records. The intention
of the option is to allow DNS servers to report an error if a zone
contains a record defined with "X" for which the server does not
implement the extra processing.
The letters "I" and "A" mean that the RRTYPE is defined in the IN class only, or
in any class, respectively.
The letters "O" and "E" indicate that the type is obsolete or experimental,
respectively.
That can 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.The rest of the lines in the stanza
describe the fields in the record. Each field is one or more octets
long, and fields are stored sequentially in the record: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.
That can be followed by an colon and an ldh string.
The string is intended to be used as the
name of the field in software applications that create data structures
for an RRTYPE. Applications will often have to change the punctuation
to match the syntax of the programming language, such as replacing
hyphens with underscores.
If two fields in an RRTYPE have the same name, the result is undefined.
The field and optional qualifiers and name 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 enter RR data.Each field type is defined by a token name consisting of letters
and digits, starting with a letter.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.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 letters, digits, and hypens. For example, to define the
type field in a CERT record:RRTYPE fields are defined by R tokens, for a two octet
field containing an RRTYPE. The corresponding
value in a master record is a symbolic RRTYPE or TYPEnnn
for types without names.
A R[L] token and qualifier defines a structured bitmap of RRTYPEs
used in NSEC and NSEC3 records, which must be the last field in the record.
The corresponding value in a master record is a list of RRTYPEs.
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.The AA token defines a 64 bit field written like half of an IPv6
address, with up to four colon separated groups of up to four hex digits.
Domain name fields are defined by N tokens. The qualifier C means
the name is compressed.
The qualifier A means that the domain name represents a mailbox, with the
first component being the local part of the mailbox.
The qualifier L means that the domain name is converted to lower case
before DNSSEC validation.
An N tag and an O qualifier, which can only appear as the last
field in a record, means the name is optional.
The corresponding value in a master record is a domain name,
written in the usual way, with \. meaning a literal dot in a
record.Names are absolute if they end with a dot, otherwise relative to
$ORIGIN, the convention for master files.String fields are defined by S tokens.
A plain S token means a single string preceded by a one-octet length.
A S[M] token and qualifier means that
there may be multiple strings, each stored as a length and string in the
record. A S[M] field must be the last field
in the record.An S[X] token and qualifier is a raw string, stored without any
length bytes. It must be the last field in the record.
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.A base32 or base64 field is defined by a B32 or B64 token.
A base32 field is stored in the record with a preceding one-octet length.
A base64 field is stored as binary data, and must be the last field in the record.The corresponding value in a master record is a string
represented as base32 or base64. The value of a
base64 field may include embedded spaces for
readability, which are ignored.A hex field is defined by an X token.
A plain X field is binary data.
An X[C] token and qualifier means that the field is stored in the record as a string
with a preceding one-octet length.
An unqualified hex field must be the last field in the record,
and may include embedded spaces for readability, which are ignored.The corresponding value in a master record is a string
represented as an even number of hexadecimal digits.
EUI48 and EUI64 fields are defined by X6 and X8 tokens, respectively.
The corresponding fields in master records are six or eight pairs of hex
digits separated by hyphens.
A 32-bit timestamp field is defined by a T token.
The corresponding value in a master record is a fourteen digit value
in the form YYYYMMDDHHmmSS indicating a UTC timestamp,
or as an unsigned number of seconds with ten digits or less.
The field is stored in the record as a Unix timestamp, the unsigned number
of seconds since January 1, 1970 00:00:00 UTC.
Some RRTYPEs have fields with a unique syntax, represented as qualifiers in a Z field.
Z[WKS] is the bitmap of port numbers in the WKS RRTYPE.Z[NSAP] is the special hex syntax for the address in the NSAP RRTYPE.Z[NXT] is the bitmap of RRTYPES in the NXT RRTYPE.Z[A6P] and Z[A6S] are the prefix length and the variable length address suffix in the A6 RRTYPE.Z[APL] is the list of address prefixes in the APL RRTYPE.Z[IPSECKEY] is the variable format gateway in the IPSECKEY RRTYPE.Z[HIPHIT] and Z[HIPPK] are the hex HIT and base64 PK fields with detached implicit
lengths in the HIP RRTYPE.Z[SVCB] is the list of service parameters in the SVCB and HTTPS RRTYPEs.A description of an MX
record could be defined as: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.The SRV record could be
defined as: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.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.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.When extension language data are imported from the DNS, a hostile
party might use DNS spoofing techniques to modify the records imported.
Methods to defend against DNS spoofing include DNSSEC.This document requests that IANA create the RRTYPE.ARPA and
RRNAME.ARPA zones. Their initial contents are as shown in Appendix B.
When new RR types are defined, the defining documents SHOULD request
IANA to add appropriate records to RRTYPE.ARPA and RRNAME.ARPA.This document requests that IANA create a registry of DNS Extension
Language Field Types. Its initial contents are as followsTYPEREFERENCEEXTLANG VERSIONI1(this document)1I2(this document)1I4(this document)1A(this document)1AA(this document)1AAAA(this document)1N(this document)1S(this document)1B32(this document)1B64(this document)1X(this document)1EUI48(this document)1EUI64(this document)1T(this document)1Z(this document)1NOTE TO RFC EDITOR: This section may be removed
upon publication of this document as an RFC.Change to current rfcxml.
Minor editorial changes.Change to xml2rfc v3.
Minor editorial changes.Put language back in the name. Add _LIST directory. Add O and E hints.Add hint letters for RRTYPE classes.Add Z fields for rrtype-specific fields.
Redid qualifier descriptions.
Add definitions of RRTYPEs.Add counted hex and raw strings and other new types. Added language tags.
Added field names.Add RRTYPE=1 tag in TXT records.Allow digits and hyphens in qualifier tags, for names like
SHA-1.Fix formatting problems.Add RRTYPE option "X".DNS publication in RRYPE.ARPA and RRNAME.ARPA.More use cases.Fix up BNFFirst stab at BNFNote $ORIGIN mattersEditorial nitsSwitch to multi-line format. Add comments for provisioning.Here are descriptions of currently RRTYPEs that can appear in zone files.
The \ indicating continuation lines are only for display in this document
and would not appear in the descriptions.