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

Sabahattin Gucukoglu <mail@sabahattin-gucukoglu.com> Thu, 31 March 2011 10:51 UTC

Return-Path: <mail@sabahattin-gucukoglu.com>
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 B3CA828C11D for <dnsext@core3.amsl.com>; Thu, 31 Mar 2011 03:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.962
X-Spam-Level:
X-Spam-Status: No, score=0.962 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HOST_MISMATCH_COM=0.311, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 OfB85oxQEBni for <dnsext@core3.amsl.com>; Thu, 31 Mar 2011 03:51:33 -0700 (PDT)
Received: from Mintaka.sabahattin-gucukoglu.com (sgucukoglu-2-pt.tunnel.tserv8.dal1.ipv6.he.net [IPv6:2001:470:1f0e:7ef::2]) by core3.amsl.com (Postfix) with ESMTP id 3E46328C113 for <dnsext@ietf.org>; Thu, 31 Mar 2011 03:51:32 -0700 (PDT)
Received: from Mintaka.sabahattin-gucukoglu.com ([::ffff:127.0.0.1]:60172) by Mintaka.sabahattin-gucukoglu.com with [XMail 1.27 ESMTP Server] id <S31C9B> for <dnsext@ietf.org> from <mail@sabahattin-gucukoglu.com>; Thu, 31 Mar 2011 11:53:10 +0100
Received: from [192.168.1.13] (cpc2-dals7-0-0-cust570.hari.cable.virginmedia.com [82.35.114.59]) (using SMTP over TLS) by Mintaka.sabahattin-gucukoglu.com (tmda-ofmipd) with ESMTP; Thu, 31 Mar 2011 11:53:08 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
In-Reply-To: <a06240800c9b93e602208@[10.31.200.115]>
Date: Thu, 31 Mar 2011 11:53:04 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <271F1E6D-202D-4BD8-9436-31BC217AA830@sabahattin-gucukoglu.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]>
To: dnsext@ietf.org
X-Mailer: Apple Mail (2.1084)
X-Delivery-Agent: TMDA/1.1.12-kg2 (Pluto)
From: Sabahattin Gucukoglu <mail@sabahattin-gucukoglu.com>
X-Primary-Address: mail@sabahattin-gucukoglu.com
Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Sabahattin Gucukoglu <mail-dated-1304160790.1f5300@sabahattin-gucukoglu.com>
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 10:51:34 -0000

On 30 Mar 2011, at 21:27, Edward Lewis wrote:
> Dan Bernstein's statement (as found in [0]) that returning NXDOMAIN for empty non-terminals is acceptable because buggy code did this in the past is an interesting point.  While technically wrong to do so, this code is out there and to accommodate (work around the bug), optimizing according what is in section 3 would be sub-optimal.  I would never say that NXDOMAIN for empty non-terminals is correct as a protocol analyst.  But if I was dealing with buggy code, I'd play the "be liberal in what you accept" card.

I have to admit, I can't even understand the question, and after so much discussion I'm starting to feel that I never will.  I could not imagine any other behaviour than the one manifest in pretty much every DNS server I can get my hands on (BIND 9, Tinydns, MaraDNS, NSD, ...) and could not see how it would even make sense or be possible to implement the suggestion to return 0 records for non-terminal labels.  What would the authority for such a query name be?  You could hardly synthesise one, and using the SOA from the next highest delegation doesn't work, unless you also don't mind making the case of no data at query name exclusively indistinct from no data at query name except for the possibility of terminating labels.  How could you distinguish components of query names which are naturally entered and used with dots in their textual representations, without providing misleading responses to questions about the right-hand sides of such names?  And doesn't it follow that a non-terminal name isn't a name, so that it doesn't exist, rather than that it does only because it happens to use more than the usual number of labels between delegations?

And then there's all the existing points raised about the feasibility of *trusting* NXDOMAIN responses, based on the idea that the authoritative servers will distinguish terminals from non-terminals in this way, which as has been discussed before is problematic for a number of good, solid reasons (RBLs, increased work for caches with non-tree structures, etc).

If somebody could help me to understand which bit of RFC 1034-5 or succeeding documents says (or even hints at) the fallibility of multi-label names, I'd be especially interested, since so far I haven't been able to do it.  It would help me decide that much more firmly one way or the other; for now, I don't like the suggestion.  Maybe it's all about semantics, but I like things the way they are (in this regard). It's clearer and, for me, more logical and sensible, with no added gotchas.

Cheers,
Sabahattin

PS: Dan did in fact post that referenced message to his dns@list.cr.yp.to list.  I use tinydns, primarily, but am thinking about shuffling along to NSD.