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

Florian Weimer <fweimer@bfk.de> Tue, 29 March 2011 09:31 UTC

Return-Path: <fweimer@bfk.de>
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 0C2613A690E for <dnsext@core3.amsl.com>; Tue, 29 Mar 2011 02:31:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.073
X-Spam-Level:
X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 z4vysCgiP0Nl for <dnsext@core3.amsl.com>; Tue, 29 Mar 2011 02:31:22 -0700 (PDT)
Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id B21B33A6906 for <dnsext@ietf.org>; Tue, 29 Mar 2011 02:31:22 -0700 (PDT)
Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Q4VIK-0002Ir-FX; Tue, 29 Mar 2011 09:33:00 +0000
Received: by bfk.de with local id 1Q4VIK-0006Yp-Ag; Tue, 29 Mar 2011 09:33:00 +0000
To: Paul Vixie <vixie@isc.org>
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> <99663.1298535473@nsa.vix.com>
From: Florian Weimer <fweimer@bfk.de>
Date: Tue, 29 Mar 2011 09:33:00 +0000
In-Reply-To: <99663.1298535473@nsa.vix.com> (Paul Vixie's message of "Thu\, 24 Feb 2011 08\:17\:53 +0000")
Message-ID: <82aagez2yb.fsf@mid.bfk.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: dnsext@ietf.org
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: Tue, 29 Mar 2011 09:31:24 -0000

* Paul Vixie:

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

It is at odds with your ex-cathedra statement (partially quoted
above).

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

Of course, ATLAS had to deal with them.  COM and NET were not
delegation-only at the time (even with Sitefinder switched off).  The
existance of authoritative child nodes in the zone looked like an
artefact in the way the zone was provisioned, but it still meant that
the particular authoritative server code paths existed, were exposed
and testable from the outside.

I don't know what else is hosted on the ATLAS infrastructure, so I
don't know if it's behavior in this corner cases is relevant.  In any
case, behavior has been changed (or has to be changed) for
DNSSEC-enabled zones, so it is slowly fading away, I guess.

-- 
Florian Weimer                <fweimer@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99