DNSSEC

DNSSEC stands for Domain Name System Security Extensions. It adds security features to the Domain Name System. DNSSEC protects against some types of attacks by verifying that DNS responses come from the correct source and have not been changed.

The Domain Name System translates domain names into IP addresses. This process usually happens in plain text. Without extra checks, attackers can intercept or forge responses. DNSSEC uses digital signatures to fix this problem. It does not encrypt traffic but adds a layer of trust.

History and development

The need for DNSSEC (Domain Name System Security Extensions) arose because the original DNS protocol lacked security features. DNS worked fine when the internet was small, but as it grew, vulnerabilities became clear.

• Attackers began exploiting DNS to trick resolvers into accepting false answers
• This led to redirection to malicious or fake websites

A major threat was cache poisoning:

• Attackers insert a forged DNS response into a resolver’s cache
• Users are then unknowingly sent to wrong or harmful addresses
• This can result in phishing, malware infection, or data theft

In 1997, the Internet Engineering Task Force began working on DNSSEC. The first version was defined in RFC 2065. It was later replaced by RFC 2535 in 1999. These early versions had flaws. They were complex and hard to implement.

A more practical version of DNSSEC arrived in 2005 with:

• RFCs 4033, 4034, and 4035
• These documents introduced:
  • A simplified framework
  • More robust and secure signing mechanisms

A major breakthrough came in 2010:

• The DNS root zone was signed, enabling:
  • Full trust chains from the root to any signed domain
  • End-to-end verification of DNS records

DNSSEC has since seen gradual adoption as tools matured and awareness of DNS vulnerabilities increased.

How DNSSEC works

DNSSEC adds digital signatures to DNS records. These signatures prove that the data has not been changed. Each DNS zone has a key pair. The private key signs data. The public key is published and used to verify the signature.

The main parts of DNSSEC are:

• RRSIG: This is the signature record. It holds the digital signature for one or more DNS records.
• DNSKEY: This is the public key used to verify signatures.
• DS: The delegation signer record links one zone to the next. It holds a hash of the child zone’s DNSKEY.
• NSEC and NSEC3: These records prove that a name does not exist. They prevent fake records from being inserted.
• Chain of trust: This is the link between the parent and child zones. The trust starts at the root zone.

When a DNS resolver supports DNSSEC, it checks these signatures. If they match, the data is trusted. If not, the resolver can reject the answer.

Example of DNSSEC in action

A user tries to visit example.com. The resolver asks the .com zone for the name servers. The .com zone gives the answer along with a DS record for example.com. The resolver then checks the DNSKEY for example.com and confirms that it matches the DS record. Next, the resolver checks the RRSIG for the A record and uses the DNSKEY to confirm the signature.

If all checks pass, the resolver trusts the answer. If any check fails, the resolver discards the answer and may show an error to the user.

Comparison with Standard DNS

Feature	DNS	DNSSEC
Authentication	No	Yes
Protection against spoofing	No	Yes
Integrity check	No	Yes
Data origin validation	No	Yes
Proof of non-existence	No	Yes (via NSEC or NSEC3)
Added complexity	Low	Medium

DNSSEC does not change how DNS names are resolved. It only adds checks to confirm the source and content. This makes it compatible with existing systems, as long as they support the new record types.

Advantages

• Data Integrity - DNSSEC makes sure that DNS data has not been changed during transit. It detects tampering.
• Source Authentication - Resolvers can check that DNS answers came from the correct zone. This prevents some redirection attacks.
• Defense Against Cache Poisoning - DNSSEC helps protect DNS resolvers from being tricked into storing fake records.
• Trust Chain - Each level of the DNS hierarchy signs the next. This chain of trust helps validate data from the root to the domain.
• Proof of Non-Existence - NSEC and NSEC3 records allow resolvers to confirm that a domain name or record does not exist. This stops fake answers from being accepted.

Limitations

DNSSEC does not encrypt data. It does not hide DNS queries or responses. Anyone on the network can still see which domains a user visits.

DNSSEC adds size to DNS responses. This can cause problems on networks that block large packets or do not support new DNS features.

Some networks strip DNSSEC records or fail to pass them through. This can cause false failures or make DNSSEC useless.

Signing keys must be kept safe. If a private key is stolen, an attacker can sign fake records. Regular key rotation is needed.

Complexity is higher than standard DNS. Zone signing, key management, and monitoring take effort and planning.

Types of keys

DNSSEC uses two types of keys:

• Zone Signing Key (ZSK): Signs the DNS data in a zone. It changes more often.
• Key Signing Key (KSK): Signs the DNSKEY record. It is higher in the trust chain and changes less often.

Separating the keys allows for safer and easier key management.

DNSSEC deployment

To use DNSSEC, domain owners must:

1. Sign their DNS zone.
2. Publish DNSKEY and RRSIG records
3. Provide a DS record to the parent zone.

Registrars must support DS record submission. Some registrars make this process easier by offering automated tools.

Resolvers must support DNSSEC validation. Many public resolvers, like Google Public DNS and Cloudflare’s 1.1.1.1, already do this.

Operating systems and browsers do not yet rely on DNSSEC results directly. They trust the resolver to handle validation.

Common problems

• Lack of support: Some registrars do not support DNSSEC or DS records.
• Broken chains: If the DS record is missing or wrong, the trust chain breaks.
• Expired signatures: Signatures must be refreshed before they expire.
• Incorrect keys: Publishing the wrong public key causes validation to fail.
• DNS response size: Larger responses may get dropped or fragmented, causing delays or failures.

Key rollover

Keys must be rotated to reduce the risk of compromise. The ZSK is usually rotated more often than the KSK.

Rollover involves generating a new key, signing the zone with both keys, publishing the new key, and then removing the old key. If done wrong, rollover can break DNSSEC and make domains unreachable.

Real-world usage

Large sites like Google, Facebook, and PayPal have DNSSEC enabled. Many country code top-level domains are signed, such as .uk, .fr, and .de. Most new top-level domains require DNSSEC support.

Banks, government sites, and healthcare systems often use DNSSEC to protect users from redirection attacks.

DNSSEC in the Hepsia Control Panel by NTC Hosting

NTC Hosting offers DNSSEC as a free feature within the Hepsia Control Panel, available across all hosting services, including web hosting, VPS, semi-dedicated servers, and dedicated servers.

This integration allows users to easily enhance their domain security, protecting their online presence from malicious activities and ensuring the integrity of their DNS data.