TOC 
Network Working GroupJ. Levine
Internet-DraftTaughannock Networks
Intended status: Standards TrackT. Finch
Expires: September 14, 2012University of Cambridge
 March 13, 2012


A DNS resource record data format description language
draft-levine-dnsextlang

Abstract

Adding a new resource record type to the DNS requires that DNS servers and provisioning software are upgraded to support the new RRTYPE in user interfaces, master files, and zone data stores. This memo specifies a DNS resource record data format description language. It is intended to allow most new RRTYPEs to be supported by adding a few lines to a configuration file read by the DNS software, with no code changes.

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 http://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 September 14, 2012.

Copyright Notice

Copyright (c) 2012 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 (http://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.



Table of Contents

1.  Introduction
2.  Typical usage
3.  RDATA description syntax
    3.1.  Lexical basics
    3.2.  Line formats
4.  Field types
    4.1.  Integer fields
    4.2.  IP address fields
    4.3.  Domain name fields
    4.4.  String fields
    4.5.  Base-64 fields
    4.6.  Hex fields
5.  Examples
6.  Security considerations
7.  IANA Considerations
8.  References
    8.1.  Normative References
    8.2.  Informative References
Appendix A.  Change Log
    A.1.  Changes from -01 to -02
    A.2.  Changes from -00 to -01
§  Authors' Addresses




 TOC 

1.  Introduction

The Domain Name System [RFC1034] (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.) [RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.) is designed to be extensible, with new resource 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 [RFC4033] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.), 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 [RFC3597] (Gustafsson, A., “Handling of Unknown DNS Resource Record (RR) Types,” September 2003.), perhaps with some additional section records if the record includes another domain name. This memo specifies a resource record data format description language for describing the RDATA layout of new RRTYPEs, so that server and provisioning software can translate them to and from DNS wire format and master file format, and provide a helpful user interfaces for displaying and editing them.



 TOC 

2.  Typical usage

RDATA format descriptions are written in plain text, intended to be stored in a file with a well-known name such as /etc/rrtypes. All of the DNS software that needs to handle master file records would read the file upon startup. To support a new RRTYPE, one would add a suitable record to /etc/rrtypes, and then restart or signal DNS software to reread the new contents of the file.

DNS servers and support tools can use the RDATA descriptions to parse new RRTYPE records in master files, and to translate them to the binary representation. Provisioning software can use the extension lanaguage 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.



 TOC 

3.  RDATA description syntax

The syntax of the rrtypes file is described using ABNF [RFC5234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.). Non-terminal symbols that are not defined here are part of Core ABNF defined in appendix B of [RFC5234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.). UTF-8 syntax is specified in section 4 of [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.), and URI generic syntax is specified in appendix A of [RFC3986] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.).



 TOC 

3.1.  Lexical basics

The rrtypes file is a sequence of lines. Each line may have leading or trailing white space, and is terminated by a newline sequence. Tokens within a line are separated by white space. Where arbitrary text is allowed it must conform to UTF-8 [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.) and should not contain control characters or vertical whitespace (though code points outside the ASCII range need not be checked.)


  file  =  *line

  line  =  *WSP item *WSP (CRLF / LF)

  S     =  1*WSP

  text  =  *( WSP / VCHAR / UTF8-2 / UTF8-3 / UTF8-4 )

Tokens are case-insensitive wrt ASCII letters. Keywords are defined by this specification, and (apart from [RFC3597] (Gustafsson, A., “Handling of Unknown DNS Resource Record (RR) Types,” September 2003.) type codes) are conventionally written in lower-case. Mnemonics are derived from the RRTYPE specification documents, and are conventionally upper-case. Descriptions provide explanatory text for use in user interfaces, and may provide links to relevant specifications. Missing mnemonics and descriptions must be marked by a dash.


  token        =  number / keyword / mnemonic

  number       =  1*DIGIT

  keyword      =  rrtype / fieldtype / qualifier

  rrtype       =  "TYPE" 1*DIGIT

  mnemonic     =  1*( ALPHA / DIGIT / "-" )
               /  "-"

  description  =  text *citation
               /  "-"

  citation     =  *WSP "[" ( "RFC" 4DIGIT / URI ) "]"



 TOC 

3.2.  Line formats

The rrtypes file contains five kinds of line, which (apart from comments) are distinguished by the keyword at the start of the line.


  item  =  comment / header / field / qualifiers / enumeration

Blank lines and comments (lines starting with a semicolon) are ignored. (Comments are treated as separate lines so that simple parsers do not need to split descriptions from comments.)


  comment  =  [ ";" text ]

A resource record data format description starts with a header line that states the [RFC3597] (Gustafsson, A., “Handling of Unknown DNS Resource Record (RR) Types,” September 2003.) type code, the mnemonic used for the type in master files, and a description for displaying to users.


  header  =  rrtype S memonic S description

The header is followed by a number of lines that describe the format of the RDATA as a series of fields. The order of the field lines in the file is the same as the order of the fields in the wire format and the master file presentation format. A field's mnemonic is useful for cross-reference between documentation and code, but does not appear on the wire or in master files. If the description is missing (i.e. just a dash), the mnemonic can be used instead; if that is also missing and there is only one field in the RDATA, the RRTYPE mnemonic should be used instead.


  field  =  fieldtype S mnemonic S description

Header and field lines may be followed by a list of qualifiers. Different qualifiers are valid depending on the preceding line.


  qualifiers  =  qualifier *( S qualifier )

Numeric field lines may be followed by a number of enumeration lines. These describe a mapping between a field value and a mnemonic for use in the master file presentation format, and/or a description for use in user interfaces.


  enumeration  =  number S mnemonic S description



 TOC 

4.  Field types

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



 TOC 

4.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 any ASCII printing character other than comma, equal sign, vertical bar, angle braces, or backslash. 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


 TOC 

4.2.  IP 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.



 TOC 

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

The corresponding value in a master record is a domain name, written in the usual way, with \. meaning a literal dot in a record.

[Are names written as absolute or relative to $ORIGIN? ]



 TOC 

4.4.  String fields

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.

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.



 TOC 

4.5.  Base-64 fields

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.

The corresponding value in a master record is a string represented as base64 [RFC3548]. The value of a base64 field without a C qualifier may include embedded spaces for readability, which are ignored.



 TOC 

4.6.  Hex fields

A hex field is defined by an X token. There are no qualifiers. A hex field must be the last field in the record.

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.



 TOC 

5.  Examples

If a DNS server didn't already have support for MX records, they could be defined as:

     MX:15 Mail exchanger
       I2 Priority (lower values are higher priority)
       N[A,C] 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
       I2 Weight
       I2 Port
       N[A] 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, but the DNS server should include additional section records for it.



 TOC 

6.  Security considerations

RDATA format descriptions make it easier to create master files that represent arbitrary DNS records. Since most DNS servers already provide ways to represent arbitrary data [RFC3597] (Gustafsson, A., “Handling of Unknown DNS Resource Record (RR) Types,” September 2003.), this doesn't introduce any new security issues to the DNS and DNS servers.

In situations where users can manipulate DNS data without restriction - for instance, when [RFC3597] (Gustafsson, A., “Handling of Unknown DNS Resource Record (RR) Types,” September 2003.) unknown RRTYPE syntax is permitted - it may be useful to allow them to provide RDATA format descriptions. The software should ensure that this facility isn't used to hide known RRTYPEs which require extra checking.

RDATA format description files with accidentally or deliberately invalid contents could provoke odd bugs in server or provisioning software that doesn't check the syntax before using it.



 TOC 

7.  IANA Considerations

This document requests that IANA create a registry of DNS Extension Language Field Types. Its initial contents are as follows

TYPEREFERENCE
I1 (this document)
I2 (this document)
I4 (this document)
A (this document)
AAAA (this document)
N (this document)
S (this document)
B (this document)
X (this document)



 TOC 

8.  References



 TOC 

8.1. Normative References

[RFC1034] Mockapetris, P., “Domain names - concepts and facilities,” STD 13, RFC 1034, November 1987 (TXT).
[RFC1035] Mockapetris, P., “Domain names - implementation and specification,” STD 13, RFC 1035, November 1987 (TXT).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC3548] Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” RFC 3548, July 2003 (TXT).
[RFC3597] Gustafsson, A., “Handling of Unknown DNS Resource Record (RR) Types,” RFC 3597, September 2003 (TXT).
[RFC3629] Yergeau, F., “UTF-8, a transformation format of ISO 10646,” STD 63, RFC 3629, November 2003 (TXT).
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” STD 66, RFC 3986, January 2005 (TXT, HTML, XML).
[RFC5234] Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” STD 68, RFC 5234, January 2008 (TXT).


 TOC 

8.2. Informative References

[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” RFC 2782, February 2000 (TXT).
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” RFC 4033, March 2005 (TXT).
[RFC4398] Josefsson, S., “Storing Certificates in the Domain Name System (DNS),” RFC 4398, March 2006 (TXT).


 TOC 

Appendix A.  Change Log

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



 TOC 

A.1.  Changes from -01 to -02

Editorial nits



 TOC 

A.2.  Changes from -00 to -01

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



 TOC 

Authors' Addresses

  John Levine
  Taughannock Networks
  PO Box 727
  Trumansburg NY 14886
Phone:  +1 831 480 2300
Email:  standards@taugh.com
URI:  http://jl.ly
  
  Tony Finch
  University of Cambridge Computing Service
  New Museums Site
  Pembroke Street
  Cambridge CB2 3QH
  ENGLAND
Phone:  +44 797 040 1426
Email:  dot@dotat.at
URI:  http://dotat.at/