DNSSEC questions

Mon Aug 9 09:11:48 UTC 2021

Hi raf,

On 09-08-2021 10:08, raf via bind-users wrote:
> Hi,
> 
> I've got a bunch of DNSSEC questions.
> Any advice would be appreciated.
> 
> The context is a little VM with six little zones,
> soon to be upgraded to debian-11 and bind-9.16.15.
> I haven't signed my zones before but now is the time.
> I'm going to rotate KSKs annually because it's
> finally so easy to on debian stable. Thanks for that.
> I know it won't be totally automatic, and that's OK,
> but I'd like to check that I have the right idea of
> what to monitor for and what to do each time.
> 
> Q: Is it OK to use exact multiples for ksk/zsk lifetimes (e.g. 366d/61d)? >     I assume it's OK if there aren't too many keys to generate at once.

Yes.

> Q: Regarding "parent-propagation-delay" and CDS/CDNSKEY RRs:
>     Assuming the registrar doesn't process them, does this equate to
>     how long it takes me to notice there's a new DS to upload,
>     plus how long it takes me to upload it via the registrar's website,
>     plus how long it takes the registrar to publish the uploaded DS?
>     Or is it, having instructed the registrar to add/remove a DS,
>     how long after I've seen it published/withdrawn in the DNS and have
>     run "rndc dnssec -checkds -key ID published/withdrawn ZONE" that
>     the parent can be expected to propagate the DS addition/removal
>     to all their servers? Or does "rndc dnssec -checkds" make
>     "parent-propagation-delay" irrelevant except when the parent
>     processes CDS/CDNSKEY RRs? I assume the last.

No, with the latest version of BIND 9.16 you will have either tell named 
that the DS is published with the "rndc dnssec -checkds published" 
command, or you will have to configure parental-agents:

     parental-agents lists allow for a common set of parental agents to
     be easily used by multiple primary and secondary zones in their
     parental-agents lists. A parental agent is the entity that the zone
     has a relationship with to change its delegation information
     (defined in RFC 7344).

     BIND will query the parental agents to see if the new DS is actually
     published before withdrawing the old DNSSEC key.

> Q: Are CDS/CDNSKEY RRs always in the zone, or just temporarily
>     there for a short time before and after KSK rollovers?
>     I don't see them in the wild, so I assume the latter.
>     I ask for monitoring purposes. What to monitor for withdrawal?
>     I'm thinking I might want to monitor for DNSKEY additions and
>     removals instead. More on that below.

While not necessary, CDS and CDNSKEY RRs are always in the zone as long 
as the corresponding DS record is expected to be published.

> Q: When would you want a DS RR for a ZSK (i.e. dnssec-dsfromkey -A)?

Never, DS is meant to refer to the key that signs the DNSKEY RRset, thus 
only applicable for KSK.

> Q: Any idea why example.com has two KSK DNSKEY RRs?
>     Might they be mid-rollover at the moment? There's only a DS for one of them.
>     Perhaps it's just an example.

Most likely a mid-rollover, I will need more details on example.com to 
know for sure.

> Q: What software could a registrar use to process CDS/CDNSKEY automatically?
>     Just curious.

...

> Q: Do any/many registrars support CDS/CDNSKEY/RFC7344 yet? It seems not.

No, but I have heard about some registrars looking into it.

> Q: Is a "key-directory" option value that doesn't start with "/" relative
>     to the "directory" option (i.e. a subdirectory)? I assume it is.

The "key-directory" is an optional option that signals that the 
configured "key-directory" should be used. Currently it is the only key 
storage supported, but in the future it may be possible to have per-key 
storage.

> Q: Does the signed zone always have a serial that is the serial in the
>     unsigned zone file plus one? If so, can I continue to use the following
>     scheme for serials: a 10-digit number consisting of the date followed
>     by a 2-digit sequence number, where I increment the serial in the zone
>     file by one whenever I change the zone multiple times on the same day?
>     e.g.
>     serial in 1st zone file = 2021091000 signed and published as 202109101
>     serial in 2nd zone file = 2021091001 signed and published as 202109102
>     i.e. Is it OK that the never-published serial in a new unsigned zone
>     file is the same as the previously/currently published serial in the
>     signed zone? Or is it better to increment the serial in the file by 2
>     instead of 1?

The serial used depends on the setting of "serial-update-method".

> Q: Does the following sound right as a process for managing KSK rollovers?
> 
>     - Monitor for the appearance of new KSK DNSKEY RRs that bind creates
>       (or monitor for the appearance of new CDS RRs)
>     - Manually upload the DS RRs for the new KSKs via the registrar's website
>     - Wait for the new DS RRs to appear in the DNS
>     - Run "rndc dnssec -checkds -key ID published ZONE" to inform bind
>     - Wait for bind to sign the ZSKs with the new KSKs
>     - Wait a few TTLs
>     - Manually delete the DS RRs for the old KSKs via the registrar's website
>     - Wait for the old DS RRs to disappear from the DNS
>     - Run "rndc dnssec -checkds -key ID withdrawn ZONE" to inform bind

The DS can be swapped, so I would suggest:

1. Monitor, look for new KSKs
2. Upload the DS once the CDS/CDNSKEY for the KSK is published.
3. Request the old DS to be removed.
3. Wait for the new DS to appear (the old DS should be replaced).
4. Run "rndc dnssec -checkds -key ID published ZONE"
5. Run "rndc dnssec -checkds -key ID withdrawn ZONE"
6. Done.

Hope this helps.

Best regards,

Matthijs

> 
> cheers,
> raf
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 