idnits 2.17.1 draft-levine-dnsextlang-08.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 6 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** 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 416: '... 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 (September 4, 2016) is 2790 days in the past. Is this intentional? 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 386, but not defined == Missing Reference: 'C' is mentioned on line 374, but not defined ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: March 8, 2017 September 4, 2016 7 An Extension Language for the DNS 8 draft-levine-dnsextlang-08 10 Abstract 12 Adding new RRTYPEs to the DNS has required that DNS servers and 13 provisioning software be upgraded to support each new RRTYPE in 14 Master files. This document defines a DNS extension language 15 intended to allow most new RRTYPEs to be supported by adding entries 16 to configuration data read by the DNS software, with no software 17 changes needed for each RRTYPE. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 8, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Typical usage . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Extension language syntax . . . . . . . . . . . . . . . . . . 3 56 3.1. Lexical structure . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Storage in the DNS . . . . . . . . . . . . . . . . . . . 4 58 3.3. Storage in a file . . . . . . . . . . . . . . . . . . . . 5 59 3.4. Stanza structure . . . . . . . . . . . . . . . . . . . . 5 60 3.5. Field types . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5. Security considerations . . . . . . . . . . . . . . . . . . . 9 63 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 7.1. References - Normative . . . . . . . . . . . . . . . . . 10 66 7.2. References - Informative . . . . . . . . . . . . . . . . 11 67 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11 68 A.1. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 11 69 A.2. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 11 70 A.3. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 11 71 A.4. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 11 72 A.5. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 12 73 A.6. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 12 74 A.7. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 12 75 A.8. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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 any RRTYPEs, so that provisioning software can 94 parse master file records for the RRTYPEs. DNS servers can use the 95 extension language to implement RRTYPEs that do not require special 96 purpose processing. 98 2. Typical usage 100 The extension language is written as strings of UTF-8 text that 101 describe new RR types, intended to be stored in the DNS itself. 102 (They may also be stored in a local file with a well-known name, for 103 debugging and local overrides, but this usage is optional.) All of 104 the DNS software that needs to handle master file records fetches 105 records from the DNS as needed. To support a new RRTYPE, one would 106 add suitable records to the DNS zone where the descriptions are 107 located, or to the local file. 109 DNS servers can use the extension language to parse new RRTYPE 110 records in master files, and to translate them to the binary 111 representation. Servers that create ASCII master files from zone 112 data retrieved via AXFR can use the extension language to create 113 master file records for new RRTYPEs. 115 Provisioning software can use the extension language to create 116 templates for users to fill in, to create new RRTYPE records in 117 master files to be passed to DNS servers, and to syntax check records 118 entered by users. The extension language includes natural language 119 field descriptions intended to be used as prompts in fill-in 120 templates, and can handle versions of prompts in multiple languages. 122 Provisioning software could create TYPEnn master records if the local 123 DNS server doesn't implement the extension language, although it 124 would be less confusing if both provisioning and server software both 125 accept the same master record syntax. 127 Some DNS servers store records in ways other than master files, such 128 as SQL databases. The extension language could be used to create new 129 schema entries to handle new RRTYPEs, although the details are too 130 specific to particular varieties of DNS server software for this 131 document to try to describe the details. 133 The extension language can describe all existing RRTYPEs, which may 134 be useful in table driven provisioning software. 136 3. Extension language syntax 138 3.1. Lexical structure 140 The extension language consists of "stanzas", each of which defines 141 an RRTYPE. In the DNS, a stanza is stored as a multi-string TXT 142 record, with each string conceptually being a line in the stanza. In 143 a file, it is stored as a series of lines. The first line of a 144 stanza defines the symbolic RRTYPE name. Subsequent lines, which 145 must start with white space, each define a field in the record. 146 Blank lines and comment lines where the first nonblank character is 147 "#" are ignored. 149 The following ABNF imports ALPHA, DIGIT, and WSP from [RFC5234]. 151 ldh = ALPHA 0*(ALPHA | DIGIT | "-") 153 dnsextfile = 1*stanza 155 stanza = rrtypeline 1*fieldline 157 rrtypeline = ldh ":" 1*DIGIT 0*1(":" 1*ALPHA) 0*1(WSP freetext) 159 fieldline = ftype 0*1qualifiers 0*1(":" ldh ) 0*1(WSP freetext) 161 ftype = "I1" | "I2" | "I4" | "A" | "AA" | "AAAA" | "N" | "S" | 162 "B32" | "B64" | "X" | "T" | "T6" 164 qualifiers = "[" qual 0*(, qual) "]" 166 qual = ldh "=" 1*DIGIT | "C" | "A" | "L" | "M" | "X" 168 freetext = 0*(%x20-%xfe) 170 3.2. Storage in the DNS 172 Each extension language stanza stored in the DNS is stored as two 173 identical TXT records, one with a name based on the numeric RR type, 174 one with a name based on the text name. (One record may be aliased 175 to the other using a CNAME.) The numeric names are located at 176 RRTYPE.ARPA, and the text names are located at RRNAME.ARPA. 178 The first two strings in the TXT record are the identification tag 179 "RRTYPE=1" to identify the record as an RRTYPE definition, and a 180 language tag [RFC5646] that identifies the language in which the 181 descriptive text is written. Each line of the stanza is a string in 182 the TXT records. The leading spaces used in the file format 183 (described below) are not used. For example, if the FOO record type 184 were type 999, the two records for an English language description 185 would be: 187 999.RRTYPE.ARPA. TXT "RRTYPE=1" "EN" "FOO:999 Foo record" "I2:count Count" "..." 188 FOO.RRNAME.ARPA. TXT "RRTYPE=1" "EN" "FOO:999 Foo record" "I2:count Count" "..." 189 If there are descriptions in multiple languages, they are all stored 190 at the same name, and applications can choose the most suitable one. 192 999.RRTYPE.ARPA. TXT "RRTYPE=1" "EN" "FOO:999 Foo record" "I2:count Count" "..." 193 999.RRTYPE.ARPA. TXT "RRTYPE=1" "FR" "FOO:999 Dossier foo" "I2:count Compte" "..." 194 FOO.RRNAME.ARPA. TXT "RRTYPE=1" "EN" "FOO:999 Foo record" "I2:count Count" "..." 195 FOO.RRNAME.ARPA. TXT "RRTYPE=1" "FR" "FOO:999 Dossier foo" "I2:count Compte" "..." 197 3.3. Storage in a file 199 All the extension language stanzas stored in a file are stored as 200 lines of ASCII text. The name of the RR type starts in the first 201 position of the first line in the stanza. Subsequent lines in the 202 stanza start with white space. A line that is blank or where the 203 first nonblank character is a # is a comment and is ignored. 205 Descriptions in different languages are stored in separate files. 207 3.4. Stanza structure 209 Each stanza starts with a line containing the name of the RRTYPE, a 210 colon, and the numeric RRTYPE. The name of the RRTYPE must start in 211 the first position on the line. When stored in a file, the RRTYPE 212 name should not be the same as an existing RRTYPE or DNS class name 213 (IN or CH) or bad things will happen. 215 The RRTYPE may be followed a colon and letters, to indicate options 216 for the RRTYPE. The only currently used letter is "X" which means 217 that implementing the RRTYPE requires extra processing by DNS 218 servers, e.g., the extra processing for DNAME or DNSSEC records. The 219 intention of the option is to allow DNS servers to report an error if 220 a zone contains a record defined with "X" for which the server does 221 not implement the extra processing. 223 That can be followed by white space and a descriptive comment 224 intended to be displayed to human users, but not interpreted by DNS 225 software. Provisioning software might use the comments as prompts or 226 labels to help a user select the desired RRTYPE. 228 The rest of the lines in the stanza describe the fields in the 229 record. Each field is one or more octets long, and fields are stored 230 sequentially in the record: 232 FOO:999 Foo record 233 field description 234 field:tag description 235 field[qual,qual] description 236 field[qual,qual]:tag description 237 field ... 239 Some fields may be followed by a comma-separated list of qualifiers 240 in square brackets. The qualifiers further define the field, e.g., 241 in a numeric field, the qualifiers may define symbolic names for 242 field values or bit masks. That can be followed by an colon and an 243 ldh string. The string is intended to be used as the name of the 244 field in software applications that create data structures for an 245 RRTYPE. Applications will often have to change the punctuation to 246 match the syntax of the programming language, such as replacing 247 hyphens with underscores. If two fields in an RRTYPE have the same 248 name, the result is undefined. 250 The field and optional qualifiers and name may be followed by white 251 space and a description of the field. The description is intended to 252 be displayed to human users, and is not interpreted by DNS software. 253 Provisioning software might use the comments as prompts or labels for 254 templates into which users enter RR data. 256 3.5. Field types 258 Each field type is defined by a token name consisting of letters and 259 digits, starting with a letter. 261 3.5.1. Integer fields 263 Integer fields are defined by I1, I2, and I4 tokens, for fields one, 264 two, or four octets long. The corresponding value in a master record 265 is an unsigned integer number. A field may be followed by qualifiers 266 defining symbolic field values. 268 A symbolic field value is represented as NAME=NN where NAME is the 269 symbol and NN is the numeric value to be placed in the field. The 270 corresponding value in a master record is the symbol. The symbol can 271 contain letters, digits, and hypens. For example, to define the type 272 field in a CERT record [RFC4398]: 274 I2[PKIX=1,SPKI=2,PGP=2,IPKIX=4,ISPKI=5,IPGP=6,ACPKIX=7,\ 275 IACPKIX=8,URI=253,OID=254]:type Certificate type 277 RRTYPE fields are defined by R tokens, for a two octet field 278 containing an RRTYPE. The corresponding value in a master record is 279 a symbolic RRTYPE or TYPEnnn for types without names. 281 3.5.2. IP address and partial address fields 283 IP address fields are defined by A or AAAA tokens, for four-octet 284 IPv4 addresses or 16-octet IPv6 addresses. The corresponding value 285 in a master record is an IP address written in the usual way. There 286 are no qualifiers. 288 The AA token defines a 64 bit field written like half of an IPv6 289 address, with up to four colon separated groups of up to four hex 290 digits. 292 3.5.3. Domain name fields 294 Domain name fields are defined by N tokens. The qualifier C means 295 the name is compressed. The qualifier M, which can only appear on 296 the last field in a record, means there can be an arbitrary number of 297 domain names. The qualifier A means that the domain name represents 298 a mailbox, with the first component being the local part of the 299 mailbox. The qualifier L means that the domain name is converted to 300 lower case before DNSSEC validation. 302 The corresponding value in a master record is a domain name or list 303 of domain names, written in the usual way, with \. meaning a literal 304 dot in a record. 306 Names are absolute if they end with a dot, otherwise relative to 307 $ORIGIN, the convention for master files. 309 3.5.4. String fields 311 String fields are defined by S tokens. The qualifier M means that 312 there may be multiple strings, each stored as a string in the record. 313 A string field with the M qualifier must be the last field in the 314 record. 316 The corresponding value in a master record is a string enclosed in 317 single or double quotes, or multiple strings if the M qualifier is 318 present. Embedded quotes may be escaped with a backslash, and a 319 double backslash represents a backslash. If a non-null string 320 contains no white space, quote characters, or backslashes, the quotes 321 may be omitted. 323 A string with the X qualifier is a raw string, stored without any 324 length bytes. It must be the last field in the record. 326 3.5.5. Base-32 and Base-64 fields 328 A base32 or base64 field is defined by a B32 or B64 token. The 329 qualifier C means that the field is stored in the record as a string 330 with a preceding length byte. The qualifier S means that the field 331 is stored in the record as a string with a preceding two-byte length 332 field. A base32 or base64 field without a C or S qualifier must be 333 the last field in the record. 335 The corresponding value in a master record is a string represented as 336 base64 [RFC3548]. The value of a base64 field without a C qualifier 337 may include embedded spaces for readability, which are ignored. 339 3.5.6. Hex fields 341 A hex field is defined by an X token. The qualifier C means that the 342 field is stored in the record as a string with a preceding length 343 byte. The qualifier S means that the field is stored in the record 344 as a string with a preceding two-byte length field. An unqualified 345 hex field must be the last field in the record. 347 The corresponding value in a master record is a string represented as 348 an even number of hexadecimal digits. The value may include embedded 349 spaces for readability, which are ignored. 351 EUI48 and EUI64 fields are defined by X6 and X8 tokens, respectively. 352 The corresponding fields in master records are six or eight pairs of 353 hex digits separated by hyphens. 355 3.5.7. Time stamp fields 357 A 32-bit timestamp field is defined by a T token. The corresponding 358 value in a master record is a fourteen digit value in the form 359 YYYYMMDDHHmmSS indicating a UTC timestamp. The field is stored in 360 the record as a Unix timestamp, the unsigned number of seconds since 361 January 1, 1970 00:00:00 UTC. 363 A 48-bit timestamp field is defined by a T6 token. The corresponding 364 value in a master record is an integer value representing the number 365 of seconds since January 1, 1970 00:00:00 UTC. The field is stored 366 in the record as a six octet binary version of that value. 368 4. Examples 369 If a DNS server didn't already have support for MX records, they 370 could be defined as: 372 MX:15 Mail exchanger 373 I2 Priority (lower values are higher priority) 374 N[A,C] Host name 376 The name is MX, the RRTYPE is 15, and the data includes a two-octet 377 number and a compressed domain name, with additional section records 378 for the domain name. 380 The SRV record [RFC2782] could be defined as: 382 SRV:33 Service location 383 I2 Priority 384 I2 Weight 385 I2 Port 386 N[A] Target host name 388 The name is SRV, the RRTYPE is 33. The record contains three two- 389 octet fields for the priority, weight, and port, and a domain name. 390 The domain name is not compressed, but the DNS server should include 391 additional section records for it. 393 5. Security considerations 395 The extension language makes it possible to create master files that 396 represent arbitrary DNS records. Since most DNS servers already 397 provide ways to represent arbitrary data, this doesn't introduce any 398 new security issues to the DNS and DNS servers, although it may 399 create security issues in provisioning software if the provisioning 400 system is intended to limit the kinds of records its users can 401 define. 403 Extension language files with accidentally or deliberately invalid 404 field definitions could provoke odd bugs in server or provisioning 405 software that doesn't check the syntax before using it. 407 When extension language data are imported from the DNS, a hostile 408 party might use DNS spoofing techniques to modify the records 409 imported. Methods to defend against DNS spoofing include DNSSEC. 411 6. IANA considerations 413 This document requests that IANA create the RRTYPE.ARPA and 414 RRNAME.ARPA zones. Their initial contents are as follows: [ list of 415 description of existing RRs here ] 416 When new RR types are defined, the defining documents SHOULD request 417 IANA to add appropriate records to RRTYPE.ARPA and RRNAME.ARPA. 419 This document requests that IANA create a registry of DNS Extension 420 Language Field Types. Its initial contents are as follows 422 +------+-----------------+-----------------+ 423 | TYPE | REFERENCE | EXTLANG VERSION | 424 +------+-----------------+-----------------+ 425 | I1 | (this document) | 1 | 426 | I2 | (this document) | 1 | 427 | I4 | (this document) | 1 | 428 | A | (this document) | 1 | 429 | AA | (this document) | 1 | 430 | AAAA | (this document) | 1 | 431 | N | (this document) | 1 | 432 | S | (this document) | 1 | 433 | B32 | (this document) | 1 | 434 | B64 | (this document) | 1 | 435 | X | (this document) | 1 | 436 | T | (this document) | 1 | 437 | T6 | (this document) | 1 | 438 +------+-----------------+-----------------+ 440 Table 1: DNS Extension Language Field Types Registry Initial Values 442 7. References 444 7.1. References - Normative 446 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 447 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 448 . 450 [RFC1035] Mockapetris, P., "Domain names - implementation and 451 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 452 November 1987, . 454 [RFC3548] Josefsson, S., Ed., "The Base16, Base32, and Base64 Data 455 Encodings", RFC 3548, DOI 10.17487/RFC3548, July 2003, 456 . 458 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 459 Specifications: ABNF", STD 68, RFC 5234, 460 DOI 10.17487/RFC5234, January 2008, 461 . 463 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 464 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 465 September 2009, . 467 7.2. References - Informative 469 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 470 specifying the location of services (DNS SRV)", RFC 2782, 471 DOI 10.17487/RFC2782, February 2000, 472 . 474 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 475 Rose, "DNS Security Introduction and Requirements", 476 RFC 4033, DOI 10.17487/RFC4033, March 2005, 477 . 479 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 480 System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006, 481 . 483 Appendix A. Change Log 485 *NOTE TO RFC EDITOR: This section may be removed upon publication of 486 this document as an RFC.* 488 A.1. Changes from -07 to -08 490 Add counted hex and raw strings and other new types. Added language 491 tags. Added field names. 493 A.2. Changes from -06 to -07 495 Add RRTYPE=1 tag in TXT records. 497 Allow digits and hyphens in qualifier tags, for names like SHA-1. 499 A.3. Changes from -05 to -06 501 Fix formatting problems. 503 Add RRTYPE option "X". 505 A.4. Changes from -04 to -05 507 DNS publication in RRYPE.ARPA and RRNAME.ARPA. 509 A.5. Changes from -03 to -04 511 More use cases. 513 Fix up BNF 515 A.6. Changes from -02 to -03 517 First stab at BNF 519 Note $ORIGIN matters 521 A.7. Changes from -01 to -02 523 Editorial nits 525 A.8. Changes from -00 to -01 527 Switch to multi-line format. Add comments for provisioning. 529 Authors' Addresses 531 John Levine 532 Taughannock Networks 533 PO Box 727 534 Trumansburg, NY 14886 536 Phone: +1 831 480 2300 537 Email: standards@taugh.com 538 URI: http://jl.ly 540 Paul Vixie 541 950 Charter Street 542 Redwood City, CA 544 Email: vixie@fsi.io