Implement DNSSEC


Intercepting and tampering with an organization’s DNS query response is a common attack method. If malicious hackers can alter responses from Contoso's DNS servers, or send spoofed responses to point client computers to their own servers, they can gain access to Contoso's sensitive information. Any service that relies on DNS for the initial connection—such as e-commerce web servers and email servers—is vulnerable.

What is DNSSEC?

DNSSEC protects clients that are making DNS queries from accepting false DNS responses. When a DNS server that is hosting a digitally signed zone receives a query, the server returns the digital signatures along with the requested records. A resolver or another server can obtain the public key of the public/private key pair from a trust anchor, and then validate that the responses are authentic and haven't been tampered with. To do this, you must configure the resolver or server with a trust anchor for either the signed zone or a parent of the signed zone.

The high-level steps for deploying DNSSEC are:

  1. Sign the DNS zone.
  2. Configure the trust anchor distribution.
  3. Configure the name resolution policy table (NRPT) on client computers.

Resource records

DNS response validation is achieved by associating a private/public key pair (as generated by the administrator) with a DNS zone, and then defining additional DNS resource records to sign and publish keys.

Resource records distribute the public key, while the private key remains on the server. When the client requests validation, DNSSEC adds data to the response that enables the client to authenticate the response.

The following table describes the additional resource records used with DNSSEC.

Resource record Purpose
RRSIG Holds a signature for a set of DNS records. DNS clients can use it to check the authority of a response. When a resource record is resolved, a Resource Record Signature (RRSIG) record is sent for verification.
DNSKEY Publishes the public keys for the zone. It allows clients to validate signatures created by the private key held by the DNS server.
NSEC When the DNS response has no data to provide to the client, the Next Secure (NSEC) record authenticates that the host does not exist.
NSEC3 A hashed version of the NSEC record, which prevents attacks by enumerating the zone.
DS A delegation record that contains the hash of the public key of a child zone. This record is signed by the parent zone’s private key. If a child zone of a signed parent is also signed, you must manually add the Delegation Signer (DS) records from the child to the parent to create a chain of trust.

Sign the DNS zone

A screenshot of the DNS Manager console. The administrator has selected the zone, and is launching the DNSSEC Zone Signing Wizard.

Windows Server includes the Zone Signing Wizard in DNS manager to simplify the configuration and signing process, and to enable online signing. The wizard allows you to choose the zone-signing parameters. If you choose to configure the zone-signing settings rather than use parameters from an existing zone or use default values, you can use the wizard to configure settings such as the following:

  • Key Signing Key options.
  • Zone Signing Key options.
  • Trust anchor distribution options.
  • Signing and polling parameters.

A screenshot of the Key Signing Key (KSK) page in the Zone Signing Wizard.

Trust anchors distribution

A trust anchor is an authoritative entity that is represented by a public key. The TrustAnchors zone stores preconfigured public keys that are associated with a specific zone. In DNS, the trust anchor is the DNSKEY or DS resource record. Client computers use these records to build trust chains. You must configure a trust anchor from the zone on every domain DNS server to validate responses from that signed zone. All DNS servers hosting a zone need to have the same DNSKEY key records to provide the information required to validate the RRSIG records.

Name Resolution Policy Table

The NRPT contains rules that control the DNS client behavior for sending DNS queries and processing the responses from those queries. For example, a DNSSEC rule prompts the client computer to check for validation of the response for a particular DNS domain suffix. As a best practice, Group Policy is the preferred method of configuring the NRPT. If no NRPT is present, the client computer accepts responses without validating them.

Review or change settings

After you've completed zone signing, you can review or change the settings by using this procedure:

  1. In DNS Manager, right-click or activate the context menu for zone, select DNSSEC, and then select Properties.
  2. Use the DNSSEC properties for zonename zone dialog box to review and edit the settings.
  3. Select OK when done.

A screenshot of the DNSSEC properties for zone dialog box. The administrator has selected the Key Master tab.


The following video demonstrates how to configure DNSSEC in Windows Server DNS using the DNS console. The main steps in the process are:

  1. Open Server Manager, and then open DNS Manager.
  2. Locate the appropriate forward lookup zone, right-click the zone or activate its context menu, select DNSSEC, and then select Sign the Zone.
  3. Use the Zone Signing Wizard to complete the process.
  4. In DNS Manager, expand Trust Points. Ensure that the DNSKEY resource records exist and that their status is valid.
  5. Open Group Policy Management.
  6. Open a suitable GPO for editing.
  7. In the Group Policy Management Editor, under Computer Configuration, navigate to Policies > Windows Settings > Name Resolution Policy.
  8. In the Create Rules section, in the Suffix text box, enter the appropriate domain suffix.
  9. Select Enable DNSSEC in this rule, select the Require DNS clients to check that the name and address data has been validated by the DNS server, and then select Create.

Quick review


After establishing DNSSEC for, where do the DNSKEY trust records reside in the DNS hierarchy?