The way the internet works closely depends on the DNS (Domain Name System). When you type in a domain name in your browser, such as smarthost.eu, or send an email, you don’t usually think about what exactly is going on in the background. In fact, every time you use a domain, the DNS system translates its name into an IP address that computers and servers on the network can understand.

However, the standard DNS system is not completely secure against various types of attack. That is why we have implemented DNSSEC, a set of extensions for the DNS system that improves security and data integrity. Using advanced cryptographic methods, this technology guarantees that answers to DNS queries remain authentic and are not modified by third parties.

Why should DNSSEC be implemented?

• Protection against fraud and attacks:

DNSSEC allows us to check that the DNS data comes from an authorised source and has not been altered during transmission. This provides us with the assurance that the DNS data is the same as that originally signed by the zone owner and has not been manipulated.

• Verification of data authentication and integrity:

DNSSEC allows us to check that the DNS data comes from an authorized source and has not been altered during transmission. This ensures that the DNS data is the same as that originally signed by the zone owner and has not been manipulated.

• Increasing user confidence:

The implementation of DNSSEC can increase user trust in websites and services, ensuring that they are authentic and secure, especially for organizations that store or process sensitive data such as financial or personal information. DNSSEC implementation demonstrates a commitment to security best practice and compliance with current standards.

How does DNSSEC work? Technical aspects and mechanisms of operation.

To better understand how DNSSEC works, let’s take a look at its component parts and the verification process.

The components of DNSSEC:

Keys:

• Private key: Used to create digital signatures of DNS records.
• Public key: Published as a DNSKEY record, it is used to verify signatures by the DNS resolver (the component of the DNS system that translates domain names into their corresponding IP addresses).

DNSSEC records:

• DNSKEY: Record containing the public key for the DNS zone.
• RRSIG: A digital signature record confirming the authenticity and integrity of DNS data.
• DS (Delegation Signer): A record pointing to the DNSKEY key for a subdomain, used to verify and create a chain of trust.
• NSEC/NSEC3: Records used to show that certain DNS records do not exist, preventing DNS spoofing attacks.

Chain of trust:

• A mechanism that links keys and signatures from the top-level zone down to a specific domain. It starts with a trusted root key that is known and recognised by the DNS resolver.

Key types:

1. ZSK (Zone Signing Key)

• It is used to create digital signatures for DNS records in a given zone. This allows the authenticity and integrity of these records to be verified.
• It is usually changed (rotated) more frequently than the KSK, e.g. every few months, to reduce the risk of compromising the key.
• The ZSK key is stored and used locally by the DNS zone operator.

2. KSK (Key Signing Key)

• It is used to sign the ZSK key, which creates a trusted path to the signing keys of the DNS zone records. The DS (Delegation Signer) record in the supervising DNS zone contains the digital fingerprint of the KSK, which enables verification.
• It is usually revised less frequently than the MCC, e.g. every few years.
• The KSK is a key component of DNSSEC and its security is particularly important.

3. CSK (Combined Signing Key)

• It combines the functions of ZSK and KSK in a single key. It is used to sign both zone records and itself. This simplifies key management, reducing the number of keys needed to secure a DNS zone.
• The frequency of change depends on the security policy of the zone operator, but is usually a compromise between the MCC and KSK frequencies.
• The CSK simplifies key management, but compromising it would have more serious consequences because it has a dual role.

Verification process with DNSSEC

1. Retrieving a DNS record:
   • The client (resolver) sends a query to the DNS server to retrieve a specific record (e.g. A, AAAA, MX).
2. Retrieving a DS record:
   • When a query is made for a domain delegated to another DNS server, the resolver retrieves a DS record from the parent DNS zone. The DS record is proof that the specified domain uses DNSSEC and contains the public key hash used to verify DNS records in the zone.
3. Retrieving the DNSKEY record:
   • The Resolver retrieves the DNSKEY record from the DNS server responsible for the zone. The DNSKEY record contains the public key used to verify the digital signatures of the DNS record.
4. Retrieving the RRSIG record:
   • The resolver retrieves the RRSIG record, which is the digital signature of the DNS record in question. The RRSIG is generated by the DNS server using a private key corresponding to the DNSKEY public key.
5. Verification of the DS record:
   • The Resolver checks the match between the hash of the public key in the DS record and the hash of the public key in the DNSKEY record. If the hashes match, this means that the DNSKEY is authentic and can be used for further verification.
6. RRSIG signature verification:
   • The resolver uses the public key from the DNSKEY record to decrypt the RRSIG signature and compares it with the DNS record. If the signature is correct, it means that the DNS record has not been altered and is authentic.

After positive signature verification, the resolver recognises the DNS record as secure and can return the result of the query to the end user.

Algorithms used to encrypt DNSSEC keys.

There are many algorithms used to generate DNSSEC keys. There are currently (according to the IANA organisation) 16 algorithms. The choice of the right algorithm depends on several factors, so it is worth noting the following features of the algorithms:

1. Security Level:
   Resistance to attacks: How well the algorithm copes with different types of cryptographic attacks.
   Key length: Longer keys usually offer a higher level of security, but at the expense of performance.
   
2. Performance:
   Signature generation time: How quickly an algorithm can generate a signature.
   Signature verification time: How quickly a signature can be verified.
   System resources: Amount of resources (CPU, memory) required for cryptographic operations.
   
3. Signature size:
   Data size: How large the signatures generated by the algorithm are. Smaller signatures are beneficial in systems with limited resources
   
4. Support and compatibility:
   Support by domain registrars: how widely the algorithm is supported by registrars and DNS service providers.
   Compatibility with other systems: How well the algorithm works with other cryptographic systems and protocols.

In cPanel, four algorithms are available:

RSA/SHA-256 (Algorithm 8)

• Security: RSA/SHA-256 is considered secure due to the SHA-256 hash function and RSA encryption. It offers a good combination of security and performance.
• Performance: RSA/SHA-256 is efficient, but can be slower compared to elliptic curve-based algorithms due to the larger key sizes and computational requirements of RSA.
• Compatibility: It is one of the most widely supported algorithms by domain registrars and DNS service providers.
• Signature size: Generates relatively large signatures, which can affect performance on resource-constrained systems.

RSA/SHA-512 (Algorytm 10)

• Security: RSA/SHA-512 offers a higher level of security than RSA/SHA-256 by using the stronger SHA-512 hash function.
• Performance: It is less efficient than RSA/SHA-256 due to the greater resources required to process SHA-512.
• Compatibility: Less widely used than RSA/SHA-256, but still supported by many systems.
• Signature size: Generates even larger signatures than RSA/SHA-256, which can affect performance and resource consumption.

ECDSA Curve P-256 with SHA-256 (Algorithm 13) – recommended by cPanel

• Security: ECDSA P-256 with SHA-256 is highly secure, using modern elliptic curves and the proven SHA-256 hash function.
• Performance: Very efficient as it uses smaller keys, resulting in faster cryptographic operations and lower resource requirements.
• Compatibility: Increasingly popular and widely supported, especially in new implementations.
• Signature size: Generates smaller signatures, which is beneficial in resource-constrained systems.

ECDSA Curve P-384 with SHA-384 (Algorithm 14)

• Security: provides an even higher level of security than ECDSA P-256 with SHA-256 due to a more complex curve and stronger hash function.
• Performance: Less efficient than ECDSA P-256, but still more efficient than RSA-based algorithms.
• Compatibility: It is supported, although not as widely as the ECDSA P-256, but is gaining popularity in environments requiring a high level of security.
• Signature size: Generates larger signatures than ECDSA P-256, but still smaller than RSA/SHA-256 and RSA/SHA-512.