1 Internet-Draft dnsext-wcard January 9, 2006
3 DNSEXT Working Group E. Lewis
5 Expiration Date: July 9, 2006 January 9, 2006
6 Updates RFC 1034, RFC 2672
9 in the Domain Name System
10 draft-ietf-dnsext-wcard-clarify-10.txt
14 By submitting this Internet-Draft, each author represents that
15 any applicable patent or other IPR claims of which he or she is
16 aware have been or will be disclosed, and any of which he or she
17 becomes aware will be disclosed, in accordance with Section 6 of
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as Internet-
25 Internet-Drafts are draft documents valid for a maximum of six
26 months and may be updated, replaced, or obsoleted by other
27 documents at any time. It is inappropriate to use Internet-Drafts
28 as reference material or to cite them other than as "work in
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html
37 This Internet-Draft will expire on July 9, 2006.
41 Copyright (C) The Internet Society (2006).
45 This is an update to the wildcard definition of RFC 1034. The
46 interaction with wildcards and CNAME is changed, an error
47 condition removed, and the words defining some concepts central
48 to wildcards are changed. The overall goal is not to change
49 wildcards, but to refine the definition of RFC 1034.
54 DNSEXT Working Group Expires July 9, 2006 [Page 1]
56 Internet-Draft dnsext-wcard January 9, 2006
60 1. Introduction . . . . . . . . . . . . . . . . 3
62 1 2 The Original Definition 3
63 1 3 Roadmap to This Document 4
66 1.3.3 Considerations with Special Types 5
67 1.4 Standards Terminology 5
68 2. Wildcard Syntax . . . . . . . . . . . . . . . 6
69 2.1 Identifying a Wildcard 6
70 2.1.1 Wild Card Domain Name and Asterisk Label 6
71 2.1.2 Asterisks and Other Characters 6
72 2.1.3 Non-terminal Wild Card Domain Names 6
75 2.2.2 Empty Non-terminals 9
76 2.2.3 Yet Another Definition of Existence 10
77 2.3 When is a Wild Card Domain Name Not Special 10
78 3. Impact of a Wild Card Domain Name On a Response . . . . . 10
82 3.3.1 Closest Encloser and the Source of Synthesis 12
83 3.3.2 Closest Encloser and Source of Synthesis Examples 12
84 3.3.3 Type Matching 13
85 4. Considerations with Special Types . . . . . . . . . 13
86 4.1 SOA RRSet at a Wild Card Domain Name 13
87 4.2 NS RRSet at a Wild Card Domain Name 14
88 4.2.1 Discarded Notions 14
89 4.3 CNAME RRSet at a Wild Card Domain Name 15
90 4.4 DNAME RRSet at a Wild Card Domain Name 15
91 4.5 SRV RRSet at a Wild Card Domain Name 16
92 4.6 DS RRSet at a Wild Card Domain Name 16
93 4.7 NSEC RRSet at a Wild Card Domain Name 17
94 4.8 RRSIG at a Wild Card Domain Name 17
95 4.9 Empty Non-terminal Wild Card Domain Name 17
96 5. Security Considerations . . . . . . . . . . . . . 17
97 6. IANA Considerations . . . . . . . . . . . . . 17
98 7. References . . . . . . . . . . . . . 17
99 8. Editor . . . . . . . . . . . . . 18
100 9. Others Contributing to the Document . . . . . . . . 18
101 10. Trailing Boilerplate . . . . . . . . . . . . . 19
110 DNSEXT Working Group Expires July 9, 2006 [Page 2]
112 Internet-Draft dnsext-wcard January 9, 2006
116 In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the
117 synthesis of answers from special resource records called
118 wildcards. The definition in RFC 1034 is incomplete and has
119 proven to be confusing. This document describes the wildcard
120 synthesis by adding to the discussion and making limited
121 modifications. Modifications are made to close inconsistencies
122 that have led to interoperability issues. This description
123 does not expand the service intended by the original definition.
125 Staying within the spirit and style of the original documents,
126 this document avoids specifying rules for DNS implementations
127 regarding wildcards. The intention is to only describe what is
128 needed for interoperability, not restrict implementation choices.
129 In addition, consideration is given to minimize any backwards
130 compatibility issues with implementations that comply with RFC
133 This document is focused on the concept of wildcards as defined
134 in RFC 1034. Nothing is implied regarding alternative means of
135 synthesizing resource record sets, nor are alternatives discussed.
139 Many DNS implementations diverge, in different ways, from the
140 original definition of wildcards. Although there is clearly a
141 need to clarify the original documents in light of this alone,
142 the impetus for this document lay in the engineering of the DNS
143 security extensions [RFC4033]. With an unclear definition of
144 wildcards the design of authenticated denial became entangled.
146 This document is intended to limit its changes, documenting only
147 those based on implementation experience, and to remain as close
148 to the original document as possible. To reinforce that this
149 document is meant to clarify and adjust and not redefine wildcards,
150 relevant sections of RFC 1034 are repeated verbatim to facilitate
151 comparison of the old and new text.
153 1.2 The Original Definition
155 The definition of the wildcard concept is comprised by the
156 documentation of the algorithm by which a name server prepares
157 a response (in RFC 1034's section 4.3.2) and the way in which
158 a resource record (set) is identified as being a source of
159 synthetic data (section 4.3.3).
161 This is the definition of the term "wildcard" as it appears in
162 RFC 1034, section 4.3.3.
166 DNSEXT Working Group Expires July 9, 2006 [Page 3]
168 Internet-Draft dnsext-wcard January 9, 2006
170 # In the previous algorithm, special treatment was given to RRs with
171 # owner names starting with the label "*". Such RRs are called
172 # wildcards. Wildcard RRs can be thought of as instructions for
173 # synthesizing RRs. When the appropriate conditions are met, the name
174 # server creates RRs with an owner name equal to the query name and
175 # contents taken from the wildcard RRs.
177 This passage follows the algorithm in which the term wildcard
178 is first used. In this definition, wildcard refers to resource
179 records. In other usage, wildcard has referred to domain names,
180 and it has been used to describe the operational practice of
181 relying on wildcards to generate answers. It is clear from this
182 that there is a need to define clear and unambiguous terminology
183 in the process of discussing wildcards.
185 The mention of the use of wildcards in the preparation of a
186 response is contained in step 3c of RFC 1034's section 4.3.2
187 entitled "Algorithm." Note that "wildcard" does not appear in
188 the algorithm, instead references are made to the "*" label.
189 The portion of the algorithm relating to wildcards is
190 deconstructed in detail in section 3 of this document, this is
191 the beginning of the relevant portion of the "Algorithm."
193 # c. If at some label, a match is impossible (i.e., the
194 # corresponding label does not exist), look to see if [...]
195 # the "*" label exists.
197 The scope of this document is the RFC 1034 definition of
198 wildcards and the implications of updates to those documents,
199 such as DNSSEC. Alternate schemes for synthesizing answers are
200 not considered. (Note that there is no reference listed. No
201 document is known to describe any alternate schemes, although
202 there has been some mention of them in mailing lists.)
204 1.3 Roadmap to This Document
206 This document accomplishes these three items.
208 o Makes minor changes to avoid conflicting concepts
209 o Describes the actions of certain resource records as wildcards
213 To help in discussing what resource records are wildcards, two
214 terms will be defined - "asterisk label" and "wild card domain
215 name". These are defined in section 2.1.1.
217 To assist in clarifying the role of wildcards in the name server
218 algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest
219 encloser" are defined. These definitions are in section 3.3.2.
220 "Label match" is defined in section 3.2.
222 DNSEXT Working Group Expires July 9, 2006 [Page 4]
224 Internet-Draft dnsext-wcard January 9, 2006
226 The new terms are used to make discussions of wildcards clearer.
227 Terminology doesn't directly have an impact on implementations.
231 The definition of "existence" is changed superficially. This
232 change will not be apparent to implementations; it is needed to
233 make descriptions more precise. The change appears in section
236 RFC 1034, section 4.3.3., seems to prohibit having two asterisk
237 labels in a wildcard owner name. With this document the
238 restriction is removed entirely. This change and its implications
239 are in section 2.1.3.
241 The actions when a source of synthesis owns a CNAME RR are
242 changed to mirror the actions if an exact match name owns a
243 CNAME RR. This is an addition to the words in RFC 1034,
244 section 4.3.2, step 3, part c. The discussion of this is in
247 Only the latter change represents an impact to implementations.
248 The definition of existence is not a protocol impact. The change
249 to the restriction on names is unlikely to have an impact, as
250 RFC 1034 contained no specification on when and how to enforce the
253 1.3.3 Considerations with Special Types
255 This document describes semantics of wildcard RRSets for
256 "interesting" types as well as empty non-terminal wildcards.
257 Understanding these situations in the context of wildcards has
258 been clouded because these types incur special processing if
259 they are the result of an exact match. This discussion is in
262 These discussions do not have an implementation impact, they cover
263 existing knowledge of the types, but to a greater level of detail.
265 1.4 Standards Terminology
267 This document does not use terms as defined in "Key words for use
268 in RFCs to Indicate Requirement Levels." [RFC2119]
270 Quotations of RFC 1034 are denoted by a '#' in the leftmost
271 column. References to section "4.3.2" are assumed to refer
272 to RFC 1034's section 4.3.2, simply titled "Algorithm."
278 DNSEXT Working Group Expires July 9, 2006 [Page 5]
280 Internet-Draft dnsext-wcard January 9, 2006
284 The syntax of a wildcard is the same as any other DNS resource
285 record, across all classes and types. The only significant
286 feature is the owner name.
288 Because wildcards are encoded as resource records with special
289 names, they are included in zone transfers and incremental zone
290 transfers[RFC1995] just as non-wildcard resource records are.
291 This feature has been under appreciated until discussions on
292 alternative approaches to wildcards appeared on mailing lists.
294 2.1 Identifying a Wildcard
296 To provide a more accurate description of wildcards, the
297 definition has to start with a discussion of the domain names
298 that appear as owners. Two new terms are needed, "Asterisk
299 Label" and "Wild Card Domain Name."
301 2.1.1 Wild Card Domain Name and Asterisk Label
303 A "wild card domain name" is defined by having its initial
304 (i.e., left-most or least significant) label be, in binary format:
306 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
308 The first octet is the normal label type and length for a 1 octet
309 long label, the second octet is the ASCII representation [RFC20]
310 for the '*' character.
312 A descriptive name of a label equaling that value is an "asterisk
315 RFC 1034's definition of wildcard would be "a resource record
316 owned by a wild card domain name."
318 2.1.2 Asterisks and Other Characters
320 No label values other than that in section 2.1.1 are asterisk
321 labels, hence names beginning with other labels are never wild
322 card domain names. Labels such as 'the*' and '**' are not
323 asterisk labels so these labels do not start wild card domain
326 2.1.3 Non-terminal Wild Card Domain Names
328 In section 4.3.3, the following is stated:
330 # .......................... The owner name of the wildcard RRs is of
331 # the form "*.<anydomain>", where <anydomain> is any domain name.
332 # <anydomain> should not contain other * labels......................
334 DNSEXT Working Group Expires July 9, 2006 [Page 6]
336 Internet-Draft dnsext-wcard January 9, 2006
338 The restriction is now removed. The original documentation of it
339 is incomplete and the restriction does not serve any purpose
340 given years of operational experience.
342 There are three possible reasons for putting the restriction in
343 place, but none of the three has held up over time. One is
344 that the restriction meant that there would never be subdomains
345 of wild card domain names, but the restriciton as stated still
346 permits "example.*.example." for instance. Another is that
347 wild card domain names are not intended to be empty non-terminals,
348 but this situation does not disrupt the algorithm in 4.3.2.
349 Finally, "nested" wild card domain names are not ambiguous once
350 the concept of the closest encloser had been documented.
352 A wild card domain name can have subdomains. There is no need
353 to inspect the subdomains to see if there is another asterisk
354 label in any subdomain.
356 A wild card domain name can be an empty non-terminal. (See the
357 upcoming sections on empty non-terminals.) In this case, any
358 lookup encountering it will terminate as would any empty
363 The notion that a domain name 'exists' is mentioned in the
364 definition of wildcards. In section 4.3.3 of RFC 1034:
366 # Wildcard RRs do not apply:
369 # - When the query name or a name between the wildcard domain and
370 # the query name is know[n] to exist. For example, if a wildcard
372 "Existence" is therefore an important concept in the understanding
373 of wildcards. Unfortunately, the definition of what exists, in RFC
374 1034, is unclear. So, in sections 2.2.2. and 2.2.3, another look is
375 taken at the definition of existence.
379 To illustrate what is meant by existence consider this complete
390 DNSEXT Working Group Expires July 9, 2006 [Page 7]
392 Internet-Draft dnsext-wcard January 9, 2006
395 example. 3600 IN SOA <SOA RDATA>
396 example. 3600 NS ns.example.com.
397 example. 3600 NS ns.example.net.
398 *.example. 3600 TXT "this is a wild card"
399 *.example. 3600 MX 10 host1.example.
400 sub.*.example. 3600 TXT "this is not a wild card"
401 host1.example. 3600 A 192.0.4.1
402 _ssh._tcp.host1.example. 3600 SRV <SRV RDATA>
403 _ssh._tcp.host2.example. 3600 SRV <SRV RDATA>
404 subdel.example. 3600 NS ns.example.com.
405 subdel.example. 3600 NS ns.example.net.
407 A look at the domain names in a tree structure is helpful:
410 -------------example------------
422 The following responses would be synthesized from one of the
423 wildcards in the zone:
425 QNAME=host3.example. QTYPE=MX, QCLASS=IN
426 the answer will be a "host3.example. IN MX ..."
428 QNAME=host3.example. QTYPE=A, QCLASS=IN
429 the answer will reflect "no error, but no data"
430 because there is no A RR set at '*.example.'
432 QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
433 the answer will be "foo.bar.example. IN TXT ..."
434 because bar.example. does not exist, but the wildcard
437 The following responses would not be synthesized from any of the
438 wildcards in the zone:
440 QNAME=host1.example., QTYPE=MX, QCLASS=IN
441 because host1.example. exists
443 QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
444 because sub.*.example. exists
446 DNSEXT Working Group Expires July 9, 2006 [Page 8]
448 Internet-Draft dnsext-wcard January 9, 2006
450 QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
451 because _tcp.host1.example. exists (without data)
453 QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
454 because subdel.example. exists (and is a zone cut)
456 QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
457 because *.example. exists
459 The final example highlights one common misconception about
460 wildcards. A wildcard "blocks itself" in the sense that a
461 wildcard does not match its own subdomains. I.e. "*.example."
462 does not match all names in the "example." zone, it fails to
463 match the names below "*.example." To cover names under
464 "*.example.", another wild card domain name is needed -
465 "*.*.example." - which covers all but it's own subdomains.
467 2.2.2 Empty Non-terminals
469 Empty non-terminals [RFC2136, Section 7.16] are domain names
470 that own no resource records but have subdomains that do. In
471 section 2.2.1, "_tcp.host1.example." is an example of a empty
472 non-terminal name. Empty non-terminals are introduced by this
473 text in section 3.1 of RFC 1034:
475 # The domain name space is a tree structure. Each node and leaf on
476 # the tree corresponds to a resource set (which may be empty). The
477 # domain system makes no distinctions between the uses of the
478 # interior nodes and leaves, and this memo uses the term "node" to
481 The parenthesized "which may be empty" specifies that empty non-
482 terminals are explicitly recognized, and that empty non-terminals
485 Pedantically reading the above paragraph can lead to an
486 interpretation that all possible domains exist - up to the
487 suggested limit of 255 octets for a domain name [RFC1035].
488 For example, www.example. may have an A RR, and as far as is
489 practically concerned, is a leaf of the domain tree. But the
490 definition can be taken to mean that sub.www.example. also
491 exists, albeit with no data. By extension, all possible domains
492 exist, from the root on down.
494 As RFC 1034 also defines "an authoritative name error indicating
495 that the name does not exist" in section 4.3.1, so this apparently
496 is not the intent of the original definition, justifying the
497 need for an updated definition in the next section.
502 DNSEXT Working Group Expires July 9, 2006 [Page 9]
504 Internet-Draft dnsext-wcard January 9, 2006
506 2.2.3 Yet Another Definition of Existence
508 RFC1034's wording is fixed by the following paragraph:
510 The domain name space is a tree structure. Nodes in the tree
511 either own at least one RRSet and/or have descendants that
512 collectively own at least one RRSet. A node may exist with no
513 RRSets only if it has descendents that do, this node is an empty
516 A node with no descendants is a leaf node. Empty leaf nodes do
519 Note that at a zone boundary, the domain name owns data,
520 including the NS RR set. In the delegating zone, the NS RR
521 set is not authoritative, but that is of no consequence here.
522 The domain name owns data, therefore, it exists.
524 2.3 When is a Wild Card Domain Name Not Special
526 When a wild card domain name appears in a message's query section,
527 no special processing occurs. An asterisk label in a query name
528 only matches a single, corresponding asterisk label in the
529 existing zone tree when the 4.3.2 algorithm is being followed.
531 When a wild card domain name appears in the resource data of a
532 record, no special processing occurs. An asterisk label in that
533 context literally means just an asterisk.
535 3. Impact of a Wild Card Domain Name On a Response
537 RFC 1034's description of how wildcards impact response
538 generation is in its section 4.3.2. That passage contains the
539 algorithm followed by a server in constructing a response.
540 Within that algorithm, step 3, part 'c' defines the behavior of
543 The algorithm in section 4.3.2. is not intended to be pseudo-code,
544 i.e., its steps are not intended to be followed in strict order.
545 The "algorithm" is a suggested means of implementing the
546 requirements. As such, in step 3, parts a, b, and c, do not have
547 to be implemented in that order, provided that the result of the
548 implemented code is compliant with the protocol's specification.
552 Step 2 of section 4.3.2 reads:
554 # 2. Search the available zones for the zone which is the nearest
555 # ancestor to QNAME. If such a zone is found, go to step 3,
558 DNSEXT Working Group Expires July 9, 2006 [Page 10]
560 Internet-Draft dnsext-wcard January 9, 2006
562 In this step, the most appropriate zone for the response is
563 chosen. The significance of this step is that it means all of
564 step 3 is being performed within one zone. This has significance
565 when considering whether or not an SOA RR can be ever be used for
570 Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'.
571 But the beginning of the step is important and needs explanation.
573 # 3. Start matching down, label by label, in the zone. The
574 # matching process can terminate several ways:
576 The word 'matching' refers to label matching. The concept
577 is based in the view of the zone as the tree of existing names.
578 The query name is considered to be an ordered sequence of
579 labels - as if the name were a path from the root to the owner
580 of the desired data. (Which it is - 3rd paragraph of RFC 1034,
583 The process of label matching a query name ends in exactly one of
584 three choices, the parts 'a', 'b', and 'c'. Either the name is
585 found, the name is below a cut point, or the name is not found.
587 Once one of the parts is chosen, the other parts are not
588 considered. (E.g., do not execute part 'c' and then change
589 the execution path to finish in part 'b'.) The process of label
590 matching is also done independent of the query type (QTYPE).
592 Parts 'a' and 'b' are not an issue for this clarification as they
593 do not relate to record synthesis. Part 'a' is an exact match
594 that results in an answer, part 'b' is a referral.
598 The context of part 'c' is that the process of label matching the
599 labels of the query name has resulted in a situation in which
600 there is no corresponding label in the tree. It is as if the
601 lookup has "fallen off the tree."
603 # c. If at some label, a match is impossible (i.e., the
604 # corresponding label does not exist), look to see if [...]
605 # the "*" label exists.
607 To help describe the process of looking 'to see if [...] the "*"
608 label exists' a term has been coined to describe the last domain
609 (node) matched. The term is "closest encloser."
614 DNSEXT Working Group Expires July 9, 2006 [Page 11]
616 Internet-Draft dnsext-wcard January 9, 2006
618 3.3.1 Closest Encloser and the Source of Synthesis
620 The closest encloser is the node in the zone's tree of existing
621 domain names that has the most labels matching the query name
622 (consecutively, counting from the root label downward). Each match
623 is a "label match" and the order of the labels is the same.
625 The closest encloser is, by definition, an existing name in the
626 zone. The closest encloser might be an empty non-terminal or even
627 be a wild card domain name itself. In no circumstances is the
628 closest encloser to be used to synthesize records for the current
631 The source of synthesis is defined in the context of a query
632 process as that wild card domain name immediately descending
633 from the closest encloser, provided that this wild card domain
634 name exists. "Immediately descending" means that the source
635 of synthesis has a name of the form:
636 <asterisk label>.<closest encloser>.
637 A source of synthesis does not guarantee having a RRSet to use
638 for synthesis. The source of synthesis could be an empty
641 If the source of synthesis does not exist (not on the domain
642 tree), there will be no wildcard synthesis. There is no search
645 The important concept is that for any given lookup process, there
646 is at most one place at which wildcard synthetic records can be
647 obtained. If the source of synthesis does not exist, the lookup
648 terminates, the lookup does not look for other wildcard records.
650 3.3.2 Closest Encloser and Source of Synthesis Examples
652 To illustrate, using the example zone in section 2.2.1 of this
653 document, the following chart shows QNAMEs and the closest
656 QNAME Closest Encloser Source of Synthesis
657 host3.example. example. *.example.
658 _telnet._tcp.host1.example. _tcp.host1.example. no source
659 _telnet._tcp.host2.example. host2.example. no source
660 _telnet._tcp.host3.example. example. *.example.
661 _chat._udp.host3.example. example. *.example.
662 foobar.*.example. *.example. no source
670 DNSEXT Working Group Expires July 9, 2006 [Page 12]
672 Internet-Draft dnsext-wcard January 9, 2006
676 RFC 1034 concludes part 'c' with this:
678 # If the "*" label does not exist, check whether the name
679 # we are looking for is the original QNAME in the query
680 # or a name we have followed due to a CNAME. If the name
681 # is original, set an authoritative name error in the
682 # response and exit. Otherwise just exit.
684 # If the "*" label does exist, match RRs at that node
685 # against QTYPE. If any match, copy them into the answer
686 # section, but set the owner of the RR to be QNAME, and
687 # not the node with the "*" label. Go to step 6.
689 The final paragraph covers the role of the QTYPE in the lookup
692 Based on implementation feedback and similarities between step
693 'a' and step 'c' a change to this passage has been made.
695 The change is to add the following text to step 'c' prior to the
696 instructions to "go to step 6":
698 If the data at the source of synthesis is a CNAME, and
699 QTYPE doesn't match CNAME, copy the CNAME RR into the
700 answer section of the response changing the owner name
701 to the QNAME, change QNAME to the canonical name in the
702 CNAME RR, and go back to step 1.
704 This is essentially the same text in step a covering the
705 processing of CNAME RRSets.
707 4. Considerations with Special Types
709 Sections 2 and 3 of this document discuss wildcard synthesis
710 with respect to names in the domain tree and ignore the impact
711 of types. In this section, the implication of wildcards of
712 specific types are discussed. The types covered are those
713 that have proven to be the most difficult to understand. The
714 types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and
715 "none," i.e., empty non-terminal wild card domain names.
717 4.1 SOA RRSet at a Wild Card Domain Name
719 A wild card domain name owning an SOA RRSet means that the
720 domain is at the root of the zone (apex). The domain can not
721 be a source of synthesis because that is, by definition, a
722 descendent node (of the closest encloser) and a zone apex is
723 at the top of the zone.
726 DNSEXT Working Group Expires July 9, 2006 [Page 13]
728 Internet-Draft dnsext-wcard January 9, 2006
730 Although a wild card domain name owning an SOA RRSet can never
731 be a source of synthesis, there is no reason to forbid the
732 ownership of an SOA RRSet.
734 E.g., given this zone:
736 @ 3600 IN SOA <SOA RDATA>
737 3600 NS ns1.example.com.
738 3600 NS ns1.example.net.
739 www 3600 TXT "the www txt record"
741 A query for www.*.example.'s TXT record would still find the
742 "the www txt record" answer. The asterisk label only becomes
743 significant when section 4.3.2, step 3 part 'c' is in effect.
745 Of course, there would need to be a delegation in the parent
746 zone, "example." for this to work too. This is covered in the
749 4.2 NS RRSet at a Wild Card Domain Name
751 With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now
752 in place, the semantics of a wild card domain name owning an
753 NS RRSet has come to be poorly defined. The dilemma relates to
754 a conflict between the rules for synthesis in part 'c' and the
755 fact that the resulting synthesis generates a record for which
756 the zone is not authoritative. In a DNSSEC signed zone, the
757 mechanics of signature management (generation and inclusion
758 in a message) have become unclear.
760 Salient points of the working group discussion on this topic is
761 summarized in section 4.2.1.
763 As a result of these discussion, there is no definition given for
764 wild card domain names owning an NS RRSet. The semantics are
765 left undefined until there is a clear need to have a set defined,
766 and until there is a clear direction to proceed. Operationally,
767 inclusion of wild card NS RRSets in a zone is discouraged, but
770 4.2.1 Discarded Notions
772 Prior to DNSSEC, a wild card domain name owning a NS RRSet
773 appeared to be workable, and there are some instances in which
774 it is found in deployments using implementations that support
775 this. Continuing to allow this in the specification is not
776 tenable with DNSSEC. The reason is that the synthesis of the
777 NS RRSet is being done in a zone that has delegated away the
778 responsibility for the name. This "unauthorized" synthesis is
779 not a problem for the base DNS protocol, but DNSSEC, in affirming
780 the authorization model for DNS exposes the problem.
782 DNSEXT Working Group Expires July 9, 2006 [Page 14]
784 Internet-Draft dnsext-wcard January 9, 2006
786 Outright banning of wildcards of type NS is also untenable as
787 the DNS protocol does not define how to handle "illegal" data.
788 Implementations may choose not to load a zone, but there is no
789 protocol definition. The lack of the definition is complicated
790 by having to cover dynamic update [RFC 2136], zone transfers,
791 as well as loading at the master server. The case of a client
792 (resolver, caching server) getting a wildcard of type NS in
793 a reply would also have to be considered.
795 Given the daunting challenge of a complete definition of how to
796 ban such records, dealing with existing implementations that
797 permit the records today is a further complication. There are
798 uses of wild card domain name owning NS RRSets.
800 One compromise proposed would have redefined wildcards of type
801 NS to not be used in synthesis, this compromise fell apart
802 because it would have required significant edits to the DNSSEC
803 signing and validation work. (Again, DNSSEC catches
806 With no clear consensus forming on the solution to this dilemma,
807 and the realization that wildcards of type NS are a rarity in
808 operations, the best course of action is to leave this open-ended
811 4.3 CNAME RRSet at a Wild Card Domain Name
813 The issue of a CNAME RRSet owned by a wild card domain name has
814 prompted a suggested change to the last paragraph of step 3c of
815 the algorithm in 4.3.2. The changed text appears in section
816 3.3.3 of this document.
818 4.4 DNAME RRSet at a Wild Card Domain Name
820 Ownership of a DNAME [RFC2672] RRSet by a wild card domain name
821 represents a threat to the coherency of the DNS and is to be
822 avoided or outright rejected. Such a DNAME RRSet represents
823 non-deterministic synthesis of rules fed to different caches.
824 As caches are fed the different rules (in an unpredictable
825 manner) the caches will cease to be coherent. ("As caches
826 are fed" refers to the storage in a cache of records obtained
827 in responses by recursive or iterative servers.)
829 For example, assume one cache, responding to a recursive
830 request, obtains the record:
831 "a.b.example. DNAME foo.bar.example.net."
832 and another cache obtains:
833 "b.example. DNAME foo.bar.example.net."
834 both generated from the record:
835 "*.example. DNAME foo.bar.example.net."
836 by an authoritative server.
838 DNSEXT Working Group Expires July 9, 2006 [Page 15]
840 Internet-Draft dnsext-wcard January 9, 2006
842 The DNAME specification is not clear on whether DNAME records
843 in a cache are used to rewrite queries. In some interpretations,
844 the rewrite occurs, in some, it is not. Allowing for the
845 occurrence of rewriting, queries for "sub.a.b.example. A" may
846 be rewritten as "sub.foo.bar.tld. A" by the former caching
847 server and may be rewritten as "sub.a.foo.bar.tld. A" by the
848 latter. Coherency is lost, an operational nightmare ensues.
850 Another justification for banning or avoiding wildcard DNAME
851 records is the observation that such a record could synthesize
852 a DNAME owned by "sub.foo.bar.example." and "foo.bar.example."
853 There is a restriction in the DNAME definition that no domain
854 exist below a DNAME-owning domain, hence, the wildcard DNAME
855 is not to be permitted.
857 4.5 SRV RRSet at a Wild Card Domain Name
859 The definition of the SRV RRset is RFC 2782 [RFC2782]. In the
860 definition of the record, there is some confusion over the term
861 "Name." The definition reads as follows:
863 # The format of the SRV RR
865 # _Service._Proto.Name TTL Class SRV Priority Weight Port Target
868 # The domain this RR refers to. The SRV RR is unique in that the
869 # name one searches for is not this name; the example near the end
870 # shows this clearly.
872 Do not confuse the definition "Name" with the owner name. I.e.,
873 once removing the _Service and _Proto labels from the owner name
874 of the SRV RRSet, what remains could be a wild card domain name
875 but this is immaterial to the SRV RRSet.
877 E.g., If an SRV record is:
878 _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.
880 *.example is a wild card domain name and although it is the Name
881 of the SRV RR, it is not the owner (domain name). The owner
882 domain name is "_foo._udp.*.example." which is not a wild card
885 The confusion is likely based on the mixture of the specification
886 of the SRV RR and the description of a "use case."
888 4.6 DS RRSet at a Wild Card Domain Name
890 A DS RRSet owned by a wild card domain name is meaningless and
891 harmless. This statement is made in the context that an NS RRSet
892 at a wild card domain name is undefined. At a non-delegation
894 DNSEXT Working Group Expires July 9, 2006 [Page 16]
896 Internet-Draft dnsext-wcard January 9, 2006
898 point, a DS RRSet has no value (no corresponding DNSKEY RRSet
899 will be used in DNSSEC validation). If there is a synthesized
900 DS RRSet, it alone will not be very useful as it exists in the
901 context of a delegation point.
903 4.7 NSEC RRSet at a Wild Card Domain Name
905 Wild card domain names in DNSSEC signed zones will have an NSEC
906 RRSet. Synthesis of these records will only occur when the
907 query exactly matches the record. Synthesized NSEC RR's will not
908 be harmful as they will never be used in negative caching or to
909 generate a negative response. [RFC2308]
911 4.8 RRSIG at a Wild Card Domain Name
913 RRSIG records will be present at a wild card domain name in a
914 signed zone, and will be synthesized along with data sought in a
915 query. The fact that the owner name is synthesized is not a
916 problem as the label count in the RRSIG will instruct the
917 verifying code to ignore it.
919 4.9 Empty Non-terminal Wild Card Domain Name
921 If a source of synthesis is an empty non-terminal, then the
922 response will be one of no error in the return code and no RRSet
923 in the answer section.
925 5. Security Considerations
927 This document is refining the specifications to make it more
928 likely that security can be added to DNS. No functional
929 additions are being made, just refining what is considered
930 proper to allow the DNS, security of the DNS, and extending
931 the DNS to be more predictable.
933 6. IANA Considerations
941 [RFC20] ASCII Format for Network Interchange, V.G. Cerf,
944 [RFC1034] Domain Names - Concepts and Facilities,
945 P.V. Mockapetris, Nov-01-1987
947 [RFC1035] Domain Names - Implementation and Specification, P.V
948 Mockapetris, Nov-01-1987
950 DNSEXT Working Group Expires July 9, 2006 [Page 17]
952 Internet-Draft dnsext-wcard January 9, 2006
954 [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996
956 [RFC2119] Key Words for Use in RFCs to Indicate Requirement
957 Levels, S Bradner, March 1997
959 [RFC2308] Negative Caching of DNS Queries (DNS NCACHE),
960 M. Andrews, March 1998
962 [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
965 [RFC2782] A DNS RR for specifying the location of services (DNS
966 SRV), A. Gulbrandsen, et.al., February 2000
968 [RFC4033] DNS Security Introduction and Requirements, R. Arends,
971 [RFC4034] Resource Records for the DNS Security Extensions,
972 R. Arends, et.al., March 2005
974 [RFC4035] Protocol Modifications for the DNS Security Extensions,
975 R. Arends, et.al., March 2005
977 Informative References
979 [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE),
980 P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
987 Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US
988 Phone: +1-571-434-5468
989 Email: ed.lewis@neustar.biz
991 Comments on this document can be sent to the editor or the mailing
992 list for the DNSEXT WG, namedroppers@ops.ietf.org.
994 9. Others Contributing to the Document
996 This document represents the work of a large working group. The
997 editor merely recorded the collective wisdom of the working group.
1007 DNSEXT Working Group Expires July 9, 2006 [Page 17]
1009 Internet-Draft dnsext-wcard January 9, 2006
1011 10. Trailing Boilerplate
1013 Copyright (C) The Internet Society (2006).
1015 This document is subject to the rights, licenses and restrictions
1016 contained in BCP 78, and except as set forth therein, the authors
1017 retain all their rights.
1019 This document and the information contained herein are provided
1020 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
1021 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
1022 SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
1023 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
1024 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
1025 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1026 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1028 Intellectual Property
1030 The IETF takes no position regarding the validity or scope of
1031 any Intellectual Property Rights or other rights that might
1032 be claimed to pertain to the implementation or use of the
1033 technology described in this document or the extent to which
1034 any license under such rights might or might not be available;
1035 nor does it represent that it has made any independent effort
1036 to identify any such rights. Information on the procedures
1037 with respect to rights in RFC documents can be found in BCP 78
1040 Copies of IPR disclosures made to the IETF Secretariat and any
1041 assurances of licenses to be made available, or the result of an
1042 attempt made to obtain a general license or permission for the
1043 use of such proprietary rights by implementers or users of this
1044 specification can be obtained from the IETF on-line IPR
1045 repository at http://www.ietf.org/ipr. The IETF invites any
1046 interested party to bring to its attention any copyrights,
1047 patents or patent applications, or other proprietary rights
1048 that may cover technology that may be required to implement
1049 this standard. Please address the information to the IETF at
1054 Funding for the RFC Editor function is currently provided by the
1059 This document expires on or about July 9, 2006.
1063 DNSEXT Working Group Expires July 9, 2006 [Page 19]