1 Internet Engineering Task Force (IETF) D. Crocker
2 Request for Comments: 8552 Brandenburg InternetWorking
3 BCP: 222 March 2019
4 Category: Best Current Practice
5 ISSN: 2070-1721
6
7
8 Scoped Interpretation of DNS Resource Records through
9 "Underscored" Naming of Attribute Leaves
10
11 Abstract
12
13 Formally, any DNS Resource Record (RR) may occur under any domain
14 name. However, some services use an operational convention for
15 defining specific interpretations of an RRset by locating the records
16 in a DNS branch under the parent domain to which the RRset actually
17 applies. The top of this subordinate branch is defined by a naming
18 convention that uses a reserved node name, which begins with the
19 underscore character (e.g., "_name"). The underscored naming
20 construct defines a semantic scope for DNS record types that are
21 associated with the parent domain above the underscored branch. This
22 specification explores the nature of this DNS usage and defines the
23 "Underscored and Globally Scoped DNS Node Names" registry with IANA.
24 The purpose of this registry is to avoid collisions resulting from
25 the use of the same underscored name for different services.
26
27 Status of This Memo
28
29 This memo documents an Internet Best Current Practice.
30
31 This document is a product of the Internet Engineering Task Force
32 (IETF). It represents the consensus of the IETF community. It has
33 received public review and has been approved for publication by the
34 Internet Engineering Steering Group (IESG). Further information on
35 BCPs is available in Section 2 of RFC 7841.
36
37 Information about the current status of this document, any errata,
38 and how to provide feedback on it may be obtained at
39 https://www.rfc-editor.org/info/rfc8552.
40
41
42
43
44
45
46
47
48
49
50
51
52 Crocker Best Current Practice [Page 1]
53 RFC 8552 DNS AttrLeaf March 2019
54
55
56 Copyright Notice
57
58 Copyright (c) 2019 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (https://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 Table of Contents
72
73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
74 1.1. Underscore-Based Scoping . . . . . . . . . . . . . . . . 3
75 1.2. Scaling Benefits . . . . . . . . . . . . . . . . . . . . 4
76 1.3. Global Underscored Node Names . . . . . . . . . . . . . . 4
77 1.4. Interaction with DNS Wildcards . . . . . . . . . . . . . 5
78 1.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 5
79 2. "Underscored and Globally Scoped DNS Node Names" Registry . . 6
80 3. Guidance for Registering RRset Use . . . . . . . . . . . . . 7
81 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
82 4.1. "Underscored and Globally Scoped DNS Node Names" Registry 8
83 4.2. Enumservices Registrations Registry . . . . . . . . . . . 11
84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
85 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
86 6.1. Normative References . . . . . . . . . . . . . . . . . . 12
87 6.2. Informative References . . . . . . . . . . . . . . . . . 15
88 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
90
91 1. Introduction
92
93 The core Domain Name System (DNS) technical specifications ([RFC1035]
94 and [RFC2181]) assign no semantics to domain names or their parts,
95 and no constraints upon which resource record (RR) types are
96 permitted to be stored under particular names [RFC1035] [RFC2181].
97 Over time, some leaf node names, such as "www" and "ftp", have come
98 to imply support for particular services, but this is a matter of
99 operational convention rather than defined protocol semantics. This
100 freedom in the basic technology has permitted a wide range of
101 administrative and semantic policies to be used -- in parallel. DNS
102 data semantics have been limited to the specification of particular
103 resource record types on the expectation that new resource record
104
105
106
107 Crocker Best Current Practice [Page 2]
108 RFC 8552 DNS AttrLeaf March 2019
109
110
111 types would be added as needed. Unfortunately, the addition of new
112 resource record types has proven extremely challenging, with
113 significant adoption and use barriers occurring over the life of the
114 DNS.
115
116 1.1. Underscore-Based Scoping
117
118 As an alternative to defining a new RR TYPE, some DNS service
119 enhancements call for using an existing resource record type but
120 specifying a restricted scope for its occurrence. Scope is meant as
121 a static property, not one dependent on the nature of the query. It
122 is an artifact of the DNS name. That scope is a leaf node containing
123 the specific resource record sets that are formally defined and
124 constrained. Specifically:
125
126 The leaf occurs in a branch having a distinguished naming
127 convention: there is a parent domain name to which the scoped data
128 applies. The branch is under this name. The sub-branch is
129 indicated by a sequence of one or more reserved DNS node names; at
130 least the first (highest) of these names begins with an underscore
131 (e.g., "_name").
132
133 Because the DNS rules for a "host" (host name) do not allow use of
134 the underscore character, the underscored name is distinguishable
135 from all legal host names [RFC0952]. Effectively, this convention
136 for naming leaf nodes creates a space for the listing of "attributes"
137 -- in the form of resource record types -- that are associated with
138 the parent domain above the underscored sub-branch.
139
140 The scoping feature is particularly useful when generalized resource
141 record types are used -- notably "TXT", "SRV", and "URI" [RFC1035]
142 [RFC2782] [RFC6335] [RFC7553]. It provides efficient separation of
143 one use of them from others. Absent this separation, an
144 undifferentiated mass of these RRsets is returned to the DNS client,
145 which then must parse through the internals of the records in the
146 hope of finding ones that are relevant. Worse, in some cases, the
147 results are ambiguous because a record type might not adequately
148 self-identify its specific purpose. With underscore-based scoping,
149 only the relevant RRsets are returned.
150
151 A simple example is DomainKeys Identified Mail (DKIM) [RFC6376],
152 which uses "_domainkey" to define a place to hold a TXT record
153 containing signing information for the parent domain.
154
155 This specification formally defines how underscored names are used as
156 "attribute" enhancements for their parent domain names. For example,
157 the domain name "_domainkey.example." acts as an attribute of the
158 parent domain name "example.". To avoid collisions resulting from
159
160
161
162 Crocker Best Current Practice [Page 3]
163 RFC 8552 DNS AttrLeaf March 2019
164
165
166 the use of the same underscored names for different applications
167 using the same resource record type, this document establishes the
168 "Underscored and Globally Scoped DNS Node Names" registry with IANA.
169 Use of such node names, which begin with an underscore character, is
170 reserved when they are the underscored name closest to the DNS root;
171 as in that case, they are considered "global". Underscored names
172 that are farther down the hierarchy are handled within the scope of
173 the global underscored node name.
174
175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
177 "OPTIONAL" in this document are to be interpreted as described in
178 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
179 capitals, as shown here.
180
181 1.2. Scaling Benefits
182
183 Some resource record types are used in a fashion that can create
184 scaling problems if an entire RRset associated with a domain name is
185 aggregated in the leaf node for that name. An increasingly popular
186 approach, with excellent scaling properties, places the RRset under a
187 specially named branch, which is in turn under the node name that
188 would otherwise contain the RRset. The rules for naming that branch
189 define the context for interpreting the RRset. That is, rather than:
190
191 domain-name.example
192 /
193 RRset
194
195 the arrangement is:
196
197 _branch.domain-name.example
198 /
199 RRset
200
201 A direct lookup to the subordinate leaf node produces only the
202 desired record types, at no greater cost than a typical DNS lookup.
203
204 1.3. Global Underscored Node Names
205
206 As defined in [RFC1034], the DNS uses names organized in a tree-
207 structured or hierarchical fashion. A domain name might have
208 multiple node names that begin with the underscore character (e.g.,
209 "_name"). A global underscored node name is the one that is closest
210 to the root of the DNS hierarchy, also called the highest level or
211 topmost. In the presentation convention described in Section 3.1 of
212 [RFC1034], this is the rightmost name beginning with an underscore.
213
214
215
216
217 Crocker Best Current Practice [Page 4]
218 RFC 8552 DNS AttrLeaf March 2019
219
220
221 In other presentation environments, it might be positioned
222 differently. To avoid concern for the presentation variations, the
223 qualifier "global" is used here.
224
225 1.4. Interaction with DNS Wildcards
226
227 DNS wildcards interact poorly with underscored names in two ways:
228
229 Since wildcards are only interpreted as leaf names, one cannot create
230 the equivalent of a wildcard name for prefixed names. A name such as
231 label.*.example.com is not a wildcard.
232
233 Conversely, a wildcard such as *.example.com can match any name
234 including an underscored name. So, a wildcard might match an
235 underscored name, returning a record that is the type controlled by
236 the underscored name but is not intended to be used in the
237 underscored context and does not conform to its rules.
238
239 1.5. History
240
241 Originally, different uses of underscored node names developed
242 largely without coordination. For TXT records, there is no
243 consistent, internal syntax that permits distinguishing among the
244 different uses. In the case of the SRV RR and URI RR, distinguishing
245 among different types of use was part of the design (see [RFC2782]
246 and [RFC7553]). The SRV and URI specifications serve as templates,
247 defining RRs that might only be used for specific applications when
248 there is an additional specification. The template definition
249 included reference to two levels of tables of names from which
250 underscored names should be drawn. The lower-level (local scope) set
251 of "_service" names is defined in terms of other IANA tables, namely
252 any table with symbolic names. The upper-level (global scope) SRV
253 naming field is "_proto", although its pool of names is not
254 explicitly defined.
255
256 The aggregate effect of these independent efforts was a long list of
257 underscored names that were reserved without coordination, which
258 invites an eventual name-assignment collision. The remedy is this
259 base document and a companion document ([RFC8553]), which define a
260 registry for these names and attempt to register all those already in
261 use as well as to direct changes to the pre-registry specifications
262 that used global underscored node names.
263
264
265
266
267
268
269
270
271
272 Crocker Best Current Practice [Page 5]
273 RFC 8552 DNS AttrLeaf March 2019
274
275
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.
276 2. "Underscored and Globally Scoped DNS Node Names" Registry
277
278 A registry for global DNS node names that begin with an underscore is
279 defined here. The purpose of the "Underscored and Globally Scoped
280 DNS Node Names" registry is to avoid collisions resulting from the
281 use of the same underscored name for different applications.
282
283 If a public specification calls for use of an underscored node
284 name, the global underscored node name -- the underscored name
285 that is closest to the DNS root -- MUST be entered into this
286 registry.
287
288 An underscored name defines the scope of use for specific resource
289 record types, which are associated with the domain name that is the
290 "parent" to the branch defined by the underscored name. A given name
291 defines a specific, constrained context for one or more RR TYPEs,
292 where use of such record types conforms to the defined constraints.
293
294 o Within a leaf that is underscore scoped, other RRsets that are not
295 specified as part of the scope MAY be used.
296
297 Structurally, the registry is defined as a single, flat table of RR
298 TYPEs, under node names beginning with underscore. In some cases,
299 such as for use of an SRV record, the full scoping name might be
300 multi-part, as a sequence of underscored names. Semantically, that
301 sequence represents a hierarchical model, and it is theoretically
302 reasonable to allow reuse of a subordinate underscored name in a
303 different, global underscored context; that is, a subordinate name is
304 meaningful only within the scope of the global underscored node name.
305 Therefore, they are ignored by this "Underscored and Globally Scoped
306 DNS Node Names" registry. This registry is for the definition of
307 highest-level -- that is, global -- underscored node name used.
308
309 +----------------------------+
310 | NAME |
311 +----------------------------+
312 | _service1 |
313 | _protoB._service2 |
314 | _protoB._service3 |
315 | _protoC._service3 |
316 | _useX._protoD._service4 |
317 | _protoE._region._authority |
318 +----------------------------+
319
320 Table 1: Examples of Underscored Names
321
322
323
324
325
326
327 Crocker Best Current Practice [Page 6]
328 RFC 8552 DNS AttrLeaf March 2019
329
330
331 Only global underscored node names are registered in the "Underscored
332 and Globally Scoped DNS Node Names" registry. From the example
333 above, that would mean _service1, _service2, _service3, _service 4,
334 and _authority would be listed in the IANA registry.
335
336 o The use of underscored node names is specific to each RR TYPE that
337 is being scoped. Each name defines a place but does not define
338 the rules for what appears underneath that place, either as
339 additional underscored naming or as a leaf node with resource
340 records. Details for those rules are provided by specifications
341 for individual RR TYPEs. The sections below describe the way that
342 existing underscored names are used with the RR TYPEs that they
343 name.
344
345 o Definition and registration of subordinate underscored node names
346 are the responsibility of the specification that creates the
347 global underscored node name registry entry.
348
349 That is, if a scheme using a global underscored node name has one or
350 more subordinate levels of underscored node naming, the namespaces
351 from which names for those lower levels are chosen are controlled by
352 the parent underscored node name. Each registered global underscored
353 node name owns a distinct, subordinate namespace.
354
355 3. Guidance for Registering RRset Use
356
357 This section provides guidance for specification writers, with a
358 basic template they can use, to register new entries in the
359 "Underscored and Globally Scoped DNS Node Names" registry. The text
360 can be added to specifications using RR TYPE / _NODE NAME
361 combinations that have not already been registered:
362
363 Per RFC 8552, please add the following entry to the "Underscored
364 and Globally Scoped DNS Node Names" registry:
365
366 +---------+-------------------+-------------------------------------+
367 | RR Type | _NODE NAME | Reference |
368 +---------+-------------------+-------------------------------------+
369 | {RR | _{DNS global node | {citation for the document making |
370 | TYPE} | name} | the addition.} |
371 +---------+-------------------+-------------------------------------+
372
373 Table 2: Template for Entries in the
374 "Underscored and Globally Scoped DNS Node Names" Registry
375
376
377
378
379
380
381
382 Crocker Best Current Practice [Page 7]
383 RFC 8552 DNS AttrLeaf March 2019
384
385
Only global underscored node names are registered in the "Underscored and Globally Scoped DNS Node Names" registry. From the example above, that would mean _service1, _service2, _service3, _service 4, and _authority would be listed in the IANA registry.
Only global underscored node names are registered in the "Underscored and Globally Scoped DNS Node Names" registry. From the example above, that would mean _service1, _service2, _service3, _service4, and _authority would be listed in the IANA registry.
Typographical error with an unwanted space character between "_service" and "4"
386 4. IANA Considerations
387
388 IANA has established the "Underscored and Globally Scoped DNS Node
389 Names" registry. This section describes the registry, the
390 definitions, the initial entries, the use of_ta and _example, and the
391 use of [RFC8126] as guidance for expert review. IANA has also
392 updated the "Enumservices Registrations" registry with a pointer to
393 this document.
394
395 4.1. "Underscored and Globally Scoped DNS Node Names" Registry
396
397 The "Underscored and Globally Scoped DNS Node Names" registry
398 includes any DNS node name that begins with the underscore character
399 ("_", ASCII 0x5F) and is the underscored node name closest to the
400 root; that is, it defines the highest level of a DNS branch under a
401 "parent" domain name.
402
403 o This registry operates under the IANA rules for "Expert Review"
404 registration; see Section 4.1.5.
405
406 o The contents of each entry in the registry are defined in
407 Section 4.1.1.
408
409 o Each entry in the registry MUST contain values for all of the
410 fields specified in Section 4.1.1.
411
412 o Within the registry, the combination of RR Type and _NODE NAME
413 MUST be unique.
414
415 o The table is to be maintained with entries sorted by the first
416 column (RR Type) and, within that, the second column (_NODE NAME).
417
418 o The required Reference for an entry MUST have a stable resolution
419 to the organization controlling that registry entry.
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437 Crocker Best Current Practice [Page 8]
438 RFC 8552 DNS AttrLeaf March 2019
439
440
441 4.1.1. Contents of an Entry in the "Underscored and Globally Scoped DNS
442 Node Names" Registry
443
444 A registry entry contains:
445
446 RR Type: Lists an RR TYPE that is defined for use within this
447 scope.
448
449 _NODE NAME: Specifies a single, underscored name that defines a
450 reserved name; this name is the global entry name for
451 the scoped resource record types that are associated
452 with that name. For characters in the name that have
453 an uppercase form and a lowercase form, the character
454 MUST be recorded as lowercase to simplify name
455 comparisons.
456
457 Reference: Lists the specification that defines a record type and
458 its use under this _Node Name. The organization
459 producing the specification retains control over the
460 registry entry for the _Node Name.
461
462 Each RR TYPE that is to be used with a _Node Name MUST have a
463 separate registry entry.
464
RFC 8552 DNS AttrLeaf March 2019 4. IANA Considerations IANA has established the "Underscored and Globally Scoped DNS Node Names" registry. This section describes the registry, the definitions, the initial entries, the use of_ta and _example, and the use of [RFC8126] as guidance for expert review. IANA has also updated the "Enumservices Registrations" registry with a pointer to this document.
RFC 8552 DNS AttrLeaf March 2019 4. IANA Considerations IANA has established the "Underscored and Globally Scoped DNS Node Names" registry. This section describes the registry, the definitions, the initial entries, the use of _ta and _example, and the use of [RFC8126] as guidance for expert review. IANA has also updated the "Enumservices Registrations" registry with a pointer to this document.
"the use of_ta and _example" is missing a single whitespace before `_ta`, corrected it should read: "the use of _ta and _example"
IANA has established the "Underscored and Globally Scoped DNS Node Names" registry. This section describes the registry, the definitions, the initial entries, the use of_ta and _example, and the
IANA has established the "Underscored and Globally Scoped DNS Node Names" registry. This section describes the registry, the definitions, the initial entries, the use of _ta and _example, and the
There should be a space character between "of" and "_ta" in "of_ta".
465 4.1.2. Initial Node Names
466
467 The initial entries in the registry are as follows:
468
469 +------------+-----------------------+---------------+
470 | RR Type | _NODE NAME | Reference |
471 +------------+-----------------------+---------------+
472 | * | _example | Section 4.1.4 |
473 | NULL | _ta-* {Section 4.1.3} | [RFC8145] |
474 | OPENPGPKEY | _openpgpkey | [RFC7929] |
475 | SMIMEA | _smimecert | [RFC8162] |
476 | SRV | _dccp | [RFC2782] |
477 | SRV | _http | [RFC4386] |
478 | SRV | _ipv6 | [RFC5026] |
479 | SRV | _ldap | [RFC4386] |
480 | SRV | _ocsp | [RFC4386] |
481 | SRV | _sctp | [RFC2782] |
482 | SRV | _sip | [RFC5509] |
483 | SRV | _tcp | [RFC2782] |
484 | SRV | _udp | [RFC2782] |
485 | SRV | _xmpp | [RFC3921] |
486 | TLSA | _dane | [RFC7671] |
487 | TLSA | _sctp | [RFC6698] |
488 | TLSA | _tcp | [RFC6698] |
489
490
491
492 Crocker Best Current Practice [Page 9]
493 RFC 8552 DNS AttrLeaf March 2019
494
495
496 | TLSA | _udp | [RFC6698] |
497 | TXT | _acme-challenge | [RFC8555] |
498 | TXT | _dmarc | [RFC7489] |
499 | TXT | _domainkey | [RFC6376] |
500 | TXT | _mta-sts | [RFC8461] |
501 | TXT | _spf | [RFC7208] |
502 | TXT | _sztp | [ZEROTOUCH] |
503 | TXT | _tcp | [RFC6763] |
504 | TXT | _udp | [RFC6763] |
505 | TXT | _vouch | [RFC5518] |
506 | URI | _acct | [RFC6118] |
507 | URI | _dccp | [RFC7566] |
508 | URI | _email | [RFC6118] |
509 | URI | _ems | [RFC6118] |
510 | URI | _fax | [RFC6118] |
511 | URI | _ft | [RFC6118] |
512 | URI | _h323 | [RFC6118] |
513 | URI | _iax | [RFC6118] |
514 | URI | _ical-access | [RFC6118] |
515 | URI | _ical-sched | [RFC6118] |
516 | URI | _ifax | [RFC6118] |
517 | URI | _im | [RFC6118] |
518 | URI | _mms | [RFC6118] |
519 | URI | _pres | [RFC6118] |
520 | URI | _pstn | [RFC6118] |
521 | URI | _sctp | [RFC6118] |
522 | URI | _sip | [RFC6118] |
523 | URI | _sms | [RFC6118] |
524 | URI | _tcp | [RFC6118] |
525 | URI | _udp | [RFC6118] |
526 | URI | _unifmsg | [RFC6118] |
527 | URI | _vcard | [RFC6118] |
528 | URI | _videomsg | [RFC6118] |
529 | URI | _voice | [RFC6118] |
530 | URI | _voicemsg | [RFC6118] |
531 | URI | _vpim | [RFC6118] |
532 | URI | _web | [RFC6118] |
533 | URI | _xmpp | [RFC6118] |
534 +------------+-----------------------+---------------+
535
536 Table 3: Initial Contents of the
537 "Underscored and Globally Scoped DNS Node Names" Registry
538
| URI | _acct | [RFC6118] |
| URI | _acct | [RFC7566] |
Wrong reference. Note that is also has an impact to the IANA registry: https://www.iana.org/assignments/dns-parameters/dns- parameters.xhtml#underscored-globally-scoped-dns-node-names --- Readers are encouraged to read the below email thread (and may also want to read RFC6118 for additional information): https://mailarchive.ietf.org/arch/msg/dnsop/TuoV8FmCf1l_pKr500Fo0AI8tVM/
| URI | _tcp | [RFC6118] |
| URI | _udp | [RFC6118] |
| URI | _tcp | [RFC4340] | | URI | _udp | [RFC4340] |
Wrong reference. RFC6118 does not even mention "tcp" nor "udp". Note that this also has an impact to the IANA registry: https://www.iana.org/assignments/dns-parameters/dns- parameters.xhtml#underscored-globally-scoped-dns-node-names [ Warren Kumari (Ops AD): Please also see Errata 7066, and the thread https://mailarchive.ietf.org/arch/msg/dnsop/WFMXL5dY8sniHwVtkPfcqvWk3nI/ This was added as "part of a list used to "reserve" the names of (transport) protocols, so that constructs like _25._quic.example.com could be constructed where the _name denotes the protocol and not the name of something." . IANA will update the reference. ]
| URI | _sctp | [RFC6118] |
| URI | _sctp | [RFC4340] |
Wrong reference. RFC6118 does not even mention "sctp". Note that this also has an impact to the IANA registry: https://www.iana.org/assignments/dns-parameters/dns- parameters.xhtml#underscored-globally-scoped-dns-node-names [ Warren Kumari (Ops AD): Please also see Errata 7066, and the thread https://mailarchive.ietf.org/arch/msg/dnsop/WFMXL5dY8sniHwVtkPfcqvWk3nI/ This was added as "part of a list used to "reserve" the names of (transport) protocols, so that constructs like _25._quic.example.com could be constructed where the _name denotes the protocol and not the name of something." . I am requesting that the IANA update the reference to match. ]
| URI | _dccp | [RFC7566] |
| URI | _dccp | [RFC4340] |
Wrong reference. RFC7566 does not even mention "dccp". Note that this also has an impact to the IANA registry: https://www.iana.org/assignments/dns-parameters/dns- parameters.xhtml#underscored-globally-scoped-dns-node-names [ Warren Kumari (Ops AD): Please see the thread for resolution: https://mailarchive.ietf.org/arch/msg/dnsop/WFMXL5dY8sniHwVtkPfcqvWk3nI/ This was added as "part of a list used to "reserve" the names of (transport) protocols, so that constructs like _25._quic.example.com could be constructed where the _name denotes the protocol and not the name of something." . I am requesting that the IANA update the reference to match. ]
539 4.1.3. _ta
540
541 Under the NULL RR Type, the entry "_ta-*" denotes all node names
542 beginning with the string "_ta-*". It does NOT refer to a DNS
543 wildcard specification.
544
545
546
547 Crocker Best Current Practice [Page 10]
548 RFC 8552 DNS AttrLeaf March 2019
549
550
551 4.1.4. _example
552
553 The node name "_example" is reserved across all RRsets.
554
555 4.1.5. Guidance for Expert Review
556
557 This section provides guidance for expert review of registration
558 requests in the "Underscored and Globally Scoped DNS Node Names"
559 registry.
560
561 This review is solely to determine adequacy of a requested entry
562 in this registry, and it does not include review of other aspects
563 of the document specifying that entry. For example, such a
564 document might also contain a definition of the resource record
565 type that is referenced by the requested entry. Any required
566 review of that definition is separate from the expert review
567 required here.
568
569 The review is for the purposes of ensuring that:
570
571 o The details for creating the registry entry are sufficiently
572 clear, precise, and complete
573
574 o The combination of the underscored name, under which the listed
575 resource record type is used, and the resource record type is
576 unique in the table
577
578 For the purposes of this expert review, other matters of the
579 specification's technical quality, adequacy, or the like are outside
580 of scope.
581
582 4.2. Enumservices Registrations Registry
583
584 The following note has been added to the "Enumservice Registrations"
585 registry:
586
587 When adding an entry to this registry, strong consideration should
588 be given to also adding an entry to the "Underscored and Globally
589 Scoped DNS Node Names" registry.
590
591 5. Security Considerations
592
593 This memo raises no security issues.
594
595
596
597
598
599
600
601
602 Crocker Best Current Practice [Page 11]
603 RFC 8552 DNS AttrLeaf March 2019
604
605
606 6. References
607
608 6.1. Normative References
609
610 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
611 host table specification", RFC 952, DOI 10.17487/RFC0952,
612 October 1985, <https://www.rfc-editor.org/info/rfc952>.
613
614 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
615 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
616 <https://www.rfc-editor.org/info/rfc1034>.
617
618 [RFC1035] Mockapetris, P., "Domain names - implementation and
619 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
620 November 1987, <https://www.rfc-editor.org/info/rfc1035>.
621
622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
623 Requirement Levels", BCP 14, RFC 2119,
624 DOI 10.17487/RFC2119, March 1997,
625 <https://www.rfc-editor.org/info/rfc2119>.
626
627 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
628 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
629 <https://www.rfc-editor.org/info/rfc2181>.
630
631 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
632 specifying the location of services (DNS SRV)", RFC 2782,
633 DOI 10.17487/RFC2782, February 2000,
634 <https://www.rfc-editor.org/info/rfc2782>.
635
636 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence
637 Protocol (XMPP): Instant Messaging and Presence",
638 RFC 3921, DOI 10.17487/RFC3921, October 2004,
639 <https://www.rfc-editor.org/info/rfc3921>.
640
641 [RFC4386] Boeyen, S. and P. Hallam-Baker, "Internet X.509 Public Key
642 Infrastructure Repository Locator Service", RFC 4386,
643 DOI 10.17487/RFC4386, February 2006,
644 <https://www.rfc-editor.org/info/rfc4386>.
645
646 [RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed.,
647 "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026,
648 DOI 10.17487/RFC5026, October 2007,
649 <https://www.rfc-editor.org/info/rfc5026>.
650
651
652
653
654
655
656
657 Crocker Best Current Practice [Page 12]
658 RFC 8552 DNS AttrLeaf March 2019
659
660
661 [RFC5509] Loreto, S., "Internet Assigned Numbers Authority (IANA)
662 Registration of Instant Messaging and Presence DNS SRV RRs
663 for the Session Initiation Protocol (SIP)", RFC 5509,
664 DOI 10.17487/RFC5509, April 2009,
665 <https://www.rfc-editor.org/info/rfc5509>.
666
667 [RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By
668 Reference", RFC 5518, DOI 10.17487/RFC5518, April 2009,
669 <https://www.rfc-editor.org/info/rfc5518>.
670
671 [RFC6118] Hoeneisen, B. and A. Mayrhofer, "Update of Legacy IANA
672 Registrations of Enumservices", RFC 6118,
673 DOI 10.17487/RFC6118, March 2011,
674 <https://www.rfc-editor.org/info/rfc6118>.
675
676 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
677 Cheshire, "Internet Assigned Numbers Authority (IANA)
678 Procedures for the Management of the Service Name and
679 Transport Protocol Port Number Registry", BCP 165,
680 RFC 6335, DOI 10.17487/RFC6335, August 2011,
681 <https://www.rfc-editor.org/info/rfc6335>.
682
683 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
684 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
685 RFC 6376, DOI 10.17487/RFC6376, September 2011,
686 <https://www.rfc-editor.org/info/rfc6376>.
687
688 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
689 of Named Entities (DANE) Transport Layer Security (TLS)
690 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
691 2012, <https://www.rfc-editor.org/info/rfc6698>.
692
693 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
694 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
695 <https://www.rfc-editor.org/info/rfc6763>.
696
697 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
698 Authorizing Use of Domains in Email, Version 1", RFC 7208,
699 DOI 10.17487/RFC7208, April 2014,
700 <https://www.rfc-editor.org/info/rfc7208>.
701
702 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
703 Message Authentication, Reporting, and Conformance
704 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
705 <https://www.rfc-editor.org/info/rfc7489>.
706
707
708
709
710
711
712 Crocker Best Current Practice [Page 13]
713 RFC 8552 DNS AttrLeaf March 2019
714
715
716 [RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource
717 Identifier (URI) DNS Resource Record", RFC 7553,
718 DOI 10.17487/RFC7553, June 2015,
719 <https://www.rfc-editor.org/info/rfc7553>.
720
721 [RFC7566] Goix, L. and K. Li, "Enumservice Registration for 'acct'
722 URI", RFC 7566, DOI 10.17487/RFC7566, June 2015,
723 <https://www.rfc-editor.org/info/rfc7566>.
724
725 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based
726 Authentication of Named Entities (DANE) Protocol: Updates
727 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
728 October 2015, <https://www.rfc-editor.org/info/rfc7671>.
729
730 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities
731 (DANE) Bindings for OpenPGP", RFC 7929,
732 DOI 10.17487/RFC7929, August 2016,
733 <https://www.rfc-editor.org/info/rfc7929>.
734
735 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
736 Writing an IANA Considerations Section in RFCs", BCP 26,
737 RFC 8126, DOI 10.17487/RFC8126, June 2017,
738 <https://www.rfc-editor.org/info/rfc8126>.
739
740 [RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust
741 Anchor Knowledge in DNS Security Extensions (DNSSEC)",
742 RFC 8145, DOI 10.17487/RFC8145, April 2017,
743 <https://www.rfc-editor.org/info/rfc8145>.
744
745 [RFC8162] Hoffman, P. and J. Schlyter, "Using Secure DNS to
746 Associate Certificates with Domain Names for S/MIME",
747 RFC 8162, DOI 10.17487/RFC8162, May 2017,
748 <https://www.rfc-editor.org/info/rfc8162>.
749
750 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
751 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
752 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
753
754 [RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,
755 and J. Jones, "SMTP MTA Strict Transport Security (MTA-
756 STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018,
757 <https://www.rfc-editor.org/info/rfc8461>.
758
759 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
760 Kasten, "Automatic Certificate Management Environment
761 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
762 <https://www.rfc-editor.org/info/rfc8555>.
763
764
765
766
767 Crocker Best Current Practice [Page 14]
768 RFC 8552 DNS AttrLeaf March 2019
769
770
771 6.2. Informative References
772
773 [RFC8553] Crocker, D., "DNS Attrleaf Changes: Fixing Specifications
774 That Use Underscored Node Names", RFC 8553,
775 DOI 10.17487/RFC8553, March 2019,
776 <https://www.rfc-editor.org/info/rfc8553>.
777
778 [ZEROTOUCH]
779 Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero
780 Touch Provisioning (SZTP)", Work in Progress, draft-ietf-
781 netconf-zerotouch-29, January 2019.
782
783 Acknowledgements
784
785 Thanks go to Bill Fenner, Dick Franks, Tony Hansen, Martin Hoffmann,
786 Paul Hoffman, Peter Koch, Olaf Kolkman, Murray Kucherawy, John
787 Levine, Benno Overeinder, and Andrew Sullivan for diligent review of
788 the (much) earlier draft versions. For the later enhancements,
789 thanks to Stephane Bortzmeyer, Alissa Cooper, Bob Harold, Joel
790 Jaeggli, Benjamin Kaduk, Mirja Kuehlewind, Warren Kumari, John
791 Levine, Benno Overeinder, Eric Rescorla, Adam Roach, Petr Spacek,
792 Ondrej Sury, Paul Vixie, Tim Wicinski, and Paul Wouters.
793
794 Special thanks to Ray Bellis for his persistent encouragement to
795 continue this effort, as well as the suggestion for an essential
796 simplification to the registration model.
797
798 Author's Address
799
800 Dave Crocker
801 Brandenburg InternetWorking
802 675 Spruce Dr.
803 Sunnyvale, CA 94086
804 United States of America
805
806 Phone: +1.408.246.8253
807 Email: dcrocker@bbiw.net
808 URI: http://bbiw.net/
809
810
811
812
813
814
815
816
817
818
819
820
821
822 Crocker Best Current Practice [Page 15]
823
4.1.3. _ta Under the NULL RR Type, the entry "_ta-*" denotes all node names beginning with the string "_ta-*". It does NOT refer to a DNS wildcard specification.
4.1.3. _ta Under the NULL RR Type, the entry "_ta-*" denotes all node names beginning with the string "_ta-". It does NOT refer to a DNS wildcard specification.
The second '*' should not be present, as a literal asterisk does not appear in all node names beginning with "_ta-".
| URI | _iax | [RFC6118] |
| URI | _iax | [RFC6315] |
Wrong reference. Note that is also has an impact to the IANA registry: https://www.iana.org/assignments/dns-parameters/dns- parameters.xhtml#underscored-globally-scoped-dns-node-names