1 Internet Engineering Task Force (IETF) D. Eastlake 3rd
2 Request for Comments: 6895 Huawei
3 BCP: 42 April 2013
4 Obsoletes: 6195
5 Updates: 1183, 2845, 2930, 3597
6 Category: Best Current Practice
7 ISSN: 2070-1721
8
9
10 Domain Name System (DNS) IANA Considerations
11
12 Abstract
13
14 This document specifies Internet Assigned Numbers Authority (IANA)
15 parameter assignment considerations for the allocation of Domain Name
16 System (DNS) resource record types, CLASSes, operation codes, error
17 codes, DNS protocol message header bits, and AFSDB resource record
18 subtypes. It obsoletes RFC 6195 and updates RFCs 1183, 2845, 2930,
19 and 3597.
20
21 Status of This Memo
22
23 This memo documents an Internet Best Current Practice.
24
25 This document is a product of the Internet Engineering Task Force
26 (IETF). It represents the consensus of the IETF community. It has
27 received public review and has been approved for publication by the
28 Internet Engineering Steering Group (IESG). Further information on
29 BCPs is available in Section 2 of RFC 5741.
30
31 Information about the current status of this document, any errata,
32 and how to provide feedback on it may be obtained at
33 http://www.rfc-editor.org/info/rfc6895.
34
35 Copyright Notice
36
37 Copyright (c) 2013 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
39
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (http://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
49
50
51
52 Eastlake Best Current Practice [Page 1]
53 RFC 6895 DNS IANA Considerations April 2013
54
55
56 Table of Contents
57
58 1. Introduction ....................................................2
59 1.1. Terminology ................................................3
60 2. DNS Query/Response Headers ......................................3
61 2.1. One Spare Bit? .............................................4
62 2.2. OpCode Assignment ..........................................4
63 2.3. RCODE Assignment ...........................................4
64 3. DNS Resource Records ............................................6
65 3.1. RRTYPE IANA Considerations .................................7
66 3.1.1. DNS RRTYPE Allocation Policy ........................8
67 3.1.2. DNS RRTYPE Expert Guidelines .......................10
68 3.1.3. Special Note on the OPT RR .........................10
69 3.1.4. The AFSDB RR Subtype Field .........................10
70 3.2. RR CLASS IANA Considerations ..............................11
71 3.3. Label Considerations ......................................13
72 3.3.1. Label Types ........................................13
73 3.3.2. Label Contents and Use .............................13
74 4. Security Considerations ........................................14
75 5. IANA Considerations ............................................14
76 Appendix A. RRTYPE Allocation Template ............................15
77 Appendix B. Changes from RFC 6195 .................................16
78 Normative References ..............................................17
79 Informative References ............................................18
80 Acknowledgements ..................................................19
81
82 1. Introduction
83
84 The Domain Name System (DNS) provides replicated distributed secure
85 hierarchical databases that store "resource records" (RRs) under
86 domain names. DNS data is structured into CLASSes and zones that can
87 be independently maintained. Familiarity with [RFC1034], [RFC1035],
88 [RFC2136], [RFC2181], and [RFC4033] is assumed.
89
90 This document provides, either directly or by reference, the general
91 IANA parameter assignment considerations that apply across DNS query
92 and response headers and all RRs. There may be additional IANA
93 considerations that apply to only a particular RRTYPE or
94 query/response OpCode. See the specific RFC defining that RRTYPE or
95 query/response OpCode for such considerations if they have been
96 defined, except for AFSDB RR considerations [RFC1183], which are
97 included herein. This RFC obsoletes [RFC6195]; however, the only
98 significant changes are those to the RRTYPE IANA allocation process,
99 aimed at streamlining it and clarifying the expected behavior of the
100 parties involved, and the closing of the AFSDB subtype registry.
101
102 IANA currently maintains a web page of DNS parameters available from
103 <http://www.iana.org>.
104
105
106
107 Eastlake Best Current Practice [Page 2]
108 RFC 6895 DNS IANA Considerations April 2013
109
110
111 1.1. Terminology
112
113 "Standards Action", "IETF Review", "Specification Required", and
114 "Private Use" are as defined in [RFC5226].
115
116 2. DNS Query/Response Headers
117
118 The header for DNS queries and responses contains field/bits in the
119 following diagram taken from [RFC2136]:
120
121 1 1 1 1 1 1
122 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
123 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
124 | ID |
125 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
126 |QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE |
127 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
128 | QDCOUNT/ZOCOUNT |
129 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
130 | ANCOUNT/PRCOUNT |
131 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
132 | NSCOUNT/UPCOUNT |
133 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
134 | ARCOUNT |
135 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
136
137 The ID field identifies the query and is echoed in the response so
138 they can be matched.
139
140 The QR bit indicates whether the header is for a query or a response.
141
142 The AA, TC, RD, RA, and CD bits are each theoretically meaningful
143 only in queries or only in responses, depending on the bit. The AD
144 bit was only meaningful in responses but is expected to have a
145 separate but related meaning in queries (see Section 5.7 of
146 [RFC6840]). Only the RD and CD bits are expected to be copied from
147 the query to the response; however, some DNS implementations copy all
148 the query header as the initial value of the response header. Thus,
149 any attempt to use a "query" bit with a different meaning in a
150 response or to define a query meaning for a "response" bit may be
151 dangerous, given the existing implementation. Meanings for these
152 bits may only be assigned by a Standards Action.
153
154 The unsigned integer fields query count (QDCOUNT), answer count
155 (ANCOUNT), authority count (NSCOUNT), and additional information
156 count (ARCOUNT) express the number of records in each section for all
157 OpCodes except Update [RFC2136]. These fields have the same
158
159
160
161
162 Eastlake Best Current Practice [Page 3]
163 RFC 6895 DNS IANA Considerations April 2013
164
165
166 structure and data type for Update but are instead the counts for the
167 zone (ZOCOUNT), prerequisite (PRCOUNT), update (UPCOUNT), and
168 additional information (ARCOUNT) sections.
169
170 2.1. One Spare Bit?
171
172 There have been ancient DNS implementations for which the Z bit being
173 on in a query meant that only a response from the primary server for
174 a zone is acceptable. It is believed that current DNS
175 implementations ignore this bit.
176
177 Assigning a meaning to the Z bit requires a Standards Action.
178
179 2.2. OpCode Assignment
180
181 Currently, DNS OpCodes are assigned as follows:
182
183 OpCode Name Reference
184
185 0 Query [RFC1035]
186 1 IQuery (Inverse Query, OBSOLETE) [RFC3425]
187 2 Status [RFC1035]
188 3 Unassigned
189 4 Notify [RFC1996]
190 5 Update [RFC2136]
191 6-15 Unassigned
192
193 Although the Status OpCode is reserved in [RFC1035], its behavior has
194 not been specified. New OpCode assignments require a Standards
195 Action with early allocation permitted as specified in [RFC4020].
196
197 2.3. RCODE Assignment
198
199 It would appear from the DNS header above that only four bits of
200 RCODE, or response/error code, are available. However, RCODEs can
201 appear not only at the top level of a DNS response but also inside
202 TSIG RRs [RFC2845], TKEY RRs [RFC2930], and extended by OPT RRs
203 [RFC6891]. The OPT RR provides an 8-bit extension to the 4 header
204 bits, resulting in a 12-bit RCODE field, and the TSIG and TKEY RRs
205 have a 16-bit field designated in their RFCs as the "Error" field.
206
207 Error codes appearing in the DNS header and in these other RR types
208 all refer to the same error code space with the exception of error
209 code 16, which has a different meaning in the OPT RR than in the TSIG
210 RR, and error code 9, whose variations are described after the table
211 below. The duplicate assignment of 16 was accidental. To the extent
212 that any prior RFCs imply any sort of different error number space
213 for the OPT, TSIG, or TKEY RRs, they are superseded by this unified
214
215
216
217 Eastlake Best Current Practice [Page 4]
218 RFC 6895 DNS IANA Considerations April 2013
219
220
221 DNS error number space. (This paragraph is the reason this document
222 updates [RFC2845] and [RFC2930].) With the existing exceptions of
223 error numbers 9 and 16, the same error number must not be assigned
224 for different errors even if they would only occur in different RR
225 types. See table below.
226
227 RCODE Name Description Reference
228 Decimal
229 Hexadecimal
230
231 0 NoError No Error [RFC1035]
232 1 FormErr Format Error [RFC1035]
233 2 ServFail Server Failure [RFC1035]
234 3 NXDomain Non-Existent Domain [RFC1035]
235 4 NotImp Not Implemented [RFC1035]
236 5 Refused Query Refused [RFC1035]
237 6 YXDomain Name Exists when it should not [RFC2136]
238 7 YXRRSet RR Set Exists when it should not [RFC2136]
239 8 NXRRSet RR Set that should exist does not [RFC2136]
240 9 NotAuth Server Not Authoritative for zone [RFC2136]
241 9 NotAuth Not Authorized [RFC2845]
242 10 NotZone Name not contained in zone [RFC2136]
243
244 11 - 15
245 0xB - 0xF Unassigned
246
247 16 BADVERS Bad OPT Version [RFC6891]
248 16 BADSIG TSIG Signature Failure [RFC2845]
249 17 BADKEY Key not recognized [RFC2845]
250 18 BADTIME Signature out of time window [RFC2845]
251 19 BADMODE Bad TKEY Mode [RFC2930]
252 20 BADNAME Duplicate key name [RFC2930]
253 21 BADALG Algorithm not supported [RFC2930]
254 22 BADTRUNC Bad Truncation [RFC4635]
255
256 23 - 3,840
257 0x0017 - 0x0F00 Unassigned
258
259 3,841 - 4,095
260 0x0F01 - 0x0FFF Reserved for Private Use
261
262 4,096 - 65,534
263 0x1000 - 0xFFFE Unassigned
264
265 65,535
266 0xFFFF Reserved; can only be allocated by Standards
267 Action.
268
269
270
271
272 Eastlake Best Current Practice [Page 5]
273 RFC 6895 DNS IANA Considerations April 2013
274
275
276 Note on error number 9 (NotAuth): This error number means either
277 "Not Authoritative" [RFC2136] or "Not Authorized" [RFC2845]. If 9
278 appears as the RCODE in the header of a DNS response without a
279 TSIG RR or with a TSIG RR having a zero error field, then it means
280 "Not Authoritative". If 9 appears as the RCODE in the header of a
281 DNS response that includes a TSIG RR with a non-zero error field,
282 then it means "Not Authorized".
283
284 Since it is important that RCODEs be understood for interoperability,
285 assignment of a new RCODE in the ranges listed above as "Unassigned"
286 requires an IETF Review.
287
288 3. DNS Resource Records
289
290 All RRs have the same top-level format, shown in the figure below
291 taken from [RFC1035].
292
293 1 1 1 1 1 1
294 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
295 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
296 | |
297 / /
298 / NAME /
299 / /
300 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
301 | TYPE |
302 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
303 | CLASS |
304 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
305 | TTL |
306 | |
307 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
308 | RDLENGTH |
309 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
310 / RDATA /
311 / /
312 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
313
314 NAME is an owner name, i.e., the name of the node to which this
315 resource record pertains. NAMEs are specific to a CLASS as described
316 in Section 3.2. NAMEs consist of an ordered sequence of one or more
317 labels, each of which has a label type [RFC1035] [RFC6891].
318
319 TYPE is a 2-octet unsigned integer containing one of the RRTYPE
320 codes. See Section 3.1.
321
322 CLASS is a 2-octet unsigned integer containing one of the RR CLASS
323 codes. See Section 3.2.
324
325
326
327 Eastlake Best Current Practice [Page 6]
328 RFC 6895 DNS IANA Considerations April 2013
329
330
331 TTL is a 4-octet (32-bit) unsigned integer that specifies, for data
332 TYPEs, the number of seconds that the resource record may be cached
333 before the source of the information should again be consulted. Zero
334 is interpreted to mean that the RR can only be used for the
335 transaction in progress.
336
337 RDLENGTH is an unsigned 16-bit integer that specifies the length in
338 octets of the RDATA field.
339
340 RDATA is a variable-length string of octets that constitutes the
341 resource. The format of this information varies according to the
342 TYPE and, in some cases, the CLASS of the resource record.
343
344 3.1. RRTYPE IANA Considerations
345
346 There are three subcategories of RRTYPE numbers: data TYPEs, QTYPEs,
347 and Meta-TYPEs.
348
349 Data TYPEs are the means of storing data. QTYPES can only be used in
350 queries. Meta-TYPEs designate transient data associated with a
351 particular DNS message and, in some cases, can also be used in
352 queries. Thus far, data TYPEs have been assigned from 1 upward, plus
353 the block from 100 through 103, and from 32,768 upward, while Q and
354 Meta-TYPEs have been assigned from 255 downward except for the OPT
355 Meta-RR, which is assigned TYPE 41. There have been DNS
356 implementations that made caching decisions based on the top bit of
357 the bottom byte of the RRTYPE.
358
359 There are currently three Meta-TYPEs assigned: OPT [RFC6891], TSIG
360 [RFC2845], and TKEY [RFC2930]. There are currently five QTYPEs
361 assigned: * (ALL/ANY), MAILA, MAILB, AXFR, and IXFR.
362
363 Allocated RRTYPEs have mnemonics that must be completely disjoint
364 from the mnemonics used for CLASSes and that must match the regular
365 expression below. In addition, the generic CLASS and RRTYPE names
366 specified in Section 5 of [RFC3597] cannot be assigned as new RRTYPE
367 mnemonics.
368
369 [A-Z][A-Z0-9\-]*[A-Z0-9]
370 but not
371 (TYPE|CLASS)[0-9]*
372
373
374
375
376
377
378
379
380
381
382 Eastlake Best Current Practice [Page 7]
383 RFC 6895 DNS IANA Considerations April 2013
384
385
386 Considerations for the allocation of new RRTYPEs are as follows:
387
388 Decimal
389 Hexadecimal Assignment Policy
390
391 0
392 0x0000 RRTYPE zero is used as a special indicator for the
393 SIG(0) RR [RFC2931] [RFC4034] and in other
394 circumstances and must never be allocated for
395 ordinary use.
396
397 1 - 127
398 0x0001 - 0x007F Remaining RRTYPEs in this range are assigned for
399 data TYPEs by the DNS RRTYPE Allocation Policy as
400 specified in Section 3.1.1.
401
402 128 - 255
403 0x0080 - 0x00FF Remaining RRTYPEs in this range are assigned for Q
404 and Meta-TYPEs by the DNS RRTYPE Allocation Policy
405 as specified in Section 3.1.1.
406
407 256 - 61,439
408 0x0100 - 0xEFFF Remaining RRTYPEs in this range are assigned for
409 data RRTYPEs by the DNS RRTYPE Allocation Policy
410 as specified in Section 3.1.1. (32,768 and 32,769
411 (0x8000 and 0x8001) have been assigned.)
412
413 61,440 - 65,279
414 0xF000 - 0xFEFF Reserved for future use. IETF Review required to
415 define use.
416
417 65,280 - 65,534
418 0xFF00 - 0xFFFE Reserved for Private Use.
419
420 65,535
421 0xFFFF Reserved (Standards Action)
422
423 3.1.1. DNS RRTYPE Allocation Policy
424
425 Parameter values specified in Section 3.1 above, as assigned based on
426 DNS RRTYPE Allocation Policy, are allocated by Expert Review if they
427 meet the two requirements listed below. There will be a pool of a
428 small number of Experts appointed by the IESG. Each application will
429 be judged by an Expert selected by IANA. In any case where the
430 selected Expert is unavailable or states they have a conflict of
431 interest, IANA may select another Expert from the pool. Some
432 guidelines for the Experts are given in Section 3.1.2.
433
434
435
436
437 Eastlake Best Current Practice [Page 8]
438 RFC 6895 DNS IANA Considerations April 2013
439
440
441 RRTYPEs that do not meet the requirements below may nonetheless be
442 allocated by a Standards Action with early allocation permitted as
443 specified in [RFC4020].
444
445 1. A complete template as specified in Appendix A has been posted to
446 the dns-rrtype-applications@ietf.org mailing list and received by
447 the Expert.
448
449 Note that the posting of partially completed, draft, or formally
450 submitted templates to dnsext@ietf.org by the applicant or Expert
451 for comment and discussion is highly encouraged. Before formal
452 submission of an RRTYPE template, we recommend submitting it for
453 community review and considering the responses in order to reduce
454 the probability of initial rejection and the need for modification
455 and resubmission.
456
457 2. The RR for which an RRTYPE code is being requested is either (a) a
458 data TYPE that can be handled as an Unknown RR as described in
459 [RFC3597] or (b) a Meta-TYPE whose processing is optional, i.e.,
460 it is safe to simply discard RRs with that Meta-TYPE in queries or
461 responses.
462
463 Note that such RRs may include additional section processing,
464 provided such processing is optional.
465
466 After the applicant submits their formal application to IANA by
467 sending the completed template specified in Appendix A to the
468 dns-rrtype-applications@ietf.org mailing list, IANA appoints an
469 Expert and sends the completed template to the Expert, copying the
470 applicant. No more than two weeks after receiving the application,
471 the Expert shall explicitly approve or reject the application,
472 informing IANA, the applicant, and the dnsext@ietf.org mailing list.
473 A rejection should include the reason for rejection and may include
474 suggestions for improvement. The Expert should consult with other
475 technical experts and the dnsext@ietf.org mailing list as necessary.
476 If the Expert does not approve the application within this period, it
477 is considered rejected. IANA should report non-responsive Experts to
478 the IESG.
479
480 IANA shall maintain a public archive of approved templates. In
481 addition, if the required description of the RRTYPE applied for is
482 referenced by URL, a copy of the document so referenced should be
483 included in the archive.
484
485
486
487
488
489
490
491
492 Eastlake Best Current Practice [Page 9]
493 RFC 6895 DNS IANA Considerations April 2013
494
495
496 3.1.2. DNS RRTYPE Expert Guidelines
497
498 The Designated Expert should normally be lenient, preferring to
499 approve most requests. However, the Expert should usually reject any
500 RRTYPE allocation request that meets one or more of the following
501 criteria:
502
503 1. The request was documented in a manner that was not sufficiently
504 clear or complete to evaluate or implement. (Additional
505 documentation can be provided during the Expert Review period.)
506
507 2. The proposed RRTYPE or RRTYPEs affect DNS processing and do not
508 meet the criteria in point 2 of Section 3.1.1 above.
509
510 3. Application use as documented makes incorrect assumptions about
511 DNS protocol behavior, such as wildcards, CNAME, DNAME, etc.
512
513 4. An excessive number of RRTYPE values is being requested when the
514 purpose could be met with a smaller number of values or with
515 Private Use values.
516
517 3.1.3. Special Note on the OPT RR
518
519 The OPT (OPTion) RR (RRTYPE 41) and its IANA considerations are
520 specified in [RFC6891]. Its primary purpose is to extend the
521 effective field size of various DNS fields, including RCODE, label
522 type, OpCode, flag bits, and RDATA size. In particular, for
523 resolvers and servers that recognize it, it extends the RCODE field
524 from 4 to 12 bits.
525
526 3.1.4. The AFSDB RR Subtype Field
527
528 The AFSDB RR [RFC1183] is a CLASS-insensitive RR that has the same
529 RDATA field structure as the MX RR [RFC1035], but the 16-bit unsigned
530 integer field at the beginning of the RDATA is interpreted as a
531 subtype as shown below. Use of the AFSDB RR to locate AFS cell
532 database servers was deprecated by [RFC5864]. This subtype registry
533 is hereby closed, and allocation of new subtypes is no longer
534 permitted.
535
536
537
538
539
540
541
542
543
544
545
546
547 Eastlake Best Current Practice [Page 10]
548 RFC 6895 DNS IANA Considerations April 2013
549
550
551 Decimal
552 Hexadecimal Assignment Policy
553
554 0
555 0x0000 Reserved; registry closed
556
557 1
558 0x0001 AFS v3.0 Location Service [RFC1183]
559
560 2
561 0x0002 DCE/NCA root cell directory node [RFC1183]
562
563 3 - 65,279
564 0x0003 - 0xFEFF Not allocated; registry closed
565
566 65,280 - 65,534
567 0xFF00 - 0xFFFE Private Use
568
569 65,535
570 0xFFFF Reserved; registry closed
571
572 3.2. RR CLASS IANA Considerations
573
574 There are currently two subcategories of DNS CLASSes: normal, data-
575 containing classes; and QCLASSes that are only meaningful in queries
576 or updates.
577
578 DNS CLASSes have been little used but constitute another dimension of
579 the DNS distributed database. In particular, there is no necessary
580 relationship between the namespace or root servers for one data CLASS
581 and those for another data CLASS. The same DNS NAME can have
582 completely different meanings in different CLASSes. The label types
583 are the same, and the null label is usable only as root in every
584 CLASS. As global networking and DNS have evolved, the IN, or
585 Internet, CLASS has dominated DNS use.
586
587 As yet, there has not been a requirement for "Meta-CLASSes". That
588 would be a CLASS to designate transient data associated with a
589 particular DNS message, which might be usable in queries. However,
590 it is possible that there might be a future requirement for one or
591 more "Meta-CLASSes".
592
593 Assigned CLASSes have mnemonics that must be completely disjoint from
594 the mnemonics used for RRTYPEs and that must match the regular
595 expression below. In addition, the generic CLASS and RRTYPE names
596 specified in Section 5 of [RFC3597] cannot be assigned as new CLASS
597 mnemonics.
598
599
600
601
602 Eastlake Best Current Practice [Page 11]
603 RFC 6895 DNS IANA Considerations April 2013
604
605
606 [A-Z][A-Z0-9\-]*[A-Z0-9]
607 but not
608 (CLASS|TYPE)[0-9]*
609
610 The current CLASS assignments and considerations for future
611 assignments are as follows:
612
613 Decimal
614 Hexadecimal Assignment / Policy, Reference
615
616 0
617 0x0000 Reserved; assignment requires a Standards Action.
618
619 1
620 0x0001 Internet (IN) [RFC1035]
621
622 2
623 0x0002 Available for assignment by IETF Review as a data
624 CLASS.
625
626 3
627 0x0003 Chaos (CH) [Moon1981]
628
629 4
630 0x0004 Hesiod (HS) [Dyer1987]
631
632 5 - 127
633 0x0005 - 0x007F Available for assignment by IETF Review for data
634 CLASSes only.
635
636 128 - 253
637 0x0080 - 0x00FD Available for assignment by IETF Review for
638 QCLASSes and Meta-CLASSes only.
639
640 254
641 0x00FE QCLASS NONE [RFC2136]
642
643 255
644 0x00FF QCLASS * (ANY) [RFC1035]
645
646 256 - 32,767
647 0x0100 - 0x7FFF Available for assignment by IETF Review.
648
649 32,768 - 57,343
650 0x8000 - 0xDFFF Available for assignment to data CLASSes only;
651 Specification Required.
652
653
654
655
656
657 Eastlake Best Current Practice [Page 12]
658 RFC 6895 DNS IANA Considerations April 2013
659
660
661 57,344 - 65,279
662 0xE000 - 0xFEFF Available for assignment to QCLASSes and
663 Meta-CLASSes only; Specification Required.
664
665 65,280 - 65,534
666 0xFF00 - 0xFFFE Private Use
667
668 65,535
669 0xFFFF Reserved; can only be assigned by a Standards
670 Action.
671
672 3.3. Label Considerations
673
674 DNS NAMEs are sequences of labels [RFC1035].
675
676 3.3.1. Label Types
677
678 At the present time, there are two categories of label types: data
679 labels and compression labels. Compression labels are pointers to
680 data labels elsewhere within an RR or DNS message and are intended to
681 shorten the wire encoding of NAMEs.
682
683 The two existing data label types are sometimes referred to as Text
684 and Binary. Text labels can, in fact, include any octet value
685 including zero-value octets, but many current uses involve only
686 printing ASCII characters [US-ASCII]. For retrieval, Text labels are
687 defined to treat ASCII uppercase and lowercase letter codes as
688 matching [RFC4343]. Binary labels are bit sequences [RFC2673]. The
689 Binary Label type is Historic [RFC6891].
690
691 3.3.2. Label Contents and Use
692
693 The last label in each NAME is "ROOT", which is the zero-length
694 label. By definition, the null or ROOT label cannot be used for any
695 other NAME purpose.
696
697 NAMEs are local to a CLASS. The Hesiod [Dyer1987] and Chaos
698 [Moon1981] CLASSes are for essentially local use. The IN, or
699 Internet, CLASS is thus the only DNS CLASS in global use on the
700 Internet at this time.
701
702 A somewhat out-of-date description of name allocation in the IN CLASS
703 is given in [RFC1591]. Some information on reserved top-level domain
704 names is in BCP 32 [RFC2606].
705
706
707
708
709
710
711
712 Eastlake Best Current Practice [Page 13]
713 RFC 6895 DNS IANA Considerations April 2013
714
715
716 4. Security Considerations
717
718 This document addresses IANA considerations in the allocation of
719 general DNS parameters, not security. See [RFC4033], [RFC4034], and
720 [RFC4035] for secure DNS considerations.
721
722 5. IANA Considerations
723
724 This document consists entirely of DNS IANA considerations.
725
726 IANA has established a process for accepting Appendix A templates and
727 selecting an Expert from those appointed to review such template form
728 applications. IANA forwards the template to the Expert, copying the
729 applicant. IANA archives and makes available all approved RRTYPE
730 allocation templates and referred documentation (unless it is readily
731 available at a stable URI). It is the duty of the applicant to post
732 the formal application template to the
733 dns-rrtype-applications@ietf.org mailing list, which IANA will
734 monitor. The dnsext@ietf.org mailing list is for community
735 discussion and comment. See Section 3.1 and Appendix A for more
736 details.
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767 Eastlake Best Current Practice [Page 14]
768 RFC 6895 DNS IANA Considerations April 2013
769
770
771 Appendix A. RRTYPE Allocation Template
772
773 DNS RRTYPE PARAMETER ALLOCATION TEMPLATE
774
775 When ready for formal consideration, this template is to be submitted
776 to IANA for processing by emailing the template to dns-rrtype-
777 applications@ietf.org.
778
779 A. Submission Date:
780
781 B.1 Submission Type: [ ] New RRTYPE [ ] Modification to RRTYPE
782 B.2 Kind of RR: [ ] Data RR [ ] Meta-RR
783
784 C. Contact Information for submitter (will be publicly posted):
785 Name: Email Address:
786 International telephone number:
787 Other contact handles:
788
789 D. Motivation for the new RRTYPE application.
790 Please keep this part at a high level to inform the Expert and
791 reviewers about uses of the RRTYPE. Most reviewers will be DNS
792 experts that may have limited knowledge of your application space.
793
794 E. Description of the proposed RR type.
795 This description can be provided in-line in the template, as an
796 attachment, or with a publicly available URL.
797
798 F. What existing RRTYPE or RRTYPEs come closest to filling that need
799 and why are they unsatisfactory?
800
801 G. What mnemonic is requested for the new RRTYPE (optional)?
802
803 Note: If a mnemonic is not supplied, not allowed, or duplicates an
804 existing RRTYPE or CLASS mnemonic, the Expert will assign a
805 mnemonic.
806
807 H. Does the requested RRTYPE make use of any existing IANA registry
808 or require the creation of a new IANA subregistry in DNS
809 Parameters? If so, please indicate which registry is to be used
810 or created. If a new subregistry is needed, specify the
811 allocation policy for it and its initial contents. Also include
812 what the modification procedures will be.
813
814 I. Does the proposal require/expect any changes in DNS
815 servers/resolvers that prevent the new type from being processed
816 as an unknown RRTYPE (see [RFC3597])?
817
818 J. Comments:
819
820
821
822 Eastlake Best Current Practice [Page 15]
823 RFC 6895 DNS IANA Considerations April 2013
824
825
826 Appendix B. Changes from RFC 6195
827
828 Dropped description of changes from RFC 5395 to [RFC6195], since
829 those changes have already happened and we don't need to do them
830 again. Added description of changes from [RFC6195] to this document.
831
832 Cut back RRTYPE Expert Review period to two weeks and eliminated the
833 mandatory dnsext@ietf.org comment period. Changed workflow
834 description for RRTYPE review and allocation to correspond more
835 closely to actual practice.
836
837 Closed the AFSDB subtype registry and added an informative reference
838 to [RFC5864] where the use of the AFSDB RR to locate AFS cell
839 database servers is deprecated.
840
841 Clarified IANA archiving of referenced documentation as well as
842 approved RRTYPE application template.
843
844 In the RRTYPE application template, changed the label of question "B"
845 to "B.1" and added "B.2" to ask about the kind of RR.
846
847 Added text and an exclusory regular expression to Sections 3.1 and
848 3.2 to prohibit the use of a slight generalization of the generic
849 CLASS and RRTYPE names specified in [RFC3597] as the mnemonics for
850 new CLASSes and RRTYPEs.
851
852 Parenthetically listed "ANY" as well as "ALL" as a meaning for the
853 "*" RRTYPE.
854
855 Clarified that there is one DNS error number space for headers, OPT
856 extended headers, TSIG RRs, and TKEY RRs. Noted that this is
857 considered to update [RFC2845] and [RFC2930]. Noted the overloading
858 of error number 9 as well as 16.
859
860 Updated references for revised versions.
861
862 Incorporated a number of editorial changes and typo fixes.
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877 Eastlake Best Current Practice [Page 16]
878 RFC 6895 DNS IANA Considerations April 2013
879
880
881 Normative References
882
883 [RFC1034] Mockapetris, P., "Domain names - concepts and
884 facilities", STD 13, RFC 1034, November 1987.
885
886 [RFC1035] Mockapetris, P., "Domain names - implementation and
887 specification", STD 13, RFC 1035, November 1987.
888
889 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
890 Changes (DNS NOTIFY)", RFC 1996, August 1996.
891
892 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
893 "Dynamic Updates in the Domain Name System (DNS UPDATE)",
894 RFC 2136, April 1997.
895
896 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
897 Specification", RFC 2181, July 1997.
898
899 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
900 Wellington, "Secret Key Transaction Authentication for
901 DNS (TSIG)", RFC 2845, May 2000.
902
903 [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
904 RR)", RFC 2930, September 2000.
905
906 [RFC3425] Lawrence, D., "Obsoleting IQUERY", RFC 3425,
907 November 2002.
908
909 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
910 (RR) Types", RFC 3597, September 2003.
911
912 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
913 Standards Track Code Points", BCP 100, RFC 4020,
914 February 2005.
915
916 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
917 Rose, "DNS Security Introduction and Requirements",
918 RFC 4033, March 2005.
919
920 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
921 Rose, "Resource Records for the DNS Security Extensions",
922 RFC 4034, March 2005.
923
924 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
925 Rose, "Protocol Modifications for the DNS Security
926 Extensions", RFC 4035, March 2005.
927
928
929
930
931
932 Eastlake Best Current Practice [Page 17]
933 RFC 6895 DNS IANA Considerations April 2013
934
935
936 [RFC4635] Eastlake 3rd, D., "HMAC SHA (Hashed Message
937 Authentication Code, Secure Hash Algorithm) TSIG
938 Algorithm Identifiers", RFC 4635, August 2006.
939
940 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
941 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
942 May 2008.
943
944 [RFC6840] Weiler, S., Ed., and D. Blacka, Ed., "Clarifications and
945 Implementation Notes for DNS Security (DNSSEC)",
946 RFC 6840, February 2013.
947
948 [RFC6891] Damas, J., Graff, M., and Vixie, P., "Extension
949 Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, April
950 2013.
951
952 [US-ASCII] American National Standards Institute (formerly United
953 States of America Standards Institute), "USA Code for
954 Information Interchange", ANSI X3.4-1968, 1968.
955
956 ANSI X3.4-1968 has been replaced by newer versions with
957 slight modifications, but the 1968 version remains
958 definitive for the Internet.
959
960 Informative References
961
962 [Dyer1987] Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
963 Plan - Name Service, April 1987.
964
965 [Moon1981] Moon, D., "Chaosnet", A.I. Memo 628, Massachusetts
966 Institute of Technology Artificial Intelligence
967 Laboratory, June 1981.
968
969 [RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P.
970 Mockapetris, "New DNS RR Definitions", RFC 1183,
971 October 1990.
972
973 [RFC1591] Postel, J., "Domain Name System Structure and
974 Delegation", RFC 1591, March 1994.
975
976 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
977 Names", BCP 32, RFC 2606, June 1999.
978
979 [RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
980 RFC 2673, August 1999.
981
982 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
983 ( SIG(0)s )", RFC 2931, September 2000.
984
985
986
987 Eastlake Best Current Practice [Page 18]
988 RFC 6895 DNS IANA Considerations April 2013
989
990
991 [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case
992 Insensitivity Clarification", RFC 4343, January 2006.
993
994 [RFC5864] Allbery, R., "DNS SRV Resource Records for AFS",
995 RFC 5864, April 2010.
996
997 [RFC6195] Eastlake 3rd, D., "Domain Name System (DNS) IANA
998 Considerations", RFC 6195, March 2011.
999
1000 Acknowledgements
1001
1002 Alfred Hoenes' contributions are gratefully acknowledged as are those
1003 by Mark Andrews, Dick Franks, and Michael Sheldon.
1004
1005 Author's Address
1006
1007 Donald E. Eastlake 3rd
1008 Huawei Technologies
1009 155 Beaver Street
1010 Milford, MA 01757
1011 USA
1012
1013 Phone: +1-508-333-2270
1014 EMail: d3e3e3@gmail.com
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042 Eastlake Best Current Practice [Page 19]
1043
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.