draft-ietf-dnsext-wcard-clarify-08.txt

bind 源码 最新实现 linux/unix/windows平台

DNSEXT Working Group                                          E. Lewis
INTERNET DRAFT                                                 NeuStar
Expiration Date: January 6, 2006                          July 6, 2005
Updates RFC 1034, RFC 2672

                             The Role of Wildcards
                           in the Domain Name System
                     draft-ietf-dnsext-wcard-clarify-08.txt

Status of this Memo

     By submitting this Internet-Draft, each author represents that
     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
     becomes aware will be disclosed, in accordance with Section 6 of
     BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as Internet-
     Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-Drafts
     as reference material or to cite them other than as "work in
     progress."

     The list of current Internet-Drafts can be accessed at
       http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
       http://www.ietf.org/shadow.html

     This Internet-Draft will expire on January 6, 2006.

Copyright Notice

     Copyright (C) The Internet Society (2005).

Abstract

     This is an update to the wildcard definition of RFC 1034.  The
     interaction with wildcards and CNAME is changed, an error
     condition removed, and the words defining some concepts central
     to wildcards are changed.  The overall goal is not to change
     wildcards, but to refine the definition of RFC 1034.

Table of Contents

1.    Introduction
1.1   Motivation
1.2   The Original Definition
1.3   Roadmap to This Document
1.3.1 New Terms
1.3.2 Changed Text
1.3.3 Considerations with Special Types
1.4   Standards Terminology
2.    Wildcard Syntax
2.1   Identifying a Wildcard
2.1.1 Wild Card Domain Name and Asterisk Label
2.1.2 Asterisks and Other Characters
2.1.3 Non-terminal Wild Card Domain Names
2.2   Existence Rules
2.2.1 An Example
2.2.2 Empty Non-terminals
2.2.3 Yet Another Definition of Existence
2.3   When is a Wild Card Domain Name Not Special
3.    Impact of a Wild Card Domain Name On a Response
3.1   Step 2
3.2   Step 3
3.3   Part 'c'
3.3.1 Closest Encloser and the Source of Synthesis
3.3.2 Closest Encloser and Source of Synthesis Examples
3.3.3 Type Matching
4.    Considerations with Special Types
4.1   SOA RRSet at a Wild Card Domain Name
4.2   NS RRSet at a Wild Card Domain Name
4.2.1 Discarded Notions
4.3   CNAME RRSet at a Wild Card Domain Name
4.4   DNAME RRSet at a Wild Card Domain Name
4.5   SRV RRSet at a Wild Card Domain Name
4.6   DS RRSet at a Wild Card Domain Name
4.7   NSEC RRSet at a Wild Card Domain Name
4.8   RRSIG at a Wild Card Domain Name
4.9   Empty Non-terminal Wild Card Domain Name
5.    Security Considerations
6.    IANA Considerations
7.    References
8.    Editor
9.    Others Contributing to the Document
10.   Trailing Boilerplate

1. Introduction

     In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the
     synthesis of answers from special resource records called
     wildcards.  The definition in RFC 1034 is incomplete and has
     proven to be confusing.  This document describes the wildcard
     synthesis by adding to the discussion and making limited
     modifications.  Modifications are made to close inconsistencies
     that have led to interoperability issues.  This description
     does not expand the service intended by the original definition.

     Staying within the spirit and style of the original documents,
     this document avoids specifying rules for DNS implementations
     regarding wildcards.  The intention is to only describe what is
     needed for interoperability, not restrict implementation choices.
     In addition, consideration is given to minimize any backwards
     compatibility issues with implementations that comply with RFC
     1034's definition.

     This document is focused on the concept of wildcards as defined
     in RFC 1034.  Nothing is implied regarding alternative means of
     synthesizing resource record sets, nor are alternatives discussed.

1.1 Motivation

     Many DNS implementations diverge, in different ways, from the
     original definition of wildcards.  Although there is clearly a
     need to clarify the original documents in light of this alone,
     the impetus for this document lay in the engineering of the DNS
     security extensions [RFC4033].  With an unclear definition of
     wildcards the design of authenticated denial became entangled.

     This document is intended to limit its changes, documenting only
     those based on implementation experience, and to remain as close
     to the original document as possible.  To reinforce that this
     document is meant to clarify and adjust and not redefine wildcards,
     relevant sections of RFC 1034 are repeated verbatim to facilitate
     comparison of the old and new text.

1.2 The Original Definition

     The defintion of the wildcard concept is comprised by the
     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 resource record (set) is identified as being a source of
     synthetic data (section 4.3.3).

     This is the definition of the term "wildcard" as it appears in
     RFC 1034, section 4.3.3.

# In the previous algorithm, special treatment was given to RRs with
# owner names starting with the label "*".  Such RRs are called
# wildcards. Wildcard RRs can be thought of as instructions for
# synthesizing RRs.  When the appropriate conditions are met, the name
# server creates RRs with an owner name equal to the query name and
# contents taken from the wildcard RRs.

     This passage follows the algorithm in which the term wildcard
     is first used.   In this definition, wildcard refers to resource
     records.  In other usage, wildcard has referred to domain names,
     and it has been used to describe the operational practice of
     relying on wildcards to generate answers.  It is clear from this
     that there is a need to define clear and unambiguous terminology
     in the process of discussing wildcards.

     The mention of the use of wildcards in the preparation of a
     response is contained in step 3c of RFC 1034's section 4.3.2
     entitled "Algorithm."  Note that "wildcard" does not appear in
     the algorithm, instead references are made to the "*" label.
     The portion of the algorithm relating to wildcards is
     deconstructed in detail in section 3 of this document, this is
     the beginning of the relevant portion of the "Algorithm."

#    c. If at some label, a match is impossible (i.e., the
#       corresponding label does not exist), look to see if [...]
#       the "*" label exists.

     The scope of this document is the RFC 1034 definition of
     wildcards and the implications of updates to those documents,
     such as DNSSEC.  Alternate schemes for synthesizing answers are
     not considered.  (Note that there is no reference listed.  No
     document is known to describe any alternate schemes, although
     there has been some mention of them in mailing lists.)

1.3 Roadmap to This Document

     This document accomplishes these three items.
     o Defines new terms
     o Makes minor changes to avoid conflicting concepts
     o Describes the actions of certain resource records as wildcards

1.3.1 New Terms

     To help in discussing what resource records are wildcards, two
     terms will be defined - "asterisk label" and "wild card domain
     name".  These are defined in section 2.1.1.

     To assist in clarifying the role of wildcards in the name server
     algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest
     encloser" are defined.  These definitions are in section 3.3.2.
     "Label match" is defined in section 3.2.

     The new terms are used to make discussions of wildcards clearer.
     Terminology doesn't directly have an impact on implementations.

1.3.2 Changed Text

     The definition of "existence" is changed superficially.  This
     change will not be apparent to implementations; it is needed to
     make descriptions more precise.  The change appears in section
     2.2.3.

     RFC 1034, section 4.3.3., seems to prohibit having two asterisk
     labels in a wildcard owner name.  With this document the
     restriction is removed entirely.  This change and its implications
     are in section 2.1.3.

     The actions when a source of synthesis owns a CNAME RR are
     changed to mirror the actions if an exact match name owns a
     CNAME RR.  This is an addition to the words in RFC 1034,
     section 4.3.2, step 3, part c.  The discussion of this is in
     section 3.3.3.

     Only the latter change represents an impact to implementations.
     The definition of existence is not a protocol impact.  The change
     to the restriction on names is unlikely to have an impact, as
     RFC 1034 contained no specification on when and how to enforce the
     restriction.

1.3.3 Considerations with Special Types

     This document describes semantics of wildcard RRSets for
     "interesting" types as well as empty non-terminal wildcards.
     Understanding these situations in the context of wildcards has
     been clouded because these types incur special processing if
     they are the result of an exact match.  This discussion is in
     section 4.

     These discussions do not have an implementation impact, they cover
     existing knowledge of the types, but to a greater level of detail.

1.4 Standards Terminology

     This document does not use terms as defined in "Key words for use
     in RFCs to Indicate Requirement Levels." [RFC2119]

     Quotations of RFC 1034 are denoted by a '#' in the leftmost
     column.  References to section "4.3.2" are assumed to refer
     to RFC 1034's section 4.3.2, simply titled "Algorithm."

2. Wildcard Syntax

     The syntax of a wildcard is the same as any other DNS resource
     record, across all classes and types.  The only significant
     feature is the owner name.

     Because wildcards are encoded as resource records with special
     names, they are included in zone transfers and incremental zone
     transfers[RFC1995] just as non-wildcard resource records are.
     This feature has been underappreciated until discussions on
     alternative approaches to wildcards appeared on mailing lists.

2.1 Identifying a Wildcard

     To provide a more accurate description of wildcards, the
     definition has to start with a discussion of the domain names
     that appear as owners.  Two new terms are needed, "Asterisk
     Label" and "Wild Card Domain Name."

2.1.1 Wild Card Domain Name and Asterisk Label

     A "wild card domain name" is defined by having its initial
     (i.e., left-most or least significant) label be, in binary format:

          0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)

     The first octet is the normal label type and length for a 1 octet
     long label, the second octet is the ASCII representation [RFC20]
     for the '*' character.

     A descriptive name of a label equaling that value is an "asterisk
     label."

     RFC 1034's definition of wildcard would be "a resource record
     owned by a wild card domain name."

2.1.2 Asterisks and Other Characters

     No label values other than that in section 2.1.1 are asterisk
     labels, hence names beginning with other labels are never wild
     card domain names.  Labels such as 'the*' and '**' are not
     asterisk labels so these labels do not start wild card domain
     names.

2.1.3 Non-terminal Wild Card Domain Names

     In section 4.3.3, the following is stated:

# ..........................  The owner name of the wildcard RRs is of
# the form "*.<anydomain>", where <anydomain> is any domain name.
# <anydomain> should not contain other * labels......................

     The restriction is now removed.  The original documentation of it
     is incomplete and the restriction does not serve any purpose given
     years of operational experience.

     There are three possible reasons for putting the restriction in
     place, but none of the three has held up over time.  One is
     that the restriction meant that there would never be subdomains
     of wild card domain names, but the restriciton as stated still
     permits "example.*.example." for instance.  Another is that
     wild card domain names are not intended to be empty non-terminals,
     but this situation does not disrupt the algorithm in 4.3.2.
     Finally, "nested" wild card domain names are not ambiguous once
     the concept of the closest encloser had been documented.

     A wild card domain name can have subdomains.  There is no need
     to inspect the subdomains to see if there is another asterisk
     label in any subdomain.

     A wild card domain name can be an empty non-terminal.  (See the
     upcoming sections on empty non-terminals.)  In this case, any
     lookup encountering it will terminate as would any empty
     non-terminal match.

2.2 Existence Rules