Hi Matthijs, On Mon, Aug 09, 2021 at 11:11:48AM +0200, Matthijs Mekking <matth...@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 _______________________________________________ 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
