Domain Name System Security Extensions (DNSSEC)

Domain Name System Security Extensions (DNSSEC) is used to protect the integrity and authenticity of the data in DNS by establishing a chain of trust.

Before an understanding of DNSSEC, first, understand the basics of DNS:

What are the DNS functionalities?

DNS is used to translate the domain names to IP addresses or vice-versa.

DNS works on both TCP and UDP but normally works on UDP port 53.

TCP port 53 use when very large requests and responses, for example, Zone Transfer.

www.example.com = 192.168.1.10

192.168.1.10 = www.example.com

Why DNS?

Domain names are alphabet and they are easier to remember that is why we user domain name.

In the old solution, the host.txt file needs to regularly update that was distributed to all hosts on the Internet.

Issues with old solutions are:

• The file becomes huge after some time
• Need to regularly update
• Need to maintain name uniqueness

How does it work?

When you enter a domain name in the browser (www.google.com), it first tries to resolve from the system host file, then passes the request to the ISP DNS server, then passes to another DNS server and this process continues until the request can not resolve. When the request resolves the response flow back to the DNS servers to the original requester that is the browser and then the requested website open.

Basic DNS terminologies:

Name servers

• Authoritative Servers
• Non-Authoritative/Caching Servers

DNS Query

• Recursive DNS Query
• Non-Recursive or Iterative DNS Query
• Inverse Query

Name servers

Authoritative Server

The authoritative name server is the official name server that is authorized to provide an answer for a domain you are querying.

The authoritative name server can be more than one name server.

There are two types of authoritative name servers based on the management method primary (master) and secondary (slave).

Changes are done in the primary name server and the secondary name server/s will retrieve the copy of the zone file from the primary name server.

Non-Authoritative/Caching Server

The non-Authoritative name server is the cache server, which cache the domain information for the faster response for the domain you are querying.

DNS Query

DNS query is configured on the DNS server and accordingly, the DNS server works.

Recursive DNS Query

When the recursive query is configured on the DNS server then the DNS server does all the job on behalf of you to fetch the answer to your query. During this process, the DNS server might query other DNS servers on the internet for the answer.

Non-Recursive or Iterative DNS Query

When a non-recursive query is configured on the DNS server then the DNS server not fetch the complete answer of your query on behalf of you but will give the address of other DNS servers, which might have the answer of your query. During this process, the DNS server might provide the IP address of other DNS servers on the internet for the answer and the operating system resolver will query until the domain name does not resolve.

Inverse Query

Inverse DNS query work opposite to normal DNS query. Inverse DNS query or reverse DNS query is used when the user wants to resolve the IP address to the fully qualified domain name (FQDN).

DNS Protocol Vulnerability

The original DNS protocol was not designed with security in mind, as the Internet grows, it becomes less trustworthy. There was no DNS data protection mechanism available which cause below vulnerabilities:

• DNS data can be corrupted as it transfers between primary server, secondary server, resolver or forwarder, cache server.
• DNS data transaction can be compromised as the primary server may send DNS records data to the wrong secondary server which is in attacker control.
• There was no way to check the integrity of the DNS data.

Basic DNS Security Practices

• Run the updated version of DNS software.
• Restrict queries
• Prevent unauthorized zone transfers
• Run BIND with the least privilege (use chroot)
• Randomize source ports
• Secure the box
• Implement TSIG and DNSSEC

Two protection mechanism “Transaction Signature (TSIG) and DNS Security Extension (DNSSEC)” use for DNS data protection

Transaction Signature (TSIG)

• TSIG secures the transaction to protect zone transfer and dynamic updates.
• TSIG makes sure that the DNS query (Ex: AXFR) comes from the right place and is not modified in transit.
• Work on a shared secret key, which is configured on both master and slave DNS servers.
• TSIG is configured in the DNS server (named.conf) file, not in the zone file.
• A wrong key does not allow for the zone transfer and will be logged on the server log.
• Command: dig @<server> <zone> AXFR -k <TSIG key file>

dig @localhost example.com AXFR -k Key-ns1.net.+200+1337.key

DNS Security Extension (DNSSEC)

• DNSSEC is used to secure the zone data by making sure that the resource records are those records that are signed by the administrator of the zone.
• It protects the integrity and authenticity of the zone data by establishing the chain of trust.
• It uses a digital signature to verify the zone data.

For signature validation DNSSEC add new DNS record types:

RRset and RRSIG

In the first step for securing the zone with DNSSEC is to group all the same type records which are called resource record set (RRset).

RRset Example:

Bundle into a single A RRset

www.example.com. 7200 IN A 192.168.1.10

blog.example.net. 7200IN A 10.0.1.1

admin.example.net. 7200IN A 172.16.2.20

RRsets are digitally signed with the private key of the zone server and signature are published in DNS as RRSIG. Public DNSKEY is also published to verify the RRSIG signature.

Zone Signing Key (ZSK)

• The private zone signing key is used to digitally sign each RRset and store them in RRSIG.
• The public zone signing key is used by the resolver to verify the digital signature stored in RRSIG.
• The public zone signing key stored in the DNSKEY record.
• When DNSSEC resolver asks for a DNS record (e.g. A), the name server also returns the corresponding RRSIG, and then DNSSEC resolver asks for the public ZSK from the name server.
• If we trust the zone signing key, then we can trust all the records in the zone but what if the zone signing key was compromised? So, to validate the public ZSK we used key signing key (KSK).

Key Signing Key (KSK)

• The KSK validates the DNSKEY record for zone signing key in the same way the ZSK validates the RRSIG record.
• The private KSK signed the public ZSK and public KSK, which is stored in DNSKEY record and create an RRSIG for the DNSKEY that stores the signature of the public ZSK and KSK.
• The name server stores the public KSK in another DNSKEY record.
• DNSSEC resolver used the public KSK to validate the public ZSK.
• To establish trust within the zone.
• The key signing key (KSK) is signed by itself, which does not provide any additional trust, an attacker compromised the zone and may alter all these keys. So, for the complete trust, we need parent-child trust for this delegation signer (DS) record is used.

Delegation Signer (DS) Record

• Delegation signer (DS) record to allow the transfer of trust from the parent zone to the child zone.
• The zone operator hashes the public KSK and gives it to the parent zone to publish the hash as a DS record.
• Whenever resolver connects with the child zone, the parent zone also shares its DS record, it makes the trust between parent and child.
• The DS record in the parent zone helps the resolver to know that the child zone is DNSSEC enabled.
• DS records should not be added in the child zone.

• Delegation signer (DS) record to allow the transfer of trust from the parent zone to the child zone.
• The zone operator hashes the public KSK and gives it to the parent zone to publish the hash as a DS record.
• Whenever resolver connects with the child zone, the parent zone also shares its DS record, it makes the trust between parent and child.
• The DS record in the parent zone helps the resolver to know that the child zone is DNSSEC enabled.
• DS records should not be added in the child zone.

Why do we use two keys?

So, now the quest is what is the purpose of using two keys when both keys are from the zone itself.

We used two keys to protect the zone itself and to provide the parent-child trust, as making any modification in key signing key (KSK) is a difficult process because we have to make a hash and change that hash into parent delegation signer (DS) record. Changing the DS record is a multi-step process that can end up breaking the zone if it’s performed incorrectly. On the other side, changing the zone signing key (ZSK) is much easier. We just need a modification within a zone.

What if attacker compromised child and parent server then all the DS information would match. So, to trust the DS record first understand the “The chain of trust”.

The Chain of Trust

• The chain of trust work by signing the delegate signer (DS) records by ZSK like any other RRset for the child’s keys, which means it stores the signing data into the RRSIG in the parent.
• The digital signature for DS stored in the RRSIG record.
• For the chain of trust, in example.com the validating resolver asks .com for the ZSK public key, DS and signature to verify the hash in the parent zone of the child KSK key and to verifying the KSK of .com, resolver asks the root (.) for the DS, ZSK and signatures and same process for root. The whole validation process repeats until we get to the parent’s public KSK.

Till now, example.com and .com check out, but what about root? There is no parent DS record to validate against.

For completing the chain of trust cycle, we must trust the security procedure done by a human.

For signing the root, the Root Signing Ceremony is performed every quarter to verify the public and highly audited way. In this ceremony, some selected individuals from the international community agree and sign the root DNS zone’s RRset for the DNSKEY records. The ceremony produces an RRSIG record that can be used to verify the root name servers public KSK and ZSK. Instead of trusting the public KSK because of the parent’s DS record, DNS resolver assumes that it’s valid because we trust the security process in which the Root Signing Ceremony was performed.

NSEC/NSEC3 (Explicit Denial of Existence)

In traditional DNS setup, when we ask DNS for the IP address of a domain that doesn’t exist, it returns an empty answer. So, how we authenticate that domain doesn’t exist since there is no message to sign. The fix for this issue was to add NSEC and NSEC3 record types that explicitly tell a DNS resolver that a given zone does not exist.

The NSEC record is used to prove that something really does not exist, by providing the name before it, and the name after it.

NSEC works by returning the “next secure” record. The NSEC record allows for proof of non-existence for record types. For every existing name, there is a corresponding NSEC record. This NSEC record states what types are available for the current name, as well as the next valid name, is in the sorted zone file. This brings us to the downside of NSEC: Since the NSEC records essentially chain through the complete zone, it’s possible to do “zone walking”.

Example:

example.com

api.example.com

beta.example.com

Let’s assume a request is made for example.com

Request:

dig NSEC example.com

Response:

ANSWER SECTION:

example.com. 3600 IN NSEC api.example.com. A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY

Request:

dig NSEC api.example.com

Response:

ANSWER SECTION:

api.example.com. 3600 IN NSEC beta.example.com. A NS SOA MX TXT AAAA RRSIG NSEC DNSKEY

In the same way, attackers use it for zone walking and enumerate all subdomains in the zone.

NSEC3 uses a hashing algorithm to list the next available domain in the “hashed” format. It is still possible for an attacker to do zone walking, although at a higher computation cost.

DNSSEC Process

1. The user enters the example.com in the browser to access the website.
2. DNS request transfer to resolver for the DNS resolution.
3. Resolver query example.com nameservers for the A record and in this query, resolver add DNSSEC bit, which notifies the nameserver that resolver is DNSSEC enabled and DNSSEC Answers are desired.
4. The name server is DNSSEC enabled, so nameserver responds with the answer to the A record query with the RRSIG of A record which is the digital signature for the verification purpose.
5. For digital signature verification, the resolver asks the nameserver for the public key which is DNSSEC (ZSK and KSK) records.
6. Nameserver responds with DNSSEC (ZSK and KSK) and RRSIG of the DNSSEC records.
7. The DNSSEC(ZSK) record is used to verify the RRSIG of the A record, the answer received in step 4 and DNSSEC (KSK) record is used to verify the RRSIG of the DNSSEC (ZSK and KSK) record.
8. For the chain of trust, the resolver queries the parent (.com) for the DS record that is hash of the of example.com KSK.
9. Parent (.com) nameserver responds with the DS record and RRSIG of the DS record.
10. The DS record is the hash value of the child KSK that stored in parent DS record. The resolver verifies the RRSIG record of the KSK in the child by decrypting the digital signature and comparing the hash of the DS record with the hash of the RRSIG KSK after decryption.
11. Resolver query the .com nameserver for the DNSKEY to verify the RRSIG of the DS record.
12. Parent (.com) nameserver responds with the DNSKEY (ZSK and KSK). The resolver decrypts the RRSIG of the DS record with the ZSK public key and verifies the result. RRSIG of KSK verifies by the KSK public key.
13. For the chain of trust, the resolver asks the root (.) for the (.com) DS record, which is a hash of the .com KSK.
14. Root name server responds with DS record and RRSIG of DS. The DS record is used to verify the KSK of the (.com).
15. Resolver query for the DNSKEY of the root to verify the RRSIG record of DS.
16. Root nameserver responds with the DNSKEY, resolver decrypts the RRSIG of the DS with the root ZSK, and compare the DS values. Public root KSK is used to decrypt the RRSIG of the ZSK and compare the ZSK for the trust. If all the results are verified, then all zones and records are trustable.

Tools for NSEC subdomain enumeration

• ldns-walk
• nsec3map
• dig