[dnsext] RFC 4035 and "caching" of "expired RRSIG's"
"Marc Lampo" <marc.lampo@eurid.eu> Tue, 04 January 2011 09:49 UTC
Return-Path: <marc.lampo@eurid.eu>
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 2674E3A6B63 for <dnsext@core3.amsl.com>; Tue, 4 Jan 2011 01:49:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 thdjSFu-s6Tm for <dnsext@core3.amsl.com>; Tue, 4 Jan 2011 01:49:48 -0800 (PST)
Received: from cuda.eurid.eu (mx.eurid.eu [77.67.53.136]) by core3.amsl.com (Postfix) with ESMTP id 33DCD3A69F5 for <dnsext@ietf.org>; Tue, 4 Jan 2011 01:49:47 -0800 (PST)
X-ASG-Debug-ID: 1294134710-1ebb1e440001-uIE7UK
Received: from zimbra.eurid.eu (blade2.bc2.vt.eurid.eu [172.19.101.22]) by cuda.eurid.eu with ESMTP id HVfXo88rQR4JXhMA for <dnsext@ietf.org>; Tue, 04 Jan 2011 10:51:50 +0100 (CET)
X-Barracuda-Envelope-From: marc.lampo@eurid.eu
X-ASG-Whitelist: Client
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 5B306B0060 for <dnsext@ietf.org>; Tue, 4 Jan 2011 10:51:50 +0100 (CET)
X-Virus-Scanned: amavisd-new at techmail.eurid.eu
Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCfiX4rw6c2q for <dnsext@ietf.org>; Tue, 4 Jan 2011 10:51:50 +0100 (CET)
Received: from zimbra.eurid.eu (zimbra.eurid.eu [172.19.0.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 482D7B005F for <dnsext@ietf.org>; Tue, 4 Jan 2011 10:51:50 +0100 (CET)
From: Marc Lampo <marc.lampo@eurid.eu>
To: dnsext@ietf.org
Date: Tue, 04 Jan 2011 10:51:50 +0100
X-ASG-Orig-Subj: RFC 4035 and "caching" of "expired RRSIG's"
Message-ID: <000201cbabf5$0533d010$0f9b7030$@eurid.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Mailer: Microsoft Office Outlook 12.0
X-Mailer: Zimbra 5.0.18_GA_3011.RHEL5_64 (ZimbraConnectorForOutlook/5.0.3064.18)
Content-Language: en-za
Thread-Index: Acur9QTIZ5zL2FvVR/aJmJd2k8RWBA==
X-Originating-IP: [172.20.1.130]
X-Barracuda-Connect: blade2.bc2.vt.eurid.eu[172.19.101.22]
X-Barracuda-Start-Time: 1294134710
X-Barracuda-URL: http://77.67.53.136:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at eurid.eu
Subject: [dnsext] RFC 4035 and "caching" of "expired RRSIG's"
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: Tue, 04 Jan 2011 09:49:50 -0000
Hello group, and my best whishes for a healthy and challenging 2011 ! Allow me to throw a question about "caching" of "expired RRSIG's". In RFC4035, DNSSEC protocol, in section 4 : Resolving 4.5. Response Caching A security-aware resolver SHOULD cache each response as a single atomic entry containing the entire answer, including the named RRset and any associated DNSSEC RRs. The resolver SHOULD discard the entire atomic entry when any of the RRs contained in it expire. In a preceding paragraph on Recursive Name Servers (3.2), it reads : The resolver side follows the usual rules for caching and negative caching that would apply to any security-aware resolver. --> I interpret that the discarding of an entire atomic entry when (even at least) one RRSIG in it expire (even though others may be still be valid) is a recommendation (only). There are two aspects I feel might need some explicit clarification : 1) the "should", from 4.5, is to be interpreted as : "recommended" and "developer, know what you are doing when you do not implement this" (free after rfc 2119) Consequently : some name server implementations/versions may chose to cache expired RRSIG's 2) "*any* of the RRs ... expire" Fact is that multiple RRSIG's may be available, not all of which expired, and those that are still valid, may allow to perform full DNSSEC validation. If taken literally, name servers that do implement discarding according to 4.5 of RFC4035 might not cache otherwise valid info (RRset + related RRSIG(set)) as soon as one of the RRSIG's expires. As this might defeat the functioning of caching - there are name servers that almost continuously return an expired RRSIG, In the presence of other, not expired, RRSIG(s) that do allow DNSSEC validation - if at leased one received RRSIG is already expired upon reception. Consequently : Wouldn't it be wise to rephrase 4.5 of RFC4035 such that "DNSSEC validation becomes impossible" is meant ? At this moment, as eu. top-level domain, we continue to warn for RRSIG's that may expire while in some cache. (because throwing them out of the cache is "recommended" only). We feel this is in the interest of optimal DNSSEC operation. Thanks for sharing your feedback. Kind regards, Marc Lampo Security Officer EURid Woluwelaan 150 1831 Diegem - Belgium marc.lampo@eurid.eu http://www.eurid.eu Register your .eu domain name and win an iPod touch this X-Mas http://www.winwith.eu
- Re: [dnsext] RFC 4035 and "caching" of "expired R… Marc Lampo
- [dnsext] RFC 4035 and "caching" of "expired RRSIG… Marc Lampo
- Re: [dnsext] RFC 4035 and "caching" of "expired R… Florian Weimer
- Re: [dnsext] RFC 4035 and "caching" of "expired R… Florian Weimer