Securing DNS with DNSSEC

In our previous post, we saw how to set up a DNS server for name resolution in the private network of the company EOS. But what about security? How can we ensure that DNS requests are being sent to the right DNS server and not a spoofed one? This is why DNSSEC has been implemented to address this issue. DNSSEC does not guarantee the confidentiality of DNS requests, but it guarantees the authentication of the DNS server by using public key encryption mechanisms and digital signatures. DNSSEC utilizes two types of keys for the authentication of the DNS server: Zone Signing Key (ZSK) and Key Signing Key (KSK).

The ZSK consists of a pair of a public ZSK and a private ZSK. The private ZSK is used to sign the RRset (Resource Record Set) of the zone in order to generate a digital signature (RRSIG), while the public ZSK is used to validate the digital signature of the RRset for the zone.

The KSK consists of a pair of a public KSK and a private KSK. The private KSK is used to sign the public ZSK to generate a digital signature, while the public KSK is used to authenticate the digital signature of the public ZSK.

If you want to learn more details about DNSSEC, you can read this informative post: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj200221(v=ws.11)

ZSK and KSK

Implementing DNSSEC

The first step is to generate the two key pairs for ZSK and KSK. The KSK can be generated using the dnssec-keygen command, specifying the RSA algorithm and SHA digest function with a size of 2048 bytes.

# cd /var/named 
# dnssec-keygen -a RSASHA256 -b 2048 -n ZONE -f KSK eos.net
KSK generation

To generate the ZSK, we continue to use the dnssec-keygen command.

# dnssec-keygen -a RSASHA256 -b 2048 -n ZONE eos.net
ZSK generation

Let’s modify the named.conf file to enable DNSSEC for our BIND. Please add the following lines to the file.

# vi /etc/named.conf

dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

The next step is to include the generated file into our zone file (please refer to the previous post where we set up the DNS server). Upon observation, we can see that the key has been added at the end of our file.

# cat Keos.net.+008+1*.key >> eos.net.db
# cat eos.net.db // to view the content
Include the key inside the zone file

We then use the dnssec-signzone command to sign the zone file. This will generate a new file. In our case, the generated file is eos.net.db.signed.

# dnssec-signzone -t -g -o eos.net eos.net.db /var/named/Keos.net.+008+1*.private
zone signing

We now need to modify the named.conf file to make sure it references the newly signed zone file, and then we can restart the named daemon.

# vi /etc/named.conf

// we modify as below :

//forward zone
zone "eos.net" IN {
type master;
file "eos.net.db.signed"; //modify here
allow-update { none; };
allow-query { any; };
};

# systemctl restart named

Verifications

To verify if DNSSEC is functioning correctly, we can utilize the dig command, which will provide information regarding the keys and algorithm used by our signed zone.

# dig DNSKEY eos.net @192.168.3.210 +multiline
dns verification using dig command

Additionally, we can examine the dsset-eos.net file for further verification.

# cat dsset-eos.net.
checking dsset-eos.net. file

Conclusion

In this post, we have demonstrated the implementation of DNSSEC to enhance the security of our DNS server. This was achieved by creating the ZSK and KSK, which were utilized to sign our zone and ensure the authentication of the DNS server. It’s important to note that there are additional methods available to protect the DNS service, so stay tuned for upcoming posts. As always, feel free to show your appreciation by clapping, commenting, or following us if you find this content valuable.

--

--

GNINGHAYE GUEMANDEU Malcolmx Hassler

Futur Linux Expert | IT Engineer | LPIC-1 | Database & SQL Developer | Data Engineer | Python Lover | Cybersecurity Enthusiast