Introduction
Basically, you need to understand that hackers can manipulate a FQDN to any IP address.
For example, if you type a FQDN and search a website then the DNS servers somewhere goes and translates that website
into that IP address. How do you know that the IP address that the DNS servers giving you back is the Website you wanted.
So what if someone could intercept that traffic or a middle man DNS server lie to you?
Therefore, the DNSSEC comes in to the role, this DNSSEC will verify what you get back from a DNS server.
- Cryptographically verified results to DNS queries
- DNS Server with signed zone sends
- DNSSEC record to validate response to query
— DNSSEC aware client, recursive server, or forwarding server can validate response - Protects against
— Packet interception
— Man in the middle
— Spoofing
— redirection
— DNS cache poisoning
— Betrayal by trusted server
Record Types
| Type | Function |
| RRSIG | Resource record signature. Each RRSIG record matches and provides a signature for an existing record in a zone |
| NSEC | Proves nonexistence of a record. Protects against spoofing attacks |
| NSEC3 | NSEC replacement that prevents zone walking. Zones can be signed with either NSEC or NSEC3 but not both |
| NSEC3PARAM | Specifies the NSEC3 records included in response for DNS names that don’t exist |
| DNSKEY | Stores the public key used to verify a signature. May store public KSK and ZSK keys |
| DS | Delegation signer records secure delegations. Used in creating authentication chains to child zones |
Components
Trust anchor
- Special public key associated with zone
- Validates DNSKEY resource records
- Can be stored in Active Directory forest partition and replicated to all DNS servers on DCs in forest
DNSSEC key master
- Special DNS server that generated and manages signing keys for DNSSEC protected zones
- A single DNS server can be DNSSEC key master for multiple zones
- Must host DNS primary zone
Key Signing Key (KSK)
- Key used to sign all DNSKEY records at the zone root
- Create the KSK using the DNSSEC key master
Zone Signing Key (ZSK)
- Sign zone data including individual resource records other than DNSKEY
- Create ZSK using DNSSEC key master
DS RECORDS
Delegation Signing records
DS record in parent zone verifies DNSKEY record in sub-zone
-Chain of trust model
Can be manually added to a parent zone to create a secure delegation
Are not automatically created when you sign a zone
Trust Anchors
Trust anchors are essential for DNSSEC validation and can be manually added as DS or DNSKEY records for the desired zone. The Name Resolution Policy Table (NRPT) allows for the configuration of DNSSEC requirements and other settings, such as requiring IPsec communication with DNS servers, using Group Policy.
DNSSEC validation requires at least one trust anchor in the chain of trust
— Add the DS or DNSKEY record for the zone you want to use at the trust anchor
— Can add root zone trust anchor if chain of trust is unbroken
Root zone trust anchor is published by IANA and can be added to Windows Server DNS
— ADD-DNSServerTrustAnchor -Root
Name Resolution Policy Table (NRPT)
Configure Using Group Policy
— Windows Setting\Name Resolution Policy
Options
Require DNSSEC for
Suffix
Prefix
FQDN
Subnet
Require IPsec communication with DNS server
Specify DNS server settings through group policy
DANE
DANE (DNS-based Authentication of Named Entities) is an extension to DNSSEC that enables the certification of TLS certificates by publishing them through DNS. This provides an additional layer of trust by allowing verification of TLS certificates against the organization’s DNS data, protecting against rogue or compromised certificate authorities (CAs). TLSA (TLS Authentication) records are used to publish TLS certificate information in DNS.
DNS-based Authentication of Named Entities
Allows certification of keys used in organization’s TLS certificates by publishing them through DNS
- Trust a TLS cert because it can be checked against the organization’s DNS data rather than published by trusted CA
- Protects against rogue/compromised CAs issuing illegitimate TLS certs
- Published using TLSA resource record type
TLSA Records
Create using Add-DnsServerResourceRecord -TLSA cmdlet
Must include port number and protocol of service
- _25._tcp.tls.microsoft.com
- _443._tcp.tls.microsoft.com
Use https://www.huque.com/bin/gen_tlsa to generate TLSA record and cryptographic has
— Require exported x.509 certificated or public key
Supports public and private CA certificates
— Also supports direct certificate trust in “Domain issued certificate” mode 3
Conclusion
In conclusion, DNSSEC (DNS Security Extensions) plays a crucial role in enhancing the security and trustworthiness of DNS resolution. By providing cryptographically verified results to DNS queries, DNSSEC helps protect against various threats such as packet interception, man-in-the-middle attacks, spoofing, redirection, DNS cache poisoning, and betrayal by trusted servers.
DNSSEC relies on specific record types, including RRSIG, NSEC, NSEC3, DNSKEY, and DS, to ensure the integrity and authenticity of DNS responses. The components of DNSSEC include trust anchors, DNSSEC key master, Key Signing Key (KSK), Zone Signing Key (ZSK), and DS records, which collectively establish a chain of trust for DNS resolution.
