DNSSEC questions

[raf]

Hi Matthijs,

On Mon, Aug 09, 2021 at 11:11:48AM +0200, Matthijs Mekking <matthijs at isc.org> wrote:

> 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.

I won't be able to use parental-agents yet. Debian-11 only
has bind-9.16.15 (to start with), and parental-agents was
added in 9.16.19.

Also, my new registrar doesn't implement RFC 7344 yet,
but I suggested it, and they're considering it.

In the meantime, I'll just use rndc.

> > 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.

That makes sense.

> > 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.

It's not important. I'm sure they have their reasons.

> > 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.

I'll use an absolute path, just to be on the safe side.

> > 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".

Ah, the documentation only mentions dynamic DNS in relation to that setting.
Perhaps a statement that it applies when zones are automatically signed as well
should also appear there.

It sounds like the default "increment" (or "date") would suit my use of serials,
whether I increment the serial in my zone files by 1 or 2.

> > 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.

That looks much neater. I was assuming that you'd need
to make absolutely sure that the old DS didn't
disappear until after the new DS was in place.

> Hope this helps.

It does. Many thanks.

> Best regards,
> 
> Matthijs

cheers,
raf