The email servers work with the DNS for routing their messages. Thus, it indicates that the email servers are prone to similar security issues as faced by the DNS infrastructure. There have been cases in the past where emails supposed to pass through servers of Gmail and Yahoo eventually got passed through some rogue or illegal mail servers. The cyber attackers exploit the security issues as DNS does not perform credentials checks before accepting entries. Hence, it has now become significant to use the DNSSEC protocol. It helps to make the DNS secure by providing relevant authentication. As a DNS resolver searches for a site called blog.wxyz.com, the .com servers allow the resolver to check the records associated with XYZ. XYZ then verifies the records as returned for the blog. Root DNS servers can help verify the .com, and all information presented by the root can be evaluated through security procedures like Root Signing Ceremony.
Basics of DNSSEC
The goal of DNSSEC is to create a secure and safe domain name system with the implementation of cryptographic signatures with the existing DNS records. Such digital signatures are stored within the DNS name servers with commonly used record types. Through checking the associated signature, it is possible to verify that the requested DNS record originates from the authoritative name server. You can then be sure that it was not altered or changed en-route. It can help you ensure that there is no possibility of a cyber-attack. DNSSEC works with DNS records like RRSIG, DNSKEY, NSEC, NSEC3, DS, CDNSKEY, and CDS.
When it comes to DNSSEC to secure a zone, it is essential to have records of the same type grouped into an RRset or resource record set. For instance, if there are 3 AAAA records within the zone for the same entity, they must be grouped into one single AAAA RRset. This full RRset eventually gets digitally signed instead of the individual DNS records. It means that you need to get all the AAAA records validated from a single zone instead of only validating one separate and single AAAA.
Every zone in DNSSEC is comprised of a ZSK or zone-signing key pair. The key used for digitally signing each RRset within the zone is its private part. The public part of the key verifies the signature. A zone operator needs to come up with digital signatures for every RRset to enable the DNSSEC. It is done with the help of the private ZSK. The digital signatures are stored as RRSIG records in the name server. The DNS resolvers must verify the signatures if the RRSIG records are to be deemed useful. The zone operator must make the public ZSK available simply by adding it to the name server within the DNSKEY record. As the DNSSEC resolver sends a request for a specific record, the name server can return the associated RRSIG. Once done, the resolver can bring out the DNSKEY record from the name server with the public ZSK. Therefore, the RRSIG, the RRset, and the public ZSK can work together to validate the response.
The DNSSEC name servers need to have a KSK or key-signing key. This KSK can be used to validate the DNSKEY record. The methodology followed by KSK for managing this action is very similar to ZSK and the way it secures the RRsets. KSK signs on the public ZSK and comes up with an RRSIG for DNSKEY. Similar to the public ZSK, the public KSK is published by the name server in another separate DNSKEY record. It provides the DNSKEY RRset. The public ZSK and public KSK are signed by private KSK.
Now the validation for resolvers can be carried out in the following manner.
- Requesting the desired RRset that eventually leads to returning of RRSIG record
- Requesting the DNSKEY records that have public KSK and the public ZSK; returns RRSIG for DNSKEY RRset.
- Verifying RRSIG of requested RRset with public ZSK.
- Verifying RRSIG of DNSKEY RRset with public KSK
It is possible to cache the DNSKEY RRset and RRSIG records. It prevents DNS name servers from being constantly hit by unnecessary requests. The reason separate key-signing keys and zone-signing keys are used for this process is that it is not easy to get rid of a compromised KSK. On the other hand, replacing the ZSK is much more convenient. Hence, it is possible to work with a smaller ZSK to avoid compromising server security and minimizing the data that a server needs to send for every response.
Delegation Signer Records
DNSSEC also works with a delegation signer record or DS record for helping the transfer of the trust from the parent zone to the child zone. The zone operator can hash the DNSKEY record with the public KSK, thus giving it to the parent zone for publishing as the DS record. Each time a child zone gets a referral to a resolver, the parent zone presents with a DS record. The DS record allows resolvers to know that a child zone is fully DNSSEC-enabled. The resolver needs to hash the public KSK of the child zone when trying to evaluate its validity. The resolver also compares the detail to the parent’s DS record. Once a match is detected, the resolver will know no tampering with the public KSK.