Re: [dnsext] Fwd: RFC 2308 & RFC 4035

"W.C.A. Wijngaards" <wouter@nlnetlabs.nl> Sun, 27 February 2011 10:59 UTC

Return-Path: <wouter@nlnetlabs.nl>
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 5C8EE3A69E8 for <dnsext@core3.amsl.com>; Sun, 27 Feb 2011 02:59:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.469
X-Spam-Level:
X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_37=0.6, 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 MTeOnjkugStf for <dnsext@core3.amsl.com>; Sun, 27 Feb 2011 02:59:25 -0800 (PST)
Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by core3.amsl.com (Postfix) with ESMTP id 1F1613A677C for <dnsext@ietf.org>; Sun, 27 Feb 2011 02:59:25 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id B848F58B4E for <dnsext@ietf.org>; Sun, 27 Feb 2011 12:00:21 +0100 (CET)
Received: from [192.168.254.2] (195-241-9-117.adsl.dds.nl [195.241.9.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id 2945658485 for <dnsext@ietf.org>; Sun, 27 Feb 2011 12:00:16 +0100 (CET)
Message-ID: <4D6A2EBF.6010806@nlnetlabs.nl>
Date: Sun, 27 Feb 2011 12:00:15 +0100
From: "W.C.A. Wijngaards" <wouter@nlnetlabs.nl>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101125 SUSE/3.0.11 Thunderbird/3.0.11
MIME-Version: 1.0
To: dnsext@ietf.org
References: <a06240805c98db61801c2@[10.31.200.114]> <20110226003214.0E1BFAFA28D@drugs.dv.isc.org><a06240800c98ed0f7a8c5@[10.31.200.114]> <20110226234237.9E59DB00438@drugs.dv.isc.org>
In-Reply-To: <20110226234237.9E59DB00438@drugs.dv.isc.org>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.96.5 at rotring
X-Virus-Status: Clean
Subject: Re: [dnsext] Fwd: RFC 2308 & RFC 4035
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: Sun, 27 Feb 2011 10:59:26 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 02/27/2011 12:42 AM, Mark Andrews wrote:
>> I think my question wasn't understood.
>>
>> Do cache implementers use the fact that the proof of no A record 
>> coincidently shows there is also no AAAA record when processing a 
>> subsequent AAAA query.  (Meaning, there's no other entry for the AAAA 
>> alredy in the cache.)
>>
>> If a cache does do this kind of proof by inference, what does the 
>> implementer think about the situation in which there is a "race 
>> condition" - that the proof of non-existence has been obviated by 
>> actions outside of it's sphere?  (Like the subsequent adding of the 
>> AAAA set in the authority.
> 
> We do this for NXDOMAIN today.  If we ask for A foo.example and get
> back a NXDOMAIN then the cache gets asked for AAAA foo.example we
> use that NXDOMAIN.  Using the NSEC/NSEC3 that matches the <qname,qclass>
> really no different.
> 
> The much more interesting question is infering NXDOMAIN for a
> <qname,qclass> we havn't asked for.  Named already does this when
> looking for DLV records when validating but is expected by all
> parties involved.

Unbound does not use this, also not for NXDOMAINs and other types.

We infer NXDOMAINs and NODATA for DLV records, like named does, because
the RFC says so.

Qtype DS is also inferred from NSECs, an artifact of the implementation.
 It should never have the problem that you describe because if the
domain suddenly got signed, you would get the DS with the referral, and
having an old referral means that exactly what Mark said earlier 'there
was a referral query 10 minutes ago', otherwise you would not have the
NS data anyway and get the DS information if you were to need new NS data.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAk1qLr8ACgkQkDLqNwOhpPhinACgiMzWRLSc4VnK/X6eOOkuuy4n
cXYAnR3oMs4g+YODyGtaGvckG/IFpQgm
=ERnd
-----END PGP SIGNATURE-----