draft-ietf-dnsext-wcard-clarify-00.txt   draft-ietf-dnsext-wcard-clarify-01.txt 
Internet Engineering Task Force B. Halley Internet Engineering Task Force B. Halley
Internet-Draft Nominum Internet-Draft Nominum
E. Lewis E. Lewis
ARIN ARIN
June 17, 2003 Expires: December 17, 2003 August 10, 2003 Expires: February 10, 2004
Clarifying the Role of Wild Card Domains Clarifying the Role of Wild Card Domains
in the Domain Name System in the Domain Name System
<draft-ietf-dnsext-wcard-clarify-00.txt> <draft-ietf-dnsext-wcard-clarify-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at line 32 skipping to change at line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in 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.
Comments on this document can be sent to the editors or the mailing
list for the DNSEXT WG, namedroppers@ops.ietf.org.
Abstract Abstract
The definition of wild cards is recast from the original in RFC 1034, The definition of wild cards is recast from the original in RFC 1034,
in words that are more specific and in line with RFC 2119. This document in words that are more specific and in line with RFC 2119. This document
is meant to supplement the definition in RFC 1034 and to alter neither is meant to supplement the definition in RFC 1034 and to alter neither
the spirit nor intent of that definition. the spirit nor intent of that definition.
1 Introduction 1 Introduction
The first section of this document will give a crisp overview of what The first section of this document will give a crisp overview of what
is begin defined, as well as the motivation for what amounts to a is begin defined, as well as the motivation rewording of an original document
simple rewording of an original document. Examples are included to and making a change to bring the specification in line with implementations.
help orient the reader. Examples are included to help orient the reader.
Wild card domain names are defined in Section 4.3.3. of RFC 1034 as Wild card domain names are defined in Section 4.3.3. of RFC 1034 as
"instructions for synthesizing RRs." [RFC1034] The meaning of this is "instructions for synthesizing RRs." [RFC1034] The meaning of this is
that a specific, special domain name is used to construct responses in that a specific, special domain name is used to construct responses in
instances in which the query name is not otherwise represented in a zone. instances in which the query name is not otherwise represented in a zone.
A wild card domain name has a specific range of influence on query names A wild card domain name has a specific range of influence on query names
(QNAMEs) within a given class, which is rooted at the domain name (QNAMEs) within a given class, which is rooted at the domain name
containing the wild card label, and is limited by explicit entries, zone containing the wild card label, and is limited by explicit entries, zone
cuts and empty non-terminal domains (see section 1.3 of this document). cuts and empty non-terminal domains (see section 1.3 of this document).
Note that a wild card domain name has no special impact on the search Note that a wild card domain name has no special impact on the search
for a query type (QTYPE). If a domain name is found that matches the for a query type (QTYPE). If a domain name is found that matches the
QNAME (exact or a wild card) but the QTYPE is not found at that point, QNAME (exact or a wild card) but the QTYPE is not found at that point,
the proper response is that there is no data available. The search the proper response is that there is no data available. The search
does not continue on to seek other wild cards that might match the QTYPE. does not continue on to seek other wild cards that might match the QTYPE.
To illustrate, a wild card owning an MX RR does not 'cover' other names To illustrate, a wild card owning an MX RR does not 'cover' other names
in the zone that own an A RR. in the zone that own an A RR. There are certain special case RR types
that will be singled out for discussion, the SOA RR, NS RR, CNAME RR,
and DNAME RR.
Why is this document needed? Empirical evidence suggests that the Why is this document needed? Empirical evidence suggests that the
words in RFC 1034 are not clear enough. There exist a number of words in RFC 1034 are not clear enough. There exist a number of
implementations that have strayed (each differently) from that definition. implementations that have strayed (each differently) from that definition.
There also exists a misconception of operators that the wild card can be There also exists a misconception of operators that the wild card can be
used to add a specific RR type to all names, such as the MX RR example used to add a specific RR type to all names, such as the MX RR example
cited above. This document is also needed as input to efforts to extend cited above. This document is also needed as input to efforts to extend
DNS, such as the DNS Security Extensions [RFC 2535]. Lack of a clear DNS, such as the DNS Security Extensions [RFC 2535]. Lack of a clear
base specification has proven to result in extension documents that base specification has proven to result in extension documents that
have unpredictable consequences. (This is true in general, not just have unpredictable consequences. (This is true in general, not just
skipping to change at line 86 skipping to change at line 91
regarding authenticated denial of existence, a service introduced in the regarding authenticated denial of existence, a service introduced in the
DNS Security Extensions [RFC 2535]. Prior to the work leading up to this DNS Security Extensions [RFC 2535]. Prior to the work leading up to this
document, it had been feared that a large number of proof records (NXTs) document, it had been feared that a large number of proof records (NXTs)
might be needed in each reply because of the unknown number of potential might be needed in each reply because of the unknown number of potential
wild card domains that were thought to be applicable. One outcome of this wild card domains that were thought to be applicable. One outcome of this
fear is a now discontinued document solving a problem that is now known fear is a now discontinued document solving a problem that is now known
not to exist. I.e., this clarification has the impact of defending against not to exist. I.e., this clarification has the impact of defending against
unwarranted protocol surgery. It is not "yet another" effort to just unwarranted protocol surgery. It is not "yet another" effort to just
rewrite the early specifications for the sake of purity. rewrite the early specifications for the sake of purity.
Although the effort to define the DNS Security Extensions has prompted this
document, the clarifications herein relate to basic DNS only. No DNS
Security Extensions considerations are mentioned in the document.
1.1 Document Limits 1.1 Document Limits
This document limits itself to reinforcing the concepts in RFC 1034. This document limits itself to reinforcing the concepts in RFC 1034. In
Any deviation from this should be brought to the attention of the editors. the effort to do this, a few issues have been discussed that change
parts of what is in RFC 1034. The discussions have been held within the
DNS Extensions Working Group.
Two changes to the text of RFC 1034 that fall within the realm of Briefly, the issues raised include:
clarifying the wild card definition have been suggested. (Changes aren't - The lack of clarity in the definition of domain name existence
really clarifications.) The two suggestions are barring the ownership - Implications of a wild card domain name owning any of the following
by a wild card domain of an CNAME resource record set and barring the resource record sets: DNAME [RFC 2672], CNAME, NS, and SOA
ownership by a wild card domain of a NS resource record set. Both - Whether RFC 1034 meant to allow special processing of CNAME RR's
of these have some merit, but do not belong in a document that has not owned by wild card domain names
yet been reviewed by the working group.
1.2 Existence 1.2 Existence
The notion that a domain name 'exists' will arise numerous times in this The notion that a domain name 'exists' will arise numerous times in this
discussion. RFC 1034 raises the issue of existence in a number of places, discussion. RFC 1034 raises the issue of existence in a number of places,
usually in reference to non-existence and often in reference to processing usually in reference to non-existence and often in reference to processing
involving wild card domain names. RFC 1034 does contain algorithms that involving wild card domain names. RFC 1034 contains algorithms that
describe how domain names impact the preparation of an answer and does describe how domain names impact the preparation of an answer and does
define wild cards as a means of synthesizing answers. define wild cards as a means of synthesizing answers. Because of this
a discussion on wild card domain names has to start with the issue of
existence.
To help clarify the topic of wild cards, a positive definition of existence To help clarify the topic of wild cards, a positive definition of existence
is needed. Complicating matters, though, is the realization that existence is needed. Complicating matters, though, is the realization that existence
is relative. To an authoritative server, a domain name exists if the is relative. To an authoritative server, a domain name exists if the
domain name plays a role following the algorithms of preparing a response. domain name plays a role following the algorithms of preparing a response.
To a resolver, a domain name exists if there is any data available To a resolver, a domain name exists if there is any data available
corresponding to the name. The difference between the two is the synthesis corresponding to the name. The difference between the two is the synthesis
of records according to a wild card. of records according to a wild card.
For the purposes of this document, the point of view of an authoritative For the purposes of this document, the point of view of an authoritative
skipping to change at line 128 skipping to change at line 140
the execution of the algorithms in RFC 1034. the execution of the algorithms in RFC 1034.
1.3 An Example 1.3 An Example
For example, consider this wild card domain name: *.example. Any query For example, consider this wild card domain name: *.example. Any query
name under example. is a candidate to be matched (answered) by this wild name under example. is a candidate to be matched (answered) by this wild
card, i.e., to have an response returned that is synthesized from the wild card, i.e., to have an response returned that is synthesized from the wild
card's RR sets. Although any name is a candidate, not all queries will card's RR sets. Although any name is a candidate, not all queries will
match. match.
To further illustrate this, consider this example: To further illustrate this, consider this zone:
$ORIGIN example. $ORIGIN example.
@ IN SOA @ IN SOA
NS NS
NS NS
* TXT "this is a wild card" * TXT "this is a wild card"
MX 10 mailhost.example. MX 10 mailhost.example.
host1 A 10.0.0.1 host1 A 10.0.0.1
_ssh._tcp.host1 SRV _ssh._tcp.host1 SRV
_ssh._tcp.host2 SRV _ssh._tcp.host2 SRV
skipping to change at line 209 skipping to change at line 221
interior node, owning or not owning any resource set, that has a leaf interior node, owning or not owning any resource set, that has a leaf
node owning a resource set as a subdomain," is the proper interpretation node owning a resource set as a subdomain," is the proper interpretation
of the middle sentence. of the middle sentence.
As an aside, an "authoritative name error" has been called NXDOMAIN in As an aside, an "authoritative name error" has been called NXDOMAIN in
some RFCs, such as RFC 2136 [RFC 2136]. NXDOMAIN is the mnemonic assigned some RFCs, such as RFC 2136 [RFC 2136]. NXDOMAIN is the mnemonic assigned
to such an error by at least one implementation of DNS. As this to such an error by at least one implementation of DNS. As this
mnemonic is specific to implementations, it is avoided in the remainder mnemonic is specific to implementations, it is avoided in the remainder
of this document. of this document.
1.3 Terminology 1.5 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in the document entitled document are to be interpreted as described in the document entitled
"Key words for use in RFCs to Indicate Requirement Levels." [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels." [RFC2119]
Requirements are denoted by paragraphs that begin with with the following Requirements are denoted by paragraphs that begin with with the following
convention: 'R'<sect>.<count>. convention: 'R'<sect>.<count>.
Quotations of RFC 1034 (as has already been done once above) are denoted by
a '#' in the leftmost column.
2 Defining the Wild Card Domain Name 2 Defining the Wild Card Domain Name
A wild card domain name is defined by having the initial label be: A wild card domain name is defined by having the initial label be:
0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal) 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
This defines domain names that may play a role in being a wild card, that This defines domain names that may play a role in being a wild card, that
is, being a source for synthesized answers. Domain names conforming to is, being a source for synthesized answers. Domain names conforming to
this definition that appear in queries and RDATA sections do not have this definition that appear in queries and RDATA sections do not have
any special role. These cases will be described in more detail in any special role. These cases will be described in more detail in
skipping to change at line 286 skipping to change at line 301
A note on terminology. A domain transcends zones, i.e., all DNS data is A note on terminology. A domain transcends zones, i.e., all DNS data is
in the root domain but segmented into zones of control. In this document, in the root domain but segmented into zones of control. In this document,
there are references to a "domain name" in the context of existing "in a there are references to a "domain name" in the context of existing "in a
zone." In this usage, a domain name is the root of a domain, not the entire zone." In this usage, a domain name is the root of a domain, not the entire
domain. The domain's root point is said to "exist in a zone" if the zone domain. The domain's root point is said to "exist in a zone" if the zone
is authoritative for the name. RR sets existing in a domain need not be is authoritative for the name. RR sets existing in a domain need not be
owned by the domain's root domain name, but are owned by other domain owned by the domain's root domain name, but are owned by other domain
names in the domain. names in the domain.
4 Impact of a Wild Card Domain In a Query Message 4 Impact of a Wild Card Domain In a Query Message or in an RDATA field
When a wild card domain name appears in a question, e.g., the query name When a wild card domain name appears in a question, e.g., the query name
is "*.example.", the response in no way differs from any other query. is "*.example.", the response in no way differs from any other query.
In other words, the wild card label in a QNAME has no special meaning, In other words, the wild card label in a QNAME has no special meaning,
and query processing will proceed using '*' as a literal query name. and query processing will proceed using '*' as a literal query name.
R4.1 A wild card domain name acting as a QNAME MUST be treated as any R4.1 A wild card domain name acting as a QNAME MUST be treated as any
other QNAME, there MUST be no special processing accorded it. other QNAME, there MUST be no special processing accorded it.
If a wild card domain name appears in the RDATA of a CNAME RR or any If a wild card domain name appears in the RDATA of a CNAME RR or any
skipping to change at line 315 skipping to change at line 330
processing accorded it. processing accorded it.
5 Impact of a Wild Card Domain On a Response 5 Impact of a Wild Card Domain On a Response
The description of how wild cards impact response generation is in RFC The description of how wild cards impact response generation is in RFC
1034, section 4.3.2. That passage contains the algorithm followed by a 1034, section 4.3.2. That passage contains the algorithm followed by a
server in constructing a response. Within that algorithm, step 3, part server in constructing a response. Within that algorithm, step 3, part
'c' defines the behavior of the wild card. The algorithm is directly 'c' defines the behavior of the wild card. The algorithm is directly
quoted in lines that begin with a '#' sign. Commentary is interleaved. quoted in lines that begin with a '#' sign. Commentary is interleaved.
[Note that are no requirements specifically listed in this section. The There is a documentation issue deserving some explanation. The algorithm
text here is explanatory and interpretative. There is no change to in RFC 1034, section 4.3.2. is not intended to be pseudo code, i.e., it's
the algorithm specified in RFC 1034.] steps are not intended to be followed in strict order. The "algorithm"
is a suggestion. As such, in step 3, parts a, b, and c, do not have to
be implemented in that order.
Another issue needing explanation is that RFC 1034 is a full standard.
There is another RFC, RFC 2672, which makes, or proposes an adjustment
to RFC 1034's section 4.3.2 for the sake of the DNAME RR. RFC 2672 is
a proposed standard. The dilemma in writing these clarifications is
knowing which document is the one being clarified. Fortunately, the
difference between RFC 1034 and RFC 2672 is not significant with respect
to wild card synthesis, so this document will continue to state that
it is clarifying RFC 1034. If RFC 2672 progresses along the standards
track, it will need to refer to modifying RFC 1034's algorithm as
amended here.
The context of part 'c' is that the search is progressing label by label The context of part 'c' is that the search is progressing label by label
through the QNAME. (Note that the data being searched is the authoritative through the QNAME. (Note that the data being searched is the authoritative
data in the server, the cache is searched in step 4.) Step 3's part 'a' data in the server, the cache is searched in step 4.) Step 3's part 'a'
covers the case that the QNAME has been matched in full, regardless of the covers the case that the QNAME has been matched in full, regardless of the
presence of a CNAME RR. Step 'b' covers crossing a cut point, resulting presence of a CNAME RR. Step 'b' covers crossing a cut point, resulting
in a referral. All that is left is to look for the wild card. in a referral. All that is left is to look for the wild card.
Step 3 of the algorithm also assumes that the search is looking in the Step 3 of the algorithm also assumes that the search is looking in the
zone closest to the answer, i.e., in the same class as QCLASS and as zone closest to the answer, i.e., in the same class as QCLASS and as
skipping to change at line 367 skipping to change at line 395
For the sake of brevity, the closest enclosing node can be referred to as For the sake of brevity, the closest enclosing node can be referred to as
the "closest encloser." The closest encloser is the most important concept the "closest encloser." The closest encloser is the most important concept
in this clarification. Describing the closest encloser is a bit tricky, in this clarification. Describing the closest encloser is a bit tricky,
but it is an easy concept. but it is an easy concept.
To find the closest encloser, you have to first locate the zone that is To find the closest encloser, you have to first locate the zone that is
the authority for the query name. This eliminates the need to be concerned the authority for the query name. This eliminates the need to be concerned
that the closest encloser is a cut point. In addition, we can assume too that the closest encloser is a cut point. In addition, we can assume too
that the query name does not exist, hence the closest encloser is not equal that the query name does not exist, hence the closest encloser is not equal
to the query name. We can assume away these two cases because they are to the query name. We can assume away these two cases because they are
handled in steps a and b of section 4.3.2.'s algorithm. handled in steps 2, 3a and 3b of section 4.3.2.'s algorithm.
What is left is to identify the existing domain name that would have been What is left is to identify the existing domain name that would have been
up the tree (closer to the root) from the query name. Knowing that an up the tree (closer to the root) from the query name. Knowing that an
exact match is impossible, if there is a "*" label descending from the exact match is impossible, if there is a "*" label descending from the
unique closest encloser, this is the one and only wild card from which unique closest encloser, this is the one and only wild card from which
an answer can be synthesized for the query. an answer can be synthesized for the query.
To illustrate, using the example in section 1.2 of this document, the To illustrate, using the example in section 1.2 of this document, the
following chart shows QNAMEs and the closest enclosers. In Appendix A following chart shows QNAMEs and the closest enclosers. In Appendix A
there is another chart showing unusual cases. there is another chart showing unusual cases.
skipping to change at line 392 skipping to change at line 420
_telnet._tcp.host2.example. host2.example. no wild card _telnet._tcp.host2.example. host2.example. no wild card
_telnet._tcp.host3.example. example. *.example. _telnet._tcp.host3.example. example. *.example.
_chat._udp.host3.example. example. *.example. _chat._udp.host3.example. example. *.example.
Note that host1.subdel.example. is in a subzone, so the search for it ends Note that host1.subdel.example. is in a subzone, so the search for it ends
in a referral in part 'b', thus does not enter into finding a closest in a referral in part 'b', thus does not enter into finding a closest
encloser. encloser.
The fact that a closest encloser will be the only superdomain that The fact that a closest encloser will be the only superdomain that
can have a candidate wild card will have an impact when it comes to can have a candidate wild card will have an impact when it comes to
designing authenticated denial of existence proofs. (This concept designing authenticated denial of existence proofs.
is not introduced until DNS Security Extensions are considered in
upcoming sections.)
# 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
# or a name we have followed due to a CNAME. If the name # or a name we have followed due to a CNAME. If the name
# is original, set an authoritative name error in the # is original, set an authoritative name error in the
# response and exit. Otherwise just exit. # response and exit. Otherwise just exit.
The above passage says that if there is not even a wild card domain name The above passage says that if there is not even a wild card domain name
to match at this point (failing to find an explicit answer elsewhere), to match at this point (failing to find an explicit answer elsewhere),
we are to return an authoritative name error at this point. If we were we are to return an authoritative name error at this point. If we were
skipping to change at line 416 skipping to change at line 442
a no error return code is appropriate, with just the CNAME RR (or sequence a no error return code is appropriate, with just the CNAME RR (or sequence
of CNAME RRs) in the answer section. of CNAME RRs) in the answer section.
# If the "*" label does exist, match RRs at that node # If the "*" label does exist, match RRs at that node
# against QTYPE. If any match, copy them into the answer # against QTYPE. If any match, copy them into the answer
# section, but set the owner of the RR to be QNAME, and # section, but set the owner of the RR to be QNAME, and
# not the node with the "*" label. Go to step 6. # not the node with the "*" label. Go to step 6.
This final paragraph covers the role of the QTYPE in the process. Note This final paragraph covers the role of the QTYPE in the process. Note
that if no resource record set matches the QTYPE the result is that no data that if no resource record set matches the QTYPE the result is that no data
is copied, but the search still ceases ("Go to step 6."). is copied, but the search still ceases ("Go to step 6."). In the following
section, a suggested change is made to this, under the heading "CNAME RRs
6 Authenticated Denial and Wild Cards at a Wild Card Domain Name."
In unsecured DNS, the only concern when there is no data to return to
a query is whether the domain name from which the answer comes exists or
not, whether or not a name error is indicated in the return code. In
either case the answer section is empty or contained just a sequence of
CNAME RR sets.
In securing DNS, authenticated denial of existence is a service that is
provided. The chosen solution to provide this service is to generate
resource records indicating what is protected in a zone and to digitally
sign these.
The resource records that do this, as defined in RFC 2535, are NXT RRs.
There are three points to consider when clarifying the topic of wild card
domain names. One is the construction of the records. The second is
the inclusion of records in responses. The third is the interpretation
of the records in a response by the resolver.
In short, authenticated denial has to be sure to prove that the closest
encloser does not equal the query name, whether there is a wild card
name directly under the closest encloser.
6.1 Preparing Wild Card Domain Name Owned Non-existence Proofs
During the creation of the authenticated denial records, the wild card
domain name plays no special role, in the same manner as the wild card
domain name playing no special role in a query.
There are two considerations with regards to preparing non-existence
proofs.
R6.1 Any mechanism used to provide authenticated denial MUST reveal the
closest enclosing existing domain name for the query. If this is not
provided, the resolver will not be able to ascertain the identity
of an appropriate wild card domain name.
R6.2 If a zone is signed in such a way that offers authenticated denial
of existence, wild card domain name owned RR sets MUST be signed.
Otherwise the determination of the "closest encloser" is not possible.
6.2 Role of Wild Cards in Answers
There are three cases to address. The first is synthesizing from wild card
domain name with data, the second is negatively synthesizing from an
existing wild card, and the third is denying that neither an exact match,
referral, nor wild card exist to answer the query.
6.2.1 Synthesizing From a Wild Card
When preparing an answer from a wild card domain name, the answer needs
to include proof that the exact match of the QNAME and QCLASS does not
exist. This is needed because synthesis of the answer replaces the "*"
label with the QNAME without securing the result. The resolver will
realize that the answer was derived from a wild card, but cannot
detect whether an exact match was maliciously omitted.
R6.3 When synthesizing a positive answer from a wild card domain name, the
answer MUST include proof that the exact match for the QNAME and
QCLASS does not exist.
Note that a proof that the QTYPE does not exist at the QNAME and QCLASS is
not sufficient to justify synthesis from a wild card.
6.2.2. Synthesizing Authoritative No Error, No Data From a Wild Card
When synthesizing a negative answer that is derived from a wild card,
meaning that a wild card matched the QNAME (no exact match happened for
QNAME) but that there is no match for QTYPE there, at most two negative
answers are needed, possibly one. As in 6.2.1, a proof that the exact
match failed is needed. A second proof is needed to show that the wild
card domain name does not have the QTYPE. Depending on the method of
authenticated denial, these this could be possible with one statement.
R6.4 When synthesizing a negative answer from a wild card domain name, the
answer MUST include proof that the exact match of the QNAME and
QCLASS does not exist and that the QTYPE matches no RR set at the
wild card. If this answer can be optimized, an implementation
SHOULD reduce the number of records included in the response.
6.2.3. Answering With an Authoritative Name Error
When answering with a result code of a name error, the answer needs to
provide proof that neither the exact match for QNAME and QCLASS exists
nor that a wild card domain name exists as a subdomain of the closest
enclosing domain name.
R6.5 When preparing a reply with an authoritative name error, the answer
MUST include proof that the exact match for the QNAME and QCLASS
does not exist and that no wild card is available to provide a match.
6.2.4. The Remaining Case (Authoritative No Error, No Data at QNAME)
When answering negatively because there is a match for QNAME and QCLASS
but no match for the QTYPE, only a proof for that is needed. Just as
the search does not proceed onto a search for the wild card in this
case, neither does the construction of the negative answer proof.
R6.6 When preparing a reply in which there is an exact match of the
QNAME and QCLASS, but there is no RR set matching the QTYPE,
the reply SHOULD NOT contain any proof regarding the wild card
domain name.
6.3 Interpreting Negative Answers Involving Wild Cards
There are three requirements for resolvers when it comes to handling
negative answers generated as described in section 6.2.
R6.7 A resolver MUST confirm that the negative data relates to the
query submitted.
It is incumbent upon the resolver to interpret the answer correctly.
R6.8 A resolver MUST confirm that an answer synthesized from a wild
card domain name is done so only in an authoritative absence of
a domain name with the query name and query class.
In the case of a wild card synthesized answer, the resolver has to
see that the query name and class has no node, proving that a synthesized
answer would be appropriate (subject to validation of it).
R6.9 A resolver MUST confirm that an authoritative name error is
valid if there is proof that both domain name matching the query
name and class and if there is proof that the closest encloser
does not have a wild card domain name as an immediate descendent.
Before concluding that an authoritative name error is justified, a
resolver has to determine that neither an exact match for the query
name and class exists nor an appropriate wild card domain name.
6.4 Authenticated Denial, Wild Card Domain Names, and Opt-In
When considering the Opt-In proposal [WIP], it is wise to not combine
a zone that adheres to both opt-in and that has a wild card domain
name. The reason is rooted in that the synthesis of an answer is done
by substituting the QNAME for the wild card domain name in the answer.
Because this is unsecured, and the is ambiguity regarding whether a
negative proof can be provided for the exact match (when it is outside
the opt-in secured area), a definitive proof of authenticated denial
is not possible.
For a more complete discussion of this topic, please refer to the document
describing the Opt-In proposal, referenced above.
7 Analytical Proof That NXT Names the Closest Encloser
How does one know, and (more importantly) *prove* using NXT records, what
the closest encloser of a given QNAME is? This section answers that
question with a rigorous proof, because security is the topic.
7.1 Background to the Proof
We'd like to have empty non-terminals provably exist in secure zones.
In other words, if someone has:
a.b.c 3600 IN A 10.0.0.1
in their zone, but does not have any records with owner names "c" or
"b.c", we'd like to be able to say (with proof) that "nodes 'c' and
'b.c' exist and yet have no RRs."
We want this because it is the behavior mandated by the nameserver
algorithm in section 4.3.2 of RFC 1034, and because it is regarded by
most as a better, more "natural" behavior than the alternative of
treating such empty non-terminals as being non-existent.
There are two ways to achieve this. One way is to instantiate all
the implied empty non-terminals, and then add NXT and SIG(NXT) to them.
This works, but is a burden to the server in storage and computation
resources. It especially complicates updates, since any deletion of
the last record at a node necessitates a computation to determine
which empty non-terminals are no longer relevant and thus must also be
deleted.
The second way is to infer the existence of the empty non-terminals
from the names of the nodes with real data (i.e. the names in the NXT
chain).
Using this technique, the "deepest existing ancestor" a.k.a. the "most
enclosing name" of any query name Q can be easily found, and proved to
exist. This allows great efficiency in the wild card matching
algorithm as well, since only one wild card possibility exists and must
subsequently be either proven to exist or proven not to exist. This
is a big improvement on the "empty non-terminals do not exist"
approach, which has many more possible candidate wild card names which
must be proven not to exist.
7.2 Definitions and Preliminaries
When we say "subdomain" anywhere below, we mean "is contained within the
domain (in the sense that RFC 1034 describes), or is equal to the domain".
I.e., we're treating it like "subset" in mathematics.
X is a "superdomain" of Y iff. Y is a subdomain of X.
A name is an "owner name in zone Z" if it is an owner name, is a subdomain
of the origin of zone Z, and is not glue (or otherwise beneath a zone cut
of zone Z).
A name N is "directly in zone Z" iff. there is some owner name in Z equal
to N.
A name N is "inferred to be in zone Z", if it is not directly in zone Z,
but is a superdomain of some direct name of Z and is still a subdomain of
Z. I.e., it is an "empty non-terminal" required to make the path from the
zone origin to some name directly in Z.
A name is "in zone Z" if it is directly in zone Z, or is inferred to be in
zone Z.
Let "<" denote the DNSSEC name order relation.
The "greatest common superdomain" of names A and B, denoted GCS(A,B), is
the greatest (according to the DNSSEC ordering) name X such that X is a
superdomain of both A and B. I.e. it is the "deepest common ancestor" of
A and B. GCS(A,B) always exists, because the root name is a superdomain
of all names.
Let Q be a name which is a subdomain of the origin of zone Z.
7.3 Bounds of Q in Z
There is always a name directly in Z, call it "GLB(Q,Z)", which is the
greatest lower bound of Q. I.e. GLB(Q,Z) <= Q, and for all N in Z where
N <= Q, N <= GLB(Q,Z).
There may or may not be a name directly in Z, call it "LUB(Q,Z)", which is
the least upper bound of Q. If there is no N directly in Z such that
N >= Q, then there is no LUB(Q,Z). If there is some N directly in Z where
N >= Q, then there is an LUB(Q,Z) >= Q such that if N >= Q, then
LUB(Q,Z) <= N.
So, GLB(Q,Z) <= Q < LUB(Q,Z), if the least upper bound exists.
GLB(Q,Z) will have a NXT record which:
If GLB(Q,Z) = Q, proves that Q is directly in Z
If GLB(Q,Z) != Q, proves that Q is not directly in Z
The "next domain name" field of this NXT record is the LUB, unless it is
the zone origin (the DNSSEC "end of chain" marker) and Q != the origin of
Z, in which case there is no LUB.
THEOREM 1: Let A, B, and Q be subdomains of Z. Let A <= B and B <= Q. Then
GCS(Q, A) <= GCS(Q, B)
Proof:
Assume GCS(Q, A) > GCS(Q, B). Then A must have more labels in common with
Q than B, but since A and B are less than Q, that means that A > B by the
DNSSEC ordering, which is a contradiction since A <= B.
THEOREM 2: Let A, B, and Q be subdomains of Z. Let A >= B and B >= Q. Then
GCS(Q, A) <= GCS(Q, B)
Proof:
Assume GCS(Q, A) > GCS(Q, B). Then A must have more labels in common with
Q than B, but since A and B are greater than Q, that means that A < B by
the DNSSEC ordering, which is a contradiction since A >= B.
7.4 Greatest Ancestor of Q in Z
The "greatest ancestor of Q in Z", denoted GA(Q,Z), is the greatest N in Z,
directly or inferred, such that Q is a subdomain of N. GA(Q,Z) is also
called the "most enclosing name of Q in Z" or the "deepest ancestor of
Q in Z".
GA(Q,Z) always exists. Since Q is a subdomain of the origin of Z, and the
origin of Z is "directly in zone Z", so there's always at least one N in Z
such that Q is a subdomain of N.
THEOREM 3: Let Q be a subdomain of the origin of zone Z. If LUB(Q,Z)
exists, then:
GA(Q,Z) = the greater of GCS(Q, GLB(Q,Z)) and GCS(Q, LUB(Q,Z))
otherwise 6 Considerations with Special Types
GA(Q,Z) = GCS(Q, GLB(Q,Z)) For the purposes of this section, "special" means that a record induces
processing at the server beyond simple lookup. The special types in this
section are SOA, NS, CNAME, and DNAME. SOA is special because it is used
as a zone marker and has an impact on step 2 of the algorithm in 4.3.2.
NS denotes a cut point and has an impact on step 3b. CNAME redirects the
query and is mentioned in steps 3a and 3b. DNAME is a "CNAME generator."
Proof: 6.1 SOA RR's at a Wild Card Domain Name
We can eliminate the trivial case where Q is directly in Z, since in that If the owner of an SOA record conforms to the basic rules of owning an
case GA(Q,Z) is obviously Q. SOA RR (meaning it is the apex of a zone) the impact on the search algorithm
is not in section 3c (where records are synthesized) as would be expected.
The impact is really in step 2 of the algorithm, the choice of zone.
For notational convenience, let We are no longer talking about whether or not an SOA RR can be synthesized
in a response because we are shifting attention to step 2. We are now talking
about what it means for a name server to synthesize a zone for a response.
To date, no implementation has done this. Thinking ahead though, anyone
choosing to pursue this would have to be aware that a server would have to
be able to distinguish between queries for data it will have to synthesize and
queries that ought to be treated as if they were prompted by a lame delegation.
L = GCS(Q, GLB(Q,Z)) It is not a protocol error to have an SOA RR owned by a wild card domain name,
U = GCS(Q, LUB(Q,Z)) just as it is not an error to have zone name be syntactically equivalent to a
domain name. However, this situation requires careful consideration of how
a server chooses the appropriate zone for an answer. And an SOA RR is
not able to be synthesized as in step 3c.
Assume L and U both exist. Assume there is an M in Z that is greater than 6.2 NS RR's at a Wild Card Domain Name
both L and U, and is a superdomain of Q.
If M is directly in Z, then M > GLB(Q,Z). This is because if M were Complimentary to the issue of an SOA RR owned by a wild card domain name is
<= GLB(Q,Z), then GCS(Q,M) would be <= L by Theorem 1. If M is directly the issue of NS RR's owned by a wild card domain name. In this instance,
in Z, it cannot be >= Q since it is a superdomain of Q and M != Q. So, each machine being referred to in the RDATA of the NS RR has to be able to
we have GLB(Q,Z) < M < Q, which implies that GLB(Q,Z) is not the greatest understand the impact of this on step 2, the choosing of the authoritative
lower bound, which is a contradiction. zone.
If M is inferred to be in Z, then there is some N directly in Z and M is a Referring to the same machine in such a NS RR will probably not work well.
superdomain of N. Either N < Q or N > Q (since Q is not directly in Z). This is because the server may become confused as to whether the query name
ought to be answered by the zone owning the NS RR in question or a synthesized
zone. (It isn't known in advance that the query name will invoke the wild
card synthesis.)
If N < Q, then N > GLB(Q,Z). If N were <= GLB(Q,Z), then the GCS(Q,N) The status of other RR's owned by a wild card domain name is the same as
would be <= L by Theorem 1, but GCS(Q,N) = M, and M > L. We thus have a if the owner name was not a wild card domain name. I.e., when there is a
contradiction, since this implies that GLB(Q,Z) is not the greatest lower NS RR at a wild card domain name, other records are treated as being below
bound. the zone cut.
If N > Q, then N < LUB(Q,Z). If N were >= LUB(Q,Z), then the GCS(Q,N) Is it not a protocol error to have a NS RR owned by a wild card domian name,
would be <= U by Theorem 2, but GCS(Q,N) = M, and M > U. We thus have a complimentary to the case of a SOA RR. However, for this to work, an
contradiction, since this implies that LUB(Q,Z) is not the least upper bound. implementation has to know how to synthesize a zone.
Now we deal with the case where U doesn't exist. Again, assume M in Z that 6.3 CNAME RR's at a Wild Card Domain Name
is greater than L, and is a superdomain of Q.
The cases where M is directly in Z, or where M is inferred and N < Q are as The issue of CNAME RR's owned by wild card domain names has prompted a
above. Now we deal with the case where N > Q. First we note that since < suggested change to the last paragraph of step 3c of the algorithm in 4.3.2.
is a well-ordering of the names in Z, if there are any upper bounds to Q in The changed text is this:
Z, then there must be a least upper bound. Now, if N existed, it would be
an upper bound of Q in Z, and hence a least upper bound would have to exist,
but there is no least upper bound of Q in Z by assumption, so we again have
a contradiction.
Q.E.D. If the "*" label does exist and if the data at the node is
a CNAME and QTYPE doesn't match CNAME, copy the CNAME RR
into the answer section of the response, set the owner
of the CNAME RR to be QNAME, and then change QNAME to the
canonical name in the CNAME RR, and go back to step 1.
7.5 Conclusion of the Proof If the "*" label does exist and either QTYPE is CNAME or the
data at the node is not a CNAME, then match RRs at that node
against QTYPE. If any match, copy them into the answer
section, but set the owner of the RR to be QNAME, and
not the node with the "*" label. Go to step 6.
We've shown how to find the "closest encloser" of any given QNAME by looking Apologies if the above isn't clear, but an attempt was made to stitch
at the QNAME along with the owner name and "next domain name" field of the together the passage using just the phrases in section 3a and 3c of the
NXT record which proves the QNAME doesn't exist. The technique works even algorithm so as to preserve the original flavor.
when the closest encloser is an inferred name.
Knowing the closest encloser lets us do very simple wild card checking in In case the passage as suggested isn't clear enough, the intent is to make
secure zones, since the only possible matching wild card is "landing" at a wild card name and finding a CNAME the same as if this happened
as a result of a direct match. I.e., Finding a CNAME at the name matched
in step 3c is supposed to have the same impact as finding the CNAME in step
3a.
*.<closest encloser> 6.4 DNAME RR's at a Wild Card Domain Name
We simply lookup that name, and if found, proceed accordingly. If not, we The specification of the DNAME RR, which is at the proposed level of
add the NXT record which proves it doesn't exist to the authority section. standardization, is not as mature as the full standard in RFC 1034. Because
of this, or the reason for this is, there appears to be a host of issues
with that definition and it's rewrite of the algorithm in 4.3.2. For the
time being, when it comes to wild card processing issues, a DNAME can
be considered to be a CNAME synthesizer. A DNAME at a wild card domain name
is effectively the same as a CNAME at a wild card domain name.
8 Security Considerations 7 Security Considerations
This document is refining the specifications to make it more likely that This document is refining the specifications to make it more likely that
security can be added to DNS. No functional additions are being made, just security can be added to DNS. No functional additions are being made, just
refining what is considered proper to allow the DNS, security of the DNS, and refining what is considered proper to allow the DNS, security of the DNS, and
extending the DNS to be more predictable. extending the DNS to be more predictable.
9 References 8 References
Normative References Normative References
[RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969 [RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969
[RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris, [RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris,
Nov-01-1987 Nov-01-1987
[RFC 1035] Domain Names - Implementation and Specification, P.V [RFC 1035] Domain Names - Implementation and Specification, P.V
Mockapetris, Nov-01-1987 Mockapetris, Nov-01-1987
[RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S [RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S
Bradner, March 1997 Bradner, March 1997
Non-normative References Informative References
[RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie, [RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie,
Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997 Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997
[RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999 [RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999
[WIP] DNSSEC Opt-In, Internet Draft, R. Arends, M. Kosters, D. Blacka, 2002 [RFC 2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999
10 Others Contributing to This Document 9 Others Contributing to This Document
Others who have directly caused text to appear in the document: Paul Vixie Others who have directly caused text to appear in the document: Paul Vixie
and Olaf Kolkman. Many others have indirect influences on the content. and Olaf Kolkman. Many others have indirect influences on the content.
11 Editors 10 Editors
Name: Bob Halley Name: Bob Halley
Affiliation: Nominum, Inc. Affiliation: Nominum, Inc.
Address: 2385 Bay Road, Redwood City, CA 94063 USA Address: 2385 Bay Road, Redwood City, CA 94063 USA
Phone: +1-650-381-6016 Phone: +1-650-381-6016
EMail: Bob.Halley@nominum.com EMail: Bob.Halley@nominum.com
Name: Edward Lewis Name: Edward Lewis
Affiliation: ARIN Affiliation: ARIN
Address: 3635 Concorde Pkwy, Suite 200, Chantilly, VA 20151 USA Address: 3635 Concorde Pkwy, Suite 200, Chantilly, VA 20151 USA
 End of changes. 

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