On Wed, Feb 10, 2021 at 3:47 AM Peterson (AWS), Alec <alecp...@amazon.com> wrote: > Hey Matt, sorry we missed your forum post, we do need to stay on top of those. > > There are actually 2 hours of overlap, not 1. For the zone I just provided, > here is the previous and current RRSIG: > > DNSKEY 13 2 3600 20210209010000 20210208150000 38680 hilander.com. > J5WR2nU1Gl3xI5ehHBsnI7OXiThuYZKc1XpV6brYf85BgurOcZkb5+6eLbsvV+ykODaPrEnEIDu/HRYcaIRrNg== > DNSKEY 13 2 3600 20210209090000 20210208230000 38680 hilander.com. > 735uL43A++phhPv/edwq02zANvAfEsas1j9HM+ghe+t7b6FLCAF6RZfXA9L+TBukYmhIkPiF87GbHDWXmETBNQ== > > So when we roll the signature over, the one that we were previously using > still has 2 hours of validity, not 1 hour. So using your example, we would > roll it over at 2300, not 0000, giving us room for 1 hour of clock skew. > Think that’s reasonable. > > Alec
I haven't looked recently, but when I checked some poor customer's domain at 2020-12-31 23:59:59, that wasn't the case. It returned the 2020-12-31 15:00:00 - 2021-01-01 01:00:00 records: <https://gist.github.com/mnordhoff/02e173d419387c3098cd0f90c7b75f34> If the record rollover has been moved back one hour, the inception should correspondingly be moved back to 06:00:00 / 14:00:00 / 22:00:00, though. :-D > On Feb 9, 2021, at 7:37 PM, Matt Nordhoff <mnordh...@gmail.com> wrote: > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you can confirm the sender and know the > content is safe. > > > > On Wed, Feb 10, 2021 at 1:44 AM Peterson (AWS), Alec via > dns-operations <dns-operati...@dns-oarc.net> wrote: > > +1 for short RRSIG times and the discipline it enforces. We went down this > path when building DNSSEC for Route 53, ZSK signatures are on the order of 10 > hours: > > hilander.com. 3599 IN RRSIG DNSKEY 13 2 3600 20210210090000 ( > 20210209230000 38680 hilander.com. > 3H3QZt3qC2XbqkbumqsvRVeVrtgJVVRVGC/TZkc7vMuN > IdlL/wZrw+qBfYaSOex7dOp2PUP7pwW+NUgCXc2F7Q== ) > > A bunch of risks with this approach that needs to be mitigated, especially > around static stability in the face of an issue with the ZSK signing process. > But all solvable. As part of this we also automated ZSK rotation (which > happens less often, but still on the order of once a week). > > > Speaking of which, the DNSKEY RRSIG lifetime should be 11 hours, not > 10 hours. The current expiration doesn't allow for client caching plus > clock skew. E.g.: > > 23:59:59: Recursive resolver queries authoritative servers for > hilander.com DNSKEY, gets back record set with TTL 3600, RRSIG > inception 15:00:00, expiration 01:00:00. > (00:00:00: Authoritative servers switch to new DNSKEY record set, TTL > 3600, inception 23:00:00, expiration 09:00:00.) > 00:59:58: Validating stub resolver queries recursive resolver for > hilander.com DNSKEY. gets back cached record set with TTL 1, RRSIG > inception 15:00:00, RRSIG expiration 01:00:00. > > If the stub resolver's clock is 3 seconds fast -- 01:00:01 -- and it > doesn't make an extra allowance for expired records or clock skew, it > will treat the record set as bogus. > > (All other records except for DNSKEY are live signed, with the RRSIG > expiration set 1 hour after the TTL.) > > <https://forums.aws.amazon.com/thread.jspa?threadID=333305&tstart=0> > > On Feb 8, 2021, at 9:27 PM, Paul Vixie <p...@redbarn.org> wrote: > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you can confirm the sender and know the > content is safe. > > > > On Mon, Feb 08, 2021 at 01:45:06AM -0500, Viktor Dukhovni wrote: > > ... > I do not recommend either X.509 certificate or RRSIG lifetimes quite > this long. Shorter lifetimes IMHO promote better discipline. > > > for my own zones i think i'm using one year signatures and regenerating them > from "cron" once per week -- just to be safe. so, not better discipline unless > you deliberately _live_ on the edge, which i think is an unwise practice. > > i expect i'll crib together some bourne shellack to check my whole signature > chains and warn me when there's less than 72 hours remaining in any validity > period. going into SERVFAIL like this is an operational risk i shouldn't take. -- Matt Nordhoff _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
