[dns-operations] Pre-publishing KSKs and ZSKs

[Matthijs Mekking]

Anand,

On 11/24/2015 10:22 AM, Anand Buddhdev wrote:
> Dear DNS folk,
> 
> I'm asking for opinions about pre-publishing KSKs and ZSKs. Our signer
> software pre-publishes both by default, but provides an option not to.
> 
> Pre-publishing has the feature that in the event of an emergency
> roll-over, they keys should already be cached. However, this appears
> to be the only advantage. Otherwise, the standby keys make the DNSKEY
> response bigger.
> 
> We publish our keys with a TTL of 1 hour, which is rather short. My
> thinking is that with such a short TTL, we shouldn't need to
> pre-publish standby keys, because we can introduce new keys quickly.
> Would you all agree with my assessment? Have I missed any other
> obvious reason for pre-publishing keys?

This is obviously a trade off between response size and the duration to
recover from an emergency. I am no good in policy so I leave the
assessment judging to somebody else :)

>From a technical point of view:

Without a standby key, you are recovering from an emergency
approximately one TTL (1 hour) than with a standby key. To be precise:
Ipub = Dprp + TTLkey. The publication interval is the TTL of the DNSKEY
RRset plus the propagation delay to the secondary servers.

So perhaps it is good to take a closer look at the propagation delay.
Some signers will have for example safety intervals which would increase
the overall publication interval/Ipub.

If the publication interval is still short, in other words the
propagation delay and other safety intervals don't add too much to the
interval, your arguments are still valid.

For the KSK: Are you performing KSK rollovers with a Double-KSK or
Double-DS style? For Double-KSK the same argument holds as for ZSK: With
a small Ipub it seems like a fair trade off.

A standby KSK with Double-DS is actually a pre-published DS record in
the parent zone. When disabling standby KSK in this scenario you should
actually take into account the registration delay of submitting the DS
and the TTL of the DS RRset at the parent.

Best regards,
  Matthijs



> 
> Regards,
> 
> Anand Buddhdev
> RIPE NCC
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>