AW: Deprecating auto-dnssec and inline-signing in 9.18+

[raf]

On Tue, Aug 10, 2021 at 11:24:31AM -0500, Tim Daneliuk via bind-users <bind-users at lists.isc.org> wrote:

> On 8/10/21 10:07 AM, Matthijs Mekking wrote:
> >> So just to be sure I'm doing the right thing, I've added this to my
> >> options stanza:
> >>
> >>      dnssec-policy "default";
> >>
> >> Then restarted named and now all the signing magic is taken care of for
> >> me for all zones?  (I was not previously using signing.)
> > 
> > Correct.
> > 
> > But you still need to manually submit the DS record to your
> > registrar/parent and if you see the DS published run:
> > 
> > rndc dnssec -checkds published <zone>.
> 
> I've never done any of the signing work before (other than for  master/slave).
> Could you kindly point me to something like
> 
>       "DS Record Creation And Implementation For Dummies"?
> 
> Thanks,
> 
> ----------------------------------------------------------------------------
> Tim Daneliuk     tundra at tundraware.com
> PGP Key:         http://www.tundraware.com/PGP/
> _______________________________________________

Hi Tim,

Here goes!

My NOVICE understanding is that bind will create
CDS (and CDNSKEY) records automatically to match the
(KSK or CSK) DNSKEY records that it also creates
automatically. Use dig cds ZONE to see them.

The CDS record is the child version of the DS record
and it contains same information. The CDS/CDNSKEY
records reside in your zones, and they exist to
facilitate the automatic uploading of DS records to
parent zones, but registrars (or TLDs?) haven't
implemented this yet. Even when they do, the first time
will be manual. Until they do, it's always manual
(if you do key rollovers - but that's not the default).

So, that DS information MUST be manually conveyed to
the registrar so that they can get it published and
signed in the parent/TLD zone. How you do this is
determined by each registrar.

Hopefully, they will have a web interface for
adding/removing DS records. Or it might be via email.
If your registrar can't accept DS records, consider
transferring to a registrar that does (and maybe let
them know why you are leaving).

Once you can see that the DS record has been published
in the DNS (dig ds ZONE), you then tell bind that this
has happened by running:

  rndc dnssec -checkds -key ID published ZONE

The ID is the first number in the DS record (e.g. 12345).

If using dnssec-policy default, that's it, because the
key lasts forever.

But if you have your own policy that involves key
rollover, you will need to monitor for the future
appearance of new KSK DNSKEY/CDS/CDNSKEY records as
they get created by bind in the lead up to a rollover
(dig cds ZONE).

When they appear, you repeat the above process to
convey the new DS information to the registrar,
and you also manually delete the old DS record via the
registrar (at the same time is OK, or afterwards, but
NOT before), and when you see that the old DS has been
removed from the DNS, you then tell bind that this has
happened by running:

  rndc dnssec -checkds -key ID withdrawn ZONE

I think that causes bind to delete the records related
to the old KSK (i.e. DNSKEY/CDS/CDNSKEY), and to
eventually delete the keys from disk.

At least, that's what I'm planning to do. :-)

And I'm setting up a cronjob to monitor for changes
in DNSKEY/CDS records and email me when it happens.
But that's not needed with the default policy.

Here's Matthijs's short version:

  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.

cheers,
raf