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

来自「非常好的dns解析软件」· 文本 代码 · 共 1,064 行 · 第 1/3 页

Internet-Draft                  dnsext-wcard           January 9, 2006

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

                              The Role of Wildcards
                            in the Domain Name System
                      draft-ietf-dnsext-wcard-clarify-10.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 July 9, 2006.

Copyright Notice

      Copyright (C) The Internet Society (2006).

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.




DNSEXT Working Group        Expires July 9, 2006             [Page  1]

Internet-Draft                  dnsext-wcard           January 9, 2006

Table of Contents

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








DNSEXT Working Group        Expires July 9, 2006             [Page  2]

Internet-Draft                  dnsext-wcard           January 9, 2006

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



DNSEXT Working Group        Expires July 9, 2006             [Page  3]

Internet-Draft                  dnsext-wcard           January 9, 2006

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

DNSEXT Working Group        Expires July 9, 2006             [Page  4]

Internet-Draft                  dnsext-wcard           January 9, 2006

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





DNSEXT Working Group        Expires July 9, 2006             [Page  5]

Internet-Draft                  dnsext-wcard           January 9, 2006

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 under appreciated 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......................

DNSEXT Working Group        Expires July 9, 2006             [Page  6]

Internet-Draft                  dnsext-wcard           January 9, 2006

      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.