idnits 2.17.1 draft-levine-dnsextlang-09.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 440: '... 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 30, 2016) is 2758 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: 'L' is mentioned on line 854, but not defined == Missing Reference: 'O' is mentioned on line 830, but not defined == Missing Reference: 'M' is mentioned on line 857, but not defined == Missing Reference: 'X' is mentioned on line 889, but not defined == Missing Reference: 'C' is mentioned on line 812, but not defined == Missing Reference: 'WKS' is mentioned on line 629, but not defined == Missing Reference: 'NSAP' is mentioned on line 668, but not defined == Missing Reference: 'NXT' is mentioned on line 714, but not defined == Missing Reference: 'A6P' is mentioned on line 743, but not defined == Missing Reference: 'A6S' is mentioned on line 744, but not defined == Missing Reference: 'APL' is mentioned on line 751, but not defined == Missing Reference: 'IPSECKEY' is mentioned on line 771, but not defined == Missing Reference: 'HIPHIT' is mentioned on line 828, but not defined == Missing Reference: 'HIPPK' is mentioned on line 829, but not defined == Missing Reference: 'A' is mentioned on line 650, but not defined == Missing Reference: 'RFC1183' is mentioned on line 663, but not defined == Missing Reference: 'RFC5864' is mentioned on line 653, but not defined == Missing Reference: 'RFC1348' is mentioned on line 670, but not defined ** Obsolete undefined reference: RFC 1348 (Obsoleted by RFC 1637) == Missing Reference: 'RFC1637' is mentioned on line 670, but not defined ** Obsolete undefined reference: RFC 1637 (Obsoleted by RFC 1706) == Missing Reference: 'RFC4034' is mentioned on line 790, but not defined == Missing Reference: 'RFC2163' is mentioned on line 690, but not defined == Missing Reference: 'RFC1712' is mentioned on line 695, but not defined == Missing Reference: 'RFC3596' is mentioned on line 700, but not defined == Missing Reference: 'RFC1876' is mentioned on line 703, but not defined == Missing Reference: 'RFC3755' is mentioned on line 790, but not defined ** Obsolete undefined reference: RFC 3755 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Looks like a reference, but probably isn't: '1' on line 716 == Missing Reference: 'RFC2915' is mentioned on line 722, but not defined ** Obsolete undefined reference: RFC 2915 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) == Missing Reference: 'RFC2168' is mentioned on line 722, but not defined ** Obsolete undefined reference: RFC 2168 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) == Missing Reference: 'RFC3403' is mentioned on line 722, but not defined == Missing Reference: 'RFC2230' is mentioned on line 730, but not defined == Missing Reference: 'RFC3226' is mentioned on line 742, but not defined == Missing Reference: 'RFC6563' is mentioned on line 742, but not defined == Missing Reference: 'RFC6672' is mentioned on line 747, but not defined == Missing Reference: 'RFC3658' is mentioned on line 753, but not defined ** Obsolete undefined reference: RFC 3658 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Missing Reference: 'RFC4255' is mentioned on line 762, but not defined == Missing Reference: 'RFC4701' is mentioned on line 797, but not defined == Missing Reference: 'RFC5155' is mentioned on line 808, but not defined == Missing Reference: 'RFC6698' is mentioned on line 814, but not defined == Missing Reference: 'RFC-ietf-hip-rfc5205-bis-10' is mentioned on line 826, but not defined ** Obsolete undefined reference: RFC 5205 (Obsoleted by RFC 8005) == Missing Reference: 'RFC7344' is mentioned on line 841, but not defined == Missing Reference: 'RFC7929' is mentioned on line 848, but not defined == Missing Reference: 'RFC7477' is mentioned on line 851, but not defined == Missing Reference: 'RFC7208' is mentioned on line 856, but not defined == Missing Reference: 'RFC6742' is mentioned on line 871, but not defined == Missing Reference: 'RFC7043' is mentioned on line 878, but not defined == Missing Reference: 'RFC7553' is mentioned on line 881, but not defined == Missing Reference: 'RFC6844' is mentioned on line 886, but not defined ** Obsolete undefined reference: RFC 6844 (Obsoleted by RFC 8659) == Missing Reference: 'RFC4431' is mentioned on line 891, but not defined ** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648) -- Obsolete informational reference (is this intentional?): RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 5205 (Obsoleted by RFC 8005) Summary: 11 errors (**), 0 flaws (~~), 48 warnings (==), 4 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: April 3, 2017 September 30, 2016 7 An Extension Language for the DNS 8 draft-levine-dnsextlang-09 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 April 3, 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 . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 5. Security considerations . . . . . . . . . . . . . . . . . . . 9 63 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 7.1. References - Normative . . . . . . . . . . . . . . . . . 11 66 7.2. References - Informative . . . . . . . . . . . . . . . . 11 67 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 68 A.1. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 12 69 A.2. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 12 70 A.3. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 12 71 A.4. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 12 72 A.5. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 13 73 A.6. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 13 74 A.7. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 13 75 A.8. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 13 76 A.9. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 13 77 Appendix B. Descriptions of currently defined RRTYPEs . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 80 1. Introduction 82 The Domain Name System[RFC1034] [RFC1035] is designed to be 83 extensible, with new record types, known as RRTYPEs, added as needed. 84 While it is straightforward in principle to add a new RRTYPE, in 85 practice it can be difficult due to the software changes needed to 86 add the new RRTYPE to the master file format read by many 87 authoritative DNS servers, and to the provisioning software used to 88 create and update the master files or the local equivalent. 90 While some new RRTYPEs, notably those for DNSSEC [RFC4033], require 91 that DNS servers do new special purpose processing, most new RRTYPEs 92 are, from the point of view of the DNS, just static data to return to 93 queries, perhaps with some additional section records if the record 94 includes another domain name. This document defines an extension 95 language to describe any RRTYPEs, so that provisioning software can 96 parse master file records for the RRTYPEs. DNS servers can use the 97 extension language to implement RRTYPEs that do not require special 98 purpose processing. 100 2. Typical usage 102 The extension language is written as strings of UTF-8 text that 103 describe new RR types, intended to be stored in the DNS itself. 104 (They may also be stored in a local file with a well-known name, for 105 debugging and local overrides, but this usage is optional.) All of 106 the DNS software that needs to handle master file records fetches 107 records from the DNS as needed. To support a new RRTYPE, one would 108 add suitable records to the DNS zone where the descriptions are 109 located, or to the local file. 111 DNS servers can use the extension language to parse new RRTYPE 112 records in master files, and to translate them to the binary 113 representation. Servers that create ASCII master files from zone 114 data retrieved via AXFR can use the extension language to create 115 master file records for new RRTYPEs. 117 Provisioning software can use the extension language to create 118 templates for users to fill in, to create new RRTYPE records in 119 master files to be passed to DNS servers, and to syntax check records 120 entered by users. The extension language includes natural language 121 field descriptions intended to be used as prompts in fill-in 122 templates, and can handle versions of prompts in multiple languages. 124 Provisioning software could create TYPEnn master records if the local 125 DNS server doesn't implement the extension language, although it 126 would be less confusing if both provisioning and server software both 127 accept the same master record syntax. 129 Some DNS servers store records in ways other than master files, such 130 as SQL databases. The extension language could be used to create new 131 schema entries to handle new RRTYPEs, although the details are too 132 specific to particular varieties of DNS server software for this 133 document to try to describe the details. 135 The extension language can describe all existing RRTYPEs, which may 136 be useful in table driven provisioning software. 138 3. Extension language syntax 139 3.1. Lexical structure 141 The extension language consists of "stanzas", each of which defines 142 an RRTYPE. In the DNS, a stanza is stored as a multi-string TXT 143 record, with each string conceptually being a line in the stanza. In 144 a file, it is stored as a series of lines. The first line of a 145 stanza defines the symbolic RRTYPE name. Subsequent lines, which 146 must start with white space, each define a field in the record. 147 Blank lines and comment lines where the first nonblank character is 148 "#" are ignored. 150 The following ABNF imports ALPHA, DIGIT, and WSP from [RFC5234]. 152 ldh = ALPHA 0*(ALPHA | DIGIT | "-") 154 dnsextfile = 1*stanza 156 stanza = rrtypeline 1*fieldline 158 rrtypeline = ldh ":" 1*DIGIT 0*1(":" 1*ALPHA) 0*1(WSP freetext) 160 fieldline = ftype 0*1qualifiers 0*1(":" ldh ) 0*1(WSP freetext) 162 ftype = "I1" | "I2" | "I4" | "A" | "AA" | "AAAA" | "N" | "S" | 163 "B32" | "B64" | "X" | "EUI48" | "EUI64" | "T" | "Z" 165 qualifiers = "[" qual 0*(, qual) "]" 167 qual = ldh "=" 1*DIGIT | "C" | "A" | "L" | "M" | "X" | "P" | 168 "WKS" | "NSAP" | "NXT" | "A6P" | "A6S" | "APL" | "IPSECKEY" | 169 "HIPHIT" | "HIPPK" 171 freetext = 0*(%x20-%xfe) 173 3.2. Storage in the DNS 175 Each extension language stanza stored in the DNS is stored as two 176 identical TXT records, one with a name based on the numeric RR type, 177 one with a name based on the text name. (One record may be aliased 178 to the other using a CNAME.) The numeric names are located at 179 RRTYPE.ARPA, and the text names are located at RRNAME.ARPA. 181 The first two strings in the TXT record are the identification tag 182 "RRTYPE=1" to identify the record as an RRTYPE definition, and a 183 language tag [RFC5646] that identifies the language in which the 184 descriptive text is written. Each line of the stanza is a string in 185 the TXT records. The leading spaces used in the file format 186 (described below) are not used. For example, if the FOO record type 187 were type 999, the two records for an English language description 188 would be: 190 999.RRTYPE.ARPA. TXT "RRTYPE=1" "EN" "FOO:999 Foo record" "I2:count Count" "..." 191 FOO.RRNAME.ARPA. TXT "RRTYPE=1" "EN" "FOO:999 Foo record" "I2:count Count" "..." 193 If there are descriptions in multiple languages, they are all stored 194 at the same name, and applications can choose the most suitable one. 196 999.RRTYPE.ARPA. TXT "RRTYPE=1" "EN" "FOO:999 Foo record" "I2:count Count" "..." 197 999.RRTYPE.ARPA. TXT "RRTYPE=1" "FR" "FOO:999 Dossier foo" "I2:count Compte" "..." 198 FOO.RRNAME.ARPA. TXT "RRTYPE=1" "EN" "FOO:999 Foo record" "I2:count Count" "..." 199 FOO.RRNAME.ARPA. TXT "RRTYPE=1" "FR" "FOO:999 Dossier foo" "I2:count Compte" "..." 201 3.3. Storage in a file 203 All the extension language stanzas stored in a file are stored as 204 lines of ASCII text. The name of the RR type starts in the first 205 position of the first line in the stanza. Subsequent lines in the 206 stanza start with white space. A line that is blank or where the 207 first nonblank character is a # is a comment and is ignored. 209 Descriptions in different languages are stored in separate files. 211 3.4. Stanza structure 213 Each stanza starts with a line containing the name of the RRTYPE, a 214 colon, and the numeric RRTYPE. The name of the RRTYPE must start in 215 the first position on the line. When stored in a file, the RRTYPE 216 name should not be the same as an existing RRTYPE or DNS class name 217 (IN or CH) or bad things will happen. 219 The RRTYPE may be followed a colon and letters, to indicate options 220 for the RRTYPE. The only currently used letter is "X" which means 221 that implementing the RRTYPE requires extra processing by DNS 222 servers, e.g., the extra processing for DNAME or DNSSEC records. The 223 intention of the option is to allow DNS servers to report an error if 224 a zone contains a record defined with "X" for which the server does 225 not implement the extra processing. 227 That can be followed by white space and a descriptive comment 228 intended to be displayed to human users, but not interpreted by DNS 229 software. Provisioning software might use the comments as prompts or 230 labels to help a user select the desired RRTYPE. 232 The rest of the lines in the stanza describe the fields in the 233 record. Each field is one or more octets long, and fields are stored 234 sequentially in the record: 236 FOO:999 Foo record 237 field description 238 field:tag description 239 field[qual,qual] description 240 field[qual,qual]:tag description 241 field ... 243 Some fields may be followed by a comma-separated list of qualifiers 244 in square brackets. The qualifiers further define the field, e.g., 245 in a numeric field, the qualifiers may define symbolic names for 246 field values or bit masks. That can be followed by an colon and an 247 ldh string. The string is intended to be used as the name of the 248 field in software applications that create data structures for an 249 RRTYPE. Applications will often have to change the punctuation to 250 match the syntax of the programming language, such as replacing 251 hyphens with underscores. If two fields in an RRTYPE have the same 252 name, the result is undefined. 254 The field and optional qualifiers and name may be followed by white 255 space and a description of the field. The description is intended to 256 be displayed to human users, and is not interpreted by DNS software. 257 Provisioning software might use the comments as prompts or labels for 258 templates into which users enter RR data. 260 3.5. Field types 262 Each field type is defined by a token name consisting of letters and 263 digits, starting with a letter. 265 3.5.1. Integer fields 267 Integer fields are defined by I1, I2, and I4 tokens, for fields one, 268 two, or four octets long. The corresponding value in a master record 269 is an unsigned integer number. A field may be followed by qualifiers 270 defining symbolic field values. 272 A symbolic field value is represented as NAME=NN where NAME is the 273 symbol and NN is the numeric value to be placed in the field. The 274 corresponding value in a master record is the symbol. The symbol can 275 contain letters, digits, and hypens. For example, to define the type 276 field in a CERT record [RFC4398]: 278 I2[PKIX=1,SPKI=2,PGP=2,IPKIX=4,ISPKI=5,IPGP=6,ACPKIX=7,\ 279 IACPKIX=8,URI=253,OID=254]:type Certificate type 281 RRTYPE fields are defined by R tokens, for a two octet field 282 containing an RRTYPE. The corresponding value in a master record is 283 a symbolic RRTYPE or TYPEnnn for types without names. A R[L] token 284 and qualifier defines a structured bitmap of RRTYPEs used in NSEC and 285 NSEC3 records, which must be the last field in the record. The 286 corresponding value in a master record is a list of RRTYPEs. 288 3.5.2. IP address and partial address fields 290 IP address fields are defined by A or AAAA tokens, for four-octet 291 IPv4 addresses or 16-octet IPv6 addresses. The corresponding value 292 in a master record is an IP address written in the usual way. There 293 are no qualifiers. 295 The AA token defines a 64 bit field written like half of an IPv6 296 address, with up to four colon separated groups of up to four hex 297 digits. 299 3.5.3. Domain name fields 301 Domain name fields are defined by N tokens. The qualifier C means 302 the name is compressed. The qualifier A means that the domain name 303 represents a mailbox, with the first component being the local part 304 of the mailbox. The qualifier L means that the domain name is 305 converted to lower case before DNSSEC validation. An N[O] tag and 306 qualifier, which can only appear as the last field in a record, means 307 the name is optional. 309 The corresponding value in a master record is a domain name, written 310 in the usual way, with \. meaning a literal dot in a record. 312 Names are absolute if they end with a dot, otherwise relative to 313 $ORIGIN, the convention for master files. 315 3.5.4. String fields 317 String fields are defined by S tokens. A plain S token means a 318 single string preceded by a one-octet length. A S[M] token and 319 qualifier means that there may be multiple strings, each stored as a 320 length and string in the record. A S[M] field must be the last field 321 in the record. 323 An S[X] token and qualifier is a raw string, stored without any 324 length bytes. It must be the last field in the record. 326 The corresponding value in a master record is a string enclosed in 327 single or double quotes, or multiple strings if the M qualifier is 328 present. Embedded quotes may be escaped with a backslash, and a 329 double backslash represents a backslash. If a non-null string 330 contains no white space, quote characters, or backslashes, the quotes 331 may be omitted. 333 3.5.5. Base-32 and Base-64 fields 335 A base32 or base64 field is defined by a B32 or B64 token. A base32 336 field is stored in the record with a preceding one-octet length. A 337 base64 field is stored as binary data must be the last field in the 338 record. 340 The corresponding value in a master record is a string represented as 341 base32 or base64 [RFC3548]. The value of a base64 field may include 342 embedded spaces for readability, which are ignored. 344 3.5.6. Hex fields 346 A hex field is defined by an X token. A plain X field is binary 347 data. An X[C] token and qualifier means that the field is stored in 348 the record as a string with a preceding one-octet length. An 349 unqualified hex field must be the last field in the record, and may 350 include embedded spaces for readability, which are ignored. 352 The corresponding value in a master record is a string represented as 353 an even number of hexadecimal digits. 355 EUI48 and EUI64 fields are defined by X6 and X8 tokens, respectively. 356 The corresponding fields in master records are six or eight pairs of 357 hex digits separated by hyphens. 359 3.5.7. Time stamp fields 361 A 32-bit timestamp field is defined by a T token. The corresponding 362 value in a master record is a fourteen digit value in the form 363 YYYYMMDDHHmmSS indicating a UTC timestamp, or as an unsigned number 364 of seconds with ten digits or less. The field is stored in the 365 record as a Unix timestamp, the unsigned number of seconds since 366 January 1, 1970 00:00:00 UTC. 368 3.5.8. Miscellaneous fields 370 Some RRTYPEs have fields with a unique syntax, represented as 371 qualifiers in a Z field. 373 Z[WKS] is the bitmap of port numbers in the WKS [RFC1035] RRTYPE. 375 Z[NSAP] is the special hex syntax for the address in the NSAP 376 [RFC1706] RRTYPE. 378 Z[NXT] is the bitmap of RRTYPES in the NXT [RFC2535] RRTYPE. 380 Z[A6P] and Z[A6S] are the prefix length and the variable length 381 address suffix in the A6 [RFC2874] RRTYPE. 383 Z[APL] is the list of address prefixes in the APL [RFC3123] RRTYPE. 385 Z[IPSECKEY] is the variable format gateway in the IPSECKEY [RFC4025] 386 RRTYPE. 388 Z[HIPHIT] and Z[HIPPK] are the hex HIT and base64 PK fields with 389 detached implicit lengths in the HIP [RFC5205] RRTYPE. 391 4. Examples 393 If a DNS server didn't already have support for MX records, they 394 could be defined as: 396 MX:15 Mail exchanger 397 I2:priority Priority (lower values are higher priority) 398 N[A,C]:exchanger Host name 400 The name is MX, the RRTYPE is 15, and the data includes a two-octet 401 number and a compressed domain name, with additional section records 402 for the domain name. 404 The SRV record [RFC2782] could be defined as: 406 SRV:33 Service location 407 I2:priority Priority 408 I2:weight Weight 409 I2:port Port 410 N:target Target host name 412 The name is SRV, the RRTYPE is 33. The record contains three two- 413 octet fields for the priority, weight, and port, and a domain name. 414 The domain name is not compressed. 416 5. Security considerations 418 The extension language makes it possible to create master files that 419 represent arbitrary DNS records. Since most DNS servers already 420 provide ways to represent arbitrary data, this doesn't introduce any 421 new security issues to the DNS and DNS servers, although it may 422 create security issues in provisioning software if the provisioning 423 system is intended to limit the kinds of records its users can 424 define. 426 Extension language files with accidentally or deliberately invalid 427 field definitions could provoke odd bugs in server or provisioning 428 software that doesn't check the syntax before using it. 430 When extension language data are imported from the DNS, a hostile 431 party might use DNS spoofing techniques to modify the records 432 imported. Methods to defend against DNS spoofing include DNSSEC. 434 6. IANA considerations 436 This document requests that IANA create the RRTYPE.ARPA and 437 RRNAME.ARPA zones. Their initial contents are as follows: [ list of 438 description of existing RRs here ] 440 When new RR types are defined, the defining documents SHOULD request 441 IANA to add appropriate records to RRTYPE.ARPA and RRNAME.ARPA. 443 This document requests that IANA create a registry of DNS Extension 444 Language Field Types. Its initial contents are as follows 446 +-------+-----------------+-----------------+ 447 | TYPE | REFERENCE | EXTLANG VERSION | 448 +-------+-----------------+-----------------+ 449 | I1 | (this document) | 1 | 450 | I2 | (this document) | 1 | 451 | I4 | (this document) | 1 | 452 | A | (this document) | 1 | 453 | AA | (this document) | 1 | 454 | AAAA | (this document) | 1 | 455 | N | (this document) | 1 | 456 | S | (this document) | 1 | 457 | B32 | (this document) | 1 | 458 | B64 | (this document) | 1 | 459 | X | (this document) | 1 | 460 | EUI48 | (this document) | 1 | 461 | EUI64 | (this document) | 1 | 462 | T | (this document) | 1 | 463 | Z | (this document) | 1 | 464 +-------+-----------------+-----------------+ 466 Table 1: DNS Extension Language Field Types Registry Initial Values 468 7. References 469 7.1. References - Normative 471 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 472 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 473 . 475 [RFC1035] Mockapetris, P., "Domain names - implementation and 476 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 477 November 1987, . 479 [RFC3548] Josefsson, S., Ed., "The Base16, Base32, and Base64 Data 480 Encodings", RFC 3548, DOI 10.17487/RFC3548, July 2003, 481 . 483 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 484 Specifications: ABNF", STD 68, RFC 5234, 485 DOI 10.17487/RFC5234, January 2008, 486 . 488 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 489 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 490 September 2009, . 492 7.2. References - Informative 494 [RFC1706] Manning, B. and R. Colella, "DNS NSAP Resource Records", 495 RFC 1706, DOI 10.17487/RFC1706, October 1994, 496 . 498 [RFC2535] Eastlake 3rd, D., "Domain Name System Security 499 Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999, 500 . 502 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 503 specifying the location of services (DNS SRV)", RFC 2782, 504 DOI 10.17487/RFC2782, February 2000, 505 . 507 [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support 508 IPv6 Address Aggregation and Renumbering", RFC 2874, 509 DOI 10.17487/RFC2874, July 2000, 510 . 512 [RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes 513 (APL RR)", RFC 3123, DOI 10.17487/RFC3123, June 2001, 514 . 516 [RFC4025] Richardson, M., "A Method for Storing IPsec Keying 517 Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March 518 2005, . 520 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 521 Rose, "DNS Security Introduction and Requirements", 522 RFC 4033, DOI 10.17487/RFC4033, March 2005, 523 . 525 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name 526 System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006, 527 . 529 [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol 530 (HIP) Domain Name System (DNS) Extensions", RFC 5205, 531 DOI 10.17487/RFC5205, April 2008, 532 . 534 Appendix A. Change Log 536 *NOTE TO RFC EDITOR: This section may be removed upon publication of 537 this document as an RFC.* 539 A.1. Changes from -08 to -09 541 Add Z fields for rrtype-specific fields. Redid qualifier 542 descriptions. 544 Add definitions of RRTYPEs. 546 A.2. Changes from -07 to -08 548 Add counted hex and raw strings and other new types. Added language 549 tags. Added field names. 551 A.3. Changes from -06 to -07 553 Add RRTYPE=1 tag in TXT records. 555 Allow digits and hyphens in qualifier tags, for names like SHA-1. 557 A.4. Changes from -05 to -06 559 Fix formatting problems. 561 Add RRTYPE option "X". 563 A.5. Changes from -04 to -05 565 DNS publication in RRYPE.ARPA and RRNAME.ARPA. 567 A.6. Changes from -03 to -04 569 More use cases. 571 Fix up BNF 573 A.7. Changes from -02 to -03 575 First stab at BNF 577 Note $ORIGIN matters 579 A.8. Changes from -01 to -02 581 Editorial nits 583 A.9. Changes from -00 to -01 585 Switch to multi-line format. Add comments for provisioning. 587 Appendix B. Descriptions of currently defined RRTYPEs 589 Here are descriptions of currently RRTYPEs that can appear in zone 590 files. The \ indicating continuation lines are only for display in 591 this document and would not appear in the descriptions. 593 A:1 a host address [RFC1035] 594 A:addr IPv4 address 596 NS:2 an authoritative name server [RFC1035] 597 N[C]:host Host name 599 MD:3 a mail destination (OBSOLETE - use MX) [RFC1035] 600 N[C]:host Host name 602 MF:4 a mail forwarder (OBSOLETE - use MX) [RFC1035] 603 N[C]:host Host name 605 CNAME:5 the canonical name for an alias [RFC1035] 606 N[C]:host Host name 608 SOA:6 marks the start of a zone of authority [RFC1035] 609 N[C]:primary Primary server name 610 N[A]:mailbox Responsible mailbox 611 I4:serial Serial number 612 I4:refresh Refresh time (seconds) 613 I4:retry Retry time (seconds) 614 I4:expire Expire time (seconds) 615 I4:minimum Minium time (seconds) 617 MB:7 a mailbox domain name (EXPERIMENTAL) [RFC1035] 618 N[C]:host Host name 620 MG:8 a mail group member (EXPERIMENTAL) [RFC1035] 621 N[A]:mailbox Mailbox name 623 MR:9 a mail rename domain name (EXPERIMENTAL) [RFC1035] 624 N[A]:mailbox Mailbox name 626 WKS:11 a well known service description [RFC1035] 627 A IPv4 address 628 I1 Protocol number 629 Z[WKS]:bitmap Bit Map 631 PTR:12 a domain name pointer [RFC1035] 632 N[C]:host Host name 634 HINFO:13 host information [RFC1035] 635 S:cpu CPU type 636 S:os Operating system 638 MINFO:14 mailbox or mail list information [RFC1035] 639 N[A]:respbox Responsible mailbox 640 N[A]:errbox Error mailbox 642 MX:15 mail exchange [RFC1035] 643 I2:priority Priority (lower values are higher priority) 644 N[C]:hostname Host name 646 TXT:16 text strings [RFC1035] 647 S[M]:text Strings 649 RP:17 for Responsible Person [RFC1183] 650 N[A]:mailbox Mailbox 651 N:text Text location 653 AFSDB:18 for AFS Data Base location [RFC1183][RFC5864] 654 I2:subtype Subtype 655 N:hostname Hostname 657 X25:19 for X.25 PSDN address [RFC1183] 658 S:address PSDN address 660 ISDN:20 for ISDN address [RFC1183] 661 S[M]:address ISDN address, and optional subaddress 663 RT:21 for Route Through [RFC1183] 664 I2:preference Preference 665 N:hostname Intermediate host 667 NSAP:22 for NSAP address, NSAP style A record [RFC1706] 668 Z[NSAP]:address NSAP Address 670 NSAP-PTR:23 for domain name pointer, NSAP style [RFC1348][RFC1637] 671 N:hostname Host name 673 SIG:24 for security signature [RFC4034] 674 I2:sigtype Type covered 675 I1:algorithm Algorithm 676 I1:labels Labels 677 I4:ttl Original TTL 678 T:expires Signature expiration time 679 T:signed Time signed 680 I2:footprint Key footprint 681 N[C]:name Signer's name 682 B64:signature Signature data 684 KEY:25 for security key [RFC4034] 685 I2:flags Flags 686 I1:protocol Protocol 687 I1:algorithm Algorithm 688 B64:data Key data 690 PX:26 X.400 mail mapping information [RFC2163] 691 I2:pref Preference 692 N:idomain Internet mail domain 693 N:xdomain X.400 mail domain 695 GPOS:27 Geographical Position [RFC1712] 696 S:longitude Longitude (decimal degrees) 697 S:latitude Latitude (decimal degrees) 698 S:altitude Altitude (meters) 700 AAAA:28 IP6 Address [RFC3596] 701 AAAA:address Address 703 LOC:29 Location Information [RFC1876] 704 I1:version Version 705 I1:sphere Sphere size 706 I2:hprecision Horiz precision 707 I2:vprecision Vert precision 708 I4:latitude Latitude (offset milliseconds) 709 I4:longitude Longitude (offset milliseconds) 710 I4:altitude Altitude (offset cm) 712 NXT:30 Next Domain (OBSOLETE) [RFC3755][RFC2535] 713 N[C]:next Domain 714 Z[NXT]:rrtypes Bitmap of rrtypes 716 SRV:33 Server Selection [1][RFC2782] 717 I2:priority Priority 718 I2:weight Weight 719 I2:port Port 720 N:target Target host name 722 NAPTR:35 Naming Authority Pointer [RFC2915][RFC2168][RFC3403] 723 I2:order Order 724 I2:pref Preference 725 S:flags Flags 726 S:services Services 727 S:regex Regular expression 728 N:replacement Replacement 730 KX:36 Key Exchanger [RFC2230] 731 I2:pref Preference 732 N:exchanger Exchanger 734 CERT:37 CERT [RFC4398] 735 I2[PKIX=1,SPKI=2,PGP=2,IPKIX=4,ISPKI=5,IPGP=6,ACPKIX=7,IACPKIX=8,\ 736 URI=253,OID=254]:type Type 737 I2:tag Key tag 738 I1[RSAMD5=1,DH=2,DSA=3,ECC=4,RSASHA1=5,INDIRECT=252,PRIVATEDNS=253,\ 739 PRIVATEOID=254]:algorithm Algorithm 740 B64:certificate Certificate or CRL 742 A6:38 A6 (OBSOLETE - use AAAA) [RFC3226][RFC2874][RFC6563] 743 Z[A6P]:preflen Prefix length 744 Z[A6S]:suffix Address suffix 745 N:prefname Prefix name 747 DNAME:39 DNAME [RFC6672] 748 N:source Source name 750 APL:42 APL [RFC3123] 751 Z[APL]:prefixes Prefixes 753 DS:43 Delegation Signer [RFC4034][RFC3658] 754 I2:keytag Key tag 755 I1[RSAMD5=1,DH=2,DSA=3,ECC=4,RSASHA1=5,DSA-NSEC-SHA1=6,\ 756 RSASHA1-NSEC3-SHA1=7,RSASHA256=8,RSASHA512=10,ECC-GOST=12,\ 757 ECDSAP256SHA256=13,ECDSAP384SHA384=14,INDIRECT=252,PRIVATEDNS=253,\ 758 PRIVATEOID=254]:algorithm Algorithm 759 I1[SHA-1=1,SHA-256=2,GOST=3,SHA-384=4]:digtype Digest type 760 X:digest Digest 762 SSHFP:44 SSH Key Fingerprint [RFC4255] 763 I1:algorithm Algorithm 764 I1:ftype Fingerprint type 765 X:fingerprint Fingerprint 767 IPSECKEY:45 IPSECKEY [RFC4025] 768 I1:prec Precedence 769 I1:gtype Gateway type 770 I1:algorithm Algorithm 771 Z[IPSECKEY]:gateway Gateway 772 B64:key Public key 774 RRSIG:46 RRSIG [RFC4034][RFC3755] 775 R:rrtype Type covered (Type mnemonic) 776 I1[RSAMD5=1,DH=2,DSA=3,ECC=4,RSASHA1=5,INDIRECT=252,PRIVATEDNS=253,\ 777 PRIVATEOID=254]:algorithm Algorithm 778 I1:labels Labels 779 I4:origttl Original TTL 780 T:expire Signature expiration (timestamp) 781 T:inception Signature inception (timestamp) 782 I2:keytag Key tag 783 N:signer Signer's name 784 B64:signature Signature 786 NSEC:47 NSEC [RFC4034][RFC3755] 787 N:next Next domain name 788 R[L]:types Type bitmaps (as window blocks) 790 DNSKEY:48 DNSKEY [RFC4034][RFC3755] 791 I2:flags Flags 792 I1:protocol Protocol (must be 3) 793 I1[RSAMD5=1,DH=2,DSA=3,ECC=4,RSASHA1=5,INDIRECT=252,PRIVATEDNS=253,\ 794 PRIVATEOID=254]:algorithm Algorithm 795 B64:publickey Public key 797 DHCID:49 DHCID [RFC4701] 798 B64:dhcpinfo DHCP information 800 NSEC3:50 NSEC3 [RFC5155] 801 I1[SHA-1=1]:algorithm Hash algorithm 802 I1[OPTOUT=1]:flags Flags 803 I2:iterations Iterations 804 X[C]:salt Salt 805 B32:next Next hashed owner 806 R[L]:types Type bitmaps (as window blocks) 808 NSEC3PARAM:51 NSEC3PARAM [RFC5155] 809 I1[SHA-1=1]:algorithm Hash algorithm 810 I1[OPTOUT=1]:flags Flags 811 I2:iterations Iterations 812 X[C]:salt Salt 814 TLSA:52 TLSA [RFC6698] 815 I1:usage Certificate usage 816 I1:selector Certificate selector 817 I1:mtype Matching Type 818 X:cert Certificate association data 820 SMIMEA:53 S/MIME cert association [draft-ietf-dane-smime] 821 I1:usage Certificate usage 822 I1:selector Certificate selector 823 I1:mtype Matching Type 824 X:cert Certificate association data 826 HIP:55 Host Identity Protocol [RFC-ietf-hip-rfc5205-bis-10] 827 I1:pkalg PK algorithm 828 Z[HIPHIT]:hit HIT 829 Z[HIPPK]:pubkey Public Key 830 N[O]:servers Rendezvous servers 832 CDS:59 Child DS [RFC7344] 833 I2:keytag Key tag 834 I1[RSAMD5=1,DH=2,DSA=3,ECC=4,RSASHA1=5,DSA-NSEC-SHA1=6,\ 835 RSASHA1-NSEC3-SHA1=7,RSASHA256=8,RSASHA512=10,ECC-GOST=12,\ 836 ECDSAP256SHA256=13,ECDSAP384SHA384=14,INDIRECT=252,\ 837 PRIVATEDNS=253,PRIVATEOID=254]:algorithm Algorithm 838 I1[SHA-1=1,SHA-256=2,GOST=3,SHA-384=4]:digtype Digest type 839 X:digest Digest 841 CDNSKEY:60 DNSKEY(s) the Child wants reflected in DS [RFC7344] 842 I2:flags Flags 843 I1:protocol Protocol (must be 3) 844 I1[RSAMD5=1,DH=2,DSA=3,ECC=4,RSASHA1=5,INDIRECT=252,PRIVATEDNS=253,\ 845 PRIVATEOID=254]:algorithm Algorithm 846 B64:publickey Public key 848 OPENPGPKEY:61 OpenPGP Key [RFC7929] 849 B64:key PGP key 851 CSYNC:62 Child-To-Parent Synchronization [RFC7477] 852 I4:serial SOA serial 853 I2:flags Flags 854 R[L]:Types 856 SPF:99 [RFC7208] 857 S[M]:text SPF data 859 NID:104 [RFC6742] 860 I2:preference Preference 861 AA:nodeid Node ID 863 L32:105 [RFC6742] 864 I2:preference Preference 865 A:locator Locator32 867 L64:106 [RFC6742] 868 I2:preference Preference 869 AA:locator Locator64 871 LP:107 [RFC6742] 872 I2:preference Preference 873 N:pointer Pointer 875 EUI48:108 an EUI-48 address [RFC7043] 876 X6:address Address (digit pairs separated by hyphens) 878 EUI64:109 an EUI-64 address [RFC7043] 879 X8:address Address (digit pairs separated by hyphens) 881 URI:256 URI [RFC7553] 882 I2:priority Priority 883 I2:weight Weight 884 S[X]:target Target 886 CAA:257 Certification Authority Restriction [RFC6844] 887 I1:flags Flags 888 S:tag Tag 889 S[X]:value Value 891 DLV:32769 DNSSEC Lookaside Validation [RFC4431] 892 I2:key Key tag 893 I1[RSAMD5=1,DH=2,DSA=3,ECC=4,RSASHA1=5,INDIRECT=252,PRIVATEDNS=253,\ 894 PRIVATEOID=254]:algorithm Algorithm 895 I1:type Digest type 896 X:digest Digest 898 Authors' Addresses 900 John Levine 901 Taughannock Networks 902 PO Box 727 903 Trumansburg, NY 14886 905 Phone: +1 831 480 2300 906 Email: standards@taugh.com 907 URI: http://jl.ly 909 Paul Vixie 910 950 Charter Street 911 Redwood City, CA 913 Email: vixie@fsi.io