By translating domain names into IP addresses, the Domain Name System (DNS) makes client-server communication possible and is crucial for the operability of the Internet.

Over time, the DNS has yielded vulnerabilities that allow hijackers to sneak into sessions and deceive users into giving their secure details to fake websites, for example.

This has called for the introduction of the DNSSEC technology so that this part of the Internet’s infrastructure can be made secure. In line with the global end-to-end deployment trend, we’re welcoming DNSSEC on our platform as well.

How do DNS lookups work?

DNSSEC, short for Domain Name System Security Extensions, is designed to address the security glitches in the DNS lookup process.

To get a better idea of DNSSEC, let’s see how the DNS lookup process works first:

1. When a user types the address of a site (for example, WWW.DOM.COM) in their browser, a request for more details on .COM is being sent to the root zone.

2. With that information at hand, a new request is sent to the .COM zone, this time for details on DOM.COM.

3. Finally, the DOM.COM zone is queried for WWW.DOM.COM’s IP address. Your browser will then receive a response, which will contain that address.

The scheme below offers a visual overview of the DNS lookup steps described above:

Each of these zones is managed by different entities: the root zone is managed by ICANN, .COM (or any other TLD) is administered by a domain registry (in our case this is VeriSign) and DOM.COM is managed by a domain registrar like LiquidNet, for example.

What is DNSSEC?

A few years ago, a decades-old vulnerability in the DNS lookup process re-surfaced.

Experts in cyber security found out that the Domain Name System cannot fully guarantee the validity and integrity of the data sent in response to a DNS query, because it doesn’t actually check for credentials when a DNS lookup is being performed.

Hijackers can use this vulnerability to sneak through the DNS lookup process and take control of a session in order to exploit it for their own phishing purposes.

This is where the DNSSEC security protocol kicks in.

How does DNSSEC curb the DNS vulnerability?

DNSSEC adds a layer of security by making sure that the end user is connecting to the real, legitimate website or some other service associated with the given web address.

This is done by validating DNS responses through the use of digital signatures during each stage of the query process:

By protecting the lookup process, DNSSEC complements another security protocol – HTTPS, which encrypts the data submitted during a browser-server ‘dialogue’.

Unlike HTTPS, however, it does not encrypt data, but instead integrates a series of digital signatures into each step of the the above-described DNS lookup process.

Those signatures are generated by special keys, which must be validated by a higher-level entity, i.e. .COM must sign DOM.COM’s key, the root must sign .COM’s key, etc.

During validation, each parent zone signs the key of the child zone below it, establishing a ‘chain of trust’ between them in the process.

The digital signatures and their corresponding keys are stored in name servers alongside common record types like A, AAAA, MX, CNAME, etc.

By checking the requested DNS record’s associated signature, it can be verified whether it comes from its authoritative name server or whether it has been altered en route and used in a man-in-the-middle attack.

How does DNSSEC validation actually work?

DNSSEC adds a few new DNS record types, which store the required signatures and their verification keys:

• · RRSIG – contains the digital cryptographic signature;
• · DNSKEY – contains the keys, which verify the digital signature;
• · DS – the Delegation Signer records enable the transfer of the authentication responses between the separate zones in the DNS lookup chain;

Namely the communication between these records is what enables the validation of DNS records (i.e. DNSSEC validation).

First, let’s see how RRSIG and DNSKEY interact to secure a given DNS zone:

1. DNS Records of the same type (A, AAAA, MX, CNAME, etc.) are grouped into an RRset (a resource record set) for an all-at-once validation;
2. A pair of zone-signing keys (ZSKs) – private and public, is generated;
3. The private ZSK creates a digital signature for the RRset, which is stored as an RRSIG record in the name server;
4. The signature in the RRSIG record is verified by the public ZSK, which is stored in a DNSKEY record;
5. A pair of key-signing keys (KSKs) – private and public, is generated to validate the DNSKEY for the ZSK;
6. The private KSK creates a digital signature and an RRSIG for the public ZSK;
7. The signature in the RRSIG record is verified by the public KSK, which is stored in another DNSKEY record;

Now let’s see what happens when a DNS query is sent to the zone:

1. The client sends a request to a given set of DNS records, the corresponding RRset is queried and it returns its RRSIG record, which stores the signature;
2. The DNSKEY records (with the public ZSK and KSK keys) are called upon to return the other RRSIG record from the name server;
3. The RRSIG of the RRset is validated with the public ZSK;
4. The RRSIG of the DNSKEY is validated with the public KSK;
5. This is how a DNS query is validated within a given zone.

However, as we’ve seen above, the lookups traverse the entire DNS hierarchy – from the root zone all the way to the specific web address.

To transfer the validation results from one zone to the zone beneath, the aforementioned DS records have been introduced.

DS records are published by the parent zone and contain a hash of the DNSKEY record, which holds the public KSK key (the final validation marker within a zone).

This way, when a query is sent to a given child zone, its parent zone will provide a DS record to confirm that the child zone is DNSSEC-protected.

Naturally, no parent DS record can be generated for the root DNS zone itself. For this reason, a special, ICANN-coordinated root zone-signing key generation ceremony is being held four times a year.

By making the connection between the separate DNSSEC-validated zones, DS records help establish trust throughout the DNS lookup chain.

The scheme below gives you an overview of a DNSSEC-protected DNS lookup chain:

In the DNS lookup example specified above, when DNSSEC is enabled, the DNS lookup process will proceed like this:

• a DNS query is sent for WWW.DOM.COM, whereupon:
• the pre-validated root zone (managed by ICANN) will help verify the .COM zone;
• the .COM zone (managed by VeriSign) will help verify the records returned for the DOM zone;
• The DOM zone will help verify the records returned for WWW.DOM.COM.

If we query the A record for the DNSSEC-enabled DOM.COM, for example, the returned response will feature a raised “DO” (DNSSEC OK) flag, along with the corresponding RRSIG record.

Which gTLDs are DNSSEC-compatible on our platform?

As a domain registrar and a web hosting provider, we offer DNSSEC support for the DOM.COM and WWW.DOM.COM zones in the DNS lookup chain.

At the moment, DNSSEC support is available for the .COM, .NET and .BIZ gTLDs.

This means that we can publish the respective DS records for any domain registered under whichever of these generic extensions.

Registrants can enable DNSSEC for their domains with a click from the Web Hosting Control Panel.

In the Hosted Domains section, they will see a new column named DNSSEC.

To enable DNSSEC for a specific domain, they will need to just click on the corresponding DNSSEC icon:

This will pull up a dialogue box where the given domain owner will be prompted to select their preferred signature algorithm:

We suggest registrants use RSA/SHA-256, or, alternatively, RSA/SHA-1.

NOTE:If a domain name is not registered through us, we will give the respective DS records to the given client so that they can add them to their domain management account with the other registrar.

To get the DS records for your DNSSEC-enabled domain, click again on the DNSSEC icon.

In the dialogue box, you will see all the required DS details:

Copy the information you see there and paste it in the domain management panel provided by the domain’s current registrar.

For instance, GoDaddy’s DS management interface will look like this:

***

DNSSEC is very important for the reputation of your domain name. By ensuring that your visitors are not routed to somebody else’s server and tricked into submitting their details to phishing sites, you literally insure yourself against losing their trust.

We’ll be adding new domain name extensions to the list of DNSSEC-compatible TLDs on our platform in the near future, so stay tuned for more details on the matter.