DNSSEC (Domain Name System Security Extensions) is a security protocol that aims to protect the integrity of DNS (Domain Name System) data and prevent DNS-related attacks.
In my previous post on DNS, I explained how the DNS works [https://chrisappleyard.net/this-diagram-is-wrong-f1d3ce2a432b] The DNS is a crucial component of the internet infrastructure, but it is also vulnerable to a number of security threats, such as DNS cache poisoning and man-in-the-middle attacks.
DNSSEC works by adding digital signatures to DNS records. These digital signatures are generated using private key cryptography and can be verified using the corresponding public key. This allows DNSSEC-validating resolvers (the systems that look up IP addresses for domain names) to check that the DNS data they receive is authentic and has not been tampered with.
A DNSSEC-validating resolver is a DNS resolver that has been configured to perform DNSSEC validation on DNS records.
When a DNSSEC-validating resolver receives a DNS query, it first checks the DNS record for a RRSIG (DNSSEC signature), which is a digital signature created using a private key. The signature is applied to the RRset (Resource Record set), which is a set of DNS records that have the same name and type but different values. It is used to provide authentication and integrity of the DNS record.
The resolver then uses the corresponding public key, which is stored in the DNSKEY record, to verify the signature. If the signature is valid, the resolver can be sure that the DNS record has not been tampered with and that it is authentic. The resolver will then return the DNS record to the client.
In addition to the RRSIG record, DNSSEC also uses the DS (Delegation Signer) record to establish a chain of trust for a domain. The DS record is used to link a child zone to its parent zone, and it contains a hash of the DNSKEY record of the child zone. When a DNSSEC-validating resolver receives a query for a child zone, it first retrieves the corresponding DS record from the parent zone. The resolver then uses the hash in the DS record to retrieve the DNSKEY record of the child zone.
The resolver then uses the public key in the DNSKEY record to verify the RRSIG of the child zone’s DNS records. This process helps to establish a chain of trust from the root of the DNS tree down to the child zone, ensuring that all DNS records along the way are authentic.
It’s important to note that DNSSEC is not a method of encryption, it’s only used to verify the integrity of the DNS answer from the zone. DNSSEC uses digital signatures and public-key infrastructure to secure the DNS. When a DNSSEC enabled resolver receives a query, it will check the authenticity of the DNS answer before returning it to the client, providing an additional layer of security to the DNS infrastructure.
The main benefit of DNSSEC is that it makes it much harder for attackers to perform DNS-related attacks. For example, DNSSEC can prevent DNS cache poisoning, which is a type of attack where an attacker injects false DNS data into the cache of a DNS resolver. This can cause the resolver to return the wrong IP address for a domain name, which can be used to redirect traffic to a malicious website. DNSSEC can also prevent man-in-the-middle attacks, where an attacker intercepts DNS traffic and modifies it.
DNSSEC provides authentication for DNS data. This means that a DNS client can be sure that the information it received is from the authoritative DNS server and not from a malicious server.
DNSSEC uses a number of different types of DNS records to secure DNS data. These include:
- DNSKEY: This record contains the public key used to sign DNS data. There are two types of DNSKEY records: a Key Signing Key (KSK) and a Zone Signing Key (ZSK). The KSK is used to sign the ZSK, which in turn is used to sign other DNS records.
- RRSIG: This record contains the digital signature for a DNS record. It is created by signing the original DNS record with the private key corresponding to the public key in the DNSKEY record.
- DS: This record is used to establish the chain of trust between the parent and child zones. It contains a hash of the KSK for the child zone, and is stored in the parent zone. For example, the DS key for example.com (child zone) would be stored within the .com (parent zone) zone.
- NSEC / NSEC3: These records are used to prove the non-existence of a DNS record. NSEC records list all of the records that exist in a zone and the order in which they appear, while NSEC3 records use a hashed version of the record names to provide the same information.
DNSKEY and RRSIG records are essential for the DNSSEC to work, the DS records are used to establish the trust in the chain of trust, and NSEC/NSEC3 records are used to prove the non-existence of a record.
Despite the many benefits of DNSSEC, there are also some disadvantages to consider. One of the main disadvantages is that it can be complex to set up and maintain. DNSSEC requires a public key infrastructure (PKI), which can be difficult to manage, especially for large organizations with many different domains.
Another disadvantage is that DNSSEC can introduce some performance overhead to the DNS system. Because DNSSEC requires additional data to be included in DNS responses, the size of DNS packets can be larger, which can slow down the DNS lookup process.
In conclusion, DNSSEC is a powerful security protocol that can protect the integrity of DNS data and prevent DNS-related attacks. It is an important tool for securing the internet infrastructure, but it also requires a significant investment of time and resources to set up and maintain. While DNSSEC has its disadvantages, it is an important protocol to consider when it comes to securing your DNS.
Now, let’s take a look at how to enable a DNSSEC signed zone using BIND. There are two ways to do this, one is manually and the other is by enabling the “dnssec-policy” option.
Create a DNSSEC signed zone on a BIND DNS server
Option 1: Maintain the DNSSEC keys yourself
Enabling DNSSEC on a BIND DNS authoritative server involves a few steps:
- You will need to generate a pair of keys for each domain you want to secure with DNSSEC. You can use the “dnssec-keygen” command to generate these keys. You will need to generate a ZSK (Zone Signing Key) and a KSK (Key Signing Key) for example:
sudo dnssec-keygen -K /var/named/keys -a RSASHA256 -b 2048 example.com
sudo dnssec-keygen -K /var/named/keys -f KSK -a RSASHA256 -b 2048 example.com
This will generate private keys “Kexample.com.+165+12345.private” and public keys “Kexample.com.+165+12345.key” for example, within the /var/named/keys directory. Please ensure the directory exists and has the correct permissions set.
2. Configure BIND to use the DNSSEC key directory within the “options” settings and then add the DNSSEC settings into the “zone” configuration within the named.conf file:
options {
....
key-directory "/var/named/keys";
....
};
zone "example.com" {
type master;
file "example.com.zone";
inline-signing yes;
auto-dnssec maintain;
};
4. Reload BIND: You will need to reload BIND to apply the changes. You can use the “rndc” command to do this. For example:
sudo rndc reload
BIND will now automatically sign the zone with the new keys that correspond to the zone.
It’s Important to note that you should change this key regularly and implement a key policy, this will include steps to retire the old key gracefully.
To check the status of the zone you can use rndc with the following commands
sudo rndc signing -list example.com
sudo rndc zonestatus example.com
“rndc signing -list” will show you if the zone has been signed, which key ID it has been signed with and what algorithm has been used.
“rndc zonestatus” will show you the overall status of the zone plus the DNSSEC status, including when the next re-signing event will take place.
Option 2: Allow BIND to maintain the DNSSEC keys automatically
The “dnssec-policy” option can automatically create and manage the DNSSEC keys and sign the zone automatically without any interaction by the user. The process of signing the zone and rolling the keys is done automatically, making it a convenient way to enable DNSSEC.
Here is an example of how to enable the default policy of the “dnssec-policy” option in BIND’s named.conf file that will automate the process of signing a zone and keeping it up to date automatically:
zone "example.com" {
type master;
file "example.com.zone";
dnssec-policy default;
inline-signing yes;
};
In the above example, the “dnssec-policy default” setting tells BIND to automatically create and manage the DNSSEC keys and sign the zone.
You will need to reload BIND to apply the changes. You can use the “rndc” command to do this. For example:
sudo rndc reload
You can then monitor the status of the zone by using the DNSSEC policy options on rndc, such as
sudo rndc dnssec -status example.com
This new feature of BIND makes it easy for users to enable DNSSEC on their zones, it automatically generates new keys, signs the zones and takes care of the key rollover process and re-signing of signatures using the default policy.
It’s Important to note that this is a experimental new feature of BIND and the default policy may change in future releases and you may find some issues when using the fully automatic DNSSEC key policy. This is not recommended for production use.
The final step is to add the DS record into the parent zone, the DS record is a hash based on the KSK, Key signing key. Use this command to create a DS record and then place this in the parent zone using your registrars portal to manage your domain.
dig @localhost example.com DNSKEY | sudo dnssec-dsfromkey -2 -f - example.com
These are the basic steps to enable DNSSEC on a BIND DNS authoritative server. However, it’s important to keep in mind that DNSSEC is a complex protocol and it’s recommended to have a good understanding of it before implementing it in a production environment. Also, it’s important to have a plan for key management, rollover, and monitoring.
Leave a Reply