draft-ietf-dnsext-wcard-clarify-09.txt   draft-ietf-dnsext-wcard-clarify-10.txt 
DNSEXT Working Group E. Lewis DNSEXT Working Group E. Lewis
INTERNET DRAFT NeuStar INTERNET DRAFT NeuStar
Expiration Date: February 28, 2006 August 31, 2005 Expiration Date: July 9, 2006 January 9, 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-09.txt draft-ietf-dnsext-wcard-clarify-10.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 February 28, 2006. This Internet-Draft will expire on July 9, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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 February 28, 2006 [Page 1] DNSEXT Working Group Expires July 9, 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
skipping to change at page 10, line ? skipping to change at page 10, line ?
4.7 NSEC RRSet at a Wild Card Domain Name 17 4.7 NSEC RRSet at a Wild Card Domain Name 17
4.8 RRSIG at a Wild Card Domain Name 17 4.8 RRSIG at a Wild Card Domain Name 17
4.9 Empty Non-terminal Wild Card Domain Name 17 4.9 Empty Non-terminal Wild Card 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 February 28, 2006 [Page 2] DNSEXT Working Group Expires July 9, 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 ?
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 February 28, 2006 [Page 3] DNSEXT Working Group Expires July 9, 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 February 28, 2006 [Page 4] DNSEXT Working Group Expires July 9, 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 February 28, 2006 [Page 5] DNSEXT Working Group Expires July 9, 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.
skipping to change at page 10, line ? skipping to change at page 10, line ?
names. names.
2.1.3 Non-terminal Wild Card Domain Names 2.1.3 Non-terminal Wild Card 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 February 28, 2006 [Page 6] DNSEXT Working Group Expires July 9, 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 wild card domain names, but the restriciton 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,
skipping to change at page 10, line ? skipping to change at page 10, line ?
"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 RFC
1034, is unclear. So, in sections 2.2.2. and 2.2.3, another look is 1034, is unclear. So, in sections 2.2.2. and 2.2.3, another look is
taken at the definition of existence. 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 February 28, 2006 [Page 7] DNSEXT Working Group Expires July 9, 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.4.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>
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 February 28, 2006 [Page 8] DNSEXT Working Group Expires July 9, 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
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 February 28, 2006 [Page 9] DNSEXT Working Group Expires July 9, 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 descendents that do, this node is an empty
non-terminal. non-terminal.
skipping to change at page 14, line 18 skipping to change at page 14, line 18
E.g., given this zone: E.g., given this zone:
$ORIGIN *.example. $ORIGIN *.example.
@ 3600 IN SOA <SOA RDATA> @ 3600 IN SOA <SOA RDATA>
3600 NS ns1.example.com. 3600 NS ns1.example.com.
3600 NS ns1.example.net. 3600 NS ns1.example.net.
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' in 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 Wild Card 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
skipping to change at page 17, line 15 skipping to change at page 17, line 15
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 Wild Card 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. generate a negative response. [RFC2308]
4.8 RRSIG at a Wild Card Domain Name 4.8 RRSIG at a Wild Card 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 Wild Card Domain Name
skipping to change at page 17, line 60 skipping to change at page 17, line 60
[RFC1034] Domain Names - Concepts and Facilities, [RFC1034] Domain Names - Concepts and Facilities,
P.V. Mockapetris, Nov-01-1987 P.V. Mockapetris, Nov-01-1987
[RFC1035] Domain Names - Implementation and Specification, P.V [RFC1035] Domain Names - Implementation and Specification, P.V
Mockapetris, Nov-01-1987 Mockapetris, Nov-01-1987
[RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996 [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996
[RFC2119] Key Words for Use in RFCs to Indicate Requirement [RFC2119] Key Words for Use in RFCs to Indicate Requirement
Levels, S Bradner, March 1997 Levels, S Bradner, March 1997
[RFC2181] Clarifications to the DNS Specification, R. Elz and
R. Bush, July 1997
[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
[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
[RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
August 1999
Informative References Informative References
[RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE), [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE),
P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
April 1997 April 1997
8. Editor 8. Editor
Name: Edward Lewis Name: Edward Lewis
Affiliation: NeuStar Affiliation: NeuStar
skipping to change at page 19, line ? skipping to change at page 19, line ?
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 the collective wisdom of the working group.
10. Trailing Boilerplate 10. Trailing Boilerplate
Copyright (C) The Internet Society (2005). 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
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
skipping to change at page 19, line ? skipping to change at page 19, line ?
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 February 28, 2006. This document expires on or about July 9, 2006.
 End of changes. 19 change blocks. 
22 lines changed or deleted 16 lines changed or added

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