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

Windows 2012 Server: Enabling DNSSEC validation

Posted by Men & Mice on 4/16/13 5:52 AM
By Mr. Arno Meulenkamp, one of Men & Mice experts. 

DNS has been a game where only ISC's BIND really played. Even though there were some other options out there, they never got a large market share, they were missing some (new) feature or they simply did not play well with others. Nowadays though, the situation is different. Not only do we have daemons like NSD and Unbound, but others have also paid more attention to current standards and Microsoft is no different. The implementation in Microsoft's Windows Server 2012 is a fully interoperable DNS server, with an up-to-date security implementation, including DNSSEC. DNSSEC in Windows Server 2012 can now also be used for dynamic zones, but only if part of Active Directory.

Management of DNS server hasn’t changed much, but there are three distinct ways. Each has their own advantages/disadvantages and feature set. DNS Manager is a graphical tool which allows you to do most things that administrators need on a daily basis. It’s got an easy overview and wizards for most recurring tasks. It doesn’t let you change more detailed settings though. Dnscmd.exe is still available, a command line utility that will allow you to check and set most DNS settings, including some options not found in the other tools. Microsoft is moving over to the Windows Powershell however, so to be sure that your scripts will use the supported way of configuring the DNS server and you won’t find yourself suddenly no longer supported, you will have to use the DNS cmdlets in the Windows Powershell.

If you use Windows 2012 Server as a recursive DNS server, there is not much to change. Microsoft 2012 Server DNS follows most IETF recommendations, so you don’t have to hunt for obscure options, just enable the features you want. If you do want to go through all the details, you will have to use the Powershell cmdlets, they will give you all the power you want/need.

One option to consider that is not enabled by default is DNSSEC validation. Doing this can of course be done in three different ways, each quite straightforward, although it takes two seperate steps, configuring at least one trust anchor and then enabling DNSSEC validation.

Configuring a Trust Anchor

To add a trust anchor, you can either add the DS record for the zone(s) you want to use as a trust anchor, or you can add the DNSKEY key material itself. Adding multiple trust anchors is no problem, but unfortunately, it is not possible to add lookaside (RFC 5074) zones.

The most obvious trust anchor to add is the one for the root zone. IANA publishes the root zone trust anchor online, along with signatures and certificates to authenticate its authenticity. If you are not sure if the TLD (that your domain zone is a child zone of) is signed, you can find that out on this ICANN page. If your TLD is not listed as having its trust anchor in the root zone, you will have to add your own DS or DNSKEY as a trust anchor as well. Of course, this is also true if you cannot or choose not to publish your trust anchor in your TLDs zone.

After you get the DS-set or DNSKEY-set file(s) for your chosen trust anchor(s), you need to add them.

DNS Manager:

You can choose to import a DS-set or DNSKEY-set file, but you can also directly enter the information, as we show here for the DS record for the root zone. Select Trust Points in the DNS Manager, then add a DS record.


DNS Manager

DNS Manager - New DS trust anchor



Dnscmd.exe has a special shortcut to adding the trust anchors for the DNS Root zone. It will retrieve the DS records for the root zone, add them and enable DNSSEC validation all in one go.

PS C:\Users\Administrator> Dnscmd.exe /RetrieveRootTrustAnchors
Are you sure you want to Retrieve and add root trust anchors (activating DNSSEC validation)? (y/n) y

The root trust anchors were succesfully retrieved and added as DS trust anchors.
They will become effective when the server is able to convert them to DNSKEY
trust anchors during an active refresh.

Command completed successfully.

PS C:\Users\Administrator>

To add a trust anchor for another zone, you can either enter the data for a DNSKEY or, as shown here, for a DS record.

Dnscmd.exe /TrustAnchorAdd DS 16389 7 1 07F5FF12568D815B7D78741EA635E42D7339E265

Windows Powershell:

Add-DnsServerTrustAnchor -Name . -CryptoAlgrithm RsaSha256 -Digest 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 -DigestType Sha256 -KeyTag 19036

Enabling DNSSEC validation

After configuring the trust anchor(s), enabling DNSSEC validation is trivial.

DNS Manager:

DNS Manager   enable DNSSEC validation resized 600


DnsCmd.exe <Servername> /Config /enablednssec 1

Windows Powershell:

Although Microsoft wants to move command line configuration to Powershell cmdlets, it is not currently possible to enable DNSSEC validation through the Powershell.


If you want to test if DNSSEC validation is active and working you cannot use nslookup.exe, as it does not support DNSSEC. Men & Mice put up a page with some tools that can help, but the easiest test would be to use DIG. You can download the zip file for the latest version of BIND from ISC. To use DIG, create an empty directory and copy the files DIG.EXE, DIG.HTML, LIBDNS.DLL, LIBEAY32.DLL, and LIBISC.DLL into it (or put those files in a directory in your path).

If you test with DIG, make sure you do so from the Command Prompt, cmd.exe, and not from the Powershell, as that may give unexpected results. A simple test is to query the nameservers for the root zone.

PS C:\Users\Administrator\Downloads\BIND9.9.2>.\dig.exe +dnssec . ns

; <<>> DiG 9.9.2 <<>> +dnssec . ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40600 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 23 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4000 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 86400 IN NS . 86400 IN NS . 86400 IN NS . 86400 IN NS . 86400 IN NS . 86400 IN NS . 86400 IN NS . 86400 IN NS . 86400 IN NS . 86400 IN NS . 86400 IN NS . 86400 IN NS . 86400 IN NS . 86400 IN RRSIG NS 8 0 518400 20130421000000 20130413230000 20580 . MLGI2vO6PUzXf7QNqmjyjj5QD8LMmWJkEL257Lkak1dBeX8VVqvt/3By yNrs7bb2PvSXbEum3OvqCFxRVD6D01bOQsFXQni/bnyJ6bd/m/ubc7qF 1GGEsF+NnkLOPb3zuslRK3kQCiz9EZIdz5Lqlwz2fsHlmlL65QEgXAbC fE4= ;; ADDITIONAL SECTION: 86400 IN A 86400 IN AAAA 2001:500:2f::f 86400 IN A 86400 IN A 86400 IN AAAA 2001:503:c27::2:30 86400 IN A 86400 IN AAAA 2001:500:2d::d 86400 IN A 86400 IN A 86400 IN AAAA 2001:500:3::42 86400 IN A 86400 IN A 86400 IN A 86400 IN AAAA 2001:dc3::35 86400 IN A 86400 IN AAAA 2001:500:1::803f:235 86400 IN A 86400 IN AAAA 2001:7fe::53 86400 IN A 86400 IN AAAA 2001:503:ba3e::2:30 86400 IN A 86400 IN AAAA 2001:7fd::1 ;; Query time: 124 msec ;; SERVER: ;; WHEN: Sun Apr 14 12:01:36 2013 ;; MSG SIZE rcvd: 871
PS C:\Users\Administrator\Downloads\BIND9.9.2>

As you can see from the answer, the ad flag is set for Authenticated Data. You now have a working authenticating DNSSEC resolver.

Topics: DNSSEC, Windows Server 2012

Join Men & Mice for these FREE Windows 2012/DNSSEC and Windows 2012/DHCP Failover Webinars

Posted by Dagmar Hilmarsdottir on 2/6/13 9:14 AM

Windows 2012 DNSSEC and DHCP Failover Webinars

Are you interested in gaining more knowledge about Microsoft 2012 server?

Men & Mice DDI experts are offering two free Windows 2012 webinars:

  • Windows 2012 DHCP Failover

Learn more about Windows 2012 DHCP Failover Cluster, DHCP Failover Configuration & Demo, Windows 2012 IPAM and IP Address Management Analysis.
  • Windows 2012 and DNSSEC

Learn more about Windows 2012 and DNSSEC. Examine DNSSEC signing with Windows 2012 (GUI & CLI).

Fetch the Webinar video recording and slides here


Windows 2012 Webinars

Topics: DNSSEC, DHCP, Windows Server 2012, DHCP failover

Men & Mice releases version 6.3.5 of the Men & Mice Suite

Posted by Dagmar Hilmarsdottir on 1/28/13 5:40 AM

Men & Mice Suite version 6.3.5 has been released. The Microsoft Windows Server 2012 contains significantly improved DNS and DHCP features, which should benefit many customers running Microsoft environments. The Men & Mice Suite 6.3.5 contains support for the new Windows Server 2012 as well as various other improvements.


  • Support for DNS and DHCP management on Windows Server 2012
  • Support for DNSSEC management on Windows Server 2012
  • Support for DHCP failover on Windows 2012
  • Support for DHCP scope policies on Windows Server 2012


  • Contents of dynamic zones and slave zones are now displayed correctly when the zone exist in multiple views
  • MAC addresses found when performing an IP Address Collection are now displayed in the IP reconciliation and Discovered Devices reports in the Web Interface

  • Verification of input XML in the SOAP API has been improved

  • It is now possible to add the root zone "." through the Create Zone dialog box

  • Parsing for TXT resource records has been improved

  • Scope migration wizard now copies access permissions for scopes

  • ACLs inside allow-update and match-clients statements on BIND servers are now supported

  • A history log entry is now created when a slave zone is created

  • Zone options from AD integrated zones are now read from the preferred server

  • Various performance and stability improvements for large environments

Current owners download of the Men & Mice Suite

Already a owner of the Men & Mice Suite? If so, download the latest version 6.3.5 from here.


Free trial of the Men & Mice Suite

Not yet an owner of the Men & Mice Suite? Go ahead and get a free trial of the Men & Mice Suite.

For further information send an e-mail to

Topics: Men & Mice Suite, DNSSEC, DNS, DHCP, 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