Re: [dnsext] bitmap inference was Re: ... - NXDOMAIN for emptynon-terminals

Jelte Jansen <> Wed, 30 March 2011 11:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1B1928C0DB for <>; Wed, 30 Mar 2011 04:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GKqyGqMV6JHD for <>; Wed, 30 Mar 2011 04:37:55 -0700 (PDT)
Received: from ( [IPv6:2001:500:60::65]) by (Postfix) with ESMTP id EE62928C171 for <>; Wed, 30 Mar 2011 04:37:54 -0700 (PDT)
Received: from ( [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "", Issuer "ISC CA" (verified OK)) by (Postfix) with ESMTPS id E4D575F98B6; Wed, 30 Mar 2011 11:39:18 +0000 (UTC) (envelope-from
Received: from [IPv6:2001:df8:0:16:222:43ff:fe24:8028] (unknown [IPv6:2001:df8:0:16:222:43ff:fe24:8028]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 01FF6216C22; Wed, 30 Mar 2011 11:39:15 +0000 (UTC) (envelope-from
Message-ID: <>
Date: Wed, 30 Mar 2011 13:39:12 +0200
From: Jelte Jansen <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: Edward Lewis <>
References: <><8EA8D1A36B8F49 68ABE973C39CA5E0E0@local><a06240800c9b78d52751f@[]><FCB25297B FF0419692724D36AF3BC99E@local> <a06240804c9b79c870558@[]><55128075215341BD92DCAAD00450FA85@l ocal> <a06240809c9b7b7143e51@[]> <3B987BF13718424BBA818C248C428E64@local> <a06240800c9b7c543104f@[]> <A5D8841CEB8F4BF9A007C8B6408C363C@local> <a06240801c9b7d3b57307@[]>
In-Reply-To: <a06240801c9b7d3b57307@[]>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [dnsext] bitmap inference was Re: ... - NXDOMAIN for emptynon-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 11:37:57 -0000

Hash: SHA1

On 03/29/2011 08:33 PM, Edward Lewis wrote:
> At 19:14 +0100 3/29/11, George Barwood wrote:
>> The standard ( ) says
>>    The Type Bit Maps field identifies the RRset types that exist at the
>>    NSEC RR's owner name.
> It doesn't say "MUST".  That's giving the semantic meaning of the
> field.  And it doesn't say "when" existence is tested.

It does not say 'MAY depend on type' either :)

> The problem is determining a if there is a protocol violation.
> If you get this:
> t=0 (Q:fqdn.tld./IN/AAAA):
> fqdn.tld.   3600 IN NSEC other.tld. priv_type
> t=5 (Q:fqdn.tld./IN/A):
> fqdn.tld.   3600 IN A
> How can you tell if I generated the NSEC regardless of the A record or
> just before the A record was added to the zone?  In the latter case, if
> you asked for the A you don't get the would-be-new NSEC.

as with another example you used in a previous discussion, it would seem
you are arguing for not doing negative caching at all (i.e. if an A
record is queried, does not exist, is then added, and queried again it
would show the same behavior as when you ask for a different type and
derive data from the nsec bitmap). Taking that further, what if
something is removed between t=0 and t=5, should we also not do positive
caching? :)

IMO whether or not aggressive caching should be done or allowed, giving
different answers where one would expect the same (i.e. different NSECs
depending on the qtype, in this case) makes me slightly nauseous :p But
that is probably not much of a protocol qualification.

Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla -