--- Begin Message ---
OK fair point, will get with the team and we’ll figure out what skew we’re
factoring in. Thanks for that.
Alec
> On Feb 9, 2021, at 7:57 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 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
--- End Message ---
_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
