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-----
- Re: [dnsext] Fwd: RFC 2308 & RFC 4035 George Barwood
- Re: [dnsext] Fwd: RFC 2308 & RFC 4035 Edward Lewis
- [dnsext] Fwd: RFC 2308 & RFC 4035 Edward Lewis
- Re: [dnsext] Fwd: RFC 2308 & RFC 4035 Brian Dickson
- Re: [dnsext] Fwd: RFC 2308 & RFC 4035 Edward Lewis
- Re: [dnsext] Fwd: RFC 2308 & RFC 4035 Paul Vixie
- Re: [dnsext] Fwd: RFC 2308 & RFC 4035 Mark Andrews
- Re: [dnsext] Fwd: RFC 2308 & RFC 4035 W.C.A. Wijngaards
- Re: [dnsext] Fwd: RFC 2308 & RFC 4035 Edward Lewis
- Re: [dnsext] Fwd: RFC 2308 & RFC 4035 Mark Andrews
- Re: [dnsext] Fwd: RFC 2308 & RFC 4035 W.C.A. Wijngaards
- Re: [dnsext] Fwd: RFC 2308 & RFC 4035 Edward Lewis
- Re: [dnsext] Fwd: RFC 2308 & RFC 4035 Edward Lewis
- Re: [dnsext] Fwd: RFC 2308 & RFC 4035 John Levine
- Re: [dnsext] Fwd: RFC 2308 & RFC 4035 Paul Vixie
- Re: [dnsext] Fwd: RFC 2308 & RFC 4035 John Levine
- Re: [dnsext] Fwd: RFC 2308 & RFC 4035 Paul Vixie
- Re: [dnsext] Fwd: RFC 2308 & RFC 4035 Edward Lewis