The DNSSEC chain of trust starts at the root of the DNS with a resolver typically trusting said root by the fact that it’s got the root key (or hash thereof, called a Delegation Signer – DS record) built-in or configured into it. From there, a resolver chases delegation signer records (DS) which indicate to it, that a child zone is signed. We can compare this to how a resolver chases name server (NS) records to find delegations. The hash of a child zone’s DNSKEY is a DS record which is located in it’s parent zone and which has therefore been signed by the parent.
In the case of example.net, we know that net is signed, so the root zone contains a DS record for net. If example.net is signed, its parent zone (net) contains a DS record for example.net, and so forth.
Any child zone which is signed must have a hash of its secure entry point as a DS record in its parent zone.
Uploading DS from a child to a parent zone can be an entertaining proposition. Anything from copy/paste into some (often lousy) Web form to sending an email might be available. Unfortunately there’s no real standard to accomplish this as some parent zones want DS records whereas others insist on DNSKEY records (from which they calculate the DS themselves). Be that as it may, what we typically do is to obtain the DS. For utilities provided by BIND or PowerDNS:
$ dnssec-dsfromkey Kexample.com.+005+08419
example.com. IN DS 8419 5 1 2E4D616E70FED736A08D7854BCDD3D269A604FD3
example.com. IN DS 8419 5 2 6682CC1E528930DB7E097101C838F8D3D0DBB8EC5D1E8B50A5425FE57AB058C6
$ dig sub.example.net DNSKEY | dnssec-dsfromkey -f - sub.example.net
sub.example.net. IN DS 48629 13 1 4E324C9416D0009B4262C39494A1C7989F9C055C
sub.example.net. IN DS 48629 13 2 87081D41BBABA1C25D28F48EDE7718E96EA8387CAE2A286FA5C61E57971B8C66With a bit of zone name mangling and TTL adding we can use pdnsutil with dnssec-dsfromkey, but pdnsutil has its own subcommand as well:
$ pdnsutil export-zone-dnskey sub.example.net 32 |
awk 'NR==1 { sub(" ", ". 60 "); print; }' |
dnssec-dsfromkey -f - -T 120 sub.example.net
sub.example.net. 120 IN DS 48629 13 1 4E324C9416D0009B4262C39494A1C7989F9C055C
sub.example.net. 120 IN DS 48629 13 2 87081D41BBABA1C25D28F48EDE7718E96EA8387CAE2A286FA5C61E57971B8C66
$ pdnsutil export-zone-ds sub.example.net
... (shown below)Generally speaking the story stops here, and I’d leave you in charge of getting that DS-set to your parent zone somehow. Digressing only slightly, OpenDNSSEC has for ages, had a DelegationSignerSubmitCommand program in its configuration which can upload DS/DNSKEY to a parent via a program you create; the script you write and configure gets new keys via stdin and you can then automate submission to a parent zone to your heart’s content.
Can I haz automatik?
What we really want is automatic DS submission such as that the child zone uploads the DS directly to the parent zone where it is then signed. Unless the parent and the child zone are both under my administrative charge, that’s easier said than done: it’s unlikely the parent will allow me to do that.
Enter RFC 7344 which allows me to indicate, in my child’s zone, that I have a new DS record for submission. (This also works for DNSKEY records for those parents which prefer DNSKEY.) The fact that the child zone has a new DS for submission is indicated with a CDS record (child DS) and/or CDNSKEY (child DNSKEY) respectively. What will actually happen is that the parent will “consume” CDS/CDNSKEY records instead of the child “pushing” them somewhere. Hereunder I will be using CDS because they’re shorter, but CDNSKEYs work equally well.
As per section 4 of RFC 7344, if a child publishes either CDS or CDNSKEY it should publish both, unless the child knows the parent will use one of a kind only.
Using PowerDNS, I can configure the Authoritative server to automatically publish CDS and/or CDNSKEY records:
$ pdnsutil set-publish-cds zone
$ pdnsutil set-publish-cdskey zoneThe process for BIND is a bit more involved. What I do here is to set a timing parameter on a key when I create a new key (or just after having created it).
$ dnssec-settime -P sync +1mi Kexample.com.+005+08419.
$ grep Sync Kexample.com.+005+08419.key
; SyncPublish: 20170921094522 (Thu Sep 21 11:45:22 2017)When running as an in-line signer, BIND will publish CDS and CDNSKEY records for the particular key until I use dnssec-settime to have it remove such records from the zone. (Note that BIND as smart signer (dnssec-signzone -S) does not add CDS or CDNSKEY records to the signed zone. Why? Good question; IMO an omission.)
So, ideally, what we then need is a mechanism by which a server checks for CDS/CDNSKEY records in a child zone and then updates the corresponding parent zone.
dnssec-cds
A combination of dig and a new utility will allow me to automate the process.
Tony Finch has written such a beast. It’s called dnssec-cds and it’s currently in a git tree he maintains and has meanwhile been brought into the BIND source tree. What this program does is to change DS records at a delegation point based on CDS or CDNSKEY records published in the child zone. By default CDS records are used if both CDS and CDNSKEY records are present.
What we’ll actually be doing in order to add a new signed child zone is:
- Create and sign the zone.
- Obtain the DS-set, copy that securely to the parent, and sign the result. We do this step once and we do it securely because this is how we affirm trust between parent and child.
- Once in the parent zone, the DS records of the child indicate the child zone’s secure entry point: validation can be chased down into the child zone.
- When the child’s KSK rolls, ensure child zone contains CDS/CDNSKEY records.
- Parent will periodically query for child’s CDS/CDNSKEY records; if there are none, processing stops.
- As soon as CDS/CDNSKEY records are visible in the child, dnssec-cds validates these by affirming, using the original DS-set obtained in 2, that they’re valid and not being replayed.
- A dynamic (or other) update can be triggered on the parent to add the child’s new DS-set.
dnssec-cds protects against replay attacks by requiring that signatures on the child’s CDS are not older than they were on a previous run of the program. (This time is obtained by the modification time of the dsset- file or from the -s option. Note below that I touch the dsset- file to ensure this, just the first time.) Furthermore, dnssec-cds protects against breaking the delegation by ensuring that the DNSKEY RRset can be verified by every key algorithm in the new DS RRset and that the same set of keys is covered by every DS digest type.
dnssec-cds writes replacement DS records (i.e. the new DS-set to standard output or to the input file if -i is specified, and -u prints commands suitable to be read by a dynamic DNS utility such as nsupdate. The replacement DS records will be the same as the existing records when no change is required. The output can be empty if the CDS / CDNSKEY records specify that the child zone wants to go insecure.
The BIND name server in my example hosts the parent zone example.net, and we’ll create a child zone (sub.example.net) on PowerDNS Authoritative (because we can). Which server brand the zone’s hosted on is quite irrelevant other than it must be able to serve CDS/CDNSKEY records in the zone. This is particularly easy to automate with PowerDNS.
First we sign the child zone and export its DS-set:
$ pdnsutil secure-zone sub.example.net
Securing zone with default key size
Adding CSK (257) with algorithm ecdsa256
Zone sub.example.net secured
Adding NSEC ordering information
$ pdnsutil export-zone-ds sub.example.net > dsset-sub.example.net.
$ cat dsset-sub.example.net.
sub.example.net. IN DS 32128 13 1 6823d9bb1b03df714dd0eb163e20b341c96d18c0 ; ( SHA1 digest )
sub.example.net. IN DS 32128 13 2 039b660206db76611305288042ee3fa132f3709e229005baf2b24bcdae7bc513 ; ( SHA256 digest )
sub.example.net. IN DS 32128 13 3 753cf5f1c9a73fdaf3e09454a55916e7381bf24ce3c0e077defe1cfd15b6da5f ; ( GOST R 34.11-94 digest )
sub.example.net. IN DS 32128 13 4 e772f48556bf23effe80946a5306e5d00c6138d321f6d0a66a2673d2b2bee4e3fe13340a7bcf921484081046e92ca983 ; ( SHA-384 digest )Note how the exported dsset- contains one DS for each algorithm supported by my PowerDNS installation. We now copy the dsset- to the parent server, and add its content to the parent zone. The zone is configured with auto-dnssec maintain so BIND will immediately sign anything we add to it.
( echo "ttl 60"
sed -e "s/^/update add /" -e "s/;.*//" dsset-sub.example.net.
echo "send" ) | nsupdate -lIf I now query for the DS records for sub.example.net in the parent zone (recall a DS RRset is in the parent) I obtain an appropriate response:
$ dig +norec @BIND sub.example.net ds
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14192
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
sub.example.net. 60 IN DS 32128 13 1 6823D9BB1B03DF714DD0EB163E20B341C96D18C0
sub.example.net. 60 IN DS 32128 13 2 039B660206DB76611305288042EE3FA132F3709E229005BAF2B24BCD AE7BC513
sub.example.net. 60 IN DS 32128 13 3 753CF5F1C9A73FDAF3E09454A55916E7381BF24CE3C0E077DEFE1CFD 15B6DA5F
sub.example.net. 60 IN DS 32128 13 4 E772F48556BF23EFFE80946A5306E5D00C6138D321F6D0A66A2673D2 B2BEE4E3FE13340A7BCF921484081046E92CA983Our parent zone is signed, our child zone is signed, our parent has a signed DS record (more than one actually, but that’s fine) for our child zone: the chain of trust is in place. (Note the key tag on the DS: 32128.)
Let it roll!
At some point in time we want to roll the child’s KSK, and I am not going to address timing issues of the roll proper; I’m discussing CDS only.
In order to roll a key, we create a new key in the child zone. Simultaneously we request PowerDNS publish CDS records in the zone for all keys:
$ pdnsutil add-zone-key sub.example.net ksk 256 active ecdsa256
Added a KSK with algorithm = 13, active=1
Requested specific key size of 256 bits
$ pdnsutil set-publish-cds sub.example.net
$ pdnsutil show-zone sub.example.net
This is a Master zone
Last SOA serial number we notified: 0 != 3 (serial in the database)
Metadata items:
PUBLISH-CDS 1,2
Zone has NSEC semantics
keys:
ID = 31 (CSK), flags = 257, tag = 32128, algo = 13, bits = 256 Active ( ECDSAP256SHA256 )
CSK DNSKEY = sub.example.net. IN DNSKEY 257 3 13 12lrJwo8w/PbnD8JssSlmuN7adbidwCsCaFn2yiXctj2k9g9dlGw+KTDqRsanj4InPgGcQwllBRGSojfwZVHRQ== ; ( ECDSAP256SHA256 )
DS = sub.example.net. IN DS 32128 13 1 6823d9bb1b03df714dd0eb163e20b341c96d18c0 ; ( SHA1 digest )
DS = sub.example.net. IN DS 32128 13 2 039b660206db76611305288042ee3fa132f3709e229005baf2b24bcdae7bc513 ; ( SHA256 digest )
DS = sub.example.net. IN DS 32128 13 3 753cf5f1c9a73fdaf3e09454a55916e7381bf24ce3c0e077defe1cfd15b6da5f ; ( GOST R 34.11-94 digest )
DS = sub.example.net. IN DS 32128 13 4 e772f48556bf23effe80946a5306e5d00c6138d321f6d0a66a2673d2b2bee4e3fe13340a7bcf921484081046e92ca983 ; ( SHA-384 digest )
ID = 32 (CSK), flags = 257, tag = 48629, algo = 13, bits = 256 Active ( ECDSAP256SHA256 )
CSK DNSKEY = sub.example.net. IN DNSKEY 257 3 13 EY2fpwiU3dcg22g83gC+9oQ65vJHPELR6sU1MLB8r8F+6egarSIDzjyM5AY2RlbFGgOkjpPMaUonCONPalOQ4A== ; ( ECDSAP256SHA256 )
DS = sub.example.net. IN DS 48629 13 1 4e324c9416d0009b4262c39494a1c7989f9c055c ; ( SHA1 digest )
DS = sub.example.net. IN DS 48629 13 2 87081d41bbaba1c25d28f48ede7718e96ea8387cae2a286fa5c61e57971b8c66 ; ( SHA256 digest )
DS = sub.example.net. IN DS 48629 13 3 99eadcdc47adfe2f68df3e1a4aa775fa409bafbd7815ca1c2643cdf49a0996bf ; ( GOST R 34.11-94 digest )
DS = sub.example.net. IN DS 48629 13 4 f961984bc561906cde1987bf89f90654865d4b9500ee7eed8bf4a0245244ac492eeb66776475e7448826f74638ad9e9e ; ( SHA-384 digest )This output is easy to follow once we notice that the top part has some metadata and then come the keys. Note that pdnsutil is printing a DS record for each of the algorithms PowerDNS supports, hence the verbosity. Let’s pay attention to the key tags: in above list we see our original 32128 tag and the new tag 48629.
The child zone is still signed; there are two keys in the zone, and we’ve requested CDS records be published. Does that work?
$ dig @POWERDNS sub.example.com cds
;; ANSWER SECTION:
sub.example.net. 3600 IN CDS 32128 13 1 6823D9BB1B03DF714DD0EB163E20B341C96D18C0
sub.example.net. 3600 IN CDS 48629 13 1 4E324C9416D0009B4262C39494A1C7989F9C055C
sub.example.net. 3600 IN CDS 32128 13 2 039B660206DB76611305288042EE3FA132F3709E229005BAF2B24BCD AE7BC513
sub.example.net. 3600 IN CDS 48629 13 2 87081D41BBABA1C25D28F48EDE7718E96EA8387CAE2A286FA5C61E57 971B8C66The CDS records are available with the digest algorithms currently implemented for DS, namely 1 (SHA1) and 2 (SHA256).
.. to the parent
Back on the parent, we prepare to use dnssec-cds for the magic. We already have the dsset- file, and as discussed above I touch its timestamp (or use -s switch):
$ touch -t 201709140000 dsset-sub.example.net.
$ cat run-cds.sh
z=sub.example.net
dig @POWERDNS +dnssec +noall +answer $z DNSKEY $z CDNSKEY $z CDS |
dnssec-cds -u -i -f /dev/stdin -T 42 -d . -i.orig $z |
tee /tmp/nsup |
nsupdate -l
$ ./run-cds.shdnssec_cds with the -u option creates a script suitable for feeding into nsupdate; for debugging purposes, I tee it into a file to show you here:
$ cat /tmp/nsup
update add sub.example.net. 42 IN DS 48629 13 1 4E324C9416D0009B4262C39494A1C7989F9C055C
update add sub.example.net. 42 IN DS 48629 13 2 87081D41BBABA1C25D28F48EDE7718E96EA8387CAE2A286FA5C61E57971B8C66
update del sub.example.net. IN DS 32128 13 3 753CF5F1C9A73FDAF3E09454A55916E7381BF24CE3C0E077DEFE1CFD15B6DA5F
update del sub.example.net. IN DS 32128 13 4 E772F48556BF23EFFE80946A5306E5D00C6138D321F6D0A66A2673D2B2BEE4E3FE13340A7BCF921484081046E92CA983
sendquerying the parent we see the DS records with the superflous algorithms have been deleted and the DS records for the new key have been added. We also see our dsset- file has been updated accordingly (and I pay attention to the file’s modification time which has been set to the inception time of the DNSKEY RRSIG of the child zone):
$ dig +norec @BIND sub.example.net ds
;; ANSWER SECTION:
sub.example.net. 42 IN DS 32128 13 1 6823D9BB1B03DF714DD0EB163E20B341C96D18C0
sub.example.net. 42 IN DS 32128 13 2 039B660206DB76611305288042EE3FA132F3709E229005BAF2B24BCD AE7BC513
sub.example.net. 42 IN DS 48629 13 1 4E324C9416D0009B4262C39494A1C7989F9C055C
sub.example.net. 42 IN DS 48629 13 2 87081D41BBABA1C25D28F48EDE7718E96EA8387CAE2A286FA5C61E57 971B8C66
$ cat dsset-sub.example.net.
sub.example.net. 42 IN DS 32128 13 1 6823D9BB1B03DF714DD0EB163E20B341C96D18C0
sub.example.net. 42 IN DS 32128 13 2 039B660206DB76611305288042EE3FA132F3709E229005BAF2B24BCDAE7BC513
sub.example.net. 42 IN DS 48629 13 1 4E324C9416D0009B4262C39494A1C7989F9C055C
sub.example.net. 42 IN DS 48629 13 2 87081D41BBABA1C25D28F48EDE7718E96EA8387CAE2A286FA5C61E57971B8C66Now I delete the “old” key from the child zone using its (in my opinion slightly confusing) ID which is 31 – compare with the output of pdnsutil show zone above. (I would have preferred pdnsutil utilize key tags to refer to keys for a zone):
$ pdnsutil remove-zone-key sub.example.net 31Now comes the drum-roll moment: if we re-run our dnssec-cds script what will it do?
$ ./run-cds.sh
$ cat /tmp/nsup
update del sub.example.net. IN DS 32128 13 1 6823D9BB1B03DF714DD0EB163E20B341C96D18C0
update del sub.example.net. IN DS 32128 13 2 039B660206DB76611305288042EE3FA132F3709E229005BAF2B24BCDAE7BC513
send$ dig +norec @BIND sub.example.net ds
;; ANSWER SECTION:
sub.example.net. 42 IN DS 48629 13 1 4E324C9416D0009B4262C39494A1C7989F9C055C
sub.example.net. 42 IN DS 48629 13 2 87081D41BBABA1C25D28F48EDE7718E96EA8387CAE2A286FA5C61E57 971B8C66A few points to note:
- when lookup at the nsupdate script produced by dnssec-cds pay attention to
addvs.delon theupdatestatements. - it’s not necessary to have dnssec-cds maintain the
dsset-file on the file system, but it gives me a warm and fuzzy feeling so I think I’d always do that - I should also mention that the dnssec-dsfromkey utility is quite versatile; we saw it above, and it’s good to know that the
-Coption creates CDS records au lieu de DS records.
Tony’s dnssec-cds together with a wee bit of scripting will basically allow us to add new DS for zones to their parent zones. In the examples above I’ve used nsupdate, but this could equally well be accomplished by other means.
Further reading
- Automated DNSSEC Provisioning: Guidelines for CDS processing at SWITCH.