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

Edward Lewis <> Wed, 30 March 2011 20:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A803228C0DE for <>; Wed, 30 Mar 2011 13:25:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.566
X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7GVVtx3EUvGi for <>; Wed, 30 Mar 2011 13:25:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 740E53A69AB for <>; Wed, 30 Mar 2011 13:25:41 -0700 (PDT)
Received: from Work-Laptop-2.local ( []) by (8.14.4/8.14.4) with ESMTP id p2UKRGU8080129; Wed, 30 Mar 2011 16:27:16 -0400 (EDT) (envelope-from
Received: from [] by Work-Laptop-2.local (PGP Universal service); Wed, 30 Mar 2011 16:27:16 -0400
X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 30 Mar 2011 16:27:16 -0400
Mime-Version: 1.0
Message-Id: <a06240800c9b93e602208@[]>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <a06240806c9b7b2040e80@[]> <> <a06240807c9b7b5a6e892@[]> <>
Date: Wed, 30 Mar 2011 16:27:14 -0400
From: Edward Lewis <>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.68 on
Cc: Edward Lewis <>
Subject: Re: [dnsext] Fwd: djb on NXDOMAIN/NODATA for non-terminals
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Mar 2011 20:25:42 -0000

At 12:04 +0000 3/30/11, Florian Weimer wrote:
>I was referring to section 3.  I think it is misleading and would lead
>to poorer service from resolvers if implemented.

Florian, thanks for the pointer. I really had lost track of the thread.

In section 3, it mentions an ambiguity in RFC 1034.  Question: what 
ambiguity (there are a lot of them), like what section or page.  I'm 
asking out of curiosity.

Still, the point of section 3 is right.   If there were no bad code 
out there and if the data never changed then I'd say it is good.  But 
there is bad code out there.

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.

Secondly, because of the fact that things change, it might be wrong 
for a cache to synthesize, based on a cached NXDOMAIN what may now be 
in a subdomain of the zone authoritative for the NXDOMAIN.  To me, 
this is a secondary concern because we've long recognized that the 
DNS protocol is pretty much agnostic about time.  It is true that 
RFC's in the past have said an NXDOMAIN can be used by caches to 
declare data of any type at a name as non-existing - but this 
pertains to the same name, not descendents.

So, while I think in theory section 3 is correct, in practice it 
seems to be an over-optimization given an imperfect world.

[0] -
(I don't see a message "directly" from him, just this forward.  In 
case the forward was a forgery my point is directed at the real 
source of the comment, not Dan Bernstein.)

Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"