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