DNSSEC - 1 RRSIG - expires while in cache
Hello, In my opinion, the following situation should be avoided, but I'd welcome motivated second opinions. A DNSSEC verification script yielded a warning, this morning : HIDDEN : (soa = HIDDEN) (# RRSIGS : 1) (keyid : HIDDEN) inception: 20101124231706 ok now : 20101127083003 expiration : 20101129231706 ok ttl : 259200 expiration - ttl : 20101126231706 WARNING (becomes invalid during TTL) In summary : There is one (1) RRSIG available, Which is valid now and not yet expired. However, given the TTL, the signature will expire while still in the cache. Q1: If a RRSIG is found in the cache (cache hit), but it is expired. ? should a validating caching name server ignore the RRSIG in the cache and look for a refresh ? ? will Bind do so ? Q2: Does Bind automatic resigning take the TTL into account ? (so that it does not resign later then present expiration - TTL) Or is this irrelevant because the answer to earlier question is that an expired RRSIG in the cache must be refreshed. Thanks and kind regards, Marc Lampo Security Officer EURid Woluwelaan 150 1831 Diegem - Belgium TEL.: +32 (0) 2 401 3030 MOB.:+32 (0)476 984 391 marc.la...@eurid.eu http://www.eurid.eu Want a .eu web address in your own language? Find out how so you dont miss out! Register your .eu domain name and win an iPod though this X-Mas http://www.winwith.eu ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC - 1 RRSIG - expires while in cache
From: Marc Lampo marc.la...@eurid.eu Date: Sat, 27 Nov 2010 13:09:13 +0100 (CET) Sender: bind-users-bounces+oberman=es@lists.isc.org Hello, In my opinion, the following situation should be avoided, but I'd welcome motivated second opinions. A DNSSEC verification script yielded a warning, this morning : HIDDEN : (soa = HIDDEN) (# RRSIGS : 1) (keyid : HIDDEN) inception: 20101124231706 ok now : 20101127083003 expiration : 20101129231706 ok ttl : 259200 expiration - ttl : 20101126231706 WARNING (becomes invalid during TTL) In summary : There is one (1) RRSIG available, Which is valid now and not yet expired. However, given the TTL, the signature will expire while still in the cache. Q1: If a RRSIG is found in the cache (cache hit), but it is expired. ? should a validating caching name server ignore the RRSIG in the cache and look for a refresh ? Nope. It should refuse to validate. ? will Bind do so ? Pretty sure that it will return SERVFAIL. Q2: Does Bind automatic resigning take the TTL into account ? (so that it does not resign later then present expiration - TTL) Or is this irrelevant because the answer to earlier question is that an expired RRSIG in the cache must be refreshed. Not sure. The RFCs contain warnings that you MUST take re-signing interval into account when setting TTL. The interval between ZSK signing must be set so that the TTL for an expiring key will always expire first so that the new key will be fetched before the old one expires. I thing the heading in the RFC is TTL Considerations, but I am working from memory. I don't use BIND to sign my data, so I am not sure how smart BIND is about these numbers. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC - 1 RRSIG - expires while in cache
On 2010-11-27 13:09, Marc Lampo wrote: Q2: Does Bind automatic resigning take the TTL into account ? (so that it does not resign later then present expiration - TTL) Depending on the configuration: sig-validity-interval Specifies the number of days into the future when DNSSEC signatures automatically generated as a result of dynamic updates (the section called Dynamic Update) will expire. There is an optional second field which specifies how long before expiry that the signatures will be regenerated. If not specified, the signatures will be regenerated at 1/4 of base interval. The second field is specified in days if the base interval is greater than 7 days otherwise it is specified in hours. The default base interval is 30 days giving a re-signing interval of 7 1/2 days. The maximum values are 10 years (3660 days). The signature inception time is unconditionally set to one hour before the current time to allow for a limited amount of clock skew. The sig-validity-interval should be, at least, several multiples of the SOA expire interval to allow for reasonable interaction between the various timer and expiry dates. If your TTL is longer than 7.5 days, bind will NOT resign correctly without this option. greetings, Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
