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

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

     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 reason is that the asterisk
     label only becomes significant when section's 4.3.2, step 3
     part 'c' in 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) become unclear.

     After some lengthy discussions, there has been no clear "best
     answer" on how to document the semantics of such a situation.
     Barring such records from the DNS would require definition of
     rules for that, as well as introducing a restriction on records
     that were once legal.  Allowing such records and amending the
     process of signature management would entail complicating the
     DNSSEC definition.

     There is one more ingredient to the discussion, that being the
     utility of a wild card domain name owned NS RRSet.  Although
     there are cases of this use, it is an operational rarity.
     Expending effort to close this topic has proven to be an
     exercise in diminishing returns.

     In summary, 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 specificaion 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.

     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, cacheing 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.

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

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

     [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

     [RFC2181] Clarifications to the DNS Specification, R. Elz and
               R. Bush, July 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

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

     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.

10. Trailing Boilerplate

     Copyright (C) The Internet Society (2005).

     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 January 6, 2006.