[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