draft-ietf-dnsext-wcard-clarify-10.txt   draft-ietf-dnsext-wcard-clarify-11.txt 
DNSEXT Working Group E. Lewis DNSEXT Working Group E. Lewis
INTERNET DRAFT NeuStar INTERNET DRAFT NeuStar
Expiration Date: July 9, 2006 January 9, 2006 Expiration Date: September 13, 2006 March 13, 2006
Updates RFC 1034, RFC 2672 Updates RFC 1034, RFC 2672
The Role of Wildcards The Role of Wildcards
in the Domain Name System in the Domain Name System
draft-ietf-dnsext-wcard-clarify-10.txt draft-ietf-dnsext-wcard-clarify-11.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 10, line ? skipping to change at page 10, line ?
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 9, 2006. This Internet-Draft will expire on September 13, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This is an update to the wildcard definition of RFC 1034. The This is an update to the wildcard definition of RFC 1034. The
interaction with wildcards and CNAME is changed, an error interaction with wildcards and CNAME is changed, an error
condition removed, and the words defining some concepts central condition removed, and the words defining some concepts central
to wildcards are changed. The overall goal is not to change to wildcards are changed. The overall goal is not to change
wildcards, but to refine the definition of RFC 1034. wildcards, but to refine the definition of RFC 1034.
DNSEXT Working Group Expires July 9, 2006 [Page 1] DNSEXT Working Group Expires September 13, 2006 [Page 1]
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . 3
1 1 Motivation 3 1 1 Motivation 3
1 2 The Original Definition 3 1 2 The Original Definition 3
1 3 Roadmap to This Document 4 1 3 Roadmap to This Document 4
1 3 1 New Terms 4 1 3 1 New Terms 4
1.3.2 Changed Text 5 1.3.2 Changed Text 5
1.3.3 Considerations with Special Types 5 1.3.3 Considerations with Special Types 5
1.4 Standards Terminology 5 1.4 Standards Terminology 5
2. Wildcard Syntax . . . . . . . . . . . . . . . 6 2. Wildcard Syntax . . . . . . . . . . . . . . . 6
2.1 Identifying a Wildcard 6 2.1 Identifying a Wildcard 6
2.1.1 Wild Card Domain Name and Asterisk Label 6 2.1.1 Wildcard Domain Name and Asterisk Label 6
2.1.2 Asterisks and Other Characters 6 2.1.2 Asterisks and Other Characters 6
2.1.3 Non-terminal Wild Card Domain Names 6 2.1.3 Non-terminal Wildcard Domain Names 6
2.2 Existence Rules 7 2.2 Existence Rules 7
2.2.1 An Example 7 2.2.1 An Example 7
2.2.2 Empty Non-terminals 9 2.2.2 Empty Non-terminals 9
2.2.3 Yet Another Definition of Existence 10 2.2.3 Yet Another Definition of Existence 10
2.3 When is a Wild Card Domain Name Not Special 10 2.3 When is a Wildcard Domain Name Not Special 10
3. Impact of a Wild Card Domain Name On a Response . . . . . 10 3. Impact of a Wildcard Domain Name On a Response . . . . . 10
3.1 Step 2 10 3.1 Step 2 10
3.2 Step 3 11 3.2 Step 3 11
3.3 Part 'c' 11 3.3 Part 'c' 11
3.3.1 Closest Encloser and the Source of Synthesis 12 3.3.1 Closest Encloser and the Source of Synthesis 12
3.3.2 Closest Encloser and Source of Synthesis Examples 12 3.3.2 Closest Encloser and Source of Synthesis Examples 12
3.3.3 Type Matching 13 3.3.3 Type Matching 13
4. Considerations with Special Types . . . . . . . . . 13 4. Considerations with Special Types . . . . . . . . . 13
4.1 SOA RRSet at a Wild Card Domain Name 13 4.1 SOA RRSet at a Wildcard Domain Name 13
4.2 NS RRSet at a Wild Card Domain Name 14 4.2 NS RRSet at a Wildcard Domain Name 14
4.2.1 Discarded Notions 14 4.2.1 Discarded Notions 14
4.3 CNAME RRSet at a Wild Card Domain Name 15 4.3 CNAME RRSet at a Wildcard Domain Name 15
4.4 DNAME RRSet at a Wild Card Domain Name 15 4.4 DNAME RRSet at a Wildcard Domain Name 15
4.5 SRV RRSet at a Wild Card Domain Name 16 4.5 SRV RRSet at a Wildcard Domain Name 16
4.6 DS RRSet at a Wild Card Domain Name 16 4.6 DS RRSet at a Wildcard Domain Name 17
4.7 NSEC RRSet at a Wild Card Domain Name 17 4.7 NSEC RRSet at a Wildcard Domain Name 17
4.8 RRSIG at a Wild Card Domain Name 17 4.8 RRSIG at a Wildcard Domain Name 17
4.9 Empty Non-terminal Wild Card Domain Name 17 4.9 Empty Non-terminal Wildcard Domain Name 17
5. Security Considerations . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . 17
8. Editor . . . . . . . . . . . . . 18 8. Editor . . . . . . . . . . . . . 18
9. Others Contributing to the Document . . . . . . . . 18 9. Others Contributing to the Document . . . . . . . . 18
10. Trailing Boilerplate . . . . . . . . . . . . . 19 10. Trailing Boilerplate . . . . . . . . . . . . . 19
DNSEXT Working Group Expires July 9, 2006 [Page 2] DNSEXT Working Group Expires September 13, 2006 [Page 2]
1. Introduction 1. Introduction
In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the
synthesis of answers from special resource records called synthesis of answers from special resource records called
wildcards. The definition in RFC 1034 is incomplete and has wildcards. The definition in RFC 1034 is incomplete and has
proven to be confusing. This document describes the wildcard proven to be confusing. This document describes the wildcard
synthesis by adding to the discussion and making limited synthesis by adding to the discussion and making limited
modifications. Modifications are made to close inconsistencies modifications. Modifications are made to close inconsistencies
that have led to interoperability issues. This description that have led to interoperability issues. This description
skipping to change at page 10, line ? skipping to change at page 10, line ?
Many DNS implementations diverge, in different ways, from the Many DNS implementations diverge, in different ways, from the
original definition of wildcards. Although there is clearly a original definition of wildcards. Although there is clearly a
need to clarify the original documents in light of this alone, need to clarify the original documents in light of this alone,
the impetus for this document lay in the engineering of the DNS the impetus for this document lay in the engineering of the DNS
security extensions [RFC4033]. With an unclear definition of security extensions [RFC4033]. With an unclear definition of
wildcards the design of authenticated denial became entangled. wildcards the design of authenticated denial became entangled.
This document is intended to limit its changes, documenting only This document is intended to limit its changes, documenting only
those based on implementation experience, and to remain as close those based on implementation experience, and to remain as close
to the original document as possible. To reinforce that this to the original document as possible. To reinforce that this
document is meant to clarify and adjust and not redefine wildcards, document is meant to clarify and adjust and not redefine
relevant sections of RFC 1034 are repeated verbatim to facilitate wildcards, relevant sections of RFC 1034 are repeated verbatim
comparison of the old and new text. to facilitate comparison of the old and new text.
1.2 The Original Definition 1.2 The Original Definition
The definition of the wildcard concept is comprised by the The definition of the wildcard concept is comprised by the
documentation of the algorithm by which a name server prepares documentation of the algorithm by which a name server prepares
a response (in RFC 1034's section 4.3.2) and the way in which a response (in RFC 1034's section 4.3.2) and the way in which
a resource record (set) is identified as being a source of a resource record (set) is identified as being a source of
synthetic data (section 4.3.3). synthetic data (section 4.3.3).
This is the definition of the term "wildcard" as it appears in This is the definition of the term "wildcard" as it appears in
RFC 1034, section 4.3.3. RFC 1034, section 4.3.3.
DNSEXT Working Group Expires July 9, 2006 [Page 3] DNSEXT Working Group Expires September 13, 2006 [Page 3]
# In the previous algorithm, special treatment was given to RRs with # In the previous algorithm, special treatment was given to RRs with
# owner names starting with the label "*". Such RRs are called # owner names starting with the label "*". Such RRs are called
# wildcards. Wildcard RRs can be thought of as instructions for # wildcards. Wildcard RRs can be thought of as instructions for
# synthesizing RRs. When the appropriate conditions are met, the name # synthesizing RRs. When the appropriate conditions are met, the name
# server creates RRs with an owner name equal to the query name and # server creates RRs with an owner name equal to the query name and
# contents taken from the wildcard RRs. # contents taken from the wildcard RRs.
This passage follows the algorithm in which the term wildcard This passage follows the algorithm in which the term wildcard
is first used. In this definition, wildcard refers to resource is first used. In this definition, wildcard refers to resource
skipping to change at page 10, line ? skipping to change at page 10, line ?
To help in discussing what resource records are wildcards, two To help in discussing what resource records are wildcards, two
terms will be defined - "asterisk label" and "wild card domain terms will be defined - "asterisk label" and "wild card domain
name". These are defined in section 2.1.1. name". These are defined in section 2.1.1.
To assist in clarifying the role of wildcards in the name server To assist in clarifying the role of wildcards in the name server
algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest
encloser" are defined. These definitions are in section 3.3.2. encloser" are defined. These definitions are in section 3.3.2.
"Label match" is defined in section 3.2. "Label match" is defined in section 3.2.
DNSEXT Working Group Expires July 9, 2006 [Page 4] DNSEXT Working Group Expires September 13, 2006 [Page 4]
The new terms are used to make discussions of wildcards clearer. The new terms are used to make discussions of wildcards clearer.
Terminology doesn't directly have an impact on implementations. Terminology doesn't directly have an impact on implementations.
1.3.2 Changed Text 1.3.2 Changed Text
The definition of "existence" is changed superficially. This The definition of "existence" is changed superficially. This
change will not be apparent to implementations; it is needed to change will not be apparent to implementations; it is needed to
make descriptions more precise. The change appears in section make descriptions more precise. The change appears in section
2.2.3. 2.2.3.
skipping to change at page 10, line ? skipping to change at page 10, line ?
1.4 Standards Terminology 1.4 Standards Terminology
This document does not use terms as defined in "Key words for use This document does not use terms as defined in "Key words for use
in RFCs to Indicate Requirement Levels." [RFC2119] in RFCs to Indicate Requirement Levels." [RFC2119]
Quotations of RFC 1034 are denoted by a '#' in the leftmost Quotations of RFC 1034 are denoted by a '#' in the leftmost
column. References to section "4.3.2" are assumed to refer column. References to section "4.3.2" are assumed to refer
to RFC 1034's section 4.3.2, simply titled "Algorithm." to RFC 1034's section 4.3.2, simply titled "Algorithm."
DNSEXT Working Group Expires July 9, 2006 [Page 5] DNSEXT Working Group Expires September 13, 2006 [Page 5]
2. Wildcard Syntax 2. Wildcard Syntax
The syntax of a wildcard is the same as any other DNS resource The syntax of a wildcard is the same as any other DNS resource
record, across all classes and types. The only significant record, across all classes and types. The only significant
feature is the owner name. feature is the owner name.
Because wildcards are encoded as resource records with special Because wildcards are encoded as resource records with special
names, they are included in zone transfers and incremental zone names, they are included in zone transfers and incremental zone
transfers[RFC1995] just as non-wildcard resource records are. transfers[RFC1995] just as non-wildcard resource records are.
This feature has been under appreciated until discussions on This feature has been under appreciated until discussions on
alternative approaches to wildcards appeared on mailing lists. alternative approaches to wildcards appeared on mailing lists.
2.1 Identifying a Wildcard 2.1 Identifying a Wildcard
To provide a more accurate description of wildcards, the To provide a more accurate description of wildcards, the
definition has to start with a discussion of the domain names definition has to start with a discussion of the domain names
that appear as owners. Two new terms are needed, "Asterisk that appear as owners. Two new terms are needed, "Asterisk
Label" and "Wild Card Domain Name." Label" and "Wildcard Domain Name."
2.1.1 Wild Card Domain Name and Asterisk Label 2.1.1 Wildcard Domain Name and Asterisk Label
A "wild card domain name" is defined by having its initial A "wild card domain name" is defined by having its initial
(i.e., left-most or least significant) label be, in binary format: (i.e., left-most or least significant) label be, in binary format:
0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
The first octet is the normal label type and length for a 1 octet The first octet is the normal label type and length for a 1 octet
long label, the second octet is the ASCII representation [RFC20] long label, the second octet is the ASCII representation [RFC20]
for the '*' character. for the '*' character.
A descriptive name of a label equaling that value is an "asterisk A descriptive name of a label equaling that value is an "asterisk
label." label."
RFC 1034's definition of wildcard would be "a resource record RFC 1034's definition of wildcard would be "a resource record
owned by a wild card domain name." owned by a wild card domain name."
2.1.2 Asterisks and Other Characters 2.1.2 Asterisks and Other Characters
No label values other than that in section 2.1.1 are asterisk No label values other than that in section 2.1.1 are asterisk
labels, hence names beginning with other labels are never wild labels, hence names beginning with other labels are never wildcard
card domain names. Labels such as 'the*' and '**' are not domain names. Labels such as 'the*' and '**' are not asterisk
asterisk labels so these labels do not start wild card domain labels so these labels do not start wildcard domain names.
names.
2.1.3 Non-terminal Wild Card Domain Names 2.1.3 Non-terminal Wildcard Domain Names
In section 4.3.3, the following is stated: In section 4.3.3, the following is stated:
# .......................... The owner name of the wildcard RRs is of # .......................... The owner name of the wildcard RRs is of
# the form "*.<anydomain>", where <anydomain> is any domain name. # the form "*.<anydomain>", where <anydomain> is any domain name.
# <anydomain> should not contain other * labels...................... # <anydomain> should not contain other * labels......................
DNSEXT Working Group Expires July 9, 2006 [Page 6] DNSEXT Working Group Expires September 13, 2006 [Page 6]
The restriction is now removed. The original documentation of it The restriction is now removed. The original documentation of it
is incomplete and the restriction does not serve any purpose is incomplete and the restriction does not serve any purpose
given years of operational experience. given years of operational experience.
There are three possible reasons for putting the restriction in There are three possible reasons for putting the restriction in
place, but none of the three has held up over time. One is place, but none of the three has held up over time. One is
that the restriction meant that there would never be subdomains that the restriction meant that there would never be subdomains
of wild card domain names, but the restriciton as stated still of wildcard domain names, but the restriction as stated still
permits "example.*.example." for instance. Another is that permits "example.*.example." for instance. Another is that
wild card domain names are not intended to be empty non-terminals, wild card domain names are not intended to be empty non-terminals,
but this situation does not disrupt the algorithm in 4.3.2. but this situation does not disrupt the algorithm in 4.3.2.
Finally, "nested" wild card domain names are not ambiguous once Finally, "nested" wild card domain names are not ambiguous once
the concept of the closest encloser had been documented. the concept of the closest encloser had been documented.
A wild card domain name can have subdomains. There is no need A wild card domain name can have subdomains. There is no need
to inspect the subdomains to see if there is another asterisk to inspect the subdomains to see if there is another asterisk
label in any subdomain. label in any subdomain.
skipping to change at page 10, line ? skipping to change at page 10, line ?
The notion that a domain name 'exists' is mentioned in the The notion that a domain name 'exists' is mentioned in the
definition of wildcards. In section 4.3.3 of RFC 1034: definition of wildcards. In section 4.3.3 of RFC 1034:
# Wildcard RRs do not apply: # Wildcard RRs do not apply:
# #
... ...
# - When the query name or a name between the wildcard domain and # - When the query name or a name between the wildcard domain and
# the query name is know[n] to exist. For example, if a wildcard # the query name is know[n] to exist. For example, if a wildcard
"Existence" is therefore an important concept in the understanding "Existence" is therefore an important concept in the understanding
of wildcards. Unfortunately, the definition of what exists, in RFC of wildcards. Unfortunately, the definition of what exists, in
1034, is unclear. So, in sections 2.2.2. and 2.2.3, another look is RFC 1034, is unclear. So, in sections 2.2.2. and 2.2.3, another
taken at the definition of existence. look is taken at the definition of existence.
2.2.1 An Example 2.2.1 An Example
To illustrate what is meant by existence consider this complete To illustrate what is meant by existence consider this complete
zone: zone:
DNSEXT Working Group Expires July 9, 2006 [Page 7] DNSEXT Working Group Expires September 13, 2006 [Page 7]
$ORIGIN example. $ORIGIN example.
example. 3600 IN SOA <SOA RDATA> example. 3600 IN SOA <SOA RDATA>
example. 3600 NS ns.example.com. example. 3600 NS ns.example.com.
example. 3600 NS ns.example.net. example. 3600 NS ns.example.net.
*.example. 3600 TXT "this is a wild card" *.example. 3600 TXT "this is a wild card"
*.example. 3600 MX 10 host1.example. *.example. 3600 MX 10 host1.example.
sub.*.example. 3600 TXT "this is not a wild card" sub.*.example. 3600 TXT "this is not a wild card"
host1.example. 3600 A 192.0.4.1 host1.example. 3600 A 192.0.2.1
_ssh._tcp.host1.example. 3600 SRV <SRV RDATA> _ssh._tcp.host1.example. 3600 SRV <SRV RDATA>
_ssh._tcp.host2.example. 3600 SRV <SRV RDATA> _ssh._tcp.host2.example. 3600 SRV <SRV RDATA>
subdel.example. 3600 NS ns.example.com. subdel.example. 3600 NS ns.example.com.
subdel.example. 3600 NS ns.example.net. subdel.example. 3600 NS ns.example.net.
A look at the domain names in a tree structure is helpful: A look at the domain names in a tree structure is helpful:
| |
-------------example------------ -------------example------------
/ / \ \ / / \ \
skipping to change at page 10, line ? skipping to change at page 10, line ?
The following responses would not be synthesized from any of the The following responses would not be synthesized from any of the
wildcards in the zone: wildcards in the zone:
QNAME=host1.example., QTYPE=MX, QCLASS=IN QNAME=host1.example., QTYPE=MX, QCLASS=IN
because host1.example. exists because host1.example. exists
QNAME=sub.*.example., QTYPE=MX, QCLASS=IN QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
because sub.*.example. exists because sub.*.example. exists
DNSEXT Working Group Expires July 9, 2006 [Page 8] DNSEXT Working Group Expires September 13, 2006 [Page 8]
QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
because _tcp.host1.example. exists (without data) because _tcp.host1.example. exists (without data)
QNAME=host.subdel.example., QTYPE=A, QCLASS=IN QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
because subdel.example. exists (and is a zone cut) because subdel.example. exists (and is a zone cut)
QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
because *.example. exists because *.example. exists
The final example highlights one common misconception about The final example highlights one common misconception about
wildcards. A wildcard "blocks itself" in the sense that a wildcards. A wildcard "blocks itself" in the sense that a
wildcard does not match its own subdomains. I.e. "*.example." wildcard does not match its own subdomains. I.e. "*.example."
does not match all names in the "example." zone, it fails to does not match all names in the "example." zone, it fails to
match the names below "*.example." To cover names under match the names below "*.example." To cover names under
"*.example.", another wild card domain name is needed - "*.example.", another wild card domain name is needed -
"*.*.example." - which covers all but it's own subdomains. "*.*.example." - which covers all but its own subdomains.
2.2.2 Empty Non-terminals 2.2.2 Empty Non-terminals
Empty non-terminals [RFC2136, Section 7.16] are domain names Empty non-terminals [RFC2136, Section 7.16] are domain names
that own no resource records but have subdomains that do. In that own no resource records but have subdomains that do. In
section 2.2.1, "_tcp.host1.example." is an example of a empty section 2.2.1, "_tcp.host1.example." is an example of a empty
non-terminal name. Empty non-terminals are introduced by this non-terminal name. Empty non-terminals are introduced by this
text in section 3.1 of RFC 1034: text in section 3.1 of RFC 1034:
# The domain name space is a tree structure. Each node and leaf on # The domain name space is a tree structure. Each node and leaf on
skipping to change at page 10, line ? skipping to change at page 10, line ?
practically concerned, is a leaf of the domain tree. But the practically concerned, is a leaf of the domain tree. But the
definition can be taken to mean that sub.www.example. also definition can be taken to mean that sub.www.example. also
exists, albeit with no data. By extension, all possible domains exists, albeit with no data. By extension, all possible domains
exist, from the root on down. exist, from the root on down.
As RFC 1034 also defines "an authoritative name error indicating As RFC 1034 also defines "an authoritative name error indicating
that the name does not exist" in section 4.3.1, so this apparently that the name does not exist" in section 4.3.1, so this apparently
is not the intent of the original definition, justifying the is not the intent of the original definition, justifying the
need for an updated definition in the next section. need for an updated definition in the next section.
DNSEXT Working Group Expires July 9, 2006 [Page 9] DNSEXT Working Group Expires September 13, 2006 [Page 9]
2.2.3 Yet Another Definition of Existence 2.2.3 Yet Another Definition of Existence
RFC1034's wording is fixed by the following paragraph: RFC1034's wording is fixed by the following paragraph:
The domain name space is a tree structure. Nodes in the tree The domain name space is a tree structure. Nodes in the tree
either own at least one RRSet and/or have descendants that either own at least one RRSet and/or have descendants that
collectively own at least one RRSet. A node may exist with no collectively own at least one RRSet. A node may exist with no
RRSets only if it has descendents that do, this node is an empty RRSets only if it has descendants that do; this node is an empty
non-terminal. non-terminal.
A node with no descendants is a leaf node. Empty leaf nodes do A node with no descendants is a leaf node. Empty leaf nodes do
not exist. not exist.
Note that at a zone boundary, the domain name owns data, Note that at a zone boundary, the domain name owns data,
including the NS RR set. In the delegating zone, the NS RR including the NS RR set. In the delegating zone, the NS RR
set is not authoritative, but that is of no consequence here. set is not authoritative, but that is of no consequence here.
The domain name owns data, therefore, it exists. The domain name owns data, therefore, it exists.
2.3 When is a Wild Card Domain Name Not Special 2.3 When is a Wildcard Domain Name Not Special
When a wild card domain name appears in a message's query section, When a wild card domain name appears in a message's query section,
no special processing occurs. An asterisk label in a query name no special processing occurs. An asterisk label in a query name
only matches a single, corresponding asterisk label in the only matches a single, corresponding asterisk label in the
existing zone tree when the 4.3.2 algorithm is being followed. existing zone tree when the 4.3.2 algorithm is being followed.
When a wild card domain name appears in the resource data of a When a wild card domain name appears in the resource data of a
record, no special processing occurs. An asterisk label in that record, no special processing occurs. An asterisk label in that
context literally means just an asterisk. context literally means just an asterisk.
3. Impact of a Wild Card Domain Name On a Response 3. Impact of a Wildcard Domain Name On a Response
RFC 1034's description of how wildcards impact response RFC 1034's description of how wildcards impact response
generation is in its section 4.3.2. That passage contains the generation is in its section 4.3.2. That passage contains the
algorithm followed by a server in constructing a response. algorithm followed by a server in constructing a response.
Within that algorithm, step 3, part 'c' defines the behavior of Within that algorithm, step 3, part 'c' defines the behavior of
the wildcard. the wildcard.
The algorithm in section 4.3.2. is not intended to be pseudo-code, The algorithm in section 4.3.2. is not intended to be pseudo-code,
i.e., its steps are not intended to be followed in strict order. i.e., its steps are not intended to be followed in strict order.
The "algorithm" is a suggested means of implementing the The "algorithm" is a suggested means of implementing the
skipping to change at page 12, line 46 skipping to change at page 12, line 46
3.3.2 Closest Encloser and Source of Synthesis Examples 3.3.2 Closest Encloser and Source of Synthesis Examples
To illustrate, using the example zone in section 2.2.1 of this To illustrate, using the example zone in section 2.2.1 of this
document, the following chart shows QNAMEs and the closest document, the following chart shows QNAMEs and the closest
enclosers. enclosers.
QNAME Closest Encloser Source of Synthesis QNAME Closest Encloser Source of Synthesis
host3.example. example. *.example. host3.example. example. *.example.
_telnet._tcp.host1.example. _tcp.host1.example. no source _telnet._tcp.host1.example. _tcp.host1.example. no source
_telnet._tcp.host2.example. host2.example. no source _dns._udp.host2.example. host2.example. no source
_telnet._tcp.host3.example. example. *.example. _telnet._tcp.host3.example. example. *.example.
_chat._udp.host3.example. example. *.example. _chat._udp.host3.example. example. *.example.
foobar.*.example. *.example. no source foobar.*.example. *.example. no source
3.3.3 Type Matching 3.3.3 Type Matching
RFC 1034 concludes part 'c' with this: RFC 1034 concludes part 'c' with this:
# If the "*" label does not exist, check whether the name # If the "*" label does not exist, check whether the name
# we are looking for is the original QNAME in the query # we are looking for is the original QNAME in the query
skipping to change at page 13, line 48 skipping to change at page 13, line 48
4. Considerations with Special Types 4. Considerations with Special Types
Sections 2 and 3 of this document discuss wildcard synthesis Sections 2 and 3 of this document discuss wildcard synthesis
with respect to names in the domain tree and ignore the impact with respect to names in the domain tree and ignore the impact
of types. In this section, the implication of wildcards of of types. In this section, the implication of wildcards of
specific types are discussed. The types covered are those specific types are discussed. The types covered are those
that have proven to be the most difficult to understand. The that have proven to be the most difficult to understand. The
types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and
"none," i.e., empty non-terminal wild card domain names. "none," i.e., empty non-terminal wild card domain names.
4.1 SOA RRSet at a Wild Card Domain Name 4.1 SOA RRSet at a Wildcard Domain Name
A wild card domain name owning an SOA RRSet means that the A wild card domain name owning an SOA RRSet means that the
domain is at the root of the zone (apex). The domain can not domain is at the root of the zone (apex). The domain can not
be a source of synthesis because that is, by definition, a be a source of synthesis because that is, by definition, a
descendent node (of the closest encloser) and a zone apex is descendent node (of the closest encloser) and a zone apex is
at the top of the zone. at the top of the zone.
Although a wild card domain name owning an SOA RRSet can never Although a wild card domain name owning an SOA RRSet can never
be a source of synthesis, there is no reason to forbid the be a source of synthesis, there is no reason to forbid the
ownership of an SOA RRSet. ownership of an SOA RRSet.
skipping to change at page 14, line 24 skipping to change at page 14, line 24
www 3600 TXT "the www txt record" www 3600 TXT "the www txt record"
A query for www.*.example.'s TXT record would still find the A query for www.*.example.'s TXT record would still find the
"the www txt record" answer. The asterisk label only becomes "the www txt record" answer. The asterisk label only becomes
significant when section 4.3.2, step 3 part 'c' is in effect. significant when section 4.3.2, step 3 part 'c' is in effect.
Of course, there would need to be a delegation in the parent Of course, there would need to be a delegation in the parent
zone, "example." for this to work too. This is covered in the zone, "example." for this to work too. This is covered in the
next section. next section.
4.2 NS RRSet at a Wild Card Domain Name 4.2 NS RRSet at a Wildcard Domain Name
With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now
in place, the semantics of a wild card domain name owning an in place, the semantics of a wild card domain name owning an
NS RRSet has come to be poorly defined. The dilemma relates to NS RRSet has come to be poorly defined. The dilemma relates to
a conflict between the rules for synthesis in part 'c' and the a conflict between the rules for synthesis in part 'c' and the
fact that the resulting synthesis generates a record for which fact that the resulting synthesis generates a record for which
the zone is not authoritative. In a DNSSEC signed zone, the the zone is not authoritative. In a DNSSEC signed zone, the
mechanics of signature management (generation and inclusion mechanics of signature management (generation and inclusion
in a message) have become unclear. in a message) have become unclear.
skipping to change at page 15, line 30 skipping to change at page 15, line 30
NS to not be used in synthesis, this compromise fell apart NS to not be used in synthesis, this compromise fell apart
because it would have required significant edits to the DNSSEC because it would have required significant edits to the DNSSEC
signing and validation work. (Again, DNSSEC catches signing and validation work. (Again, DNSSEC catches
unauthorized data.) unauthorized data.)
With no clear consensus forming on the solution to this dilemma, With no clear consensus forming on the solution to this dilemma,
and the realization that wildcards of type NS are a rarity in and the realization that wildcards of type NS are a rarity in
operations, the best course of action is to leave this open-ended operations, the best course of action is to leave this open-ended
until "it matters." until "it matters."
4.3 CNAME RRSet at a Wild Card Domain Name 4.3 CNAME RRSet at a Wildcard Domain Name
The issue of a CNAME RRSet owned by a wild card domain name has The issue of a CNAME RRSet owned by a wild card domain name has
prompted a suggested change to the last paragraph of step 3c of prompted a suggested change to the last paragraph of step 3c of
the algorithm in 4.3.2. The changed text appears in section the algorithm in 4.3.2. The changed text appears in section
3.3.3 of this document. 3.3.3 of this document.
4.4 DNAME RRSet at a Wild Card Domain Name 4.4 DNAME RRSet at a Wildcard Domain Name
Ownership of a DNAME [RFC2672] RRSet by a wild card domain name Ownership of a DNAME [RFC2672] RRSet by a wild card domain name
represents a threat to the coherency of the DNS and is to be represents a threat to the coherency of the DNS and is to be
avoided or outright rejected. Such a DNAME RRSet represents avoided or outright rejected. Such a DNAME RRSet represents
non-deterministic synthesis of rules fed to different caches. non-deterministic synthesis of rules fed to different caches.
As caches are fed the different rules (in an unpredictable As caches are fed the different rules (in an unpredictable
manner) the caches will cease to be coherent. ("As caches manner) the caches will cease to be coherent. ("As caches
are fed" refers to the storage in a cache of records obtained are fed" refers to the storage in a cache of records obtained
in responses by recursive or iterative servers.) in responses by recursive or iterative servers.)
skipping to change at page 16, line 13 skipping to change at page 16, line 13
by an authoritative server. by an authoritative server.
The DNAME specification is not clear on whether DNAME records The DNAME specification is not clear on whether DNAME records
in a cache are used to rewrite queries. In some interpretations, in a cache are used to rewrite queries. In some interpretations,
the rewrite occurs, in some, it is not. Allowing for the the rewrite occurs, in some, it is not. Allowing for the
occurrence of rewriting, queries for "sub.a.b.example. A" may occurrence of rewriting, queries for "sub.a.b.example. A" may
be rewritten as "sub.foo.bar.tld. A" by the former caching be rewritten as "sub.foo.bar.tld. A" by the former caching
server and may be rewritten as "sub.a.foo.bar.tld. A" by the server and may be rewritten as "sub.a.foo.bar.tld. A" by the
latter. Coherency is lost, an operational nightmare ensues. latter. Coherency is lost, an operational nightmare ensues.
Another justification for banning or avoiding wildcard DNAME Another justification for a recommendation to avoid the use of
records is the observation that such a record could synthesize wildcard DNAME records is the observation that such a record
a DNAME owned by "sub.foo.bar.example." and "foo.bar.example." could synthesize a DNAME owned by "sub.foo.bar.example." and
There is a restriction in the DNAME definition that no domain "foo.bar.example." There is a restriction in the DNAME
exist below a DNAME-owning domain, hence, the wildcard DNAME definition that no domain exist below a DNAME-owning domain,
is not to be permitted. hence, the wildcard DNAME is to be avoided.
4.5 SRV RRSet at a Wild Card Domain Name 4.5 SRV RRSet at a Wildcard Domain Name
The definition of the SRV RRset is RFC 2782 [RFC2782]. In the The definition of the SRV RRset is RFC 2782 [RFC2782]. In the
definition of the record, there is some confusion over the term definition of the record, there is some confusion over the term
"Name." The definition reads as follows: "Name." The definition reads as follows:
# The format of the SRV RR # The format of the SRV RR
... ...
# _Service._Proto.Name TTL Class SRV Priority Weight Port Target # _Service._Proto.Name TTL Class SRV Priority Weight Port Target
... ...
# Name # Name
skipping to change at page 16, line 48 skipping to change at page 16, line 48
but this is immaterial to the SRV RRSet. but this is immaterial to the SRV RRSet.
E.g., If an SRV record is: E.g., If an SRV record is:
_foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example. _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.
*.example is a wild card domain name and although it is the Name *.example is a wild card domain name and although it is the Name
of the SRV RR, it is not the owner (domain name). The owner of the SRV RR, it is not the owner (domain name). The owner
domain name is "_foo._udp.*.example." which is not a wild card domain name is "_foo._udp.*.example." which is not a wild card
domain name. domain name.
A query for the SRV RRSet of "_foo._udp.bar.example." (class IN),
will result in a match of the name "*.example." (assuming there
is no bar.example.) and not a match of the SRV record shown. If
there is no SRV RRSet at "*.example." the answer section will
reflect that (be empty or a CNAME RRset).
The confusion is likely based on the mixture of the specification The confusion is likely based on the mixture of the specification
of the SRV RR and the description of a "use case." of the SRV RR and the description of a "use case."
4.6 DS RRSet at a Wild Card Domain Name 4.6 DS RRSet at a Wildcard Domain Name
A DS RRSet owned by a wild card domain name is meaningless and A DS RRSet owned by a wild card domain name is meaningless and
harmless. This statement is made in the context that an NS RRSet harmless. This statement is made in the context that an NS RRSet
at a wild card domain name is undefined. At a non-delegation at a wild card domain name is undefined. At a non-delegation
point, a DS RRSet has no value (no corresponding DNSKEY RRSet point, a DS RRSet has no value (no corresponding DNSKEY RRSet
will be used in DNSSEC validation). If there is a synthesized will be used in DNSSEC validation). If there is a synthesized
DS RRSet, it alone will not be very useful as it exists in the DS RRSet, it alone will not be very useful as it exists in the
context of a delegation point. context of a delegation point.
4.7 NSEC RRSet at a Wild Card Domain Name 4.7 NSEC RRSet at a Wildcard Domain Name
Wild card domain names in DNSSEC signed zones will have an NSEC Wild card domain names in DNSSEC signed zones will have an NSEC
RRSet. Synthesis of these records will only occur when the RRSet. Synthesis of these records will only occur when the
query exactly matches the record. Synthesized NSEC RR's will not query exactly matches the record. Synthesized NSEC RR's will not
be harmful as they will never be used in negative caching or to be harmful as they will never be used in negative caching or to
generate a negative response. [RFC2308] generate a negative response. [RFC2308]
4.8 RRSIG at a Wild Card Domain Name 4.8 RRSIG at a Wildcard Domain Name
RRSIG records will be present at a wild card domain name in a RRSIG records will be present at a wild card domain name in a
signed zone, and will be synthesized along with data sought in a signed zone, and will be synthesized along with data sought in a
query. The fact that the owner name is synthesized is not a query. The fact that the owner name is synthesized is not a
problem as the label count in the RRSIG will instruct the problem as the label count in the RRSIG will instruct the
verifying code to ignore it. verifying code to ignore it.
4.9 Empty Non-terminal Wild Card Domain Name 4.9 Empty Non-terminal Wildcard Domain Name
If a source of synthesis is an empty non-terminal, then the If a source of synthesis is an empty non-terminal, then the
response will be one of no error in the return code and no RRSet response will be one of no error in the return code and no RRSet
in the answer section. in the answer section.
5. Security Considerations 5. Security Considerations
This document is refining the specifications to make it more This document is refining the specifications to make it more
likely that security can be added to DNS. No functional likely that security can be added to DNS. No functional
additions are being made, just refining what is considered additions are being made, just refining what is considered
skipping to change at page 17, line 69 skipping to change at page 18, line 24
[RFC2308] Negative Caching of DNS Queries (DNS NCACHE), [RFC2308] Negative Caching of DNS Queries (DNS NCACHE),
M. Andrews, March 1998 M. Andrews, March 1998
[RFC2672] Non-Terminal DNS Name Redirection, M. Crawford, [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
August 1999. August 1999.
[RFC2782] A DNS RR for specifying the location of services (DNS [RFC2782] A DNS RR for specifying the location of services (DNS
SRV), A. Gulbrandsen, et.al., February 2000 SRV), A. Gulbrandsen, et.al., February 2000
[RFC3978] IETF Rights in Contributions, S. Bradner, March 2005
[RFC4033] DNS Security Introduction and Requirements, R. Arends, [RFC4033] DNS Security Introduction and Requirements, R. Arends,
et.al., March 2005 et.al., March 2005
[RFC4034] Resource Records for the DNS Security Extensions, [RFC4034] Resource Records for the DNS Security Extensions,
R. Arends, et.al., March 2005 R. Arends, et.al., March 2005
[RFC4035] Protocol Modifications for the DNS Security Extensions, [RFC4035] Protocol Modifications for the DNS Security Extensions,
R. Arends, et.al., March 2005 R. Arends, et.al., March 2005
Informative References Informative References
skipping to change at page 17, line 92 skipping to change at page 18, line 49
April 1997 April 1997
8. Editor 8. Editor
Name: Edward Lewis Name: Edward Lewis
Affiliation: NeuStar Affiliation: NeuStar
Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US
Phone: +1-571-434-5468 Phone: +1-571-434-5468
Email: ed.lewis@neustar.biz Email: ed.lewis@neustar.biz
As required by law, as stated in RFC 3978, Section 3.4,
subsection a [RFC3978], this section comprises an
"Authors Section."
Comments on this document can be sent to the editor or the mailing Comments on this document can be sent to the editor or the mailing
list for the DNSEXT WG, namedroppers@ops.ietf.org. list for the DNSEXT WG, namedroppers@ops.ietf.org.
9. Others Contributing to the Document 9. Others Contributing to the Document
This document represents the work of a large working group. The This document represents the work of a large working group. The
editor merely recorded the collective wisdom of the working group. editor merely recorded its collective wisdom.
As required by law, as stated in RFC 3978, Section 3.4,
subsection a [RFC3978], this section comprises an
"Acknowledgements Section."
10. Trailing Boilerplate 10. Trailing Boilerplate
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided This document and the information contained herein are provided
skipping to change at page 19, line ? skipping to change at page 20, line 12
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Expiration Expiration
This document expires on or about July 9, 2006. This document expires on or about September 13, 2006.
 End of changes. 45 change blocks. 
61 lines changed or deleted 76 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/