idnits 2.17.1 draft-levine-dnsextlang-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 357: '... the defining documents SHOULD request...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 25, 2013) is 3868 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'A' is mentioned on line 326, but not defined == Missing Reference: 'C' is mentioned on line 314, but not defined ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Levine 3 Internet-Draft Taughannock Networks 4 Intended status: Standards Track P. Vixie 5 Expires: February 26, 2014 Internet Systems Consortium 6 August 25, 2013 8 An Extension Language for the DNS 9 draft-levine-dnsextlang-07 11 Abstract 13 Adding new RRTYPEs to the DNS requires that DNS servers and 14 provisioning software be upgraded to support each new RRTYPE in 15 Master files. This document defines a DNS extension language 16 intended to allow most new RRTYPEs to be supported by adding entries 17 to configuration data read by the DNS software, with no software 18 changes needed for each RRTYPE. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 26, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Typical usage . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Extension language syntax . . . . . . . . . . . . . . . . . . 3 57 3.1. Lexical structure . . . . . . . . . . . . . . . . . . . . 3 58 3.2. Storage in the DNS . . . . . . . . . . . . . . . . . . . 4 59 3.3. Storage in a file . . . . . . . . . . . . . . . . . . . . 4 60 3.4. Stanza structure . . . . . . . . . . . . . . . . . . . . 4 61 3.5. Field types . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. Security considerations . . . . . . . . . . . . . . . . . . . 8 64 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 7.1. References - Normative . . . . . . . . . . . . . . . . . 9 67 7.2. References - Informative . . . . . . . . . . . . . . . . 9 68 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 69 A.1. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 9 70 A.2. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 9 71 A.3. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 10 72 A.4. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 10 73 A.5. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 10 74 A.6. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 10 75 A.7. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 The Domain Name System[RFC1034] [RFC1035] is designed to be 81 extensible, with new record types, known as RRTYPEs, added as needed. 82 While it is straightforward in principle to add a new RRTYPE, in 83 practice it can be difficult due to the software changes needed to 84 add the new RRTYPE to the master file format read by many 85 authoritative DNS servers, and to the provisioning software used to 86 create and update the master files or the local equivalent. 88 While some new RRTYPEs, notably those for DNSSEC [RFC4033], require 89 that DNS servers do new special purpose processing, most new RRTYPEs 90 are, from the point of view of the DNS, just static data to return to 91 queries, perhaps with some additional section records if the record 92 includes another domain name. This document defines an extension 93 language to describe these RRTYPEs, so that server and provisioning 94 software can parse master file records for the RRTYPEs. 96 2. Typical usage 98 The extension language is written as strings of ASCII text that 99 describe new RR types, intended to be stored in the DNS itself. 100 (They may also be stored in a local file with a well-known name, for 101 debugging and local overrides, but this usage is optional.) All of 102 the DNS software that needs to handle master file records fetches 103 records from the DNS as needed. To support a new RRTYPE, one would 104 add suitable records to the DNS zone where the descriptions are 105 located, or to the local file. 107 DNS servers can use the extension language to parse new RRTYPE 108 records in master files, and to translate them to the binary 109 representation. Servers that create ASCII master files from zone 110 data retrieved via AXFR can use the extension language to create 111 master file records for new RRTYPEs. 113 Provisioning software can use the extension language to create 114 templates for users to fill in, to create new RRTYPE records in 115 master files to be passed to DNS servers, and to syntax check records 116 entered by users. 118 In principle, provisioning software could create TYPEnn master 119 records if the local DNS server doesn't implement the extension 120 language, although it would be less confusing if both provisioning 121 and server software both accept the same master record syntax. 123 Some DNS servers store records in ways other than master files, such 124 as SQL databases. In principle, the extension language could be used 125 to create new schema entries to handle new RRTYPEs, although the 126 details are too specific to particular varieties of DNS server 127 software for this document to try to describe the details. 129 3. Extension language syntax 131 3.1. Lexical structure 133 The extension language consists of "stanzas", each of which defines 134 an RRTYPE. In the DNS, a stanza is stored as a multi-string TXT 135 record, with each string conceptually being a line in the stanza. In 136 a file, it is stored as a series of lines. The first line of a 137 stanza defines the symbolic RRTYPE name. Subsequent lines, which 138 must start with white space, each define a field in the record. 139 Blank lines and comment lines starting with "#" are ignored. 141 The following ABNF imports ALPHA, DIGIT, and WSP from [RFC5234]. 143 ldh = ALPHA 0*(ALPHA | DIGIT | "-") 145 dnsextfile = 1*stanza 147 stanza = rrtypeline 1*fieldline 149 rrtypeline = ldh ":" 1*DIGIT 150 0*1(":" 1*ALPHA) 0*1(WSP freetext) 152 fieldline = WSP ftype 0*1qualifiers 0*1(WSP freetext) 154 ftype = "I1" | "I2" | "I4" | "A" | "AAAA" | "N" | "S" | "B" | "X" 156 qualifiers = "[" qual 0*(, qual) "]" 158 qual = ldh "=" 1*DIGIT | "C" | "A" | "L" | "M" 160 freetext = 0*(%x20-%xfe) 162 3.2. Storage in the DNS 164 Each extension language stanza stored in the DNS is stored as two 165 identical TXT records, one with a name based on the numeric RR type, 166 one with a name based on the text name. (One record may be aliased 167 to the other using a CNAME.) The numeric names are located at 168 RRTYPE.ARPA, and the text names are located at RRNAME.ARPA. The 169 first string in the TXT record is the identification tag "RRTYPE=1" 170 to identify the record as an RRTYPE definition. Each line of the 171 stanza is a string in the TXT records. The leading spaces used in 172 the file format (described below) are not used. For example, if the 173 FOO record type were type 999, the two records would be: 175 999.RRTYPE.ARPA TXT "RRTYPE=1" "FOO:999 Foo record" "I2:Count" "..." 176 FOO.RRNAME.ARPA TXT "RRTYPE=1" "FOO:999 Foo record" "I2:Count" "..." 178 3.3. Storage in a file 180 All the extension language stanzas stored in a file are stored as 181 lines of ASCII text. The name of the RR type starts in the first 182 position of the first line in the stanza. Subsequent lines in the 183 stanza start with white space. A line that is blank or starts with a 184 # character is a comment and is ignored. 186 3.4. Stanza structure 187 Each stanza starts with a line containing the name of the RRTYPE, a 188 colon, and the numeric RRTYPE. The name of the RRTYPE must start in 189 the first position on the line. When stored in a file, the RRTYPE 190 name should not be the same as an existing RRTYPE or DNS class name 191 (IN or CH) or bad things will happen. 193 The RRTYPE may be followed a colon and letters, to indicate options 194 for the RRTYPE. The only currently used letter is "X" which means 195 that implementing the RRTYPE requires extra processing by DNS 196 servers, e.g., the extra processing for DNAME or DNSSEC records. The 197 intention of the option is to allow DNS servers to report an error if 198 a zone contains a record defined with "X" for which the server does 199 not implement the extra processing. 201 That can be followed by white space and a descriptive comment 202 intended to be displayed to human users, but not interpreted by DNS 203 software. Provisioning software might use the comments as prompts or 204 labels to help a user select the desired RRTYPE. 206 The rest of the lines in the stanza start with white space and 207 describe the fields in the record. Each field is one or more octets 208 long, and fields are stored sequentially in the record: 210 FOO:999 Foo record 211 field description 212 field[qual,qual] description 213 field 214 ... 216 Some fields may be followed by a comma-separated list of qualifiers 217 in square brackets. The qualifiers further define the field, e.g., 218 in a numeric field, the qualifiers may define symbolic names for 219 field values or bit masks. The field and optional qualifiers may be 220 followed by white space and a description of the field. The 221 description is intended to be displayed to human users, and is not 222 interpreted by DNS software. Provisioning software might use the 223 comments as prompts or labels for templates into which users enter RR 224 data. 226 3.5. Field types 228 Each field type is defined by a token name consisting of letters and 229 digits, starting with a letter. 231 3.5.1. Integer fields 232 Integer fields are defined by I1, I2, and I4 tokens, for fields one, 233 two, or four octets long. The corresponding value in a master record 234 is an unsigned integer number. A field may be followed by qualifiers 235 defining symbolic field values. 237 A symbolic field value is represented as NAME=NN where NAME is the 238 symbol and NN is the numeric value to be placed in the field. The 239 corresponding value in a master record is the symbol. The symbol can 240 contain letters, digits, and hypens. For example, to define the type 241 field in a CERT record [RFC4398]: 243 I2[PKIX=1,SPKI=2,PGP=2,IPKIX=4,ISPKI=5,IPGP=6,ACPKIX=7,\ 244 IACPKIX=8,URI=253,OID=254] Type 246 3.5.2. IP address fields 248 IP address fields are defined by A or AAAA tokens, for four-octet 249 IPv4 addresses or 16-octet IPv6 addresses. The corresponding value 250 in a master record is an IP address written in the usual way. There 251 are no qualifiers. 253 3.5.3. Domain name fields 255 Domain name fields are defined by N tokens. The qualifier C means 256 the name is compressed. The qualifier A means that the DNS server 257 should do the usual additional record processing, including related A 258 and AAAA records if available. The qualifier M means the name is 259 really an e-mail address, i.e., the first component is the mailbox 260 and the rest is the actual domain name. Multiple qualifiers are 261 permitted, e.g. N[A,C] for a compressed name with additional record 262 processing. 264 The corresponding value in a master record is a domain name, written 265 in the usual way, with \. meaning a literal dot in a record. 267 Names are absolute if they end with a dot, otherwise relative to 268 $ORIGIN, the existing convention for master files. 270 3.5.4. String fields 272 String fields are defined by S tokens. The qualifier L means that 273 the string can be long, more than 255 bytes, in which case it is 274 stored in the record as multiple strings, with the location of the 275 boundary between the strings undefined. The qualifier M means that 276 there may be multiple strings, each stored as a string in the record. 277 A string field with either qualifier must be the last field in the 278 record. 280 The corresponding value in a master record is a string enclosed in 281 single or double quotes, or multiple strings if the M qualifier is 282 present. Embedded quotes may be escaped with a backslash, and a 283 double backslash represents a backslash. If a non-null string 284 contains no white space, quote characters, or backslashes, the quotes 285 may be omitted. 287 3.5.5. Base-64 fields 289 A base64 field is defined by a B token. The qualifier C means that 290 the field is stored in the record as a string with a preceding length 291 byte. A base64 field without a C qualifier must be the last field in 292 the record. 294 The corresponding value in a master record is a string represented as 295 base64 [RFC3548]. The value of a base64 field without a C qualifier 296 may include embedded spaces for readability, which are ignored. 298 3.5.6. Hex fields 300 A hex field is defined by an X token. There are no qualifiers. A 301 hex field must be the last field in the record. 303 The corresponding value in a master record is a string represented as 304 an even number of hexadecimal digits. The value may include embedded 305 spaces for readability, which are ignored. 307 4. Examples 309 If a DNS server didn't already have support for MX records, they 310 could be defined as: 312 MX:15 Mail exchanger 313 I2 Priority (lower values are higher priority) 314 N[A,C] Host name 316 The name is MX, the RRTYPE is 15, and the data includes a two-octet 317 number and a compressed domain name, with additional section records 318 for the domain name. 320 The SRV record [RFC2782] could be defined as: 322 SRV:33 Service location 323 I2 Priority 324 I2 Weight 325 I2 Port 326 N[A] Target host name 328 The name is SRV, the RRTYPE is 33. The record contains three two- 329 octet fields for the priority, weight, and port, and a domain name. 330 The domain name is not compressed, but the DNS server should include 331 additional section records for it. 333 5. Security considerations 335 The extension language makes it possible to create master files that 336 represent arbitrary DNS records. Since most DNS servers already 337 provide ways to represent arbitrary data, this doesn't introduce any 338 new security issues to the DNS and DNS servers, although it may 339 create security issues in provisioning software if the provisioning 340 system is intended to limit the kinds of records its users can 341 define. 343 Extension language files with accidentally or deliberately invalid 344 field definitions could provoke odd bugs in server or provisioning 345 software that doesn't check the syntax before using it. 347 When extension language data are imported from the DNS, a hostile 348 party might use DNS spoofing techniques to modify the records 349 imported. Methods to defend against DNS spoofing include DNSSEC. 351 6. IANA considerations 353 This document requests that IANA create the RRTYPE.ARPA and 354 RRNAME.ARPA zones. Their initial contents are as follows: [ list of 355 description of existing RRs here ] 357 When new RR types are defined, the defining documents SHOULD request 358 IANA to add appropriate records to RRTYPE.ARPA and RRNAME.ARPA. 360 This document requests that IANA create a registry of DNS Extension 361 Language Field Types. Its initial contents are as follows 363 +------+------------------+-----------------+ 364 | TYPE | REFERENCE | EXTLANG VERSION | 365 +------+------------------+-----------------+ 366 | I1 | (this document) | 1 | 367 | I2 | (this document) | 1 | 368 | I4 | (this document) | 1 | 369 | A | (this document) | 1 | 370 | AAAA | (this document) | 1 | 371 | N | (this document) | 1 | 372 | S | (this document) | 1 | 373 | B | (this document) | 1 | 374 | X | (this document) | 1 | 375 +------+------------------+-----------------+ 377 Table 1: DNS Extension Language Field Types Registry Initial Values 379 7. References 381 7.1. References - Normative 383 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 384 STD 13, RFC 1034, November 1987. 386 [RFC1035] Mockapetris, P., "Domain names - implementation and 387 specification", STD 13, RFC 1035, November 1987. 389 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 390 Encodings", RFC 3548, July 2003. 392 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 393 Specifications: ABNF", STD 68, RFC 5234, January 2008. 395 7.2. References - Informative 397 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 398 specifying the location of services (DNS SRV)", RFC 2782, 399 February 2000. 401 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 402 Rose, "DNS Security Introduction and Requirements", RFC 403 4033, March 2005. 405 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 406 System (DNS)", RFC 4398, March 2006. 408 Appendix A. Change Log 410 *NOTE TO RFC EDITOR: This section may be removed upon publication of 411 this document as an RFC.* 413 A.1. Changes from -06 to -07 415 Add RRTYPE=1 tag in TXT records. 417 Allow digits and hyphens in qualifier tags, for names like SHA-1. 419 A.2. Changes from -05 to -06 421 Fix formatting problems. 423 Add RRTYPE option "X". 425 A.3. Changes from -04 to -05 427 DNS publication in RRYPE.ARPA and RRNAME.ARPA. 429 A.4. Changes from -03 to -04 431 More use cases. 433 Fix up BNF 435 A.5. Changes from -02 to -03 437 First stab at BNF 439 Note $ORIGIN matters 441 A.6. Changes from -01 to -02 443 Editorial nits 445 A.7. Changes from -00 to -01 447 Switch to multi-line format. Add comments for provisioning. 449 Authors' Addresses 451 John Levine 452 Taughannock Networks 453 PO Box 727 454 Trumansburg, NY 14886 456 Phone: +1 831 480 2300 457 Email: standards@taugh.com 458 URI: http://jl.ly 460 Paul Vixie 461 Internet Systems Consortium 462 950 Charter Street 463 Redwood City, CA> 465 Email: vixie@isc.org