In the previous blog, we discussed various DNS vulnerabilities such as Cache Poisoning, Client Flooding, Information Disclosure attacks, Vulnerability in sharing a nameserver and DDos in DNS. DNSSEC provides answers to all except DDoS attacks. DNSSEC is not the abbreviation for DNS security but a set of resource records (such as A record, MX record) which can seamlessly integrate with our existing DNS infrastructure.

What DNSSEC can do?

It simply provides the proof that the data received from a DNS server is authentic and the DNS server which resolved the query is authentic itself. It confirms that the data from a DNS server has not been altered in any way while passing through the “dangerous” public Internet. This ensures that when you type “www.example.com” in your web browser, the site which comes up is the real example.com and not a forged site. What’s the big deal? Just replace example.com with paypal.com and you will get an idea of its importance.

What DNSSEC cannot do?

As said above, it does not provide any resort to DDoS on DNS servers. DDoS attack will still slow down the DNS servers and make legitimate requests fail. It also does not deal with validating dynamic updates, nor with master to slave data transfers.

Is it backward-compatible?

DNSSEC is just a set of extensions provided to secure the existing DNS infrastructure. Just as we insert A and MX records, we have to insert DNSKEY, RRSIG and DS records in the zone files. It is fully compatible with other non-secure DNS servers as well as client side software which are not DNSSEC aware.
As there is nothing radical in DNSSEC implementation, it gives us the time to fully understand and then integrate it in our existing DNS infrastructure.

How DNSSEC works?

DNSSEC uses cryptographic signatures generated through the use of public key technology. Yes, those are heavy words but an example and a picture would make it easier to digest them.

The procedure:

1. Private key is used to sign DNS data.
2. Public key is given to all DNS validators that is your local nameservers/ISP resolvers.
3. Public key is then used to decrypt the data.

The analogy:

Lets get it this way, you have a padlock and its key. You lock your suitcase and send it to your friend. If your friend has another key, with which he can open the suitcase, he can get the information inside it.

The key with which you lock the suitcase is the private key and it is with only you. Nobody else can lock the suitcase. Your friend’s key with which the suitcase can be opened is the public key. Note that, public key can only open the padlock and not lock it.

Since, public and private key come in unique pairs, your friend can be sure that the suitcase he received is actually sent by you. If somebody else would have used his private key to lock the suitcase, then your friend would not have been able to open it since the private – public key combo do not match in that case.

The picture:

float: center;”/>

Thus private key and public key come in a pair. Only the corresponding public key can decrypt the data. The private key is used only by the owner of the domain, whose domain’s DNS records are being signed.

Thus we are assured that the data has not changed in transit. But how can we be sure that the data is coming from the DNS server it intends to come?

DNSSEC is based on chains of trust anchor. It can be done by “signing” the “.” root zone. Thus we can trust the “.” root zone and everything that follows under this zone.

For example :
To authenticate IP address of www.example.com.

1. We start from well known root public key. We trust the “.” root zone as it is digitally signed by ICANN and IANA.

2. Root uses its private key to sign the “.com” zone and attaches the public key to it. Thus when your local nameserver queries a domain associated with “.com” zone, it can verify the authenticity of the “.com” zone by unlocking the “.com” zone with the attached public key.
Since private-public key come in pairs, “.com” zone has been singed by the root zone and attached public key was able to unlock it, so the “.com” zone is
authentic too.

3. This way the chain flows and “.com” zone authenticates the validity of zone “example.com”.
Thus we get the assurance that the domain name is mapped to the correct IP address and no tampering has been done with it.

Few facts

1. “.” root zone is still not signed, efforts are on by ICANN and IANA. Then we can establish “chains of trust anchor”.

2. The .se – Internet country code top-level domain (TLD) for Sweden has been “signed” and is the first TLD to offer DNSSEC services.

3. After implementing DNSSEC, a request for a single address record might return up to 2K of data! It will slow down the DNS but works are on to minimize this.

For the curious minds, you can read through the presentations at:
https://www.dnssec.net/presentations.

DNSSEC is the future for our DNS service. Though it has not been widely deployed and is still under development, future is indeed secure with DNSSEC!

About the Author

It has been four months and some odd days since Vicky Karmakar joined the Poornam family.
A graduate of Information Technology branch, Vicky has always been interested in exploring the newer ventures of the Open source technology with an acute inclination towards network security. He also harbors a passion towards writing poetry and cooking culinary delicacies.

Co-Authored by Sankar.H