The Men & Mice Blog

Windows 2012 Server: Preparing to sign a DNS zone with DNSSEC

Posted by Men & Mice on 5/7/13 9:45 AM

By Mr. Arno Meulenkamp, one of Men & Mice experts.

Men & Mice will be posting a few blog posts on how to set up and maintain DNSSEC on the Microsoft Windows 2012 Server platform. We assume that you know about DNS and DNS administration on Windows 2012 Server and have at least a minimal knowledge of DNSSEC.

Before you start signing and handing out your Trust Anchor, you will have to make a few choices. Will you use KSK/ZSK or Single-Type? How will you perform Key Rollovers and zone signing? How strong do your keys have to be? How will you store your keys? Do you want to go with NSEC3 or is NSEC more useful in your environment? Will you use your keys as trust anchors or will you (also) have a DS record in your parent zone?

Don't worry if the previous paragraph was filled with acronym overload. Let's go through the steps and choices one by one. Beginning with turning off recursion.

Making Windows 2012 DNS Server Authoritative only

The default state for the DNS server from Microsoft is to be a recursive server. Adding authoritative zones does not switch off the recursive part. Authoritative servers should be reachable for everyone, which means that if the same server also offers recursion, it can also be abused.

BCP 140 provides some recommendations for recursive nameservers and the Windows Firewall allows you to limit the IP addresses that can reach port 53, for DNS. However, Windows 2012 does not allow you to selectively switch recursion on or off for specific ranges of IP addresses, so the safest option is to switch off recursion for authoritative DNS servers. Switching recursion off can be done in three ways, like most configuration options for DNS servers.

DNS manager:

DNS Manager

In the advanced tab in the server properties you have the "Disable recursion" option. Select this option.


  DnsCmd.exe <Servername> /Config /NoRecursion 1  

Windows Powershell:

  Set-DnsServerRecursion -Enable 0 

Key Signing Keys (KSK) and Zone Signing Keys (ZSK) or Single-Type

With DNSSEC, a private key creates a signature over a resource record set (all resource records with the same name, class and type attributes) and stores that signature in a new RRSIG resource record. This can be verified with the related public key that is published in the DNSKEY resource record. In order to be able to have confidence in the keys in DNS, you will need to securely get information about a public key through a channel that is not DNS. People that want to trust your DNS data will trust your key either through the Delegation Signer (DS) record in your parent zone or they get the key directly from you. In both cases, it takes some effort to distribute a new key.

In most cases, it is advisable to use two keys, Zone Signing Keys (ZSK), which are used to sign your entire zone, and Key Signing Keys (KSK), which are used to sign only the DNSKEY resource record set. The KSK will be used to point to by the DS record in your parent zone (most often a TLD) and can also be used as secure entry point for others that want to manually configure a trust point for your DNS data. Unless you know that you will not need the added flexibility of the KSK/ZSK distinction, it is recommended to do it, as it will make regular ZSK rollovers simpler. 

Key strength, Key rollover and Key storage

Windows 2012 Server has the option to have multiple key storage providers. Going through which option is best in different situations is beyond the scope of this post, but it means that you can be more flexible with regards to security requirements for your DNS zone data.

Key Signing Key (KSK)

As you can see in the screenshot, the zone signing wizard asks you not only to specify the regular attributes like key length and crypto algorithm, but it also lets you specify the key storage provider as well as a rollover frequency.

RFC 6781, the current IETF document on DNSSEC Operational Practices mentions that a key length of 1024 bits (for RSA keys) is enough to allow usage of those keys for a long time, even decades. However, for operational purposes it is a good idea to roll over keys more regularly so as to have operational knowledge of rollovers should the need arise to perform an emergency rollover. Windows 2012 Server does not allow keys shorter than 1024 bits, but it does allow you to set a wide range of rollover frequencies, from one week to twenty years.


If you want to be able to trust the DNS resource records, you also need to be able to trust the message that particular data does not exist. DNSSEC solves this with NSEC or NSEC3 records. The short explanation is that with an NSEC record, it lists the resource record types for the name, as well as the name of the next resource record. With this information you can see that the resource record type (for the name you queried) or the resource record name you requested does not exist. NSEC uses the actual resource record names, whereas NSEC3 uses a one-way hash of the name. This way it prevents people from walking your zone data from one record to the next, at the expense of some CPU cycles both on the authoritative server as well as the resolver. Because of the before mentioned amplification attacks, it is a very bad idea to allow zone transfers, but do you mind if people have the contents of your entire zone? If you do not want to give people access to your entire zone file, you should choose NSEC3. Be aware that in order to use NSEC3, you cannot use RSA/SHA-1 as the algorithm of your keys, as some resolvers that understand RSA/SHA-1 might not understand NSEC3. Using RSA/SHA-256 is a safe alternative.

Zone signing wizard

Secure Entry Points (SEP), Trust Anchors and DS records

The last part to look at before you sign your zone is who you want to distribute your key to. It might be necessary for some servers to be configured with your key directly, but, as long as your TLD supports DNSSEC, it will create less overhead during KSK rollovers to only have a DS record at your parent zone.

Ducks in a row

You will be ready to start signing your zone, as soon as you have settled on:

  • the key strength you need
  • how you will store your keys
  • how often you will roll over your keys
  • if you will use NSEC or NSEC3
  • who to distribute your public key to

Zone Signing Wizard

Signing your zone can be done with the simple Zone Signing Wizard, but dnscmd.exe and the powershell have their own advantages. We will go deeper into how to sign in a future post.

Topics: DNSSEC, Windows Server 2012

Why follow Men & Mice?

The Men & Mice blog publishes educational, informational, as well as product-related material for everyone and anyone interested in IP Address Management, DNS, DHCP, IPv6, DNSSEC and more.

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all