An Extension Language for the DNS
draft-levine-dnsextlang-12

Document Type Active Internet-Draft (individual)
Last updated 2019-10-12
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          J. Levine
Internet-Draft                                      Taughannock Networks
Intended status: Standards Track                                P. Vixie
Expires: 14 April 2020                                   12 October 2019

                   An Extension Language for the DNS
                       draft-levine-dnsextlang-12

Abstract

   Adding 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.

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 https://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 14 April 2020.

Copyright Notice

   Copyright (c) 2019 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 (https://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.

Levine & Vixie            Expires 14 April 2020                 [Page 1]
Internet-Draft           DNS Extension Language             October 2019

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Typical usage . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Extension language syntax . . . . . . . . . . . . . . . . . .   4
     3.1.  Lexical structure . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Storage in the DNS  . . . . . . . . . . . . . . . . . . .   5
       3.2.1.  Record type directory . . . . . . . . . . . . . . . .   5
     3.3.  Storage in a file . . . . . . . . . . . . . . . . . . . .   6
     3.4.  Stanza structure  . . . . . . . . . . . . . . . . . . . .   6
     3.5.  Field types . . . . . . . . . . . . . . . . . . . . . . .   7
       3.5.1.  Integer fields  . . . . . . . . . . . . . . . . . . .   7
       3.5.2.  IP address and partial address fields . . . . . . . .   8
       3.5.3.  Domain name fields  . . . . . . . . . . . . . . . . .   8
       3.5.4.  String fields . . . . . . . . . . . . . . . . . . . .   8
       3.5.5.  Base-32 and Base-64 fields  . . . . . . . . . . . . .   9
       3.5.6.  Hex fields  . . . . . . . . . . . . . . . . . . . . .   9
       3.5.7.  Time stamp fields . . . . . . . . . . . . . . . . . .   9
       3.5.8.  Miscellaneous fields  . . . . . . . . . . . . . . . .   9
   4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.  Security considerations . . . . . . . . . . . . . . . . . . .  10
   6.  IANA considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  References - Normative  . . . . . . . . . . . . . . . . .  12
     7.2.  References - Informative  . . . . . . . . . . . . . . . .  13
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  14
     A.1.  Changes from -11 to -12 . . . . . . . . . . . . . . . . .  14
     A.2.  Changes from -10 to -11 . . . . . . . . . . . . . . . . .  14
     A.3.  Changes from -09 to -10 . . . . . . . . . . . . . . . . .  14
     A.4.  Changes from -08 to -09 . . . . . . . . . . . . . . . . .  14
     A.5.  Changes from -07 to -08 . . . . . . . . . . . . . . . . .  14
     A.6.  Changes from -06 to -07 . . . . . . . . . . . . . . . . .  14
     A.7.  Changes from -05 to -06 . . . . . . . . . . . . . . . . .  14
     A.8.  Changes from -04 to -05 . . . . . . . . . . . . . . . . .  15
     A.9.  Changes from -03 to -04 . . . . . . . . . . . . . . . . .  15
     A.10. Changes from -02 to -03 . . . . . . . . . . . . . . . . .  15
     A.11. Changes from -01 to -02 . . . . . . . . . . . . . . . . .  15
     A.12. Changes from -00 to -01 . . . . . . . . . . . . . . . . .  15
   Appendix B.  Descriptions of currently defined RRTYPEs  . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   The Domain Name System[RFC1034] [RFC1035] 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

Levine & Vixie            Expires 14 April 2020                 [Page 2]
Internet-Draft           DNS Extension Language             October 2019

   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 [RFC4033], 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.

2.  Typical usage

   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

Levine & Vixie            Expires 14 April 2020                 [Page 3]
Internet-Draft           DNS Extension Language             October 2019

   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.

3.  Extension language syntax

3.1.  Lexical structure

   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 [RFC5234].

   ldh = ALPHA 0*(ALPHA | DIGIT | "-")

   dnsextfile = 1*stanza

   stanza = rrtypeline 1*fieldline

   rrtypeline = ldh ":" 1*DIGIT 0*1(":" 1*ALPHA) 0*1(WSP freetext)

   fieldline = ftype 0*1qualifiers 0*1(":" ldh ) 0*1(WSP freetext)

   ftype = "I1" | "I2" | "I4" | "A" | "AA" | "AAAA" | "N" | "S" |
     "B32" | "B64" | "X" | "EUI48" | "EUI64" | "T" | "Z"

   qualifiers = "[" qual 0*(, qual) "]"

   qual = ldh "=" 1*DIGIT | "C" | "A" | "L" | "M" | "X" | "P" |
      "WKS" | "NSAP" | "NXT" | "A6P" | "A6S" | "APL" | "IPSECKEY" |
      "HIPHIT" | "HIPPK"

   freetext = 0*(%x20-%xfe)

Levine & Vixie            Expires 14 April 2020                 [Page 4]
Internet-Draft           DNS Extension Language             October 2019

3.2.  Storage in the DNS

   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 [RFC5646] 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:

   999.RRTYPE.ARPA. TXT "RRTYPE=1" "FOO:999 Foorec" "I2:count Count" "..."
   FOO.RRNAME.ARPA. TXT "RRTYPE=1" "FOO:999 Foorec" "I2:count Count" "..."

   If there are descriptions in multiple languages, they are stored with
   name prefixes, and applications can choose the most suitable one.

   EN.999.RRTYPE.ARPA. TXT "RRTYPE=1" "FOO:999 Foo rec" "..."
   999.RRTYPE.ARPA. CNAME EN.999.RTYPE.ARPA.
   FR.999.RRTYPE.ARPA. TXT "RRTYPE=1" "FOO:999 Un foo" "..."
   EN.FOO.RRNAME.ARPA. TXT "RRTYPE=1" "FOO:999 Foo rec" "..."
   FOO.RRTYPE.ARPA. CNAME EN.FOO.RTYPE.ARPA.
   FR.FOO.RRNAME.ARPA. TXT "RRTYPE=1" "FOO:999 Un foo" "..."

3.2.1.  Record type directory

   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.:

   _LIST.RRNAME.ARPA. TXT "RRTYPE=1" "A" "A6" ... "WKS" "X25"

Levine & Vixie            Expires 14 April 2020                 [Page 5]
Internet-Draft           DNS Extension Language             October 2019

3.3.  Storage in a file

   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.

3.4.  Stanza structure

   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:

    FOO:999 Foo record
       field description
       field:tag description
       field[qual,qual] description
       field[qual,qual]:tag description
       field ...

   Some fields may be followed by a comma-separated list of qualifiers
   in square brackets.  The qualifiers further define the field, e.g.,

Levine & Vixie            Expires 14 April 2020                 [Page 6]
Internet-Draft           DNS Extension Language             October 2019

   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.

3.5.  Field types

   Each field type is defined by a token name consisting of letters and
   digits, starting with a letter.

3.5.1.  Integer fields

   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 [RFC4398]:

      I2[PKIX=1,SPKI=2,PGP=2,IPKIX=4,ISPKI=5,IPGP=6,ACPKIX=7,\
       IACPKIX=8,URI=253,OID=254]:type Certificate type

   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.

Levine & Vixie            Expires 14 April 2020                 [Page 7]
Internet-Draft           DNS Extension Language             October 2019

3.5.2.  IP address and partial address fields

   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.

3.5.3.  Domain name fields

   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.

3.5.4.  String fields

   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.

Levine & Vixie            Expires 14 April 2020                 [Page 8]
Internet-Draft           DNS Extension Language             October 2019

3.5.5.  Base-32 and Base-64 fields

   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 [RFC3548].  The value of a base64 field may include
   embedded spaces for readability, which are ignored.

3.5.6.  Hex fields

   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.

3.5.7.  Time stamp fields

   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.

3.5.8.  Miscellaneous fields

   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 [RFC1035] RRTYPE.

   Z[NSAP] is the special hex syntax for the address in the NSAP
   [RFC1706] RRTYPE.

   Z[NXT] is the bitmap of RRTYPES in the NXT [RFC2535] RRTYPE.

Levine & Vixie            Expires 14 April 2020                 [Page 9]
Internet-Draft           DNS Extension Language             October 2019

   Z[A6P] and Z[A6S] are the prefix length and the variable length
   address suffix in the A6 [RFC2874] RRTYPE.

   Z[APL] is the list of address prefixes in the APL [RFC3123] RRTYPE.

   Z[IPSECKEY] is the variable format gateway in the IPSECKEY [RFC4025]
   RRTYPE.

   Z[HIPHIT] and Z[HIPPK] are the hex HIT and base64 PK fields with
   detached implicit lengths in the HIP [RFC5205] RRTYPE.

4.  Examples

   A description of an MX record could be defined as:

    MX:15 Mail exchanger
      I2:priority Priority (lower values are higher priority)
      N[A,C]:exchanger Host name

   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 [RFC2782] could be defined as:

    SRV:33 Service location
      I2:priority Priority
      I2:weight Weight
      I2:port Port
      N:target Target host name

   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.

5.  Security considerations

   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.

Levine & Vixie            Expires 14 April 2020                [Page 10]
Internet-Draft           DNS Extension Language             October 2019

   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.

6.  IANA considerations

   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 follows

Levine & Vixie            Expires 14 April 2020                [Page 11]
Internet-Draft           DNS Extension Language             October 2019

               +-------+-----------------+-----------------+
               |  TYPE | REFERENCE       | EXTLANG VERSION |
               +=======+=================+=================+
               |   I1  | (this document) | 1               |
               +-------+-----------------+-----------------+
               |   I2  | (this document) | 1               |
               +-------+-----------------+-----------------+
               |   I4  | (this document) | 1               |
               +-------+-----------------+-----------------+
               |   A   | (this document) | 1               |
               +-------+-----------------+-----------------+
               |   AA  | (this document) | 1               |
               +-------+-----------------+-----------------+
               |  AAAA | (this document) | 1               |
               +-------+-----------------+-----------------+
               |   N   | (this document) | 1               |
               +-------+-----------------+-----------------+
               |   S   | (this document) | 1               |
               +-------+-----------------+-----------------+
               |  B32  | (this document) | 1               |
               +-------+-----------------+-----------------+
               |  B64  | (this document) | 1               |
               +-------+-----------------+-----------------+
               |   X   | (this document) | 1               |
               +-------+-----------------+-----------------+
               | EUI48 | (this document) | 1               |
               +-------+-----------------+-----------------+
               | EUI64 | (this document) | 1               |
               +-------+-----------------+-----------------+
               |   T   | (this document) | 1               |
               +-------+-----------------+-----------------+
               |   Z   | (this document) | 1               |
               +-------+-----------------+-----------------+

                   Table 1: DNS Extension Language Field
                       Types Registry Initial Values

7.  References

7.1.  References - Normative

   [RFC1034]  Mockapetris, P.V., "Domain names - concepts and
              facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034,
              November 1987, <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P.V., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

Levine & Vixie            Expires 14 April 2020                [Page 12]
Internet-Draft           DNS Extension Language             October 2019

   [RFC3548]  Josefsson, S., Ed., "The Base16, Base32, and Base64 Data
              Encodings", RFC 3548, DOI 10.17487/RFC3548, July 2003,
              <https://www.rfc-editor.org/info/rfc3548>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
              Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
              September 2009, <https://www.rfc-editor.org/info/rfc5646>.

7.2.  References - Informative

   [RFC1706]  Manning, B. and R. Colella, "DNS NSAP Resource Records",
              RFC 1706, DOI 10.17487/RFC1706, October 1994,
              <https://www.rfc-editor.org/info/rfc1706>.

   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
              Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999,
              <https://www.rfc-editor.org/info/rfc2535>.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              DOI 10.17487/RFC2782, February 2000,
              <https://www.rfc-editor.org/info/rfc2782>.

   [RFC2874]  Crawford, M. and C. Huitema, "DNS Extensions to Support
              IPv6 Address Aggregation and Renumbering", RFC 2874,
              DOI 10.17487/RFC2874, July 2000,
              <https://www.rfc-editor.org/info/rfc2874>.

   [RFC3123]  Koch, P., "A DNS RR Type for Lists of Address Prefixes
              (APL RR)", RFC 3123, DOI 10.17487/RFC3123, June 2001,
              <https://www.rfc-editor.org/info/rfc3123>.

   [RFC4025]  Richardson, M., "A Method for Storing IPsec Keying
              Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March
              2005, <https://www.rfc-editor.org/info/rfc4025>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/info/rfc4033>.

   [RFC4398]  Josefsson, S., "Storing Certificates in the Domain Name

Levine & Vixie            Expires 14 April 2020                [Page 13]
Internet-Draft           DNS Extension Language             October 2019

              System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006,
              <https://www.rfc-editor.org/info/rfc4398>.

   [RFC5205]  Nikander, P. and J. Laganier, "Host Identity Protocol
              (HIP) Domain Name System (DNS) Extensions", RFC 5205,
              DOI 10.17487/RFC5205, April 2008,
              <https://www.rfc-editor.org/info/rfc5205>.

Appendix A.  Change Log

   *NOTE TO RFC EDITOR: This section may be removed upon publication of
   this document as an RFC.*

A.1.  Changes from -11 to -12

   Change to xml2rfc v3.  Minor editorial changes.

A.2.  Changes from -10 to -11

   Put language back in the name.  Add _LIST directory.  Add O and E
   hints.

A.3.  Changes from -09 to -10

   Add hint letters for RRTYPE classes.

A.4.  Changes from -08 to -09

   Add Z fields for rrtype-specific fields.  Redid qualifier
   descriptions.

   Add definitions of RRTYPEs.

A.5.  Changes from -07 to -08

   Add counted hex and raw strings and other new types.  Added language
   tags.  Added field names.

A.6.  Changes from -06 to -07

   Add RRTYPE=1 tag in TXT records.

   Allow digits and hyphens in qualifier tags, for names like SHA-1.

A.7.  Changes from -05 to -06

   Fix formatting problems.

Levine & Vixie            Expires 14 April 2020                [Page 14]
Internet-Draft           DNS Extension Language             October 2019

   Add RRTYPE option "X".

A.8.  Changes from -04 to -05

   DNS publication in RRYPE.ARPA and RRNAME.ARPA.

A.9.  Changes from -03 to -04

   More use cases.

   Fix up BNF

A.10.  Changes from -02 to -03

   First stab at BNF

   Note $ORIGIN matters

A.11.  Changes from -01 to -02

   Editorial nits

A.12.  Changes from -00 to -01

   Switch to multi-line format.  Add comments for provisioning.

Appendix B.  Descriptions of currently defined RRTYPEs

   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.

   A:1:I a host address [RFC1035]
      A:addr IPv4 address

   NS:2:A an authoritative name server [RFC1035]
      N[C]:host Host name

   MD:3:AO a mail destination (OBSOLETE - use MX) [RFC1035]
      N[C]:host Host name

   MF:4:AO a mail forwarder (OBSOLETE - use MX) [RFC1035]
      N[C]:host Host name

   CNAME:5:A the canonical name for an alias [RFC1035]
      N[C]:host Host name

   SOA:6:A marks the start of a zone of authority [RFC1035]

Levine & Vixie            Expires 14 April 2020                [Page 15]
Internet-Draft           DNS Extension Language             October 2019

      N[C]:primary Primary server name
      N[A]:mailbox Responsible mailbox
      I4:serial Serial number
      I4:refresh Refresh time (seconds)
      I4:retry Retry time (seconds)
      I4:expire Expire time (seconds)
      I4:minimum Minium time (seconds)

   MB:7:AE a mailbox domain name (EXPERIMENTAL) [RFC1035]
      N[C]:host Host name

   MG:8:AE a mail group member (EXPERIMENTAL) [RFC1035]
      N[A]:mailbox Mailbox name

   MR:9:AE a mail rename domain name (EXPERIMENTAL) [RFC1035]
      N[A]:mailbox Mailbox name

   WKS:11:I a well known service description [RFC1035]
      A IPv4 address
      I1 Protocol number
      Z[WKS]:bitmap Bit Map

   PTR:12:A a domain name pointer [RFC1035]
      N[C]:host Host name

   HINFO:13:A host information [RFC1035]
      S:cpu CPU type
      S:os Operating system

   MINFO:14:A mailbox or mail list information [RFC1035]
      N[A]:respbox Responsible mailbox
      N[A]:errbox Error mailbox

   MX:15:A mail exchange [RFC1035]
      I2:priority Priority (lower values are higher priority)
      N[C]:hostname Host name

   TXT:16:A text strings [RFC1035]
      S[M]:text Strings

   RP:17:A for Responsible Person [RFC1183]
      N[A]:mailbox Mailbox
      N:text Text location

   AFSDB:18:A for AFS Data Base location [RFC1183][RFC5864]
       I2:subtype Subtype
       N:hostname Hostname

Levine & Vixie            Expires 14 April 2020                [Page 16]
Internet-Draft           DNS Extension Language             October 2019

   X25:19:A for X.25 PSDN address [RFC1183]
      S:address PSDN address

   ISDN:20:A for ISDN address [RFC1183]
      S[M]:address ISDN address, and optional subaddress

   RT:21:A for Route Through [RFC1183]
      I2:preference Preference
      N:hostname Intermediate host

   NSAP:22:I for NSAP address, NSAP style A record [RFC1706]
      Z[NSAP]:address NSAP Address

   NSAP-PTR:23:I for domain name pointer, NSAP style [RFC1348][RFC1637]
      N:hostname Host name

   SIG:24:A for security signature [RFC4034]
      I2:sigtype Type covered
      I1:algorithm Algorithm
      I1:labels Labels
      I4:ttl Original TTL
      T:expires Signature expiration time
      T:signed Time signed
      I2:footprint Key footprint
      N[C]:name Signer's name
      B64:signature Signature data

   KEY:25:A for security key [RFC4034]
      I2:flags Flags
      I1:protocol Protocol
      I1:algorithm Algorithm
      B64:data Key data

   PX:26:I X.400 mail mapping information [RFC2163]
      I2:pref Preference
      N:idomain Internet mail domain
      N:xdomain X.400 mail domain

   GPOS:27:A Geographical Position [RFC1712]
      S:longitude Longitude (decimal degrees)
      S:latitude Latitude (decimal degrees)
      S:altitude Altitude (meters)

   AAAA:28:I IP6 Address [RFC3596]
      AAAA:address Address

   LOC:29:A Location Information [RFC1876]
      I1:version Version

Levine & Vixie            Expires 14 April 2020                [Page 17]
Internet-Draft           DNS Extension Language             October 2019

      I1:sphere Sphere size
      I2:hprecision Horiz precision
      I2:vprecision Vert precision
      I4:latitude Latitude (offset milliseconds)
      I4:longitude Longitude (offset milliseconds)
      I4:altitude Altitude (offset cm)

   NXT:30:AO Next Domain (OBSOLETE) [RFC3755][RFC2535]
      N[C]:next Domain
      Z[NXT]:rrtypes Bitmap of rrtypes

   SRV:33:I Server Selection [1][RFC2782]
      I2:priority Priority
      I2:weight Weight
      I2:port Port
      N:target Target host name

   NAPTR:35:I Naming Authority Pointer [RFC2915][RFC2168][RFC3403]
      I2:order Order
      I2:pref Preference
      S:flags Flags
      S:services Services
      S:regex Regular expression
      N:replacement Replacement

   KX:36:I Key Exchanger [RFC2230]
      I2:pref Preference
      N:exchanger Exchanger

   CERT:37:A CERT [RFC4398]
      I2[PKIX=1,SPKI=2,PGP=2,IPKIX=4,ISPKI=5,IPGP=6,ACPKIX=7,IACPKIX=8,\
       URI=253,OID=254]:type Type
      I2:tag Key tag
      I1[RSAMD5=1,DH=2,DSA=3,ECC=4,RSASHA1=5,INDIRECT=252,PRIVATEDNS=253,\
       PRIVATEOID=254]:algorithm Algorithm
      B64:certificate Certificate or CRL

   A6:38:IO A6 (OBSOLETE - use AAAA) [RFC3226][RFC2874][RFC6563]
      Z[A6P]:preflen Prefix length
      Z[A6S]:suffix Address suffix
      N:prefname Prefix name

   DNAME:39:A DNAME [RFC6672]
      N:source Source name

   APL:42:I APL [RFC3123]
      Z[APL]:prefixes Prefixes

Levine & Vixie            Expires 14 April 2020                [Page 18]
Internet-Draft           DNS Extension Language             October 2019

   DS:43:A Delegation Signer [RFC4034][RFC3658]
      I2:keytag Key tag
      I1[RSAMD5=1,DH=2,DSA=3,ECC=4,RSASHA1=5,DSA-NSEC-SHA1=6,\
       RSASHA1-NSEC3-SHA1=7,RSASHA256=8,RSASHA512=10,ECC-GOST=12,\
       ECDSAP256SHA256=13,ECDSAP384SHA384=14,INDIRECT=252,PRIVATEDNS=253,\
       PRIVATEOID=254]:algorithm Algorithm
      I1[SHA-1=1,SHA-256=2,GOST=3,SHA-384=4]:digtype Digest type
      X:digest Digest

   SSHFP:44:A SSH Key Fingerprint [RFC4255]
     I1:algorithm Algorithm
     I1:ftype Fingerprint type
     X:fingerprint Fingerprint

   IPSECKEY:45:I IPSECKEY [RFC4025]
      I1:prec Precedence
      I1:gtype Gateway type
      I1:algorithm Algorithm
      Z[IPSECKEY]:gateway Gateway
      B64:key Public key

   RRSIG:46:A RRSIG [RFC4034][RFC3755]
      R:rrtype Type covered (Type mnemonic)
      I1[RSAMD5=1,DH=2,DSA=3,ECC=4,RSASHA1=5,INDIRECT=252,PRIVATEDNS=253,\
       PRIVATEOID=254]:algorithm Algorithm
      I1:labels Labels
      I4:origttl Original TTL
      T:expire Signature expiration (timestamp)
      T:inception Signature inception (timestamp)
      I2:keytag Key tag
      N:signer Signer's name
      B64:signature Signature

   NSEC:47:A NSEC [RFC4034][RFC3755]
      N:next Next domain name
      R[L]:types Type bitmaps (as window blocks)

   DNSKEY:48:A DNSKEY [RFC4034][RFC3755]
      I2:flags Flags
      I1:protocol Protocol (must be 3)
      I1[RSAMD5=1,DH=2,DSA=3,ECC=4,RSASHA1=5,INDIRECT=252,PRIVATEDNS=253,\
       PRIVATEOID=254]:algorithm Algorithm
      B64:publickey Public key

   DHCID:49:I DHCID [RFC4701]
      B64:dhcpinfo DHCP information

   NSEC3:50:A NSEC3 [RFC5155]

Levine & Vixie            Expires 14 April 2020                [Page 19]
Internet-Draft           DNS Extension Language             October 2019

      I1[SHA-1=1]:algorithm Hash algorithm
      I1[OPTOUT=1]:flags Flags
      I2:iterations Iterations
      X[C]:salt Salt
      B32:next Next hashed owner
      R[L]:types Type bitmaps (as window blocks)

   NSEC3PARAM:51:A NSEC3PARAM [RFC5155]
      I1[SHA-1=1]:algorithm Hash algorithm
      I1[OPTOUT=1]:flags Flags
      I2:iterations Iterations
      X[C]:salt Salt

   TLSA:52:A TLSA [RFC6698]
      I1:usage Certificate usage
      I1:selector Certificate selector
      I1:mtype Matching Type
      X:cert Certificate association data

   SMIMEA:53:A S/MIME cert association [draft-ietf-dane-smime]
      I1:usage Certificate usage
      I1:selector Certificate selector
      I1:mtype Matching Type
      X:cert Certificate association data

   HIP:55:A Host Identity Protocol [RFC-ietf-hip-rfc5205-bis-10]
      I1:pkalg PK algorithm
      Z[HIPHIT]:hit HIT
      Z[HIPPK]:pubkey Public Key
      N[O]:servers Rendezvous servers

   CDS:59:A Child DS [RFC7344]
      I2:keytag Key tag
      I1[RSAMD5=1,DH=2,DSA=3,ECC=4,RSASHA1=5,DSA-NSEC-SHA1=6,\
       RSASHA1-NSEC3-SHA1=7,RSASHA256=8,RSASHA512=10,ECC-GOST=12,\
       ECDSAP256SHA256=13,ECDSAP384SHA384=14,INDIRECT=252,\
       PRIVATEDNS=253,PRIVATEOID=254]:algorithm Algorithm
      I1[SHA-1=1,SHA-256=2,GOST=3,SHA-384=4]:digtype Digest type
      X:digest Digest

   CDNSKEY:60:A DNSKEY(s) the Child wants reflected in DS [RFC7344]
      I2:flags Flags
      I1:protocol Protocol (must be 3)
      I1[RSAMD5=1,DH=2,DSA=3,ECC=4,RSASHA1=5,INDIRECT=252,PRIVATEDNS=253,\
       PRIVATEOID=254]:algorithm Algorithm
      B64:publickey Public key

   OPENPGPKEY:61:A OpenPGP Key [RFC7929]

Levine & Vixie            Expires 14 April 2020                [Page 20]
Internet-Draft           DNS Extension Language             October 2019

      B64:key PGP key

   CSYNC:62:A Child-To-Parent Synchronization [RFC7477]
      I4:serial SOA serial
      I2:flags Flags
      R[L]:Types

   SPF:99:AO  [RFC7208]
     S[M]:text SPF data

   NID:104:A  [RFC6742]
      I2:preference Preference
      AA:nodeid Node ID

   L32:105:A  [RFC6742]
      I2:preference Preference
      A:locator Locator32

   L64:106:A  [RFC6742]
      I2:preference Preference
      AA:locator Locator64

   LP:107:A  [RFC6742]
      I2:preference Preference
      N:pointer Pointer

   EUI48:108:A an EUI-48 address [RFC7043]
      X6:address Address (digit pairs separated by hyphens)

   EUI64:109:A an EUI-64 address [RFC7043]
      X8:address Address (digit pairs separated by hyphens)

   URI:256:A URI [RFC7553]
      I2:priority Priority
      I2:weight Weight
      S[X]:target Target

   CAA:257:A Certification Authority Restriction [RFC6844]
      I1:flags Flags
      S:tag Tag
      S[X]:value Value

   DLV:32769:A DNSSEC Lookaside Validation [RFC4431]
      I2:key Key tag
      I1[RSAMD5=1,DH=2,DSA=3,ECC=4,RSASHA1=5,INDIRECT=252,PRIVATEDNS=253,\
       PRIVATEOID=254]:algorithm Algorithm
      I1:type Digest type
      X:digest Digest

Levine & Vixie            Expires 14 April 2020                [Page 21]
Internet-Draft           DNS Extension Language             October 2019

Authors' Addresses

   John Levine
   Taughannock Networks
   PO Box 727
   Trumansburg

   Email: standards@taugh.com
   URI:   http://jl.ly

   Paul Vixie
   950 Charter Street
   Redwood City
   Canada

   Email: vixie@fsi.io

Levine & Vixie            Expires 14 April 2020                [Page 22]