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

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

      of types.  In this section, the implication of wildcards of
      specific types are discussed.  The types covered are those
      that have proven to be the most difficult to understand.  The
      types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and
      "none," i.e., empty non-terminal wild card domain names.

4.1 SOA RRSet at a Wild Card Domain Name

      A wild card domain name owning an SOA RRSet means that the
      domain is at the root of the zone (apex).  The domain can not
      be a source of synthesis because that is, by definition, a
      descendent node (of the closest encloser) and a zone apex is
      at the top of the zone.


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

      Although a wild card domain name owning an SOA RRSet can never
      be a source of synthesis, there is no reason to forbid the
      ownership of an SOA RRSet.

      E.g., given this zone:
             $ORIGIN *.example.
             @                 3600 IN  SOA   <SOA RDATA>
                               3600     NS    ns1.example.com.
                               3600     NS    ns1.example.net.
             www               3600     TXT   "the www txt record"

      A query for www.*.example.'s TXT record would still find the
      "the www txt record" answer.  The asterisk label only becomes
      significant when section 4.3.2, step 3 part 'c' is in effect.

      Of course, there would need to be a delegation in the parent
      zone, "example." for this to work too.  This is covered in the
      next section.

4.2 NS RRSet at a Wild Card Domain Name

      With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now
      in place, the semantics of a wild card domain name owning an
      NS RRSet has come to be poorly defined.  The dilemma relates to
      a conflict between the rules for synthesis in part 'c' and the
      fact that the resulting synthesis generates a record for which
      the zone is not authoritative.  In a DNSSEC signed zone, the
      mechanics of signature management (generation and inclusion
      in a message) have become unclear.

      Salient points of the working group discussion on this topic is
      summarized in section 4.2.1.

      As a result of these discussion, there is no definition given for
      wild card domain names owning an NS RRSet.  The semantics are
      left undefined until there is a clear need to have a set defined,
      and until there is a clear direction to proceed.  Operationally,
      inclusion of wild card NS RRSets in a zone is discouraged, but
      not barred.

4.2.1 Discarded Notions

      Prior to DNSSEC, a wild card domain name owning a NS RRSet
      appeared to be workable, and there are some instances in which
      it is found in deployments using implementations that support
      this.  Continuing to allow this in the specification is not
      tenable with DNSSEC.  The reason is that the synthesis of the
      NS RRSet is being done in a zone that has delegated away the
      responsibility for the name.  This "unauthorized" synthesis is
      not a problem for the base DNS protocol, but DNSSEC, in affirming
      the authorization model for DNS exposes the problem.

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

      Outright banning of wildcards of type NS is also untenable as
      the DNS protocol does not define how to handle "illegal" data.
      Implementations may choose not to load a zone, but there is no
      protocol definition.  The lack of the definition is complicated
      by having to cover dynamic update [RFC 2136], zone transfers,
      as well as loading at the master server.  The case of a client
      (resolver, caching server) getting a wildcard of type NS in
      a reply would also have to be considered.

      Given the daunting challenge of a complete definition of how to
      ban such records, dealing with existing implementations that
      permit the records today is a further complication.  There are
      uses of wild card domain name owning NS RRSets.

      One compromise proposed would have redefined wildcards of type
      NS to not be used in synthesis, this compromise fell apart
      because it would have required significant edits to the DNSSEC
      signing and validation work.  (Again, DNSSEC catches
      unauthorized data.)

      With no clear consensus forming on the solution to this dilemma,
      and the realization that wildcards of type NS are a rarity in
      operations, the best course of action is to leave this open-ended
      until "it matters."

4.3 CNAME RRSet at a Wild Card Domain Name

      The issue of a CNAME RRSet owned by a wild card domain name has
      prompted a suggested change to the last paragraph of step 3c of
      the algorithm in 4.3.2.  The changed text appears in section
      3.3.3 of this document.

4.4 DNAME RRSet at a Wild Card Domain Name

      Ownership of a DNAME [RFC2672] RRSet by a wild card domain name
      represents a threat to the coherency of the DNS and is to be
      avoided or outright rejected.  Such a DNAME RRSet represents
      non-deterministic synthesis of rules fed to different caches.
      As caches are fed the different rules (in an unpredictable
      manner) the caches will cease to be coherent.  ("As caches
      are fed" refers to the storage in a cache of records obtained
      in responses by recursive or iterative servers.)

      For example, assume one cache, responding to a recursive
      request, obtains the record:
         "a.b.example. DNAME foo.bar.example.net."
      and another cache obtains:
         "b.example.  DNAME foo.bar.example.net."
      both generated from the record:
         "*.example. DNAME foo.bar.example.net."
      by an authoritative server.

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

      The DNAME specification is not clear on whether DNAME records
      in a cache are used to rewrite queries.  In some interpretations,
      the rewrite occurs, in some, it is not.  Allowing for the
      occurrence of rewriting, queries for "sub.a.b.example. A" may
      be rewritten as "sub.foo.bar.tld. A" by the former caching
      server and may be rewritten as "sub.a.foo.bar.tld. A" by the
      latter.  Coherency is lost, an operational nightmare ensues.

      Another justification for banning or avoiding wildcard DNAME
      records is the observation that such a record could synthesize
      a DNAME owned by "sub.foo.bar.example." and "foo.bar.example."
      There is a restriction in the DNAME definition that no domain
      exist below a DNAME-owning domain, hence, the wildcard DNAME
      is not to be permitted.

4.5 SRV RRSet at a Wild Card Domain Name

      The definition of the SRV RRset is RFC 2782 [RFC2782].  In the
      definition of the record, there is some confusion over the term
      "Name."  The definition reads as follows:

# The format of the SRV RR
...
#    _Service._Proto.Name TTL Class SRV Priority Weight Port Target
...
#  Name
#   The domain this RR refers to.  The SRV RR is unique in that the
#   name one searches for is not this name; the example near the end
#   shows this clearly.

      Do not confuse the definition "Name" with the owner name.  I.e.,
      once removing the _Service and _Proto labels from the owner name
      of the SRV RRSet, what remains could be a wild card domain name
      but this is immaterial to the SRV RRSet.

      E.g.,  If an SRV record is:
         _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.

      *.example is a wild card domain name and although it is the Name
      of the SRV RR, it is not the owner (domain name).  The owner
      domain name is "_foo._udp.*.example." which is not a wild card
      domain name.

      The confusion is likely based on the mixture of the specification
      of the SRV RR and the description of a "use case."

4.6 DS RRSet at a Wild Card Domain Name

      A DS RRSet owned by a wild card domain name is meaningless and
      harmless.  This statement is made in the context that an NS RRSet
      at a wild card domain name is undefined.  At a non-delegation

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

      point, a DS RRSet has no value (no corresponding DNSKEY RRSet
      will be used in DNSSEC validation).  If there is a synthesized
      DS RRSet, it alone will not be very useful as it exists in the
      context of a delegation point.

4.7 NSEC RRSet at a Wild Card Domain Name

      Wild card domain names in DNSSEC signed zones will have an NSEC
      RRSet.  Synthesis of these records will only occur when the
      query exactly matches the record.  Synthesized NSEC RR's will not
      be harmful as they will never be used in negative caching or to
      generate a negative response.  [RFC2308]

4.8 RRSIG at a Wild Card Domain Name

      RRSIG records will be present at a wild card domain name in a
      signed zone, and will be synthesized along with data sought in a
      query.  The fact that the owner name is synthesized is not a
      problem as the label count in the RRSIG will instruct the
      verifying code to ignore it.

4.9 Empty Non-terminal Wild Card Domain Name

      If a source of synthesis is an empty non-terminal, then the
      response will be one of no error in the return code and no RRSet
      in the answer section.

5. 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 DNS, security of the DNS, and extending
      the DNS to be more predictable.

6. IANA Considerations

       None.

7. References

      Normative References

      [RFC20]   ASCII Format for Network Interchange, V.G. Cerf,
                Oct-16-1969

      [RFC1034] Domain Names - Concepts and Facilities,
                P.V. Mockapetris, Nov-01-1987

      [RFC1035] Domain Names - Implementation and Specification, P.V
                Mockapetris, Nov-01-1987

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

      [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996

      [RFC2119] Key Words for Use in RFCs to Indicate Requirement
                Levels, S Bradner, March 1997

      [RFC2308] Negative Caching of DNS Queries (DNS NCACHE),
                M. Andrews, March 1998

      [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
                August 1999.

      [RFC2782] A DNS RR for specifying the location of services (DNS
                SRV), A. Gulbrandsen, et.al., February 2000

      [RFC4033] DNS Security Introduction and Requirements, R. Arends,
                et.al., March 2005

      [RFC4034] Resource Records for the DNS Security Extensions,
                R. Arends, et.al., March 2005

      [RFC4035] Protocol Modifications for the DNS Security Extensions,
                R. Arends, et.al., March 2005

      Informative References

      [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE),
                P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
                April 1997

8. Editor

           Name:         Edward Lewis
           Affiliation:  NeuStar
           Address:      46000 Center Oak Plaza, Sterling, VA, 20166, US
           Phone:        [phone]
           Email:        [e-mail]

      Comments on this document can be sent to the editor or the mailing
      list for the DNSEXT WG, [e-mail].

9. Others Contributing to the Document

      This document represents the work of a large working group.  The
      editor merely recorded the collective wisdom of the working group.









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

10. Trailing Boilerplate

      Copyright (C) The Internet Society (2006).

      This document is subject to the rights, licenses and restrictions
      contained in BCP 78, and except as set forth therein, the authors
      retain all their rights.

      This document and the information contained herein are provided
      on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
      HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
      SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

      The IETF takes no position regarding the validity or scope of
      any Intellectual Property Rights or other rights that might
      be claimed to pertain to the implementation or use of the
      technology described in this document or the extent to which
      any license under such rights might or might not be available;
      nor does it represent that it has made any independent effort
      to identify any such rights.  Information on the procedures
      with respect to rights in RFC documents can be found in BCP 78
      and BCP 79.

      Copies of IPR disclosures made to the IETF Secretariat and any
      assurances of licenses to be made available, or the result of an
      attempt made to obtain a general license or permission for the
      use of such proprietary rights by implementers or users of this
      specification can be obtained from the IETF on-line IPR
      repository at http://www.ietf.org/ipr.  The IETF invites any
      interested party to bring to its attention any copyrights,
      patents or patent applications, or other proprietary rights
      that may cover technology that may be required to implement
      this standard.  Please address the information to the IETF at
      [e-mail].

Acknowledgement

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

Expiration

      This document expires on or about July 9, 2006.



DNSEXT Working Group        Expires July 9, 2006             [Page 19]