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

Colm MacCárthaigh <colm@allcosts.net> Thu, 31 March 2011 02:23 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 1AFDF3A6874 for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 19:23:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.638
X-Spam-Level:
X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 0ZhenofoMdUb for <dnsext@core3.amsl.com>; Wed, 30 Mar 2011 19:23:50 -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 6E5213A6BF1 for <dnsext@ietf.org>; Wed, 30 Mar 2011 19:23:49 -0700 (PDT)
Received: by fxm15 with SMTP id 15so1678474fxm.31 for <dnsext@ietf.org>; Wed, 30 Mar 2011 19:25:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.64.201 with SMTP id f9mr2145044fai.102.1301538328710; Wed, 30 Mar 2011 19:25:28 -0700 (PDT)
Received: by 10.223.96.8 with HTTP; Wed, 30 Mar 2011 19:25:28 -0700 (PDT)
In-Reply-To: <1330.1301525305@nsa.vix.com>
References: <AANLkTimCZVyag8+Pv8zJsah2B-C=h3bPJ=DNVVo3agLc@mail.gmail.com> <34319.1301351478@nsa.vix.com> <BANLkTikkx4ndK3TpByptuRdtPGuFztm2yA@mail.gmail.com> <65033.1301383238@nsa.vix.com> <82ei5qz3bi.fsf@mid.bfk.de> <84978.1301403827@nsa.vix.com> <82fwq6vsvk.fsf@mid.bfk.de> <94669.1301414190@nsa.vix.com> <a06240806c9b7b2040e80@10.31.200.119> <95465.1301414968@nsa.vix.com> <a06240807c9b7b5a6e892@10.31.200.119> <82vcz0n7a4.fsf@mid.bfk.de> <a06240800c9b93e602208@10.31.200.115> <1330.1301525305@nsa.vix.com>
Date: Wed, 30 Mar 2011 19:25:28 -0700
Message-ID: <AANLkTinurOKv61WOdwu4XtFHkzp2FzX5b2kFwazqRPHE@mail.gmail.com>
From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= <colm@allcosts.net>
To: Paul Vixie <vixie@isc.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: dnsext@ietf.org
Subject: Re: [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: Thu, 31 Mar 2011 02:23:52 -0000

On Wed, Mar 30, 2011 at 3:48 PM, Paul Vixie <vixie@isc.org> wrote:
> if we don't want to do that with rbldnsd given its 0.00005% market share
> and that really is the consensus of the working group, we can remove the
> text.  i'd like to hear from different voices to help judge consensus.

The behavior isn't limited to rbldnsd. It is also manifest in TinyDNS,
and probably other non-tree-indexed implementations.

These implementations may not have a plurality of domain names on
them, but I think they do meet the "widely deployed" bar.

Given that, it seems imprudent for resolvers to make inferences about
empty sub-trees based merely on NXDOMAIN.

At least one EDNS0 capable implementation exists that exhibits this
behavior [1] . So for the moment, making inferences on EDNS0 also
seems unwise.

Making inferences based on returning DNSSEC data may be safe, I
haven't yet found any counter-examples. I wouldn't be surprised to
find one though.

My vote would be for;

  Recommending that authoritative servers implementing DNSSEC SHOULD
NOT return NXDOMAIN for non-terminal labels.

  Recommending that caches SHOULD NOT infer empty sub-trees based on NXDOMAIN.

My reason for saying "implementing DNSSEC" is that inferring sub-tree
emptiness is another dangerous poisoning case (along with spoofed
DNAME and NS responses) that can poison a very large name-space in a
cache for very low effort. DNSSEC is a reasonable mitigation against
that problem.

On the historical point, I don't agree with djb's interpretation of
RFC2308. That RFC says;

  "A negative answer that resulted from a name error (NXDOMAIN) should
   be cached such that it can be retrieved and returned in response to
   another query for the same <QNAME, QCLASS> that resulted in the
   cached negative response."

It doesn't say "only returned". To say that inferences about empty sub-trees
is "outlawed" goes too far. But I think there's so little clarity in
the standards, that
no particular "side" has great support there. Greater clarity from now
on will definitely help!

[1]   dig +edns=0 terminal-label.non-terminal.notesfromthesound.com
@ns-431.awsdns-53.com
       dig +edns=0 non-terminal.notesfromthesound.com @ns-431.awsdns-53.com

-- 
Colm