Eager to master hybrid server management? Discover how to administer Windows Server Hybrid Core Infrastructure on Azure, setting your path towards the Microsoft Certified: Azure Hybrid Infrastructure Administrator Associate certification!
Prepare and test your skills
Prepare and test your skills
A sequence diagram showing how a client query with the DO bit flows through a recursive resolver, which walks the chain of trust from a trust anchor through DS and DNSKEY records to validate RRSIG signatures before returning the answer to the client.
A Zone Signing Key (ZSK) is used frequently to sign individual DNS records within a zone, whereas a Key Signing Key (KSK) is used less often specifically to sign DNSKEY records. This separation provides higher security for the more sensitive KSK. Both keys must be rotated on a regular schedule, and generating a new KSK requires publishing a corresponding Delegation Signer (DS) record to the parent zone.
NSEC and NSEC3 records are used to prove that a requested name does not exist without listing everything in the zone. This mechanism prevents attackers from discovering all the records hosted in that zone.
A DNS resolver uses a Trust Anchor as an inherently trusted, pre-configured public key to begin validation by walking the chain of trust down to a specific record. If every digital signature along the chain is valid, the resolver delivers the answer to the client. If the chain of trust is broken or a signature is invalid, the resolver returns a SERVFAIL failure and withholds the data.
A client or recursive server requests DNSSEC validation by setting the DNSSEC OK (DO) bit flag in its DNS query. In response, the authoritative server includes the required digital signatures and records, allowing the recursive server to perform validation before answering the client.
Cryptographic Key Management and Zone Signing are core tasks for implementing DNS Security Extensions (DNSSEC). DNSSEC protects DNS data from being tampered with by adding digital signatures to it, which proves the data is authentic and hasn't been altered. This prevents attacks like DNS spoofing or cache poisoning.
When a DNS zone is signed, several new types of records are added to it. The RRSIG record contains the digital signature for a set of records, proving they are valid. The DNSKEY record holds the public key that a DNS resolver uses to check those signatures. To prevent attackers from discovering all the records in a zone, NSEC or NSEC3 records are used to prove a name does not exist without listing everything. Finally, a DS (Delegation Signer) record is published in the parent zone (like .com or an Azure DNS parent zone) to create a secure link, or chain of trust, from the parent down to your signed zone.
DNSSEC uses two types of cryptographic keys. The Zone Signing Key (ZSK) is used frequently to sign the individual DNS records (like A or MX records) within the zone. The Key Signing Key (KSK) is used less often, specifically to sign the DNSKEY records themselves. This separation provides higher security for the more sensitive KSK. Both keys must be rotated (replaced with new ones) on a regular schedule to maintain security, and this process should be automated where possible. After a new KSK is generated, its corresponding DS record must be published to the parent zone to re-establish the chain of trust.
For a DNS resolver to begin validating DNSSEC-signed responses, it needs a starting point of trust called a Trust Anchor. This is a pre-configured public key (often the KSK of a top-level zone like the root) that the resolver inherently trusts. The validation process checks the digital signatures in a response, walking the chain of trust from the anchor down to the specific record. If every signature is valid, the resolver delivers the answer to the client. If the chain is broken or a signature is invalid, the resolver returns a failure (SERVFAIL) and does not provide the potentially fake data.
To request DNSSEC validation, a client or recursive server sets a special flag called the DNSSEC OK (DO) bit in its DNS query. The authoritative server then includes the necessary RRSIG and other records in its response. The recursive server performs the validation check before answering the client. You can use Group Policy to configure Windows clients to require DNSSEC validation for certain domains, ensuring end-users only receive authenticated DNS data.
StudyCerts
StudyCerts