draft-lewis-dns-wildcard-clarify-00.txt

bind-3.2.

for the query.  Even if the closest enclosing node conforms to the syntax
rule in section 2 for being a wild card domain name, the closest enclosing
node is not eligible to be a source of a synthesized answer.

The only wild card domain name that is a candidate to synthesize an answer
will be the "*" subdomain of the closest enclosing domain name.  Three
possibilities can happen.  The "*" subdomain does not exist, the "*"
subdomain does but does not have an RR set of the same type as the QTYPE,
or it exists and has the desired RR set.

For the sake of brevity, the closest enclosing node can be referred to as
the "closest encloser."

To illustrate, using the example in section 1.2 of this document, the
following chart shows QNAMEs and the closest enclosers.  In Appendix A
there is another chart showing unusual cases.

    QNAME                        Closest Encloser     Wild Card Source
    host3.example.               example.             *.example.
    _telnet._tcp.host1.example.  _tcp.host1.example.  no wild card
    _telnet._tcp.host2.example.  host2.example.       no wild card
    _telnet._tcp.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
in a referral in part 'b', thus does not enter into finding a closest
encloser.

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
designing authenticated denial of existence proofs.  (This concept
is not introduced until DNS Security Extensions are considered in
upcoming sections.)

#            If the "*" label does not exist, check whether the name
#            we are looking for is the original QNAME in the query
#            or a name we have followed due to a CNAME.  If the name
#            is original, set an authoritative name error in the
#            response and exit.  Otherwise just exit.

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),
we are to return an authoritative name error at this point.  If we were
following a CNAME, the specification is unclear, but seems to imply that
a no error return code is appropriate, with just the CNAME RR (or sequence
of CNAME RRs) in the answer section.

#            If the "*" label does exist, 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.

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
is copied, but the search still ceases ("Go to step 6.").

6 Authenticated Denial and Wild Cards

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.

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 is one consideration with regards to preparing non-existence
proofs.

R6.1 Any mechanism used to provide authenticated denial MUST reveal the
      closest enclosing existing domain 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.

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.2 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.

6.2.2. Synthesizing Negatively 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, 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.3 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.4 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

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.5 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 two requirements for resolvers when it comes to handling
negative answers generated as described in section 6.2.

R6.6 A resolver MUST be able to identify negative answer data that
      indicate when a match for QNAME and QCLASS does not exist.

R6.7 From a negative answer, a resolver MUST be able to determine
      the closest enclosing domain name in a negative answer and
      MUST be able to process a negative answer involving the one
      wild card domain name that is a candidate to provide a
      synthesized answer.

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.

7 Security Considerations

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 refining what is considered proper to allow the system, security
of the system, and extending the system more predictable.

8 References

Normative References

[RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969
[RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris,
            Nov-01-1987
[RFC 1035] Domain Names - Implementation and Specification, P.V
            Mockapetris, Nov-01-1987
[RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S
            Bradner, March 1997

Non-normative References

[RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie,
            Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997
[RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999
[WIP] DNSSEC Opt-In, Internet Draft, R. Arends, M. Kosters, D. Blacka, 2002

9 Other Contributing to This Document

Others who have directly caused text to appear in the document: Paul Vixie
and Olaf Kolkman.  Many others have indirect influences on the content.

10 Editor

Name:        Edward Lewis
Title:       Research Engineer
Affiliation: ARIN
Email:       [e-mail]
Phone:       [phone]

Appendix A: Subdomains of Wild Card Domain Names

In reading the definition of section 2 carefully, it is possible to
rationalize unusual names as legal.  In the example given, *.example.
could have subdomains of *.sub.*.example. and even the more direct
*.*.example.  (The implication here is that these domain names own
explicit resource records sets.)  Although defining these names is not
easy to justify, it is important that implementations account for the
possibility.  This section will give some further guidance on handling
these names.

The first thing to realize is that by all definitions, subdomains of
wild card domain names are legal.  In analyzing them, one realizes
that they cause no harm by their existence.  Because of this, they are
allowed to exist, i.e., there are no special case rules made to disallow
them.  The reason for not preventing these names is that the prevention
would just introduce more code paths to put into implementations.

The concept of "closest enclosing" existing names is important to keep in
mind.  It is also important to realize that a wild card domain name can
be a closest encloser of a query name.  For example, if *.*.example. is
defined in a zone, and the query name is a.*.example., then the closest
enclosing domain name is *.example.  Keep in mind that the closest
encloser is not eligible to be a source of synthesized answers, just the
subdomain of it that has the first label "*".

To illustrate this, the following chart shows some matches.  Assume that
the names *.example., *.*.example., and *.sub.*.example. are defined
in the zone.

       QNAME                Closest Encloser   Wild Card Source
       a.example.           example.           *.example.
       b.a.example.         example.           *.example.
       a.*.example.         *.example.         *.*.example.
       b.a.*.example.       *.example.         *.*.example.
       b.a.*.*.example.     *.*.example.       no wild card
       a.sub.*.example.     sub.*.example.     *.sub.*.example.
       b.a.sub.*.example.   sub.*.example.     *.sub.*.example.
       a.*.sub.*.example.   *.sub.*.example.   no wild card
       *.a.example.         example.           *.example.
       a.sub.b.example.     example.           *.example.

Recall that the closest encloser itself cannot be the wild card.  Therefore
the match for b.a.*.*.example. has no applicable wild card.

Finally, if a query name is sub.*.example., any answer available will come
from an exact name match for sub.*.example.  No wild card synthesis is
performed in this case.

Full Copyright Statement

   Copyright (C) The Internet Society 2003.  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of developing
   Internet standards in which case the procedures for copyrights defined
   in the Internet Standards process must be followed, or as required to
   translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
   WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer