[dns-operations] Minimum clock skew tolerance?

[Viktor Dukhovni]

> On May 25, 2017, at 12:06 PM, Olafur Gudmundsson <ogud at ogud.com> wrote:
> 
>> Named’s signers set the inception date to (now - 1 hour), by default, to allow
>> for clock skew.  I’ve been tempted to make that (now - 1 day).  Resigning should
>> be done days before the signatures expire.  They should be valid for at least
>> the SOA’s expire interval to handle replication issues. Validators really shouldn’t
>> have to add allowances for clock skew.
>> 
> 
> Cloudflare online generated signatures are valid for -25 H .. +25H
> to avoid any problems with wrong time and day 

And yet it seems that unbound needed work-arounds:

       val-sig-skew-min: <seconds>

              Minimum number of seconds of clock skew to  apply  to  validated
              signatures.   A  value of 10% of the signature lifetime (expira-
              tion - inception) is used, capped by this setting.   Default  is
              3600  (1  hour)  which  allows for daylight savings differences.
              Lower this value for more strict checking of short lived  signa-
              tures.

       val-sig-skew-max: <seconds>

              Maximum  number  of  seconds of clock skew to apply to validated
              signatures.  A value of 10% of the signature  lifetime  (expira-
              tion  -  inception) is used, capped by this setting.  Default is
              86400 (24 hours) which allows for timezone setting  problems  in
              stable  domains.  Setting both min and max very low disables the
              clock skew allowances.  Setting both min and max very high makes
              the validator check the signature timestamps less strictly.

I ran into the ".mg" anomaly after lowering these to 20 minutes, to see what
the impact would be.

>> None of this is documented in any RFC.
> 
> DNSSEC best practices ?

Yes, I have another issue up my sleeve that will require attention to signer
practices.

-- 
	Viktor.