What is DNSSEC?

Understanding DNS

Understanding DNSSEC first requires basic knowledge of how the DNS system works.

The DNS is used to translate domain names (like example.com) into numeric Internet addresses (like 198.161.0.1).

Although this address system is very efficient for computers to read and process the data, it is extremely difficult for people to remember. Let’s say that every time when you need to check a website, you should remember the IP address of the machine where it is located. People often call the DNS system the “phone book of the Internet”.

To solve this problem, a numeric IP address was attached to every domain name. The website addresses we know are actually domain names.

Domain name information is stored and accessed on special servers, known as domain name servers, that convert domain names into IP addresses and vice versa.

The top level of the DNS resides in the root zone where all IP addresses and domain names are kept in databases and sorted by top-level domain name, such as .com, .net, .org, etc.

When the DNS was first implemented, it was not secured, and soon after being put into use, several vulnerabilities were discovered. As a result, a security system was developed in the form of extensions that could be added to the existing DNS protocols.

Domain name system security extensions (DNSSEC) are a set of protocols that add a layer of security to the domain name system (DNS) lookup and exchange processes, which have become integral in accessing websites through the Internet.

Let’s see how this security can be implemented.


How DNSSEC Works

The original purpose of DNSSEC was to protect Internet clients from counterfeit DNS data by verifying digital signatures embedded in the data.

When a visitor enters the domain name in a browser, the resolver verifies the digital signature.

If the digital signatures in the data match those that are stored in the master DNS servers, then the data is allowed to access the client computer making the request.

The DNSSEC digital signature ensures that you're communicating with the site or Internet location you intended to visit.

DNSSEC uses a system of public keys and digital signatures to verify data. It simply adds new records to DNS alongside existing records. These new record types, such as RRSIG and DNSKEY, can be retrieved in the same way as common records such as A, CNAME and MX.

These new records are used to digitally “sign” a domain, using a method known as public key cryptography.

A signed nameserver has a public and private key for each zone. When someone makes a request, it sends information signed with its private key; the recipient then unlocks it with the public key. If a third party tries to send untrustworthy information, it won’t unlock properly with the public key, so the recipient will know the information is bogus.

Note that DNSSEC does not provide data confidentiality because it does not include encryption algorithms. It only carries the keys required to authenticate DNS data as genuine or genuinely not available.

Also, DNSSEC does not protect against DDoS Attacks.


Keys used by DNSSEC

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.
·   The key signing key (KSK) - is used to sign the DNSKEY records in the zone.

Both of these keys are stored as ‘DNSKEY’ records in the zone file.


Viewing the DS record

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.

Each DS record consists of four fields: KeyTag, Algorithm, DigestType and Digest and it looks like the following:



We can break up different components of the DS record to see what information each part holds:

  • Example.com. - domain name that the DS is for.
  • 3600 - TTL, the time that the record may remain in cache.
  • IN stands for internet.
  • 2371 - 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.

All DS records must comply with RFC 3658.


If you have any questions, feel free to contact our Support Team.

Comments

We welcome your comments, questions, corrections and additional information relating to this article. Your comments may take some time to appear. Please be aware that off-topic comments will be deleted.

If you need specific help with your account, feel free to contact our Support Team. Thank you.

Need help? We're always here for you.

× Close