Re: [dnsext] RFC 4035 and "caching" of "expired RRSIG's"

Florian Weimer <fweimer@bfk.de> Tue, 04 January 2011 10:50 UTC

To: Marc Lampo <marc.lampo@eurid.eu>
References: <000201cbabf5$0533d010$0f9b7030$@eurid.eu> <82sjx9kmqf.fsf@mid.bfk.de> <000c01cbabfc$b527e4f0$1f77aed0$@eurid.eu>
From: Florian Weimer <fweimer@bfk.de>
Date: Tue, 04 Jan 2011 10:52:06 +0000
In-Reply-To: <000c01cbabfc$b527e4f0$1f77aed0$@eurid.eu> (Marc Lampo's message of "Tue\, 4 Jan 2011 11\:46\:51 +0100 $CET$")
Message-ID: <82lj31uejt.fsf@mid.bfk.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: dnsext@ietf.org
Subject: Re: [dnsext] RFC 4035 and "caching" of "expired RRSIG's"
Precedence: list

* Marc Lampo:

> You indicate that this portion of the RFC handles TTL only,
>  but the last paragraph of that section 4.5 states :
>  "until the TTL or signatures ... expire"
>  --> this leads to believe that it is not exclusively TTL only
> That possible, dual, interpretation indicates the need for clarifation, I
> would say.

The paragraph containing this statement sketches
NODATA/NXDOMAIN/wildcard synthesis and recommends against it.  For
that type of synthesis, you likely want to obey cryptographic
constraints because you only want to synthesize an answer which can be
proven cryptographically valid.  This is about pulling records from
thin air, and it is fundamentally different from regular caching
behavior.

-- 
Florian Weimer                <fweimer@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

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