bind at raf.org
Mon Aug 9 09:45:15 UTC 2021
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.
> > 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,
More information about the bind-users