[dns-operations] anybody awake over at comcast.net?

[Peterson (AWS), Alec]

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 <mnordhoff at 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
> <alecpete at 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 <mnordhoff at 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-operations at 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 <paul at 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