Skip to main content

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.

  • The file becomes huge after some time
  • Need to regularly update
  • Need to maintain name uniqueness
  • Authoritative Servers
  • Non-Authoritative/Caching Servers
  • Recursive DNS Query
  • Non-Recursive or Iterative DNS Query
  • Inverse Query

Name servers

Authoritative Server

  • DNS data can be corrupted as it transfers between primary server, secondary server, resolver or forwarder, cache server.
  • DNS data transactions 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.
  • 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
  • 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>
  • 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.
  • 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 is stored in the DNSKEY record.
  • When the DNSSEC resolver asks for a DNS record (e.g. A), the name server also returns the corresponding RRSIG, and then the 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).
  • The KSK validates the DNSKEY record for the 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 the DNSKEY record, and creates 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 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 the 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.
  • 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 is 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 verify the KSK of .com, the 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.
  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 adds DNSSEC bit, which notifies the nameserver that resolver is DNSSEC enabled and DNSSEC Answers are desired.
  4. The name server is DNSSEC enabled, so the 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 the 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 is stored in the 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. The root nameserver responds with the DNSKEY, the resolver decrypts the RRSIG of the DS with the root ZSK, and compares 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.
Labels:

Comments

Post a Comment

Popular posts from this blog

Free Cybersecurity Certifications

Introduction to Cybersecurity Cybersecurity Essentials Networking Essentials Android Bug Bounty Hunting: Hunt Like a Rat Ethical Hacking Essentials (EHE) Digital Forensics Essentials (DFE) Network Defense Essentials (NDE) Introduction to Dark Web, Anonymity, and Cryptocurrency AWS Skill Builder Introduction to Cybersecurity Building a Cybersecurity Toolkit Cyber Aces Free Cyber Security Training Course Introduction to Information Security Penetration Testing - Discovering Vulnerabilities
Post a Comment
Read more

Is your webcam exposed on the internet and everyone enjoying your personal moments? | How to check webcam or security camera is exposed on the internet or not?

Nowadays we start using many technology devices in our homes. Many people are installing CCTV or security cameras in their houses, private rooms, offices, private places, etc for security purposes and monitoring, but many of them don't know how to configure that device securely. So let's talk about CCTV and security cameras only.  What do most CCTV/Security camera users believe? Most users believe that using a strong username and password on a camera administrative page protects them. (Partially true in the case of online cameras) Example: Why it is partially true? It's partially true because you are protecting only the camera administrative page which is also an important part. Still, you are not protecting the protocol used to control streaming media servers (Real-Time Streaming Protocol ( RTSP )). I have seen many online webcams whose administrative page is secured by strong credentials, but they forget to secure the RTSP protocol which gives me access to the streaming
Post a Comment
Read more

Web Application Security Testing (WAPT) Interview Questions

Let's Contribute All Together For Creating a Questions Dump What are the vulnerabilities you have to test in the Login form, Payment gateway? What is clickjacking? What is the mitigation of clickjacking? What is CSRF? How to mitigate CSRF? Let's take an example, If a developer implements a CSRF token in a cookie, will it mitigate the CSRF issue? Is it possible to mitigate the CSRF by header? If yes why, if No why? If the data is in JSON format, how you will check the CSRF issue and what are the ways of exploitation? Where to implement the CSRF token and why? If the client doesn't want to change the UI or doesn't want to implement the CSRF tokens, and headers then what mitigation you recommended to the client for CSRF? What is the problem with the per-request token? Is login CSRF possible? Explain login CSRF? Have you ever exploited it? What is the mitigation for login CSRF? Suppose, in an application csrf token is implemented in each request and every request, except th
Post a Comment
Read more