Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness

Paul Vixie <vixie@isc.org> Thu, 24 February 2011 08:17 UTC

Return-Path: <vixie@isc.org>
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 E8AF13A6961 for <dnsext@core3.amsl.com>; Thu, 24 Feb 2011 00:17:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 RXI2eSJlAERH for <dnsext@core3.amsl.com>; Thu, 24 Feb 2011 00:17:06 -0800 (PST)
Received: from nsa.vix.com (unknown [IPv6:2001:4f8:3:bb:230:48ff:fe5a:2f38]) by core3.amsl.com (Postfix) with ESMTP id EE6AA3A6A0C for <dnsext@ietf.org>; Thu, 24 Feb 2011 00:17:05 -0800 (PST)
Received: from nsa.vix.com (localhost [127.0.0.1]) by nsa.vix.com (Postfix) with ESMTP id 7401CA1059 for <dnsext@ietf.org>; Thu, 24 Feb 2011 08:17:53 +0000 (UTC) (envelope-from vixie@isc.org)
From: Paul Vixie <vixie@isc.org>
To: dnsext@ietf.org
In-Reply-To: Your message of "Wed, 23 Feb 2011 15:48:24 GMT." <82y656u4zb.fsf@mid.bfk.de>
References: <4D622624.90303@ogud.com> <BF79BE89-20B2-4897-B07C-1426745C4AA9@verisign.com> <AANLkTinQig=e7wv-3GsXi73p3AKQOsbjE6EzDNMbWWRw@mail.gmail.com> <4D63907A.8010700@nlnetlabs.nl> <82zkpnyt3z.fsf@mid.bfk.de> <22348.1298455916@nsa.vix.com> <82ei6zyqqz.fsf@mid.bfk.de> <39328.1298474414@nsa.vix.com> <82y656u4zb.fsf@mid.bfk.de>
X-Mailer: MH-E 8.2; nmh 1.2; XEmacs 21.4 (patch 22)
Date: Thu, 24 Feb 2011 08:17:53 +0000
Message-ID: <99663.1298535473@nsa.vix.com>
Subject: Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness
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: Thu, 24 Feb 2011 08:17:07 -0000

> From: Florian Weimer <fweimer@bfk.de>
> Date: Wed, 23 Feb 2011 15:48:24 +0000
> 
> > who is everyone?  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.
> 
> The handling of empty non-terminals was changed in BIND 9.2.3,
> probably prompted by the standardization work on DNSSECbis.  According
> to the CHANGES file, this is RT #4715 in your bug tracker.

as marka has explained, this was a dnssec protocol bug, which bind9 tracked.

> > nlnetlabs nsd and verisign atlas both understood the spec in this
> > regard also.
> 
> Actually, ATLAS sent NXDOMAIN instead of NODATA for existing,
> non-delegated names with a missing RRset (that is, empty terminals) at
> one point in the not too-distant past.  I don't remember if they
> implemented the old BIND behavior, too, but it would be odd to send
> NXDOMAIN for empty terminals, and NODATA for empty non-terminals.
---
> Off-list, I was told that my terminology is off, which is true.
> Please read "empty RRsets" for "empty terminals".

either way this is unrelated to empty nonterminals, which atlas never had
to deal with anyway, i should not have mentioned it.

---

> Date: Wed, 23 Feb 2011 12:52:56 -0400
> From: Brian Dickson <brian.peter.dickson@gmail.com>
> ...
> - it shows that regardless of deployment scope, there should be
> pressure to fix broken deployments, rather than to ankylose (rigidly
> anchor, forever) that broken-ness into the specifications (IMHO)

right.