Why DNSSEC ?
Normal DNS resolution is straightforward: when a device sends a DNS query, domain name servers and resolvers respond with a DNS lookup. They ensure that the DNS query receives an IP address from the relevant record as a response.
Unfortunately, simple also means native in this case. The DNS protocol’s characteristics can expose any entity to cyberattacks.
As long as the resolver receives data that fulfills the request’s intent, it will continue to process the query until it receives an IP address from the client.
Standard DNS requests are thus vulnerable to man-in-the-middle attacks such as DNS cache poisoning (and the closely related DNS poisoning, which is also called DNS spoofing). To substitute the authentic response to a DNS request, an attacker injects a forged answer. The faked response usually refers to an attacker-controlled server that is set up to seem just like the legitimate site. The end-user may be completely ignorant that they are in an inappropriate location.
The malicious site is also cached in the resolver if DNSSEC is disabled. As a result, additional devices that use the same DNS resolver will also be sent to the fraudulent site. It remains in the cache until its time-to-live expires, possibly affecting a large number of devices.
The above articulation is only for a specific DNS Threat and below is the comprehensive list of DNS-based attacks for which DNSSEC helps to resolve the issues.
- Triggered Cache Poisoning
- Message ID guessing and query prediction
- Man in the Middle Attacks
- Distributed Denial of Service (DoS) using open recursive DNS Server as amplifier
Compare DNS over DNSSEC
Put sincerely, the main cause at the back of constructing DNSSEC becomes to secure net customers from fake DNS records by way of verifying and embedding virtual signatures inside the DNS records. Every time any person enters a site call of their browser, the virtual signature gets shown by the resolver. Furthermore, once the digital signature matches the records saved inside the grasp DNS server, the information is granted access to the customer’s laptop by means of making a request.
DNSSEC Terminology and Records
Fingerprint – the hash/digest of a public key
KSK (Encryption) – Key Signing Key – used to sign or verify a domain’s / zone’s keys
ZSK (Authentication) – Zone Signing Key – used to sign or verify a domain’s / zone’s non-key records
Trust – to accept the validity and truthfulness of an entity with no need to further validate
Trust Anchor – A trust anchor is a key that is set into an approving resolver so that the validator can confirm the outcomes for a given solicitation back to a known or confided out in the open key (the trust anchor). An approving resolver should have no less than one trust anchor introduced to perform DNSSEC approval.
The DNSKEY document holds the public key used at some point of DNS verification. Whilst a protection-conscious DNS resolver gets a DNSSEC response, it recovers the public key and uses it to test the remaining records’ tokens. The final call servers offer the public keys, and their associated personal keys are used to sign this information. There are commonly two according to the sector, for the Zone Signing Key (ZSK) and Key Signing Key (KSK). The resolver makes use of the DNSKEY report to check that the tokens inside the RRSIG file are valid.
Record Digital Signature (RRSIG) records add a cryptographic signature and information including the kind of DNS records the signature pertains to, the cryptographic algorithms used, the TTL values as well as the expiration dates. An RRSIG may be validated with a DNSKEY and secure a DNS zone with DNSSEC by grouping the same type and name of records into a resource record set or RRset. What gets signed is the RRset, not the individual DNS records. An RRSIG record contains a cryptographic signature for an RRset.
RRSIG records are fine for authenticating existing data. But what about negative responses, like NXDOMAIN or NO DATA? These don’t contain records to sign. We can’t just provide the SOA record and its signature. That would allow replay attacks. A new RR type was created to prove negatives, which could be signed. To authenticate those, DNSSEC adds a new record type: NSEC(Next SECure). NSEC records prove negatives by enumerating positives. Enumerate all domain names in the zone to prove what names don’t exist (NXDOMAIN responses). Enumerate all RR types at a given label to prove what types don’t exist (NO DATA responses). This creates a new problem – zone enumeration (zone “walking”). NSEC3 overcomes the potential for NSEC-walking by cryptographically hashing all record names in a zone.
DNS delegation is the process of dividing the DNS namespace into one or more zones. A Delegated Signer (DS) record is a hashed “fingerprint” of the public DNSKEY stored in the parent zone.
DS records demonstrate the link between parent and child areas. The DS record is in the parent zone and contains the DNSKEY hash from the child zone containing the KSK. The DS record points to the next key in the chain of trust.
When a resolver attempts to access a record from a subzone, it verifies the public DNSKEY stored in the subzone. To do this, it hashes the DNSKEY and compares the hash to the DS record stored in the parent zone. If it matches, the parser can trust all records in the subzone.
DNSSEC Validation Process
Dissection of DNSSEC records
Recursive DNS Cache Server:
1. Sends an iterative query to the authoritative server of root / TLD / actual domain.
Sends a referral:
2. A non-secured referral for the authoritative name server for the child zone.
Sends the records:
3. RR set of DNSKey records for the root zone (the root zone’s PubKSK and PubZSK).RRSig of the above records is signed by parent zone PvtKSK.
4. DS record for the child zone has the hash/digest/fingerprint of the child zone’s PubKSK. RSig of the above DS records is signed by parent zone PvtZSK.
Recursive DNS Cache Server:
Verifies the records:
5. Parent zone DNSKey RR set is verified by successfully decrypting the RR set’s RRSig unsigned the parent zone’s PubKSK.
6. Parent zone DS Record is verified by successfully decrypting the record’s RRSig unsigned the parent zone’s PubZSK.
Verifies the zone:
The trust anchor has a trusted copy of parent PubKSK which is obtained by means other than the DNS protocol such as from different vendors. The zone is verified by the copy of the parent zone PubKSK is found to match that provided to the recursive DNS cache server by the parent zone server.
Public DNSSEC Live Traffic Explanation
Real-time DNSSEC resolution and validation are blow
- To begin with, the client demands an ietf.org from its nearby approving recursive server.
- The approving recursive server follows the ordinary recursion way from root down to the definitive servers of the zone for ietf.org
- Then, the recursive server demands the A record from the legitimate server.
- The legitimate server replies with the A record and comparing RRSIG A record for ietf.org.
- Then, at that point, the recursive server asks the ietf.org authoritative server for the DNSKEY record for the zone.
- The authoritative server for ietf.org returns the DNSKEY record and RRSIG DNSKEY record for ietf.org.
- Next, the recursive server asks .org for the DS record for ietf.org.
- The .org server responds with the DS record and corresponding RRSIG DS record for ietf.org.
- Then, the recursive server requests the DNSKEY record from the .org server.
- The .org server responds with the DNSKEY record and corresponding RRSIG DNSKEY record.
- Then, the recursive server demands the DS record of .org from the root servers.
- The root servers return the DS record and relating RRSIG DS record for .org.
- Then, at that point, the recursive server requests the DNSKEY record for the root.
- The root server returns the DNSKEY record and the RRSIG DNSKEY record for the root.
- At long last, the recursive server utilizes the arranged trust anchor to approve the DNSKEY record and relating RRSIG DNSKEY record for root. DNSSEC-mindful resolvers have the important key for approving reactions from root servers previously underlying.
DO: The DO bit is remembered for a DNS question and is a condensing for “DNSSEC OK”. If the DO bit is set (DO=1), the customer is DNSSEC-aware, and it is OK for the DNS server to return DNSSEC information in a response
Denial of Existence
When there is no existence of domain which client requested for, Denial of existence will come and play the role.
- Imagine we want to resolve “doesnotexist.ietf.org”.
- The resolver will send us back to: domain doesn’t exist.
- So, how can we validate this denial of existence?
As we have already briefly described in the section “| <variable> Terminology and Records”. However, NSEC works by returning the “next secure” record, it creates zone enumeration (zone “walking”). So, to address this NSEC3 got introduced.
NSEC3 was added to keep an assailant from strolling the zone. It works the same way as the NSEC; however, it builds a chain of hashed and not plain text asset records. Because of NXDOMAIN, it returns the hash prior and then afterward the hash of a mentioned domain name.
When a resolver requests a domain and got an NXDOMAIN they can register the hash of the mentioned domain and contrast it with the hashes got in NSEC3.
Chain of Trust
The arrangement is to store a hash of the DNSKEY record at the vault, in a purported DS record. Assuming the hash matches the public keys in the DNS zone, we can be certain that those public keys are credible, and we can trust the marks.
“DNS Over TLS” vs “DNS Over HTTPs” vs “DANE”
If you’re investigating DNS security, there’s a decent possibility you have gone over terms like DANE, DoT, and DoH. While this multitude of things relates to DNS security, they are no different either way. Here is a fast outline of each and how they connect with DNSSEC.
- DANE-DNS-based Authentication of Named Entities (DANE) permits executives to indicate what declaration specialists (CAs) can make endorsements for a domain. For DANE to work, DNSSEC should be empowered.
- DNS over TLS (DoT) scrambles DNS traffic utilizing Transport Layer Security (TLS) encryption. DoT is a technique for tackling the DNS security issue that DNSSEC doesn’t.
- DoH-DNS over HTTPS (DoH) plans to tackle a similar general issue DoT does, however, goes about it in an unexpected way. Like DoT, it tends to be considered corresponding to DNSSEC.
What “Not Solved” and “Solved”
CIA Triad is the baseline for all the InfoSec concepts. Let us dissect what can or can’t be solved by DNSSEC using confidentiality, integrity, and accountability matrix.
Does solve by DNSSEC
- Cache Poisoning
- False Authoritative Servers
Doesn’t solve by DNSSEC
- Correct DNS data
- Parent Zone security
DNSSEC is an augmentation of the DNS used to get the DNS information, not the communication channel. It implies that DNSSEC doesn’t encrypt the zone, however, it guarantees that the received zone was sent, and has not been altered, by its proprietor. DNS records are cryptographically marked, so DNSSEC presents the new DNS record types for cryptography.
Probably the greatest benefit of DNSSEC is that it’s viable with the DNS – yet to be secure the entire chain of trust should mean utilizing the DNSSEC from child to root.