1 DNSEXT Working Group E. Lewis
3 Expiration Date: January 6, 2006 July 6, 2005
4 Updates RFC 1034, RFC 2672
7 in the Domain Name System
8 draft-ietf-dnsext-wcard-clarify-08.txt
12 By submitting this Internet-Draft, each author represents that
13 any applicable patent or other IPR claims of which he or she is
14 aware have been or will be disclosed, and any of which he or she
15 becomes aware will be disclosed, in accordance with Section 6 of
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
23 Internet-Drafts are draft documents valid for a maximum of six
24 months and may be updated, replaced, or obsoleted by other
25 documents at any time. It is inappropriate to use Internet-Drafts
26 as reference material or to cite them other than as "work in
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html
35 This Internet-Draft will expire on January 6, 2006.
39 Copyright (C) The Internet Society (2005).
43 This is an update to the wildcard definition of RFC 1034. The
44 interaction with wildcards and CNAME is changed, an error
45 condition removed, and the words defining some concepts central
46 to wildcards are changed. The overall goal is not to change
47 wildcards, but to refine the definition of RFC 1034.
53 1.2 The Original Definition
54 1.3 Roadmap to This Document
57 1.3.3 Considerations with Special Types
58 1.4 Standards Terminology
60 2.1 Identifying a Wildcard
61 2.1.1 Wild Card Domain Name and Asterisk Label
62 2.1.2 Asterisks and Other Characters
63 2.1.3 Non-terminal Wild Card Domain Names
66 2.2.2 Empty Non-terminals
67 2.2.3 Yet Another Definition of Existence
68 2.3 When is a Wild Card Domain Name Not Special
69 3. Impact of a Wild Card Domain Name On a Response
73 3.3.1 Closest Encloser and the Source of Synthesis
74 3.3.2 Closest Encloser and Source of Synthesis Examples
76 4. Considerations with Special Types
77 4.1 SOA RRSet at a Wild Card Domain Name
78 4.2 NS RRSet at a Wild Card Domain Name
79 4.2.1 Discarded Notions
80 4.3 CNAME RRSet at a Wild Card Domain Name
81 4.4 DNAME RRSet at a Wild Card Domain Name
82 4.5 SRV RRSet at a Wild Card Domain Name
83 4.6 DS RRSet at a Wild Card Domain Name
84 4.7 NSEC RRSet at a Wild Card Domain Name
85 4.8 RRSIG at a Wild Card Domain Name
86 4.9 Empty Non-terminal Wild Card Domain Name
87 5. Security Considerations
88 6. IANA Considerations
91 9. Others Contributing to the Document
92 10. Trailing Boilerplate
96 In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the
97 synthesis of answers from special resource records called
98 wildcards. The definition in RFC 1034 is incomplete and has
99 proven to be confusing. This document describes the wildcard
100 synthesis by adding to the discussion and making limited
101 modifications. Modifications are made to close inconsistencies
102 that have led to interoperability issues. This description
103 does not expand the service intended by the original definition.
105 Staying within the spirit and style of the original documents,
106 this document avoids specifying rules for DNS implementations
107 regarding wildcards. The intention is to only describe what is
108 needed for interoperability, not restrict implementation choices.
109 In addition, consideration is given to minimize any backwards
110 compatibility issues with implementations that comply with RFC
113 This document is focused on the concept of wildcards as defined
114 in RFC 1034. Nothing is implied regarding alternative means of
115 synthesizing resource record sets, nor are alternatives discussed.
119 Many DNS implementations diverge, in different ways, from the
120 original definition of wildcards. Although there is clearly a
121 need to clarify the original documents in light of this alone,
122 the impetus for this document lay in the engineering of the DNS
123 security extensions [RFC4033]. With an unclear definition of
124 wildcards the design of authenticated denial became entangled.
126 This document is intended to limit its changes, documenting only
127 those based on implementation experience, and to remain as close
128 to the original document as possible. To reinforce that this
129 document is meant to clarify and adjust and not redefine wildcards,
130 relevant sections of RFC 1034 are repeated verbatim to facilitate
131 comparison of the old and new text.
133 1.2 The Original Definition
135 The defintion of the wildcard concept is comprised by the
136 documentation of the algorithm by which a name server prepares
137 a response (in RFC 1034's section 4.3.2) and the way in which
138 a resource record (set) is identified as being a source of
139 synthetic data (section 4.3.3).
141 This is the definition of the term "wildcard" as it appears in
142 RFC 1034, section 4.3.3.
144 # In the previous algorithm, special treatment was given to RRs with
145 # owner names starting with the label "*". Such RRs are called
146 # wildcards. Wildcard RRs can be thought of as instructions for
147 # synthesizing RRs. When the appropriate conditions are met, the name
148 # server creates RRs with an owner name equal to the query name and
149 # contents taken from the wildcard RRs.
151 This passage follows the algorithm in which the term wildcard
152 is first used. In this definition, wildcard refers to resource
153 records. In other usage, wildcard has referred to domain names,
154 and it has been used to describe the operational practice of
155 relying on wildcards to generate answers. It is clear from this
156 that there is a need to define clear and unambiguous terminology
157 in the process of discussing wildcards.
159 The mention of the use of wildcards in the preparation of a
160 response is contained in step 3c of RFC 1034's section 4.3.2
161 entitled "Algorithm." Note that "wildcard" does not appear in
162 the algorithm, instead references are made to the "*" label.
163 The portion of the algorithm relating to wildcards is
164 deconstructed in detail in section 3 of this document, this is
165 the beginning of the relevant portion of the "Algorithm."
167 # c. If at some label, a match is impossible (i.e., the
168 # corresponding label does not exist), look to see if [...]
169 # the "*" label exists.
171 The scope of this document is the RFC 1034 definition of
172 wildcards and the implications of updates to those documents,
173 such as DNSSEC. Alternate schemes for synthesizing answers are
174 not considered. (Note that there is no reference listed. No
175 document is known to describe any alternate schemes, although
176 there has been some mention of them in mailing lists.)
178 1.3 Roadmap to This Document
180 This document accomplishes these three items.
182 o Makes minor changes to avoid conflicting concepts
183 o Describes the actions of certain resource records as wildcards
187 To help in discussing what resource records are wildcards, two
188 terms will be defined - "asterisk label" and "wild card domain
189 name". These are defined in section 2.1.1.
191 To assist in clarifying the role of wildcards in the name server
192 algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest
193 encloser" are defined. These definitions are in section 3.3.2.
194 "Label match" is defined in section 3.2.
196 The new terms are used to make discussions of wildcards clearer.
197 Terminology doesn't directly have an impact on implementations.
201 The definition of "existence" is changed superficially. This
202 change will not be apparent to implementations; it is needed to
203 make descriptions more precise. The change appears in section
206 RFC 1034, section 4.3.3., seems to prohibit having two asterisk
207 labels in a wildcard owner name. With this document the
208 restriction is removed entirely. This change and its implications
209 are in section 2.1.3.
211 The actions when a source of synthesis owns a CNAME RR are
212 changed to mirror the actions if an exact match name owns a
213 CNAME RR. This is an addition to the words in RFC 1034,
214 section 4.3.2, step 3, part c. The discussion of this is in
217 Only the latter change represents an impact to implementations.
218 The definition of existence is not a protocol impact. The change
219 to the restriction on names is unlikely to have an impact, as
220 RFC 1034 contained no specification on when and how to enforce the
223 1.3.3 Considerations with Special Types
225 This document describes semantics of wildcard RRSets for
226 "interesting" types as well as empty non-terminal wildcards.
227 Understanding these situations in the context of wildcards has
228 been clouded because these types incur special processing if
229 they are the result of an exact match. This discussion is in
232 These discussions do not have an implementation impact, they cover
233 existing knowledge of the types, but to a greater level of detail.
235 1.4 Standards Terminology
237 This document does not use terms as defined in "Key words for use
238 in RFCs to Indicate Requirement Levels." [RFC2119]
240 Quotations of RFC 1034 are denoted by a '#' in the leftmost
241 column. References to section "4.3.2" are assumed to refer
242 to RFC 1034's section 4.3.2, simply titled "Algorithm."
246 The syntax of a wildcard is the same as any other DNS resource
247 record, across all classes and types. The only significant
248 feature is the owner name.
250 Because wildcards are encoded as resource records with special
251 names, they are included in zone transfers and incremental zone
252 transfers[RFC1995] just as non-wildcard resource records are.
253 This feature has been underappreciated until discussions on
254 alternative approaches to wildcards appeared on mailing lists.
256 2.1 Identifying a Wildcard
258 To provide a more accurate description of wildcards, the
259 definition has to start with a discussion of the domain names
260 that appear as owners. Two new terms are needed, "Asterisk
261 Label" and "Wild Card Domain Name."
263 2.1.1 Wild Card Domain Name and Asterisk Label
265 A "wild card domain name" is defined by having its initial
266 (i.e., left-most or least significant) label be, in binary format:
268 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
270 The first octet is the normal label type and length for a 1 octet
271 long label, the second octet is the ASCII representation [RFC20]
272 for the '*' character.
274 A descriptive name of a label equaling that value is an "asterisk
277 RFC 1034's definition of wildcard would be "a resource record
278 owned by a wild card domain name."
280 2.1.2 Asterisks and Other Characters
282 No label values other than that in section 2.1.1 are asterisk
283 labels, hence names beginning with other labels are never wild
284 card domain names. Labels such as 'the*' and '**' are not
285 asterisk labels so these labels do not start wild card domain
288 2.1.3 Non-terminal Wild Card Domain Names
290 In section 4.3.3, the following is stated:
292 # .......................... The owner name of the wildcard RRs is of
293 # the form "*.<anydomain>", where <anydomain> is any domain name.
294 # <anydomain> should not contain other * labels......................
296 The restriction is now removed. The original documentation of it
297 is incomplete and the restriction does not serve any purpose given
298 years of operational experience.
300 There are three possible reasons for putting the restriction in
301 place, but none of the three has held up over time. One is
302 that the restriction meant that there would never be subdomains
303 of wild card domain names, but the restriciton as stated still
304 permits "example.*.example." for instance. Another is that
305 wild card domain names are not intended to be empty non-terminals,
306 but this situation does not disrupt the algorithm in 4.3.2.
307 Finally, "nested" wild card domain names are not ambiguous once
308 the concept of the closest encloser had been documented.
310 A wild card domain name can have subdomains. There is no need
311 to inspect the subdomains to see if there is another asterisk
312 label in any subdomain.
314 A wild card domain name can be an empty non-terminal. (See the
315 upcoming sections on empty non-terminals.) In this case, any
316 lookup encountering it will terminate as would any empty
321 The notion that a domain name 'exists' is mentioned in the
322 definition of wildcards. In section 4.3.3 of RFC 1034:
324 # Wildcard RRs do not apply:
327 # - When the query name or a name between the wildcard domain and
328 # the query name is know[n] to exist. For example, if a wildcard
330 "Existence" is therefore an important concept in the understanding
331 of wildcards. Unfortunately, the definition of what exists, in RFC
332 1034, is unlcear. So, in sections 2.2.2. and 2.2.3, another look is
333 taken at the definition of existence.
337 To illustrate what is meant by existence consider this complete
341 example. 3600 IN SOA <SOA RDATA>
342 example. 3600 NS ns.example.com.
343 example. 3600 NS ns.example.net.
344 *.example. 3600 TXT "this is a wild card"
345 *.example. 3600 MX 10 host1.example.
346 sub.*.example. 3600 TXT "this is not a wild card"
347 host1.example. 3600 A 192.0.4.1
348 _ssh._tcp.host1.example. 3600 SRV <SRV RDATA>
349 _ssh._tcp.host2.example. 3600 SRV <SRV RDATA>
350 subdel.example. 3600 NS ns.example.com.
351 subdel.example. 3600 NS ns.example.net.
353 A look at the domain names in a tree structure is helpful:
356 -------------example------------
368 The following responses would be synthesized from one of the
369 wildcards in the zone:
371 QNAME=host3.example. QTYPE=MX, QCLASS=IN
372 the answer will be a "host3.example. IN MX ..."
374 QNAME=host3.example. QTYPE=A, QCLASS=IN
375 the answer will reflect "no error, but no data"
376 because there is no A RR set at '*.example.'
378 QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
379 the answer will be "foo.bar.example. IN TXT ..."
380 because bar.example. does not exist, but the wildcard
383 The following responses would not be synthesized from any of the
384 wildcards in the zone:
386 QNAME=host1.example., QTYPE=MX, QCLASS=IN
387 because host1.example. exists
389 QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
390 because sub.*.example. exists
392 QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
393 because _tcp.host1.example. exists (without data)
395 QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
396 because subdel.example. exists (and is a zone cut)
398 QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
399 because *.example. exists
401 The final example highlights one common misconception about
402 wildcards. A wildcard "blocks itself" in the sense that a
403 wildcard does not match its own subdomains. I.e. "*.example."
404 does not match all names in the "example." zone, it fails to
405 match the names below "*.example." To cover names under
406 "*.example.", another wild card domain name is needed -
407 "*.*.example." - which covers all but it's own subdomains.
409 2.2.2 Empty Non-terminals
411 Empty non-terminals [RFC2136, Section 7.16] are domain names
412 that own no resource records but have subdomains that do. In
413 section 2.2.1, "_tcp.host1.example." is an example of a empty
414 non-terminal name. Empty non-terminals are introduced by this
415 text in section 3.1 of RFC 1034:
417 # The domain name space is a tree structure. Each node and leaf on
418 # the tree corresponds to a resource set (which may be empty). The
419 # domain system makes no distinctions between the uses of the
420 # interior nodes and leaves, and this memo uses the term "node" to
423 The parenthesized "which may be empty" specifies that empty non-
424 terminals are explicitly recognized, and that empty non-terminals
427 Pedantically reading the above paragraph can lead to an
428 interpretation that all possible domains exist - up to the
429 suggested limit of 255 octets for a domain name [RFC1035].
430 For example, www.example. may have an A RR, and as far as is
431 practically concerned, is a leaf of the domain tree. But the
432 definition can be taken to mean that sub.www.example. also
433 exists, albeit with no data. By extension, all possible domains
434 exist, from the root on down.
436 As RFC 1034 also defines "an authoritative name error indicating
437 that the name does not exist" in section 4.3.1, so this apparently
438 is not the intent of the original definition, justifying the
439 need for an updated definition in the next section.
441 2.2.3 Yet Another Definition of Existence
443 RFC1034's wording is fixed by the following paragraph:
445 The domain name space is a tree structure. Nodes in the tree
446 either own at least one RRSet and/or have descendants that
447 collectively own at least one RRSet. A node may exist with no
448 RRSets only if it has descendents that do, this node is an empty
451 A node with no descendants is a leaf node. Empty leaf nodes do
454 Note that at a zone boundary, the domain name owns data,
455 including the NS RR set. In the delegating zone, the NS RR
456 set is not authoritative, but that is of no consequence here.
457 The domain name owns data, therefore, it exists.
459 2.3 When is a Wild Card Domain Name Not Special
461 When a wild card domain name appears in a message's query section,
462 no special processing occurs. An asterisk label in a query name
463 only matches a single, corresponding asterisk label in the
464 existing zone tree when the 4.3.2 algorithm is being followed.
466 When a wild card domain name appears in the resource data of a
467 record, no special processing occurs. An asterisk label in that
468 context literally means just an asterisk.
470 3. Impact of a Wild Card Domain Name On a Response
472 RFC 1034's description of how wildcards impact response
473 generation is in its section 4.3.2. That passage contains the
474 algorithm followed by a server in constructing a response.
475 Within that algorithm, step 3, part 'c' defines the behavior of
478 The algorithm in section 4.3.2. is not intended to be pseudo-code,
479 i.e., its steps are not intended to be followed in strict order.
480 The "algorithm" is a suggested means of implementing the
481 requirements. As such, in step 3, parts a, b, and c, do not have
482 to be implemented in that order, provided that the result of the
483 implemented code is compliant with the protocol's specification.
487 Step 2 of the section 4.3.2 reads:
489 # 2. Search the available zones for the zone which is the nearest
490 # ancestor to QNAME. If such a zone is found, go to step 3,
493 In this step, the most appropriate zone for the response is
494 chosen. The significance of this step is that it means all of
495 step 3 is being performed within one zone. This has significance
496 when considering whether or not an SOA RR can be ever be used for
501 Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'.
502 But the beginning of the step is important and needs explanation.
504 # 3. Start matching down, label by label, in the zone. The
505 # matching process can terminate several ways:
507 The word 'matching' refers to label matching. The concept
508 is based in the view of the zone as the tree of existing names.
509 The query name is considered to be an ordered sequence of
510 labels - as if the name were a path from the root to the owner
511 of the desired data. (Which it is - 3rd paragraph of RFC 1034,
514 The process of label matching a query name ends in exactly one of
515 three choices, the parts 'a', 'b', and 'c'. Either the name is
516 found, the name is below a cut point, or the name is not found.
518 Once one of the parts is chosen, the other parts are not
519 considered. (E.g., do not execute part 'c' and then change
520 the execution path to finish in part 'b'.) The process of label
521 matching is also done independent of the query type (QTYPE).
523 Parts 'a' and 'b' are not an issue for this clarification as they
524 do not relate to record synthesis. Part 'a' is an exact match
525 that results in an answer, part 'b' is a referral.
529 The context of part 'c' is that the process of label matching the
530 labels of the query name has resulted in a situation in which
531 there is no corresponding label in the tree. It is as if the
532 lookup has "fallen off the tree."
534 # c. If at some label, a match is impossible (i.e., the
535 # corresponding label does not exist), look to see if [...]
536 # the "*" label exists.
538 To help describe the process of looking 'to see if [...] the "*"
539 label exists' a term has been coined to describe the last domain
540 (node) matched. The term is "closest encloser."
542 3.3.1 Closest Encloser and the Source of Synthesis
544 The closest encloser is the node in the zone's tree of existing
545 domain names that has the most labels matching the query name
546 (consecutively, counting from the root label downward). Each match
547 is a "label match" and the order of the labels is the same.
549 The closest encloser is, by definition, an existing name in the
550 zone. The closest encloser might be an empty non-terminal or even
551 be a wild card domain name itself. In no circumstances is the
552 closest encloser to be used to synthesize records for the current
555 The source of synthesis is defined in the context of a query
556 process as that wild card domain name immediately descending
557 from the closest encloser, provided that this wild card domain
558 name exists. "Immediately descending" means that the source
559 of synthesis has a name of the form:
560 <asterisk label>.<closest encloser>.
561 A source of synthesis does not guarantee having a RRSet to use
562 for synthesis. The source of synthesis could be an empty
565 If the source of synthesis does not exist (not on the domain
566 tree), there will be no wildcard synthesis. There is no search
569 The important concept is that for any given lookup process, there
570 is at most one place at which wildcard synthetic records can be
571 obtained. If the source of synthesis does not exist, the lookup
572 terminates, the lookup does not look for other wildcard records.
574 3.3.2 Closest Encloser and Source of Synthesis Examples
576 To illustrate, using the example zone in section 2.2.1 of this
577 document, the following chart shows QNAMEs and the closest
580 QNAME Closest Encloser Source of Synthesis
581 host3.example. example. *.example.
582 _telnet._tcp.host1.example. _tcp.host1.example. no source
583 _telnet._tcp.host2.example. host2.example. no source
584 _telnet._tcp.host3.example. example. *.example.
585 _chat._udp.host3.example. example. *.example.
586 foobar.*.example. *.example. no source
590 RFC 1034 concludes part 'c' with this:
592 # If the "*" label does not exist, check whether the name
593 # we are looking for is the original QNAME in the query
594 # or a name we have followed due to a CNAME. If the name
595 # is original, set an authoritative name error in the
596 # response and exit. Otherwise just exit.
598 # If the "*" label does exist, match RRs at that node
599 # against QTYPE. If any match, copy them into the answer
600 # section, but set the owner of the RR to be QNAME, and
601 # not the node with the "*" label. Go to step 6.
603 The final paragraph covers the role of the QTYPE in the lookup
606 Based on implementation feedback and similarities between step
607 'a' and step 'c' a change to this passage has been made.
609 The change is to add the following text to step 'c' prior to the
610 instructions to "go to step 6":
612 If the data at the source of synthesis is a CNAME, and
613 QTYPE doesn't match CNAME, copy the CNAME RR into the
614 answer section of the response changing the owner name
615 to the QNAME, change QNAME to the canonical name in the
616 CNAME RR, and go back to step 1.
618 This is essentially the same text in step a covering the
619 processing of CNAME RRSets.
621 4. Considerations with Special Types
623 Sections 2 and 3 of this document discuss wildcard synthesis
624 with respect to names in the domain tree and ignore the impact
625 of types. In this section, the implication of wildcards of
626 specific types are discussed. The types covered are those
627 that have proven to be the most difficult to understand. The
628 types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and
629 "none," i.e., empty non-terminal wild card domain names.
631 4.1 SOA RRSet at a Wild Card Domain Name
633 A wild card domain name owning an SOA RRSet means that the
634 domain is at the root of the zone (apex). The domain can not
635 be a source of synthesis because that is, by definition, a
636 descendent node (of the closest encloser) and a zone apex is
637 at the top of the zone.
639 Although a wild card domain name owning an SOA RRSet can never
640 be a source of synthesis, there is no reason to forbid the
641 ownership of an SOA RRSet.
643 E.g., given this zone:
645 @ 3600 IN SOA <SOA RDATA>
646 3600 NS ns1.example.com.
647 3600 NS ns1.example.net.
648 www 3600 TXT "the www txt record"
650 A query for www.*.example.'s TXT record would still find the
651 "the www txt record" answer. The reason is that the asterisk
652 label only becomes significant when section's 4.3.2, step 3
653 part 'c' in in effect.
655 Of course, there would need to be a delegation in the parent
656 zone, "example." for this to work too. This is covered in the
659 4.2 NS RRSet at a Wild Card Domain Name
661 With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now
662 in place, the semantics of a wild card domain name owning an
663 NS RRSet has come to be poorly defined. The dilemma relates to
664 a conflict between the rules for synthesis in part 'c' and the
665 fact that the resulting synthesis generates a record for which
666 the zone is not authoritative. In a DNSSEC signed zone, the
667 mechanics of signature management (generation and inclusion
668 in a message) become unclear.
670 After some lengthy discussions, there has been no clear "best
671 answer" on how to document the semantics of such a situation.
672 Barring such records from the DNS would require definition of
673 rules for that, as well as introducing a restriction on records
674 that were once legal. Allowing such records and amending the
675 process of signature management would entail complicating the
678 There is one more ingredient to the discussion, that being the
679 utility of a wild card domain name owned NS RRSet. Although
680 there are cases of this use, it is an operational rarity.
681 Expending effort to close this topic has proven to be an
682 exercise in diminishing returns.
684 In summary, there is no definition given for wild card domain
685 names owning an NS RRSet. The semantics are left undefined until
686 there is a clear need to have a set defined, and until there is
687 a clear direction to proceed. Operationally, inclusion of wild
688 card NS RRSets in a zone is discouraged, but not barred.
690 4.2.1 Discarded Notions
692 Prior to DNSSEC, a wild card domain name owning a NS RRSet
693 appeared to be workable, and there are some instances in which
694 it is found in deployments using implementations that support
695 this. Continuing to allow this in the specificaion is not
696 tenable with DNSSEC. The reason is that the synthesis of the
697 NS RRSet is being done in a zone that has delegated away the
698 responsibility for the name. This "unauthorized" synthesis is
699 not a problem for the base DNS protocol, but DNSSEC, in affirming
700 the authorization model for DNS exposes the problem.
702 Outright banning of wildcards of type NS is also untenable as
703 the DNS protocol does not define how to handle "illegal" data.
704 Implementations may choose not to load a zone, but there is no
705 protocol definition. The lack of the definition is complicated
706 by having to cover dynamic update [RFC 2136], zone transfers,
707 as well as loading at the master server. The case of a client
708 (resolver, cacheing server) getting a wildcard of type NS in
709 a reply would also have to be considered.
711 Given the daunting challenge of a complete definition of how to
712 ban such records, dealing with existing implementations that
713 permit the records today is a further complication. There are
714 uses of wild card domain name owning NS RRSets.
716 One compromise proposed would have redefined wildcards of type
717 NS to not be used in synthesis, this compromise fell apart
718 because it would have required significant edits to the DNSSEC
719 signing and validation work. (Again, DNSSEC catches
722 With no clear consensus forming on the solution to this dilemma,
723 and the realization that wildcards of type NS are a rarity in
724 operations, the best course of action is to leave this open-ended
727 4.3 CNAME RRSet at a Wild Card Domain Name
729 The issue of a CNAME RRSet owned by a wild card domain name has
730 prompted a suggested change to the last paragraph of step 3c of
731 the algorithm in 4.3.2. The changed text appears in section
732 3.3.3 of this document.
734 4.4 DNAME RRSet at a Wild Card Domain Name
736 Ownership of a DNAME [RFC2672] RRSet by a wild card domain name
737 represents a threat to the coherency of the DNS and is to be
738 avoided or outright rejected. Such a DNAME RRSet represents
739 non-deterministic synthesis of rules fed to different caches.
740 As caches are fed the different rules (in an unpredictable
741 manner) the caches will cease to be coherent. ("As caches
742 are fed" refers to the storage in a cache of records obtained
743 in responses by recursive or iterative servers.)
745 For example, assume one cache, responding to a recursive
746 request, obtains the record:
747 "a.b.example. DNAME foo.bar.example.net."
748 and another cache obtains:
749 "b.example. DNAME foo.bar.example.net."
750 both generated from the record:
751 "*.example. DNAME foo.bar.example.net."
752 by an authoritative server.
754 The DNAME specification is not clear on whether DNAME records
755 in a cache are used to rewrite queries. In some interpretations,
756 the rewrite occurs, in some, it is not. Allowing for the
757 occurrence of rewriting, queries for "sub.a.b.example. A" may
758 be rewritten as "sub.foo.bar.tld. A" by the former caching
759 server and may be rewritten as "sub.a.foo.bar.tld. A" by the
760 latter. Coherency is lost, an operational nightmare ensues.
762 Another justification for banning or avoiding wildcard DNAME
763 records is the observation that such a record could synthesize
764 a DNAME owned by "sub.foo.bar.example." and "foo.bar.example."
765 There is a restriction in the DNAME definition that no domain
766 exist below a DNAME-owning domain, hence, the wildcard DNAME
767 is not to be permitted.
769 4.5 SRV RRSet at a Wild Card Domain Name
771 The definition of the SRV RRset is RFC 2782 [RFC2782]. In the
772 definition of the record, there is some confusion over the term
773 "Name." The definition reads as follows:
775 # The format of the SRV RR
777 # _Service._Proto.Name TTL Class SRV Priority Weight Port Target
780 # The domain this RR refers to. The SRV RR is unique in that the
781 # name one searches for is not this name; the example near the end
782 # shows this clearly.
784 Do not confuse the definition "Name" with the owner name. I.e.,
785 once removing the _Service and _Proto labels from the owner name
786 of the SRV RRSet, what remains could be a wild card domain name
787 but this is immaterial to the SRV RRSet.
789 E.g., If an SRV record is:
790 _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.
792 *.example is a wild card domain name and although it it the Name
793 of the SRV RR, it is not the owner (domain name). The owner
794 domain name is "_foo._udp.*.example." which is not a wild card
797 The confusion is likely based on the mixture of the specification
798 of the SRV RR and the description of a "use case."
800 4.6 DS RRSet at a Wild Card Domain Name
802 A DS RRSet owned by a wild card domain name is meaningless and
803 harmless. This statement is made in the context that an NS RRSet
804 at a wild card domain name is undefined. At a non-delegation
805 point, a DS RRSet has no value (no corresponding DNSKEY RRSet
806 will be used in DNSSEC validation). If there is a synthesized
807 DS RRSet, it alone will not be very useful as it exists in the
808 context of a delegation point.
810 4.7 NSEC RRSet at a Wild Card Domain Name
812 Wild card domain names in DNSSEC signed zones will have an NSEC
813 RRSet. Synthesis of these records will only occur when the
814 query exactly matches the record. Synthesized NSEC RR's will not
815 be harmful as they will never be used in negative caching or to
816 generate a negative response.
818 4.8 RRSIG at a Wild Card Domain Name
820 RRSIG records will be present at a wild card domain name in a
821 signed zone, and will be synthesized along with data sought in a
822 query. The fact that the owner name is synthesized is not a
823 problem as the label count in the RRSIG will instruct the
824 verifying code to ignore it.
826 4.9 Empty Non-terminal Wild Card Domain Name
828 If a source of synthesis is an empty non-terminal, then the
829 response will be one of no error in the return code and no RRSet
830 in the answer section.
832 5. Security Considerations
834 This document is refining the specifications to make it more
835 likely that security can be added to DNS. No functional
836 additions are being made, just refining what is considered
837 proper to allow the DNS, security of the DNS, and extending
838 the DNS to be more predictable.
840 6. IANA Considerations
848 [RFC20] ASCII Format for Network Interchange, V.G. Cerf,
851 [RFC1034] Domain Names - Concepts and Facilities,
852 P.V. Mockapetris, Nov-01-1987
854 [RFC1035] Domain Names - Implementation and Specification, P.V
855 Mockapetris, Nov-01-1987
857 [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996
859 [RFC2119] Key Words for Use in RFCs to Indicate Requirement
860 Levels, S Bradner, March 1997
862 [RFC2181] Clarifications to the DNS Specification, R. Elz and
865 [RFC2308] Negative Caching of DNS Queries (DNS NCACHE),
866 M. Andrews, March 1998
868 [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
871 [RFC2782] A DNS RR for specifying the location of services (DNS
872 SRV), A. Gulbrandsen, et.al., February 2000
874 [RFC4033] DNS Security Introduction and Requirements, R. Arends,
877 [RFC4034] Resource Records for the DNS Security Extensions,
878 R. Arends, et.al., March 2005
880 [RFC4035] Protocol Modifications for the DNS Security Extensions,
881 R. Arends, et.al., March 2005
883 [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
886 Informative References
888 [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE),
889 P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
896 Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US
897 Phone: +1-571-434-5468
898 Email: ed.lewis@neustar.biz
900 Comments on this document can be sent to the editor or the mailing
901 list for the DNSEXT WG, namedroppers@ops.ietf.org.
903 9. Others Contributing to the Document
905 This document represents the work of a large working group. The
906 editor merely recorded the collective wisdom of the working group.
908 10. Trailing Boilerplate
910 Copyright (C) The Internet Society (2005).
912 This document is subject to the rights, licenses and restrictions
913 contained in BCP 78, and except as set forth therein, the authors
914 retain all their rights.
916 This document and the information contained herein are provided
917 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
918 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
919 SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
920 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
921 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
922 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
923 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
925 Intellectual Property
927 The IETF takes no position regarding the validity or scope of
928 any Intellectual Property Rights or other rights that might
929 be claimed to pertain to the implementation or use of the
930 technology described in this document or the extent to which
931 any license under such rights might or might not be available;
932 nor does it represent that it has made any independent effort
933 to identify any such rights. Information on the procedures
934 with respect to rights in RFC documents can be found in BCP 78
937 Copies of IPR disclosures made to the IETF Secretariat and any
938 assurances of licenses to be made available, or the result of an
939 attempt made to obtain a general license or permission for the
940 use of such proprietary rights by implementers or users of this
941 specification can be obtained from the IETF on-line IPR
942 repository at http://www.ietf.org/ipr. The IETF invites any
943 interested party to bring to its attention any copyrights,
944 patents or patent applications, or other proprietary rights
945 that may cover technology that may be required to implement
946 this standard. Please address the information to the IETF at
951 Funding for the RFC Editor function is currently provided by the
956 This document expires on or about January 6, 2006.