New on RIPE Labs: Securing DNS Across all of my Devices
Dear colleagues, Please find this new article by Scott Helme on RIPE Labs in which he describes how he is securing the DNS across all of his devices with Pi-Hole + DNS-over-HTTPS + 1.1.1.1: https://labs.ripe.net/Members/scott_helme/securing-dns-across-all-of-my-devi... Kind regards, Mirjam Kühne RIPE NCC
Configuring DNSSEC on Linux /Unix box devices. Here we go the securing the most of the common Linux devices, I mean it will suit most of the Unix/ Linux flavor . I’m posting some example base on my system’s DNSSEC configuration R & D result. a) Need to enable dnssec in /etc/named.conf configuration file. This will enable the DNSSEC feature set in bind named demon. Need to check you have the following, or add it if it doesn’t exist: options { dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; } You have to restart bind after this via service named restart or /etc/init.d/named restart which one do match with your system. b) Next, we have to find out where your DNS zone files are. I’ve used our domain in this example. We now want to create the Zone Key (ZSK). The directories below will probably be different for your system. It will also take quite a while. # cd /var/named/chroot/var/named/master # dnssec-keygen -a RSASHA1 -b 1024 -n ZONE londontelecom.net This will create two files: • Londontelecom.net.*.key (public key) • Londontelecom.net.*.private (private key) c) Now we need to create the Secure Entry Key (KSK) for the domain. It also takes quite a while. # dnssec-keygen -a RSASHA1 -b 4096 -n ZONE -f KSK londontelecom.net d) To make the zones use DNSSEC, we need to now add ONLY the public portions of the generated keys to the zone file. # cat Londontelecom.net*.key >> londontelecom.net Note: For the love of IDEITY, make sure you use >> here so you don’t wipe out your zone file! e) Next step, signing the zone files and adding the fields required: # dnssec-signzone -e +3024000 -¬N INCREMENT londontelecom.net This signs to zone file with an end time 35 days after the start time. This allows automations of resign the domain using a script in /etc/cron.monthly without the domain expiring after 30 days (the default). This will also increment the serial no on the zone files automatically. The result will be the output file londontelecom.net.signed. f) We now have to tell bind demon to use the new signed zone file in /etc/named.conf. We want to replace the entry that currently refers to the non-signed zone file (londontelecom.net) for the signed zone file (londontelecom.net.signed). zone " londontelecom.net " { file "/var/named/master/ londontelecom.net.signed"; }; g) We are now ready to restart bind to activate the new signed config. # service named reload or /etc/init.d/named restart Things to be care of: 1) By default, zone signatures (dnssec-signzone) expire 30 days after the last time they are generated. This example extends this to 35 days to allow you to use a cron to resign the zonefile in the monthly cron. I use a script as follows: #!/bin/bash SIGNZONE="/usr/sbin/dnssec-signzone" cd /var/named/chroot/var/named/master $SIGNZONE -n INCREMENT londontelecom.net service named reload If we put this script in /etc/cron.monthly/, zones will be automatically resigned every month. 2) Every time we change a zone file, we have to re-sign it. 3) The current best practice is to generate a new KSK every year, and a new ZSK every 3 months. This is pretty much repeating this example from step 1. It can probably be scripted – as long as you don’t double up on the public keys being placed in the zone file (step d). Thanks Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum
Masud Akhtar Ahmed <m.ahmed@londontelecom.net> wrote:
It's easier than that :-)
a) Need to enable dnssec in /etc/named.conf configuration file.
options { dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; }
You don't need the dnssec-enable option: the default is "yes" and turning it off will break things. The DLV has been decommissioned, so you should omit the dnssec-lookaside option. On a resolver you should set `dnssec-validation auto` which enables RFC 5011 trust anchor rollover, initialized using the root key that is built in to BIND. If you set it to `yes` then you must be prepared to do manual trust anchor management, and you should ask yourself probing questions why.
# dnssec-keygen -a RSASHA1 -b 1024 -n ZONE londontelecom.net
You should use ECDSAP256SHA256, or RSASHA256 with 2048 bit keys, same for ZSK and KSK. 1024 is too small and 4096 is wasteful.
d) To make the zones use DNSSEC,
Use `named`s built-in signer: `auto-dnssec maintain`. Don't use `dnssec-signzone` unless you are an expert doing weird stuff. The `inline-signing` option requires fewer changes to existing setups that edit zone files; it isn't necessary if your zones are dynamic. Remember to make your private keys readable by named, e.g. # chgrp named K*.private # chmog g+r K*.private Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ an equitable and peaceful international order
participants (3)
-
Masud Akhtar Ahmed
-
Mirjam Kuehne
-
Tony Finch