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

Wed Aug 11 04:27:16 UTC 2021

On Tue, Aug 10, 2021 at 09:19:33PM -0500, Tim Daneliuk via bind-users <bind-users at lists.isc.org> wrote:

> On 8/10/21 7:32 PM, raf via bind-users wrote:
> > To get the DS record information to convey to the
> > registrar, after starting to use the default policy.
> > look for the CDS record (the child version of the DS
> > record) with dig:
> > 
> >   dig CDS EXAMPLE.ORG
> > 
> > For the default policy, you'll only have to do this
> > once (or until your server gets compromised and you
> > start again). But until you've done this, it's not
> > done. The trust chain has to go all the way to the
> > root, so you need the involvement of your registrar
> > (to get your DS published and signed).
> 
> That's quite helpful, thanks, but still unclear about one
> thing.  When I run the dig command above I do get a result
> back with a "COOKIE" value in the response.  This value
> changes each time I run the dig.   Is any one of these the
> "DS record" I want to convey to my registrar?
> 
> Other than this I see nothing that resembles  a relevant response AND
> the COOKIE field does not show up if I do the dig from outside the zone.

I don't know what the cookie is for (Sorry).
And I haven't signed my zones yet (I'm waiting
for debian-11 to come out in a few days), so
I can't show you anything definite. But this is
what I'd expect to see. I'll use the real
example.org as an example, and use host, rather
than dig, for compact output.

They have DNSKEY and DS records (too many of both for some reason):

  > host -t dnskey example.org
  example.org has DNSKEY record 257 3 8 AwEAAayIYwp6ixWfhYM4THrWtVOVLbtJLekeXoNANfroGA/9R5ynPhmR V5MufCgluPCXs0xcWKMxunggLfQm87L/KkL+9W6Ux5aCWIAlVIbD+Vio VXuHbmaW0SUXApi1wIaq9yP9P0oVfbKSqlQLQPbvrOTGXAeR+XAARkgr PJQadTDw3zA7YugzoH/jJEmjK3AGVRUb13ZByUsf+aAnVJmAtBdl3772 mN2rLoaCCa6wyCrT0YZcHrxiMGo8J/KjU/1IidfufsOHH1iQ3CLoV0Kf hQDBb33S8TH30cu8WCPmKhJNWjbhLaTKTDV0GKl/GIYX3IKcNLY9TZjk wUnOcEc1MxE=
  example.org has DNSKEY record 256 3 8 AwEAAcRJYEt01+ODGJx7oc/1gW8ABY3AwY5QO+b0wp+HcZFq/OK2ZZ57 RBx/nIeP+lWnQGGgKFjeJm04OpY9DKXG2i9Wg2bBxm6lA/Wsa5/flCEK bM3RqTuNzcnxcYEBgqbdmDlgqsK066nbl54DiPEQrEW8ZtroUmuEkrQB WM4xe+Uz
  example.org has DNSKEY record 257 3 8 AwEAAZtWmbB2NyRD8oX7JeNUfmJB928LBER6l44TokqhZDOL2g6IyxLv 9Ku02X/C50iyUeK1r4lr9s9WdSSAH+Qi3ozeXvhZvzAcgQzNJ1jUj4TX ufXkml4QIy9kwL18N3jRizs+Sj8gz56UQwPL1J3M3rhYvSrF0a2zQYt8 Vt0+HGUNJnaJ7dTBbfALiUJc0ATuHKOU1Le+Pb0b/3Q6b4AG3ZNKciwy 8Hb9wroeAwv5//tffTgTQy4D4544HZCUkRW8b/+jNCpzdw6x7g4edA93 8y+f4YnOn+0bI5pSpB4IDG+GKgrFO2gAEdttujylxJxsm+slx0Qn8Wrv R/ZZvcYnXvs=

Only the last DNSKEY above has corresponding DS records
below. The 257 means it's a KSK and so it needs a
corresponding DS for it to be trusted.

  > host -t ds example.org
  example.org has DS record 31589 8 2 3FDC4C11FA3AD3535EA8C1CE3EAF7BFA5CA9AE8A834D98FEE10085CF AEB625AA
  example.org has DS record 31589 8 1 7B8370002875DDA781390A8E586C31493847D9BC
  example.org has DS record 37780 8 2 D96AFA9022000D368B5F497877DF289A1E9A13A1AB1F97BC1BF4D5DE 16879134
  example.org has DS record 37780 8 1 B4A5CCE8D82DC585E327E5896EAE82E0B9A76DC6
  example.org has DS record 3397 8 2 ED1168604BC6A14068B9905401E62698BB3663B6EC2073EBD3599B88 2A785BF6
  example.org has DS record 3397 8 1 DEE10345942C98711EB058B25A749EE342FCE1DC

The last two DS records above correspond to the last
DNSKEY further up. I think the other four are just old
ones that haven't been deleted yet. They don't
correspond to any other DNSKEY records further up.

You can tell which DNSKEY that a DS corresponds to by
looking at the first number in the DS record (e.g.
3397), and using dig to extract the key id from the
DNSKEY record:

  > dig dnskey example.org +multi
  [...]
  example.org. 2552 IN DNSKEY 257 3 8 (
       AwEAAZtWmbB2NyRD8oX7JeNUfmJB928LBER6l44Tokqh
       ZDOL2g6IyxLv9Ku02X/C50iyUeK1r4lr9s9WdSSAH+Qi
       3ozeXvhZvzAcgQzNJ1jUj4TXufXkml4QIy9kwL18N3jR
       izs+Sj8gz56UQwPL1J3M3rhYvSrF0a2zQYt8Vt0+HGUN
       JnaJ7dTBbfALiUJc0ATuHKOU1Le+Pb0b/3Q6b4AG3ZNK
       ciwy8Hb9wroeAwv5//tffTgTQy4D4544HZCUkRW8b/+j
       NCpzdw6x7g4edA938y+f4YnOn+0bI5pSpB4IDG+GKgrF
       O2gAEdttujylxJxsm+slx0Qn8WrvR/ZZvcYnXvs=
       ) ; KSK; alg = RSASHA256 ; key id = 3397
  [...]

They don't have CDS or CDNSKEY records:

  > host -t cds example.org
  example.org has no CDS record
  > host -t cdnskey example.org
  example.org has no CDNSKEY record

But they would if they were using a recent version of
bind. In general, in the lead up to a key rollover, you
can tell which CDS is new by the fact that it will have
a new key id that you didn't see before.

The CDNSKEY records should look like the DNSKEY records
(and be a hypothetical signal to the parent zone that
they could use the CDNSKEY to derive a DS record that
they could then publish and sign at the parent zone
level).

Similarly, the CDS records (which are derived locally
from the CDNSKEY record) should look like a new DS
record (and be a hypothetical signal to the parent zone
that they could publish and sign the CDS record data as
a DS record, if the CDS record is validly signed).

At least, that's my understanding based on reading the
DNSSEC Guide and asking on this mailing list. I'll
probably have a better idea in a few weeks when I
can see for myself what it looks like.

I don't know if there's any time delay between DNSKEY
creation and CDS/CDNSKEY creation. Maybe there is.

Does that help at all?

cheers,
raf