I've left out as much explanation of what's going as possible. If you have questions about how DNSSEC works or what any of these commands are doing in detail there are copious amounts of data on the Internet. Also, I'm using flat files, and the keys are just getting dumped in the same "master" directory as the zone file. This works for very simple setups, but I would not recommend organizing a large site this way.
Before starting make sure your TLD and Registrar support DNSSEC. If they don't support it this is all for naught.
Create the "Key Signing Key", this should be a reasonably good key and doesn't get used/transmitted much.
# dnssec-keygen -f KSK -a ECDSAP384SHA384 -b4096 -n ZONE example.com Generating key pair........+++ ...............................+++ Kexample.com.+014+51367
Create the "Zone Signing Key", this one signs all the zones for this domain. If you are concerned about security you should change this key regularly.
# dnssec-keygen -a ECDSAP384SHA384 -b 4096 -n ZONE example.com Generating key pair......++++++++ ......++++++++ Kexample.com.+014+09261
You should now have four new files, two public and two private keys.
I recommend to rename the generated files to include which kind of keys they are.
# mv Kexample.com.+014+51367.key Kexample.com.+014+51367.ksk.key # mv Kexample.com.+014+51367.private Kexample.com.+014+51367.ksk.private # mv Kexample.com.+014+09261.key Kexample.com.+014+09261.zsk.key # mv Kexample.com.+014+09261.private Kexample.com.+014+09261.zsk.private
Include the created public keys in your existing zone file, something like this:
$TTL 2h @ IN SOA ns1.example.com. root.example.com. ( 1; serial 3h; refresh 10m; retry 3w; expiry 2h ); minimum IN NS ns1 IN NS ns2 IN A 192.168.2.1 IN AAAA fe80::21e:67ff:feec:3c92 ns1 IN A 192.168.2.2 ns1 IN AAAA fe80::fd7d:2db0:e6c1:4e59 ns2 IN A 192.168.2.3 ns2 IN AAAA fe80::250:56ff:feba:21a9 $INCLUDE Kexample.com.+014+51367.ksk.key $INCLUDE Kexample.com.+014+09261.zsk.key ; vim: sw=4 et
Sign your zone file. This generates a new "signed" version. Keep the unsigned version, update it whenever necessary and repeat the signing processes to generate a new signed version.
# dnssec-signzone -o example.com example.com.zone Kexample.com.+014+51367.ksk.key Kexample.com.+014+09261.zsk.key Verifying the zone using the following algorithms: ECDSAP384SHA384. Zone fully signed: Algorithm: ECDSAP384SHA384: KSKs: 1 active, 0 stand-by, 0 revoked ZSKs: 1 active, 0 stand-by, 0 revoked example.com.zone.signed
Make sure you pass the arguments in this exact order.
Edit your 'named.conf' or wherever the zone is specified, make sure you are pulling from the "signed" file and not the original. Something like:
zone "example.com" { type master; file "master/example.com.zone.signed"; };
The world needs to know your fingerprint, otherwise any server could be serving "trusted" signed DNS records.
# dnssec-dsfromkey -a SHA-384 -f example.com.zone.signed example.com example.com. IN DS 17677 14 4 531F4B4324399490BEBC45EBA9624967C8AB8650481E53AB53CA982D7B4ADC710DFE6FD4873BCDE965ED67540C85EB18
You're registrar will have a page where you can "upload" this information. There are 4 key pieces of information from that output. The Key "Tag" is the 5 digit number, "17677" in this example. The Algorithm is the next number "14". The Digest Type is the next number "4". Finally the Digest is the long hex string at the end.
Keep in mind that it might take a few hours before you can verify your configuration. If it's still failing after a day contact their support to see what is holding up the process. For a basic verification that signed records are accessible:
# dig +dnssec +short example.com 192.0.2.1 192.168.2.1 A 14 2 7200 20170302174936 20170131174936 21675 example.com. JPDk2tgoldOY/alcJko+91LCzxSHd5wNu2wn4Ds2rS7GaHoRITgK+yEZ 35hfnb5pi+AVIv63o5GuqHcFgjvQvTTM+SJXsWui3Maltn88hgKfBYS4 VNfXwdJodhYeHgRh
For a complete verification at every level, you first need a copy of the root keys:
# dig . DNSKEY | grep -Ev '^($|;)' > root.keys
You will also need a copy of 'dig' built with the '-DDIG_SIGCHASE' option. Most *nix systems should have that already buitin. You can then run:
# dig +dnssec +sigchase +topdown +trusted-key=root.keys example.com <-- Snipped output: there's a lot of diagnostic details in here --> ;; The Answer: example.com. 6981 IN A 192.168.2.1 ;; FINISH : we have validate the DNSSEC chain of trust: SUCCESS ;; cleanandgo
We got the correct Answer and a successful validation of the chain of "trust", it's working.
If you don't have 'dig' available you can use Sandia Nation Laboratories' online DNSViz tool to verify a variety of DNS functionality, including DNSSEC. It tends to be a bit slow, so have patience with it.
Original Source: https://stoneyforest.net/~chris/blog/freebsd/dns/dnssec-zone.html
This has been modified.