DNSSEC Questions
Last weekend I had my DNSSEC keys expire. I discovered that they had expired the hard way… namely randomly websites could not be found and email did not get delivered. It seems that the keys were only valid for what I estimate was about 30 days. It is a real PITA to have update the keys, restart named and then update Godaddy with new digests.
The first part of the problem is fairly manageable in the sense I
already have a script that partially can do the job of updating the DNS
server. However from what I can tell the only way I can update the DNSSEC of my 8 domains is via the Godaddy control panel GUI. So a couple of questions.
1.) Is anyone aware of anyway to update Godaddy DNSSEC data via a CentOS
7 bash shell? I will contact Godaddy but I suspect I am SOL but thought I would ask here thinking somebody else may have already run into this issue.
2.) Assuming the answer to DNSSEC is no, can I at least have the keys last longer than they do by default. I am presently creating the keys via:
> dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZONE zone
> dnssec-keygen -f KSK -a NSEC3RSASHA1 -b 4096 -n ZONE zone
It is very unclear to me given the dnssec-keygen man page how to set the date so that I could get 90 days or even more per key. The descriptions I found about constructing rolling keys was even more cryptic to me. For example, how do you use these switches:
-A date/offset
Sets the date on which the key is to be activated. After that date,
the key will be included in the zone and used to sign it. If not
set, and
if the -G option has not been used, the default is “now”.
-D date/offset
Sets the date on which the key is to be deleted. After that date,
the key will no longer be included in the zone. (It may remain in
the key
repository, however.)
-I date/offset
Sets the date on which the key is to be retired. After that date,
the key will still be included in the zone, but it will not be used
to sign
it.
-P date/offset
Sets the date on which a key is to be published to the zone. After
that date, the key will be included in the zone but will not be used
to sign
it. If not set, and if the -G option has not been used, the default
is “now”.
-R date/offset
Sets the date on which the key is to be revoked. After that date,
the key will be flagged as revoked. It will be included in the zone
and will
be used to sign it.
Is it as simple as setting the -I and -R switches to something like +90d
At least if I can get the DNS server to update via a cron job even if the 1st item will always have to be done manually that would be help.
Thanks for your help.
5 thoughts on - DNSSEC Questions
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.
That I don’t know, I use ldns to sign my zone files and upload them to my own authoritative nameserver.
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
It has switches for setting the start and expiration date of signatures. By default I believe it uses current timestamp for start and +60 days for end, though it may be +30 days.
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.
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?
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.
Yes that is what I do, daily via cron (or whenever I change a record) I
resign it and upload.
As long as you don’t change your KSK that information will not change.
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 :)
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.
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/)
Yes, I think so. If I understand you properly.
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.