7Network Working Group E. Lewis
8Request for Comments: 4592 NeuStar
9Updates: 1034, 2672 July 2006
10Category: Standards Track
14 in the Domain Name System
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
26 Copyright (C) The Internet Society (2006).
30 This is an update to the wildcard definition of RFC 1034. The
31 interaction with wildcards and CNAME is changed, an error condition
32 is removed, and the words defining some concepts central to wildcards
33 are changed. The overall goal is not to change wildcards, but to
34 refine the definition of RFC 1034.
58Lewis Standards Track [Page 1]
60RFC 4592 DNSEXT WCARD July 2006
65 1. Introduction ....................................................3
66 1.1. Motivation .................................................3
67 1.2. The Original Definition ....................................3
68 1.3. Roadmap to This Document ...................................4
69 1.3.1. New Terms ...........................................5
70 1.3.2. Changed Text ........................................5
71 1.3.3. Considerations with Special Types ...................5
72 1.4. Standards Terminology ......................................6
73 2. Wildcard Syntax .................................................6
74 2.1. Identifying a Wildcard .....................................6
75 2.1.1. Wildcard Domain Name and Asterisk Label .............6
76 2.1.2. Asterisks and Other Characters ......................7
77 2.1.3. Non-terminal Wildcard Domain Names ..................7
78 2.2. Existence Rules ............................................7
79 2.2.1. An Example ..........................................8
80 2.2.2. Empty Non-terminals .................................9
81 2.2.3. Yet Another Definition of Existence ................10
82 2.3. When Is a Wildcard Domain Name Not Special? ...............10
83 3. Impact of a Wildcard Domain Name on a Response .................10
84 3.1. Step 2 ....................................................11
85 3.2. Step 3 ....................................................11
86 3.3. Part 'c' ..................................................12
87 3.3.1. Closest Encloser and the Source of Synthesis .......12
88 3.3.2. Closest Encloser and Source of Synthesis Examples ..13
89 3.3.3. Type Matching ......................................13
90 4. Considerations with Special Types ..............................14
91 4.1. SOA RRSet at a Wildcard Domain Name .......................14
92 4.2. NS RRSet at a Wildcard Domain Name ........................14
93 4.2.1. Discarded Notions ..................................15
94 4.3. CNAME RRSet at a Wildcard Domain Name .....................16
95 4.4. DNAME RRSet at a Wildcard Domain Name .....................16
96 4.5. SRV RRSet at a Wildcard Domain Name .......................17
97 4.6. DS RRSet at a Wildcard Domain Name ........................17
98 4.7. NSEC RRSet at a Wildcard Domain Name ......................18
99 4.8. RRSIG at a Wildcard Domain Name ...........................18
100 4.9. Empty Non-terminal Wildcard Domain Name ...................18
101 5. Security Considerations ........................................18
102 6. References .....................................................18
103 6.1. Normative References ......................................18
104 6.2. Informative References ....................................19
105 7. Others Contributing to the Document ............................19
114Lewis Standards Track [Page 2]
116RFC 4592 DNSEXT WCARD July 2006
121 In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the
122 synthesis of answers from special resource records (RRs) called
123 wildcards. The definition in RFC 1034 is incomplete and has proven
124 to be confusing. This document describes the wildcard synthesis by
125 adding to the discussion and making limited modifications.
126 Modifications are made to close inconsistencies that have led to
127 interoperability issues. This description does not expand the
128 service intended by the original definition.
130 Staying within the spirit and style of the original documents, this
131 document avoids specifying rules for DNS implementations regarding
132 wildcards. The intention is to only describe what is needed for
133 interoperability, not restrict implementation choices. In addition,
134 consideration is given to minimize any backward-compatibility issues
135 with implementations that comply with RFC 1034's definition.
137 This document is focused on the concept of wildcards as defined in
138 RFC 1034. Nothing is implied regarding alternative means of
139 synthesizing resource record sets (RRSets), nor are alternatives
144 Many DNS implementations diverge, in different ways, from the
145 original definition of wildcards. Although there is clearly a need
146 to clarify the original documents in light of this alone, the impetus
147 for this document lay in the engineering of the DNS security
148 extensions [RFC4033]. With an unclear definition of wildcards, the
149 design of authenticated denial became entangled.
151 This document is intended to limit its changes, documenting only
152 those deemed necessary based on implementation experience, and to
153 remain as close to the original document as possible. To reinforce
154 that this document is meant to clarify and adjust and not redefine
155 wildcards, relevant sections of RFC 1034 are repeated verbatim to
156 facilitate comparison of the old and new text.
1581.2. The Original Definition
160 The definition of the wildcard concept is comprised by the
161 documentation of the algorithm by which a name server prepares a
162 response (in RFC 1034's section 4.3.2) and the way in which a
163 resource record (set) is identified as being a source of synthetic
164 data (section 4.3.3).
170Lewis Standards Track [Page 3]
172RFC 4592 DNSEXT WCARD July 2006
175 This is the definition of the term "wildcard" as it appears in RFC
178 # In the previous algorithm, special treatment was given to RRs with
179 # owner names starting with the label "*". Such RRs are called
180 # wildcards. Wildcard RRs can be thought of as instructions for
181 # synthesizing RRs. When the appropriate conditions are met, the
182 # name server creates RRs with an owner name equal to the query name
183 # and contents taken from the wildcard RRs.
185 This passage follows the algorithm in which the term wildcard is
186 first used. In this definition, wildcard refers to resource records.
187 In other usage, wildcard has referred to domain names, and it has
188 been used to describe the operational practice of relying on
189 wildcards to generate answers. It is clear from this that there is a
190 need to define clear and unambiguous terminology in the process of
191 discussing wildcards.
193 The mention of the use of wildcards in the preparation of a response
194 is contained in step 3, part 'c' of RFC 1034's section 4.3.2,
195 entitled "Algorithm". Note that "wildcard" does not appear in the
196 algorithm, instead references are made to the "*" label. The portion
197 of the algorithm relating to wildcards is deconstructed in detail in
198 section 3 of this document; this is the beginning of the relevant
199 portion of the "Algorithm".
201 # c. If at some label, a match is impossible (i.e., the
202 # corresponding label does not exist), look to see if [...]
203 # the "*" label exists.
205 The scope of this document is the RFC 1034 definition of wildcards
206 and the implications of updates to those documents, such as DNS
207 Security (DNSSEC). Alternate schemes for synthesizing answers are
208 not considered. (Note that there is no reference listed. No
209 document is known to describe any alternate schemes, although there
210 has been some mention of them in mailing lists.)
2121.3. Roadmap to This Document
214 This document accomplishes these three tasks.
218 o Makes minor changes to avoid conflicting concepts
220 o Describes the actions of certain resource records as wildcards
226Lewis Standards Track [Page 4]
228RFC 4592 DNSEXT WCARD July 2006
233 To help in discussing what resource records are wildcards, two terms
234 will be defined: "asterisk label" and "wildcard domain name". These
235 are defined in section 2.1.1.
237 To assist in clarifying the role of wildcards in the name server
238 algorithm in RFC 1034, section 4.3.2, "source of synthesis" and
239 "closest encloser" are defined. These definitions are in section
240 3.3.1. "Label match" is defined in section 3.2.
242 The new terms are used to make discussions of wildcards clearer.
243 Terminology does not directly have an impact on implementations.
247 The definition of "existence" is changed superficially. This change
248 will not be apparent to implementations; it is needed to make
249 descriptions more precise. The change appears in section 2.2.3.
251 RFC 1034, section 4.3.3, seems to prohibit having two asterisk labels
252 in a wildcard owner name. With this document, the restriction is
253 removed entirely. This change and its implications are in section
256 The actions when a source of synthesis owns a CNAME RR are changed to
257 mirror the actions if an exact match name owns a CNAME RR. This is
258 an addition to the words in RFC 1034, section 4.3.2, step 3, part
259 'c'. The discussion of this is in section 3.3.3.
261 Only the latter change represents an impact to implementations. The
262 definition of existence is not a protocol impact. The change to the
263 restriction on names is unlikely to have an impact, as RFC 1034
264 contained no specification on when and how to enforce the
2671.3.3. Considerations with Special Types
269 This document describes semantics of wildcard RRSets for
270 "interesting" types as well as empty non-terminal wildcards.
271 Understanding these situations in the context of wildcards has been
272 clouded because these types incur special processing if they are the
273 result of an exact match. This discussion is in section 4.
275 These discussions do not have an implementation impact; they cover
276 existing knowledge of the types, but to a greater level of detail.
282Lewis Standards Track [Page 5]
284RFC 4592 DNSEXT WCARD July 2006
2871.4. Standards Terminology
289 This document does not use terms as defined in "Key words for use in
290 RFCs to Indicate Requirement Levels" [RFC2119].
292 Quotations of RFC 1034 are denoted by a '#' at the start of the line.
293 References to section "4.3.2" are assumed to refer to RFC 1034's
294 section 4.3.2, simply titled "Algorithm".
298 The syntax of a wildcard is the same as any other DNS resource
299 record, across all classes and types. The only significant feature
302 Because wildcards are encoded as resource records with special names,
303 they are included in zone transfers and incremental zone transfers
304 [RFC1995] just as non-wildcard resource records are. This feature
305 has been under appreciated until discussions on alternative
306 approaches to wildcards appeared on mailing lists.
3082.1. Identifying a Wildcard
310 To provide a more accurate description of wildcards, the definition
311 has to start with a discussion of the domain names that appear as
312 owners. Two new terms are needed, "asterisk label" and "wildcard
3152.1.1. Wildcard Domain Name and Asterisk Label
317 A "wildcard domain name" is defined by having its initial (i.e.,
318 leftmost or least significant) label be, in binary format:
320 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
322 The first octet is the normal label type and length for a 1-octet-
323 long label, and the second octet is the ASCII representation [RFC20]
324 for the '*' character.
326 A descriptive name of a label equaling that value is an "asterisk
329 RFC 1034's definition of wildcard would be "a resource record owned
330 by a wildcard domain name".
338Lewis Standards Track [Page 6]
340RFC 4592 DNSEXT WCARD July 2006
3432.1.2. Asterisks and Other Characters
345 No label values other than that in section 2.1.1 are asterisk labels,
346 hence names beginning with other labels are never wildcard domain
347 names. Labels such as 'the*' and '**' are not asterisk labels, so
348 these labels do not start wildcard domain names.
3502.1.3. Non-terminal Wildcard Domain Names
352 In section 4.3.3, the following is stated:
354 # .......................... The owner name of the wildcard RRs is
355 # of the form "*.<anydomain>", where <anydomain> is any domain name.
356 # <anydomain> should not contain other * labels......................
358 The restriction is now removed. The original documentation of it is
359 incomplete and the restriction does not serve any purpose given years
360 of operational experience.
362 There are three possible reasons for putting the restriction in
363 place, but none of the three has held up over time. One is that the
364 restriction meant that there would never be subdomains of wildcard
365 domain names, but the restriction as stated still permits
366 "example.*.example." for instance. Another is that wildcard domain
367 names are not intended to be empty non-terminals, but this situation
368 does not disrupt the algorithm in 4.3.2. Finally, "nested" wildcard
369 domain names are not ambiguous once the concept of the closest
370 encloser had been documented.
372 A wildcard domain name can have subdomains. There is no need to
373 inspect the subdomains to see if there is another asterisk label in
376 A wildcard domain name can be an empty non-terminal. (See the
377 upcoming sections on empty non-terminals.) In this case, any lookup
378 encountering it will terminate as would any empty non-terminal match.
382 The notion that a domain name 'exists' is mentioned in the definition
383 of wildcards. In section 4.3.3 of RFC 1034:
385 # Wildcard RRs do not apply:
388 # - When the query name or a name between the wildcard domain and
389 # the query name is know[n] to exist. . . .
394Lewis Standards Track [Page 7]
396RFC 4592 DNSEXT WCARD July 2006
399 "Existence" is therefore an important concept in the understanding of
400 wildcards. Unfortunately, the definition of what exists, in RFC
401 1034, is unclear. So, in sections 2.2.2. and 2.2.3, another look is
402 taken at the definition of existence.
406 To illustrate what is meant by existence consider this complete zone:
409 example. 3600 IN SOA <SOA RDATA>
410 example. 3600 NS ns.example.com.
411 example. 3600 NS ns.example.net.
412 *.example. 3600 TXT "this is a wildcard"
413 *.example. 3600 MX 10 host1.example.
414 sub.*.example. 3600 TXT "this is not a wildcard"
415 host1.example. 3600 A 192.0.2.1
416 _ssh._tcp.host1.example. 3600 SRV <SRV RDATA>
417 _ssh._tcp.host2.example. 3600 SRV <SRV RDATA>
418 subdel.example. 3600 NS ns.example.com.
419 subdel.example. 3600 NS ns.example.net.
421 A look at the domain names in a tree structure is helpful:
424 -------------example------------
436 The following responses would be synthesized from one of the
437 wildcards in the zone:
439 QNAME=host3.example. QTYPE=MX, QCLASS=IN
440 the answer will be a "host3.example. IN MX ..."
442 QNAME=host3.example. QTYPE=A, QCLASS=IN
443 the answer will reflect "no error, but no data"
444 because there is no A RR set at '*.example.'
450Lewis Standards Track [Page 8]
452RFC 4592 DNSEXT WCARD July 2006
455 QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
456 the answer will be "foo.bar.example. IN TXT ..."
457 because bar.example. does not exist, but the wildcard
460 The following responses would not be synthesized from any of the
461 wildcards in the zone:
463 QNAME=host1.example., QTYPE=MX, QCLASS=IN
464 because host1.example. exists
466 QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
467 because sub.*.example. exists
469 QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
470 because _tcp.host1.example. exists (without data)
472 QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
473 because subdel.example. exists (and is a zone cut)
475 QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
476 because *.example. exists
478 The final example highlights one common misconception about
479 wildcards. A wildcard "blocks itself" in the sense that a wildcard
480 does not match its own subdomains. That is, "*.example." does not
481 match all names in the "example." zone; it fails to match the names
482 below "*.example.". To cover names under "*.example.", another
483 wildcard domain name is needed--"*.*.example."--which covers all but
4862.2.2. Empty Non-terminals
488 Empty non-terminals [RFC2136, section 7.16] are domain names that own
489 no resource records but have subdomains that do. In section 2.2.1,
490 "_tcp.host1.example." is an example of an empty non-terminal name.
491 Empty non-terminals are introduced by this text in section 3.1 of RFC
494 # The domain name space is a tree structure. Each node and leaf on
495 # the tree corresponds to a resource set (which may be empty). The
496 # domain system makes no distinctions between the uses of the
497 # interior nodes and leaves, and this memo uses the term "node" to
500 The parenthesized "which may be empty" specifies that empty non-
501 terminals are explicitly recognized and that empty non-terminals
506Lewis Standards Track [Page 9]
508RFC 4592 DNSEXT WCARD July 2006
511 Pedantically reading the above paragraph can lead to an
512 interpretation that all possible domains exist--up to the suggested
513 limit of 255 octets for a domain name [RFC1035]. For example,
514 www.example. may have an A RR, and as far as is practically
515 concerned, is a leaf of the domain tree. But the definition can be
516 taken to mean that sub.www.example. also exists, albeit with no data.
517 By extension, all possible domains exist, from the root on down.
519 As RFC 1034 also defines "an authoritative name error indicating that
520 the name does not exist" in section 4.3.1, so this apparently is not
521 the intent of the original definition, justifying the need for an
522 updated definition in the next section.
5242.2.3. Yet Another Definition of Existence
526 RFC 1034's wording is fixed by the following paragraph:
528 The domain name space is a tree structure. Nodes in the tree either
529 own at least one RRSet and/or have descendants that collectively own
530 at least one RRSet. A node may exist with no RRSets only if it has
531 descendants that do; this node is an empty non-terminal.
533 A node with no descendants is a leaf node. Empty leaf nodes do not
536 Note that at a zone boundary, the domain name owns data, including
537 the NS RR set. In the delegating zone, the NS RR set is not
538 authoritative, but that is of no consequence here. The domain name
539 owns data; therefore, it exists.
5412.3. When Is a Wildcard Domain Name Not Special?
543 When a wildcard domain name appears in a message's query section, no
544 special processing occurs. An asterisk label in a query name only
545 matches a single, corresponding asterisk label in the existing zone
546 tree when the 4.3.2 algorithm is being followed.
548 When a wildcard domain name appears in the resource data of a record,
549 no special processing occurs. An asterisk label in that context
550 literally means just an asterisk.
5523. Impact of a Wildcard Domain Name on a Response
554 RFC 1034's description of how wildcards impact response generation is
555 in its section 4.3.2. That passage contains the algorithm followed
556 by a server in constructing a response. Within that algorithm, step
557 3, part 'c' defines the behavior of the wildcard.
562Lewis Standards Track [Page 10]
564RFC 4592 DNSEXT WCARD July 2006
567 The algorithm in section 4.3.2 is not intended to be pseudo-code;
568 that is, its steps are not intended to be followed in strict order.
569 The "algorithm" is a suggested means of implementing the
570 requirements. As such, in step 3, parts 'a', 'b', and 'c' do not
571 have to be implemented in that order, provided that the result of the
572 implemented code is compliant with the protocol's specification.
576 Step 2 of section 4.3.2 reads:
578 # 2. Search the available zones for the zone which is the nearest
579 # ancestor to QNAME. If such a zone is found, go to step 3,
582 In this step, the most appropriate zone for the response is chosen.
583 The significance of this step is that it means all of step 3 is being
584 performed within one zone. This has significance when considering
585 whether or not an SOA RR can ever be used for synthesis.
589 Step 3 is dominated by three parts, labeled 'a', 'b', and 'c'. But
590 the beginning of the step is important and needs explanation.
592 # 3. Start matching down, label by label, in the zone. The
593 # matching process can terminate several ways:
595 The word 'matching' refers to label matching. The concept is based
596 in the view of the zone as the tree of existing names. The query
597 name is considered to be an ordered sequence of labels--as if the
598 name were a path from the root to the owner of the desired data
599 (which it is--3rd paragraph of RFC 1034, section 3.1).
601 The process of label matching a query name ends in exactly one of
602 three choices, the parts 'a', 'b', and 'c'. Either the name is
603 found, the name is below a cut point, or the name is not found.
605 Once one of the parts is chosen, the other parts are not considered
606 (e.g., do not execute part 'c' and then change the execution path to
607 finish in part 'b'). The process of label matching is also done
608 independent of the query type (QTYPE).
610 Parts 'a' and 'b' are not an issue for this clarification as they do
611 not relate to record synthesis. Part 'a' is an exact match that
612 results in an answer; part 'b' is a referral.
618Lewis Standards Track [Page 11]
620RFC 4592 DNSEXT WCARD July 2006
625 The context of part 'c' is that the process of label matching the
626 labels of the query name has resulted in a situation in which there
627 is no corresponding label in the tree. It is as if the lookup has
628 "fallen off the tree".
630 # c. If at some label, a match is impossible (i.e., the
631 # corresponding label does not exist), look to see if [...]
632 # the "*" label exists.
634 To help describe the process of looking 'to see if [...] the "*"
635 label exists' a term has been coined to describe the last domain
636 (node) matched. The term is "closest encloser".
6383.3.1. Closest Encloser and the Source of Synthesis
640 The closest encloser is the node in the zone's tree of existing
641 domain names that has the most labels matching the query name
642 (consecutively, counting from the root label downward). Each match
643 is a "label match" and the order of the labels is the same.
645 The closest encloser is, by definition, an existing name in the zone.
646 The closest encloser might be an empty non-terminal or even be a
647 wildcard domain name itself. In no circumstances is the closest
648 encloser to be used to synthesize records for the current query.
650 The source of synthesis is defined in the context of a query process
651 as that wildcard domain name immediately descending from the closest
652 encloser, provided that this wildcard domain name exists.
653 "Immediately descending" means that the source of synthesis has a
656 <asterisk label>.<closest encloser>.
658 A source of synthesis does not guarantee having a RRSet to use for
659 synthesis. The source of synthesis could be an empty non-terminal.
661 If the source of synthesis does not exist (not on the domain tree),
662 there will be no wildcard synthesis. There is no search for an
665 The important concept is that for any given lookup process, there is
666 at most one place at which wildcard synthetic records can be
667 obtained. If the source of synthesis does not exist, the lookup
668 terminates, and the lookup does not look for other wildcard records.
674Lewis Standards Track [Page 12]
676RFC 4592 DNSEXT WCARD July 2006
6793.3.2. Closest Encloser and Source of Synthesis Examples
681 To illustrate, using the example zone in section 2.2.1 of this
682 document, the following chart shows QNAMEs and the closest enclosers.
684 QNAME Closest Encloser Source of Synthesis
685 host3.example. example. *.example.
686 _telnet._tcp.host1.example. _tcp.host1.example. no source
687 _dns._udp.host2.example. host2.example. no source
688 _telnet._tcp.host3.example. example. *.example.
689 _chat._udp.host3.example. example. *.example.
690 foobar.*.example. *.example. no source
694 RFC 1034 concludes part 'c' with this:
696 # If the "*" label does not exist, check whether the name
697 # we are looking for is the original QNAME in the query
698 # or a name we have followed due to a CNAME. If the name
699 # is original, set an authoritative name error in the
700 # response and exit. Otherwise just exit.
702 # If the "*" label does exist, match RRs at that node
703 # against QTYPE. If any match, copy them into the answer
704 # section, but set the owner of the RR to be QNAME, and
705 # not the node with the "*" label. Go to step 6.
707 The final paragraph covers the role of the QTYPE in the lookup
710 Based on implementation feedback and similarities between part 'a'
711 and part 'c', a change to this passage has been made.
713 The change is to add the following text to part 'c' prior to the
714 instructions to "go to step 6":
716 If the data at the source of synthesis is a CNAME, and QTYPE
717 doesn't match CNAME, copy the CNAME RR into the answer section of
718 the response changing the owner name to the QNAME, change QNAME to
719 the canonical name in the CNAME RR, and go back to step 1.
721 This is essentially the same text in part 'a' covering the processing
730Lewis Standards Track [Page 13]
732RFC 4592 DNSEXT WCARD July 2006
7354. Considerations with Special Types
737 Sections 2 and 3 of this document discuss wildcard synthesis with
738 respect to names in the domain tree and ignore the impact of types.
739 In this section, the implication of wildcards of specific types is
740 discussed. The types covered are those that have proven to be the
741 most difficult to understand. The types are SOA, NS, CNAME, DNAME,
742 SRV, DS, NSEC, RRSIG, and "none", that is, empty non-terminal
743 wildcard domain names.
7454.1. SOA RRSet at a Wildcard Domain Name
747 A wildcard domain name owning an SOA RRSet means that the domain is
748 at the root of the zone (apex). The domain cannot be a source of
749 synthesis because that is, by definition, a descendant node (of the
750 closest encloser) and a zone apex is at the top of the zone.
752 Although a wildcard domain name owning an SOA RRSet can never be a
753 source of synthesis, there is no reason to forbid the ownership of an
756 For example, given this zone:
759 @ 3600 IN SOA <SOA RDATA>
760 3600 NS ns1.example.com.
761 3600 NS ns1.example.net.
762 www 3600 TXT "the www txt record"
764 A query for www.*.example.'s TXT record would still find the "the www
765 txt record" answer. The asterisk label only becomes significant when
766 section 4.3.2, step 3, part 'c' is in effect.
768 Of course, there would need to be a delegation in the parent zone,
769 "example." for this to work too. This is covered in the next
7724.2. NS RRSet at a Wildcard Domain Name
774 With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now in
775 place, the semantics of a wildcard domain name owning an NS RRSet has
776 come to be poorly defined. The dilemma relates to a conflict between
777 the rules for synthesis in part 'c' and the fact that the resulting
778 synthesis generates a record for which the zone is not authoritative.
779 In a DNSSEC signed zone, the mechanics of signature management
780 (generation and inclusion in a message) have become unclear.
786Lewis Standards Track [Page 14]
788RFC 4592 DNSEXT WCARD July 2006
791 Salient points of the working group discussion on this topic are
792 summarized in section 4.2.1.
794 As a result of these discussions, there is no definition given for
795 wildcard domain names owning an NS RRSet. The semantics are left
796 undefined until there is a clear need to have a set defined, and
797 until there is a clear direction to proceed. Operationally,
798 inclusion of wildcard NS RRSets in a zone is discouraged, but not
8014.2.1. Discarded Notions
803 Prior to DNSSEC, a wildcard domain name owning a NS RRSet appeared to
804 be workable, and there are some instances in which it is found in
805 deployments using implementations that support this. Continuing to
806 allow this in the specification is not tenable with DNSSEC. The
807 reason is that the synthesis of the NS RRSet is being done in a zone
808 that has delegated away the responsibility for the name. This
809 "unauthorized" synthesis is not a problem for the base DNS protocol,
810 but DNSSEC in affirming the authorization model for DNS exposes the
813 Outright banning of wildcards of type NS is also untenable as the DNS
814 protocol does not define how to handle "illegal" data.
815 Implementations may choose not to load a zone, but there is no
816 protocol definition. The lack of the definition is complicated by
817 having to cover dynamic update [RFC2136] and zone transfers, as well
818 as loading at the master server. The case of a client (resolver,
819 caching server) getting a wildcard of type NS in a reply would also
820 have to be considered.
822 Given the daunting challenge of a complete definition of how to ban
823 such records, dealing with existing implementations that permit the
824 records today is a further complication. There are uses of wildcard
825 domain name owning NS RRSets.
827 One compromise proposed would have redefined wildcards of type NS to
828 not be used in synthesis, this compromise fell apart because it would
829 have required significant edits to the DNSSEC signing and validation
830 work. (Again, DNSSEC catches unauthorized data.)
832 With no clear consensus forming on the solution to this dilemma, and
833 the realization that wildcards of type NS are a rarity in operations,
834 the best course of action is to leave this open-ended until "it
842Lewis Standards Track [Page 15]
844RFC 4592 DNSEXT WCARD July 2006
8474.3. CNAME RRSet at a Wildcard Domain Name
849 The issue of a CNAME RRSet owned by a wildcard domain name has
850 prompted a suggested change to the last paragraph of step 3c of the
851 algorithm in 4.3.2. The changed text appears in section 3.3.3 of
8544.4. DNAME RRSet at a Wildcard Domain Name
856 Ownership of a DNAME [RFC2672] RRSet by a wildcard domain name
857 represents a threat to the coherency of the DNS and is to be avoided
858 or outright rejected. Such a DNAME RRSet represents non-
859 deterministic synthesis of rules fed to different caches. As caches
860 are fed the different rules (in an unpredictable manner) the caches
861 will cease to be coherent. ("As caches are fed" refers to the
862 storage in a cache of records obtained in responses by recursive or
865 For example, assume one cache, responding to a recursive request,
866 obtains the following record:
868 "a.b.example. DNAME foo.bar.example.net."
870 and another cache obtains:
872 "b.example. DNAME foo.bar.example.net."
874 both generated from the record:
876 "*.example. DNAME foo.bar.example.net."
878 by an authoritative server.
880 The DNAME specification is not clear on whether DNAME records in a
881 cache are used to rewrite queries. In some interpretations, the
882 rewrite occurs; in others, it does not. Allowing for the occurrence
883 of rewriting, queries for "sub.a.b.example. A" may be rewritten as
884 "sub.foo.bar.tld. A" by the former caching server and may be
885 rewritten as "sub.a.foo.bar.tld. A" by the latter. Coherency is
886 lost, and an operational nightmare ensues.
888 Another justification for a recommendation to avoid the use of
889 wildcard DNAME records is the observation that such a record could
890 synthesize a DNAME owned by "sub.foo.bar.example." and
891 "foo.bar.example.". There is a restriction in the DNAME definition
892 that no domain exist below a DNAME-owning domain; hence, the wildcard
893 DNAME is to be avoided.
898Lewis Standards Track [Page 16]
900RFC 4592 DNSEXT WCARD July 2006
9034.5. SRV RRSet at a Wildcard Domain Name
905 The definition of the SRV RRset is RFC 2782 [RFC2782]. In the
906 definition of the record, there is some confusion over the term
907 "Name". The definition reads as follows:
909 # The format of the SRV RR
911 # _Service._Proto.Name TTL Class SRV Priority Weight Port Target
914 # The domain this RR refers to. The SRV RR is unique in that the
915 # name one searches for is not this name; the example near the end
916 # shows this clearly.
918 Do not confuse the definition "Name" with the owner name. That is,
919 once removing the _Service and _Proto labels from the owner name of
920 the SRV RRSet, what remains could be a wildcard domain name but this
921 is immaterial to the SRV RRSet.
923 For example, if an SRV record is the following:
925 _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.
927 *.example is a wildcard domain name and although it is the Name of
928 the SRV RR, it is not the owner (domain name). The owner domain name
929 is "_foo._udp.*.example.", which is not a wildcard domain name.
931 A query for the SRV RRSet of "_foo._udp.bar.example." (class IN),
932 will result in a match of the name "*.example." (assuming there is no
933 bar.example.) and not a match of the SRV record shown. If there is
934 no SRV RRSet at "*.example.", the answer section will reflect that
935 (be empty or a CNAME RRset).
937 The confusion is likely based on the mixture of the specification of
938 the SRV RR and the description of a "use case".
9404.6. DS RRSet at a Wildcard Domain Name
942 A DS RRSet owned by a wildcard domain name is meaningless and
943 harmless. This statement is made in the context that an NS RRSet at
944 a wildcard domain name is undefined. At a non-delegation point, a DS
945 RRSet has no value (no corresponding DNSKEY RRSet will be used in
946 DNSSEC validation). If there is a synthesized DS RRSet, it alone
947 will not be very useful as it exists in the context of a delegation
954Lewis Standards Track [Page 17]
956RFC 4592 DNSEXT WCARD July 2006
9594.7. NSEC RRSet at a Wildcard Domain Name
961 Wildcard domain names in DNSSEC signed zones will have an NSEC RRSet.
962 Synthesis of these records will only occur when the query exactly
963 matches the record. Synthesized NSEC RRs will not be harmful as they
964 will never be used in negative caching or to generate a negative
9674.8. RRSIG at a Wildcard Domain Name
969 RRSIG records will be present at a wildcard domain name in a signed
970 zone and will be synthesized along with data sought in a query. The
971 fact that the owner name is synthesized is not a problem as the label
972 count in the RRSIG will instruct the verifying code to ignore it.
9744.9. Empty Non-terminal Wildcard Domain Name
976 If a source of synthesis is an empty non-terminal, then the response
977 will be one of no error in the return code and no RRSet in the answer
9805. Security Considerations
982 This document is refining the specifications to make it more likely
983 that security can be added to DNS. No functional additions are being
984 made, just refining what is considered proper to allow the DNS,
985 security of the DNS, and extending the DNS to be more predictable.
9896.1. Normative References
991 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,
994 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
995 STD 13, RFC 1034, November 1987.
997 [RFC1035] Mockapetris, P., "Domain names - implementation and
998 specification", STD 13, RFC 1035, November 1987.
1000 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
1003 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1004 Requirement Levels", BCP 14, RFC 2119, March 1997.
1010Lewis Standards Track [Page 18]
1012RFC 4592 DNSEXT WCARD July 2006
1015 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
1016 NCACHE)", RFC 2308, March 1998.
1018 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC
1021 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
1022 specifying the location of services (DNS SRV)", RFC 2782,
1025 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1026 Rose, "DNS Security Introduction and Requirements", RFC
1029 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1030 Rose, "Resource Records for the DNS Security Extensions",
1031 RFC 4034, March 2005.
1033 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
1034 Rose, "Protocol Modifications for the DNS Security
1035 Extensions", RFC 4035, March 2005.
10376.2. Informative References
1039 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
1040 Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
10437. Others Contributing to the Document
1045 This document represents the work of a large working group. The
1046 editor merely recorded its collective wisdom.
1048 Comments on this document can be sent to the editor or the mailing
1049 list for the DNSEXT WG, namedroppers@ops.ietf.org.
1055 46000 Center Oak Plaza
1059 Phone: +1-571-434-5468
1060 EMail: ed.lewis@neustar.biz
1066Lewis Standards Track [Page 19]
1068RFC 4592 DNSEXT WCARD July 2006
1071Full Copyright Statement
1073 Copyright (C) The Internet Society (2006).
1075 This document is subject to the rights, licenses and restrictions
1076 contained in BCP 78, and except as set forth therein, the authors
1077 retain all their rights.
1079 This document and the information contained herein are provided on an
1080 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1081 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1082 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1083 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1084 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1085 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1087Intellectual Property
1089 The IETF takes no position regarding the validity or scope of any
1090 Intellectual Property Rights or other rights that might be claimed to
1091 pertain to the implementation or use of the technology described in
1092 this document or the extent to which any license under such rights
1093 might or might not be available; nor does it represent that it has
1094 made any independent effort to identify any such rights. Information
1095 on the procedures with respect to rights in RFC documents can be
1096 found in BCP 78 and BCP 79.
1098 Copies of IPR disclosures made to the IETF Secretariat and any
1099 assurances of licenses to be made available, or the result of an
1100 attempt made to obtain a general license or permission for the use of
1101 such proprietary rights by implementers or users of this
1102 specification can be obtained from the IETF on-line IPR repository at
1103 http://www.ietf.org/ipr.
1105 The IETF invites any interested party to bring to its attention any
1106 copyrights, patents or patent applications, or other proprietary
1107 rights that may cover technology that may be required to implement
1108 this standard. Please address the information to the IETF at
1113 Funding for the RFC Editor function is provided by the IETF
1114 Administrative Support Activity (IASA).
1122Lewis Standards Track [Page 20]