On 2/12/19 10:55 PM, Alice Wonder wrote:> DNSSEC keys do not expire. Signatures do expire. How long a signature > is good for depends upon the software generating the signature, some > lets you specify. ldns I believe defaults to 60 days but I am not sure. > > The keys are in DNSSKEY records that are signed by your Key Signing > Key and must be resigning before the signature expires or they will no > longer validate. > > Likewise, the other records in the zone must be resigned by your Zone > Signing Key before their signatures expire. > <snip> > It's not the keys that are the issue, but the RRSIG record that > contains a start and expiration time for the records. > > If you upload signed zone files to godaddy, make sure to resign once a > week or so so that the RRSIG gets updated. > > man ldns-signzoneOkay so I misunderstood the message I was getting when I checked my DNSSEC setup via http://dnsviz.net/. What you are telling me is that all I had to do was re-sign the zone files but that it was not necessary to generate new keys. This point is definitely one that I missed. I too run my own authoritative nameservers. I was following the Digital Ocean procedure to setup DNSSEC: https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2 That site suggested the use of dnssec-signzone after key creation ala a command like (the stuff that follows has been sanitized): > dnssec-signzone -3 `head -c 1000 /dev/random | sha1sum | cut -b 1-16` -N INCREMENT -o domain.tld -t domain.tld.zone After resigning with that command a file named dsset-domain.tld. is created which contains 2 digests. > cat dsset-domain.tld. domain.tld. IN DS 20716 7 1 04E3E6C87CD4190F74DD0371A14AD5CC42B71521 domain.tld. IN DS 20716 7 2 FA6D0EF0100855E5C85C6CD5A33590681DD9D7D9F6C773785C53E865 E02FF572 It is the keytag (20716) and the digests (hex fields) that are supposed to be uploaded to the registrar according to the section entitled "Configure DS records with the registrar" in the Digital Ocean reference I previously mentioned. In my original message it was the uploading of these keytags and digests to Godaddy that I was referring in my point 1 and which seems to be accomplished only manually via the Godaddy web interface. So doesn't ldns-signzone create the same kind of digest that requires it be uploaded to the registrar? Isn't that essential information in order to tell the .tld that the domain.tld DNSSEC is valid and to maintain the DNSSEC authentication chain trust up to the root servers? You can go to the http://dnsviz.net/ site and can use nurdog.com as an example of what i mean. If I do not have to generate the keys every time the RRSIGs expire then the scripting or re-signing the zones is really trivial as I am in full control of my own DNS servers. It is even easier now if I don't have to generate new keys although that really isn't a difficult step. So maybe I asked the wrong question. Is there a way to re-sign the zone files without having to recreate the information found in that dsset-domain.tld. file and uploading it to the registrar? I suspect there is no way around that as I believe it is essential to maintaining the chain of trust. But if I can keep everything on my own nameservers that would be a big help ... maybe ldns-signzone is the answer? -- Paul (ganci at nurdog.com) Cell: (303)257-5208
On 2/12/19 11:49 PM, Paul R. Ganci wrote:> > On 2/12/19 10:55 PM, Alice Wonder wrote: >> DNSSEC keys do not expire. Signatures do expire. How long a signature >> is good for depends upon the software generating the signature, some >> lets you specify. ldns I believe defaults to 60 days but I am not sure. >> >> The keys are in DNSSKEY records that are signed by your Key Signing >> Key and must be resigning before the signature expires or they will no >> longer validate. >> >> Likewise, the other records in the zone must be resigned by your Zone >> Signing Key before their signatures expire. >> <snip> >> It's not the keys that are the issue, but the RRSIG record that >> contains a start and expiration time for the records. >> >> If you upload signed zone files to godaddy, make sure to resign once a >> week or so so that the RRSIG gets updated. >> >> man ldns-signzone > > Okay so I misunderstood the message I was getting when I checked my > DNSSEC setup via http://dnsviz.net/. What you are telling me is that all > I had to do was re-sign the zone files but that it was not necessary to > generate new keys. This point is definitely one that I missed. > > I too run my own authoritative nameservers. I was following the Digital > Ocean procedure to setup DNSSEC: > > https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2 > > > That site suggested the use of dnssec-signzone after key creation ala a > command like (the stuff that follows has been sanitized): > > > dnssec-signzone -3 `head -c 1000 /dev/random | sha1sum | cut -b 1-16` > -N INCREMENT -o domain.tld -t domain.tld.zone > > After resigning with that command a file named dsset-domain.tld. is > created which contains 2 digests. > > > cat dsset-domain.tld. > domain.tld. IN DS 20716 7 1 04E3E6C87CD4190F74DD0371A14AD5CC42B71521 > domain.tld. IN DS 20716 7 2 > FA6D0EF0100855E5C85C6CD5A33590681DD9D7D9F6C773785C53E865 E02FF572 > > It is the keytag (20716) and the digests (hex fields) that are supposed > to be uploaded to the registrar according to the section entitled > "Configure DS records with the registrar" in the Digital Ocean reference > I previously mentioned. In my original message it was the uploading of > these keytags and digests to Godaddy that I was referring in my point 1 > and which seems to be accomplished only manually via the Godaddy web > interface. > > So doesn't ldns-signzone create the same kind of digest that requires it > be uploaded to the registrar? Isn't that essential information in order > to tell the .tld that the domain.tld DNSSEC is valid and to maintain the > DNSSEC authentication chain trust up to the root servers? You can go to > the http://dnsviz.net/ site and can use nurdog.com as an example of what > i mean.The DS record does have to be uploaded to your registrar but it only changes when you change your Key Signing Key, as it is based on your Key Signing Key. I see you are using algorithm 7 - I would recommend switching to either algorithm 13 or at least to 8. Algorithm 7 uses a SHA1 hash. See https://tools.ietf.org/html/draft-ietf-dnsop-algorithm-update-04 That's a draft but soon will be an update to the standard. Algorithm 13 (ECDSAP256SHA256) results in much smaller keys and signatures and is equivalent to about RSA-3072 in strength, and it uses a SHA-256 hash. However note that changing algorithms will result in validation failure for few days unless done carefully.> > If I do not have to generate the keys every time the RRSIGs expire then > the scripting or re-signing the zones is really trivial as I am in full > control of my own DNS servers. It is even easier now if I don't have to > generate new keys although that really isn't a difficult step.Yes that is what I do, daily via cron (or whenever I change a record) I resign it and upload.> > So maybe I asked the wrong question. Is there a way to re-sign the zone > files without having to recreate the information found in that > dsset-domain.tld. file and uploading it to the registrar? I suspect > there is no way around that as I believe it is essential to maintaining > the chain of trust. But if I can keep everything on my own nameservers > that would be a big help ... maybe ldns-signzone is the answer? >As long as you don't change your KSK that information will not change.
On 2/13/19 3:51 AM, Alice Wonder wrote:> I see you are using algorithm 7 - I would recommend switching to > either algorithm 13 or at least to 8. > > Algorithm 7 uses a SHA1 hash. > > See https://tools.ietf.org/html/draft-ietf-dnsop-algorithm-update-04 > > That's a draft but soon will be an update to the standard. > > Algorithm 13 (ECDSAP256SHA256) results in much smaller keys and > signatures and is equivalent to about RSA-3072 in strength, and it > uses a SHA-256 hash. > > However note that changing algorithms will result in validation > failure for few days unless done carefully.Okay thanks. What ever problems it might cause I think the Alaskan Malamute Assistance League can deal with for a day or two. Seeing as I already caused a problem last weekend I see no reason not to repeat this weekend! But at least I can give some warning :)> As long as you don't change your KSK that information will not change.I kind of figured this out on my own this morning when I woke up around 7AM MST. I guess I wanted to turn a mole hill into a mountain. Thank you so much for your help Alice. -- Paul (ganci at nurdog.com) Cell: (303)257-5208
On 2/12/19 11:49 PM, Paul R. Ganci wrote:> Okay so I misunderstood the message I was getting when I checked my > DNSSEC setup via http://dnsviz.net/. What you are telling me is that > all I had to do was re-sign the zone files but that it was not > necessary to generate new keys. This point is definitely one that I > missed. > > I too run my own authoritative nameservers. I was following the > Digital Ocean procedure to setup DNSSEC:Key rotation and signature rotation are separate concerns.? Most users should be able to significantly simplify signature rotation using bind's built-in signing management, rather than using dnssec-signzone.? You can define your zone like so: ??????? zone "example.net" IN { ??????????????? type master; ??????????????? file "dynamic/db.example.net"; ??????????????? update-policy local; ??????????????? key-directory "keys/example.net"; ??????????????? inline-signing yes; ??????????????? auto-dnssec maintain; ??????? }; ...and then either replicate your zone to a public-facing host, or export and manually copy the zone (maybe "dig @localhost example.net -t axfr"?) Manual signing is probably only useful if you want your DNSSEC key files kept on a system that isn't connected to a network, for security reasons, and you have another process for publishing the signed zone files. (Newer bind releases have a python tool to manage key rotation. I use this one: https://bitbucket.org/gordonmessmer/update-dns-keys/)> So doesn't ldns-signzone create the same kind of digest that requires > it be uploaded to the registrar?Yes, I think so.? If I understand you properly.> So maybe I asked the wrong question. Is there a way to re-sign the > zone files without having to recreate the information found in that > dsset-domain.tld. file and uploading it to the registrar?If you mean the DS records, those should be stable as long as you have the same KSK, so there's nothing *new* to upload when your zones are re-signed.