[dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals

Colm MacCárthaigh <colm@allcosts.net> Mon, 28 March 2011 22:22 UTC

Return-Path: <colm@allcosts.net>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4D33A679F for <dnsext@core3.amsl.com>; Mon, 28 Mar 2011 15:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.52
X-Spam-Level:
X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNk2QECXjUIZ for <dnsext@core3.amsl.com>; Mon, 28 Mar 2011 15:22:16 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id CBF8D3A68DF for <dnsext@ietf.org>; Mon, 28 Mar 2011 15:22:12 -0700 (PDT)
Received: by fxm15 with SMTP id 15so3352498fxm.31 for <dnsext@ietf.org>; Mon, 28 Mar 2011 15:23:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.14.22 with SMTP id e22mr5154863faa.64.1301351029291; Mon, 28 Mar 2011 15:23:49 -0700 (PDT)
Received: by 10.223.96.8 with HTTP; Mon, 28 Mar 2011 15:23:49 -0700 (PDT)
Date: Mon, 28 Mar 2011 15:23:49 -0700
Message-ID: <AANLkTimCZVyag8+Pv8zJsah2B-C=h3bPJ=DNVVo3agLc@mail.gmail.com>
From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= <colm@allcosts.net>
To: dnsext@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Mar 2011 22:22:17 -0000

Forwarding due to relevancy ...

---------- Forwarded message ----------
From: D. J. Bernstein <djb@cr.yp.to>
Date: Mon, Mar 28, 2011 at 3:13 PM
Subject: Re: Fixing the NXDOMAIN/NODATA bug in tinydns
To: dns@list.cr.yp.to


Returning NXDOMAIN for empty nonterminals is not a bug. It is perfectly
interoperable behavior that has been used and continues to be used by
many different pieces of DNS software, including many versions of BIND.
The behavior has never caused problems for DNS users.

Fun historical fact: This behavior was put into the first version of
tinydns after a public statement by BIND maintainer Paul Vixie saying
that this behavior is _required_. Here's the exact Vixie quote:

  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.

A much more recent statement from Vixie claims that BIND never actually
did this---

  i don't think bind or nominum or microsoft's or american internet's
  (now cisco's) authority servers have ever sent nxdomain on an empty
  non-terminal, and for a long time that was 100% of the market.

---but that's totally wrong. At least five consecutive years of BIND
releases returned NXDOMAIN for empty nonterminals, contrary to Vixie's
statement. (The behavior was suddenly changed in BIND 9.2.3, RT #4715.)

Here's a more detailed message that I tried to send to namedroppers (the
IETF dnsext mailing list) on this topic a month ago. I say "tried"
because this message didn't show up on the mailing list even after I
sent it to the list, sent it again to the "moderator", and sent it once
again to the list.

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


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

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



-- 
Colm