DNSSEC was designed primarily to defend against the DNS vulnerabilities like cache poisoning & MITM.
Lack of Stronger authentication in DNS was the main reason for attacks & the need for DNSSEC.
A major threat to any DNS server was in the underlying DNS query/response along with the inception of false data into DNS cache server’s leading to a so-called cache poisoning attack.
With DNSSEC, it's not DNS queries and responses that are cryptographically signed, but rather DNS data itself is signed by the owner of the data.
DNSSEC adds two important features to the DNS protocol:
· Data origin authentication allows a resolver to cryptographically verify that the data it received actually came from the zone where it believes the data originated.
· Data integrity protection allows the resolver to know that the data hasn't been modified in transit since it was originally signed by the zone owner with the zone's private key.
Every DNS zone has a public/private key pair. The zone owner uses the zone's private key to sign DNS data in the zone and generate digital signatures over that data. Any recursive DNS resolver that looks up data in the zone also retrieves the zone's public key, which it uses to validate the authenticity of the DNS data.
There are two types of keys that are used by DNSSEC: · The zone signing key (ZSK) - is used to sign and validate the individual record sets within the zone. ZSK validates the RRsets. · The key signing key (KSK) - is used to sign the DNSKEY records in the zone. KSK validates the ZSK. Both of these keys are stored as "DNSKEY" records in the zone file.
The DS record stands for Delegation Signer, and it contains a unique string of your public key as well as metadata about the key, such as what algorithm it uses, ensures the records returned by a zone is valid, we need a way of validating the zone itself. To do so DNSSEC simply works up the chain of DNS’s hierarchical structure and passes the trust up via the parent. Each DS record consists of four fields: KeyTag, Algorithm, DigestType, and Digest and it looks like the following:
Example : We.com 3600 IN DS 2431 13 2 18e0ea78ed767d7878aa787ac778787ad78787c
· We.com - domain name that the DS is for.
· 3600 - TTL, the time that the record may remain in cache.
· IN stands for internet.
· 2431 - Key Tag, ID of the key.
· 13 - algorithm type. Each allowed algorithm in DNSSEC has a specified number. Algorithm 13 is ECDSA with a P-256 curve using SHA-256.
· 2 - Digest Type, or the hash function that was used to generate the digest from the public key.
· The long string at the end is the Digest or the hash of the public key.
The Process of validating a record from the perspective of a DNS resolver is as listed below
The resolver queries the DNS server for a record (ex. A)
The DNS server returns the RRset containing the record as well as the RRSIG record containing the signature of RRset signed by the ZSK
The resolver then queries the DNS server for the DNSKEY record to retrieve the public ZSK to validate the signature.
The DNS server returns the RRset containing both the ZSK and the KSK as well as the RRSIG record containing the signature for the RRset of both ZSK and KSK.
The resolver now has all it need to validate the query. It verifies the RRSIG for the request RRset (the A records) with the public ZSK
If that passes, then it validates the ZSK by comparing the RRSIG of the DNSKEY RRset with the public KSK.
DNSSEC TSIG/SIG(0) Keys are used for
Transaction Protection Through Hash-Based Message Authentication Codes - the process of authenticating the source of a message and its integrity through hash-based message authentication codes (HMAC).
Securing Zone Transfers.
Securing Dynamic Updates.
Configuring Dynamic Update Forwarding Restrictions.
Configuring Fine-Grained Dynamic Update Restrictions
dnssec-keygen -a HMAC-SHA256 –b 112 -n HOST ns1-ns2.we.com
Length of key is 112 bits
The above program generates the following files, each containing the key string:
The key generated by using the dnssec-keygen utility has to be defined within the named.conf