DNS/返答/NXDOMAIN/DJBの見解/続きについて、ここに記述してください。

Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers,
        for Resiliency, Robustness, and Responsiveness
From: "D. J. Bernstein" <[hidden email]>
Date: 23 Feb 2011 22:32:37 -0000
To: [hidden email]
Message-ID: <[hidden email]>

Here's a Paul Vixie quote from a message here dated 8 December 1999
(http://groups.google.com/group/comp.protocols.dns.std/msg/69e4500e7b7d73c8):

   RFC 2308 implicitly outlawed BIND's behaviour, which is to return
   NOERROR/ANCOUNT=0 for empty nonterminals. After RFC 2308, empty
   nonterminals are signalled with NXDOMAIN.

This use of NXDOMAIN has obvious benefits for some server-side database
structures. My DNS server software, tinydns,

   * was released a few weeks later,
   * signals empty nonterminals with NXDOMAIN,
   * has become increasingly popular among DNS administrators, and
   * now publishes the DNS records for millions of second-level domains.

Many versions of BIND, and many other DNS servers currently deployed on
the Internet, also signal empty nonterminals with NXDOMAIN.

If a cache misinterprets NXDOMAIN as applying to subdomains, the cache
doesn't work correctly on the Internet today. Here's a concrete example
to make clear what this means:

   * The NS records for citysearch.com today are d.ns.citysearch.com and
     e.ns.citysearch.com. 


   * ns.citysearch.com today returns NXDOMAIN.

   * If a cache follows the citysearch.com NS records to d.ns... and
     e.ns..., but then misinterprets the ns... NXDOMAIN as applying to
     d.ns... and e.ns..., then it will incorrectly conclude that
     citysearch.com has broken glue, and it will respond SERVFAIL for
     www.citysearch.com, completely screwing the user who wanted to see
     the www.citysearch.com web page.

Caches have to, and as far as I know do, apply NXDOMAIN only to "the
same <QNAME, QCLASS>" (RFC 2308, Section 5), easily avoiding this type
of interoperability problem. Anyone who believes the IETF mission
statement in RFC 3935 would expect IETF to promote interoperability by
issuing a warning saying that cache implementors MUST NOT misinterpret
NXDOMAIN as applying to subdomains---if this isn't already sufficiently
clear from the existing IETF documents such as RFC 2308.

Years after his 1999 "After RFC 2308, empty nonterminals are signalled
with NXDOMAIN" statement, Vixie suddenly changed his view and started
issuing highly irresponsible documents (such as "wcard-clarify" in 2003
and "dnsext-resimprove" in 2010) encouraging cache implementors to
misinterpret NXDOMAIN as applying to subdomains---creating exactly the
type of failures described above. At least two cache implementors have
spoken up here to say that this cache behavior _doesn't_ work, _can't_
be turned on, and _isn't_ current practice, so how can it possibly be
labelled "best current practice"?

This has been extensively discussed here before, and nowhere in any of
the discussions has there been any explanation of how this clumsy,
non-interoperable, user-antagonistic change in cache behavior would
provide any benefits for the Internet. Does someone think that the
Internet's bandwidth is being saturated by DNS queries for nonexistent
subdomains of nonexistent domains, or that users are spending noticeable 
amounts of time waiting for the answers? 

Bottom line: On behalf of the millions of users who rely on my DNS
software (and other deployed software that signals empty nonterminals
with NXDOMAIN), I object to any attempt to change the definition of
NXDOMAIN from the RFC 2308/Vixie 1999/BIND 9/tinydns/etc. definition
into something that applies to subdomains. In particular, I object to
the dnsext-reimprove document.

---D. J. Bernstein
   Research Professor, Computer Science, University of Illinois at Chicago