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.
In the advanced tab in the server properties you have the "Disable recursion" option. Select this option.
DnsCmd.exe <Servername> /Config /NoRecursion 1
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.
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.
NSEC or NSEC3
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.
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
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.
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.
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.
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.
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 example.net DS 16389 7 1 07F5FF12568D815B7D78741EA635E42D7339E265
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.
DnsCmd.exe <Servername> /Config /enablednssec 1
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 f.root-servers.net.
. 86400 IN NS c.root-servers.net.
. 86400 IN NS j.root-servers.net.
. 86400 IN NS d.root-servers.net.
. 86400 IN NS g.root-servers.net.
. 86400 IN NS l.root-servers.net.
. 86400 IN NS e.root-servers.net.
. 86400 IN NS b.root-servers.net.
. 86400 IN NS m.root-servers.net.
. 86400 IN NS h.root-servers.net.
. 86400 IN NS i.root-servers.net.
. 86400 IN NS a.root-servers.net.
. 86400 IN NS k.root-servers.net.
. 86400 IN RRSIG NS 8 0 518400 20130421000000 20130413230000 20580 . MLGI2vO6PUzXf7QNqmjyjj5QD8LMmWJkEL257Lkak1dBeX8VVqvt/3By yNrs7bb2PvSXbEum3OvqCFxRVD6D01bOQsFXQni/bnyJ6bd/m/ubc7qF 1GGEsF+NnkLOPb3zuslRK3kQCiz9EZIdz5Lqlwz2fsHlmlL65QEgXAbC fE4=
;; ADDITIONAL SECTION:
f.root-servers.net. 86400 IN A 22.214.171.124
f.root-servers.net. 86400 IN AAAA 2001:500:2f::f
c.root-servers.net. 86400 IN A 126.96.36.199
j.root-servers.net. 86400 IN A 188.8.131.52
j.root-servers.net. 86400 IN AAAA 2001:503:c27::2:30
d.root-servers.net. 86400 IN A 184.108.40.206
d.root-servers.net. 86400 IN AAAA 2001:500:2d::d
g.root-servers.net. 86400 IN A 220.127.116.11
l.root-servers.net. 86400 IN A 18.104.22.168
l.root-servers.net. 86400 IN AAAA 2001:500:3::42
e.root-servers.net. 86400 IN A 22.214.171.124
b.root-servers.net. 86400 IN A 126.96.36.199
m.root-servers.net. 86400 IN A 188.8.131.52
m.root-servers.net. 86400 IN AAAA 2001:dc3::35
h.root-servers.net. 86400 IN A 184.108.40.206
h.root-servers.net. 86400 IN AAAA 2001:500:1::803f:235
i.root-servers.net. 86400 IN A 220.127.116.11
i.root-servers.net. 86400 IN AAAA 2001:7fe::53
a.root-servers.net. 86400 IN A 18.104.22.168
a.root-servers.net. 86400 IN AAAA 2001:503:ba3e::2:30
k.root-servers.net. 86400 IN A 22.214.171.124
k.root-servers.net. 86400 IN AAAA 2001:7fd::1
;; Query time: 124 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Apr 14 12:01:36 2013
;; MSG SIZE rcvd: 871
As you can see from the answer, the ad flag is set for Authenticated Data. You now have a working authenticating DNSSEC resolver.
DNS Servers as weapons?
The usually stealth DNS was in the news recently when some very worrisome news surfaced last week. A feud between an anti-spam organisation (Spamhaus) and a hosting site that is accused of offering spam senders a safe haven has escalated, and the criminals used DNS and BGP to attack Spamhaus.
The press picked the story up from Cloudfare, and while the Internet was not at risk, as some wrote, the attack was big enough to bring down servers on the Internet and even single networks. That is a scary thought, especially as any one of us could be a victim of such attacks in the future. Many organizations today cannot survive very long without Internet, and once you are under attack even by just one individual, it might be difficult and expensive in terms of time and money to mitigate these attacks.
While not all parts of the recent attacks were caused by DNS, the larger part of the denial of service attack was. Experts have known about these kind of attacks (known as "DNS reflection" and "DNS amplification" attacks), and also the solutions for years. But many DNS administrators are not aware of the problem, or have not made it a priority to prevent their DNS servers from being used as a weapon for criminals. Many are running outdated DNS server software or a DNS server that is unknowingly configured to be a weapon in such attacks. The US-Cert (Computer Emergency Response Team) was prompted by the recent attacks to issue instructions on how to secure a DNS server.
How to secure your DNS server
Having your DNS server "open" doesn't only put other users of the Internet at risk, but also eats away your own resources. You network gets more saturated and your DNS service will be slowed down when your DNS server is misused for attacks. It only takes a minute to secure your DNS server so that it cannot be used as a weapon in Denial of Service attacks, and here's how:
* close down open DNS resolvers
* implement BCP38 or ask your upstream provider to implement it
* deploy DNS Response Rate Limiting on authoritative DNS Servers
* monitor your DNS servers to detect attacks
Men & Mice Webinar
"The dangers of DNS reflection attacks (and how to mitigate them)"
To help you with the task, Men & Mice is offering a FREE 1 hour WEBINAR.
This webinar will explain the nature of DNS reflection attacks and what DNS operators on Unix (BIND DNS) and Windows (Microsoft DNS) can do to prevent their DNS servers to be used as weapons in DNS reflection attacks.
The first Release Candidate of the new DNS and DHCP server from ISC, BIND 10 (http://bind10.isc.org) was released on February 15, 2013.
Men & Mice is monitoring and supporting the BIND 10 development, and as part of that, our engineers sometimes create little helpful tools to share with the community.
TSIG is short for Transaction Signatures, defined in RFC 2845 "Secret Key Transaction Authentication for DNS (TSIG)". TSIG is primarily used to authenticate DNS zone transfer between DNS servers, and to secure dynamic DNS updates.
BIND 10 supports TSIG for both zone transfer and dynamic updates, but it does not contain a tool to create the TSIG keys. While it is possible to use the tools from BIND 9 (https://www.isc.org/wordpress/software/bind/) or ldns (ldns-keygen, http://www.nlnetlabs.nl/projects/ldns/), installing these tools along with BIND 10 might be too much overhead.
Men & Mice engineers have written a small tool in Python called b10-gentsigkey.py (https://github.com/menandmice/b10-gentsigkey).
The tool creates by default an HMAC-MD5 key with 128bits size and prints the key on the screen:
# b10-gentsigkey.py example.com
Usage: b10-gentsigkey.py [--help | options] name
-h, --help show this help message and exit
-a ALGORITHM, --algorithm=ALGORITHM
algorithm for the TSIG key
-b SIZE, --bytes=SIZE
size of the key
-f print bindctl CLI command
b10-gentsigkey supports all the TSIG algorithms that are also supported by BIND 10 ('hmac-md5', 'hmac-sha1', 'hmac-sha224', 'hmac-sha256', 'hmac-sha384', 'hmac-sha512').
Using the "-f" (Format) switch, the tool will print the bindctl command to enter the TSIG key into the BIND 10 configuration. That command can be copy-n-paste into the bindctl command line:
# b10-gentsigkey.py -a hmac-sha256 -b 256 -f example.de
config add tsig_keys/keys "example.de:M2nrsQWVEAuAfm67U2Gdfj2dFfJIPay9ZFMukXSSCiY=:hmac-sha256"
this output can be directly piped into bindctl:
# b10-gentsigkey.py -a hmac-sha1 -b 256 -f example.com | bindctl
We hope to bring a similar command into the BIND 10 CLI (bindctl), so that no external tool is required to create TSIG keys by an external tool.
Until then, enjoy this little tool.
If you are interested in learning more about BIND 10, Men & Mice is working close with ISC to deliver the first industry training on this new version of the BIND name server software in Amsterdam, Netherlands from February 20th - 21st, 2013. You can learn more about it from the Men & Mice BIND 10 workshop page.
BIND 10 is the next generation of BIND, the most widely-used DNS server on the Internet. It is modular server that includes an authoritative DNS server, a recursive DNS server, a DNSSEC signer and a DHCP server for IPv4 and IPv6. BIND 10 first production release to be expected in 2013.
Additional information on BIND 10 can be found on the BIND 10 project website http://bind10.isc.org.
Men & Mice is working close with ISC to deliver the first industry training on this new version of the BIND name server software in Amsterdam, Netherlands from February 20th - 21st, 2013.
This is a classroom-style course with lecture and hands-on labs.
The students will learn how to:
- install BIND 10 from source or from packages
- configure BIND 10 as an authoritative DNS Server, a DHCP server and automate DNS and DHCP data provisioning using the BIND 10 management toolset.
The class is geared towards sysadmins and network administrators with basic knowledge on DNS.
Knowledge on BIND 9 is not required.
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.
Learn more about Windows 2012 and DNSSEC. Examine DNSSEC signing with Windows 2012 (GUI & CLI).
Register for the Webinars below at a date and time convenient for you.
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 firstname.lastname@example.org
From all of us here at Men & Mice, merry christmas and a happy new year.
May the holiday season fill your home with joy, your heart with love and your life with laughter.
Men & Mice staff
Why not visit Men & Mice, have a beer or two and get to know the fun side of us before seeing some of the world’s most exciting artists performing. We're going be attending Iceland Airwaves 2012!
If you aren’t one of the lucky ones that were able to purchase the festival pass before they sold out, don’t be discouraged. You can visit 450 off-venue shows located throughout Reykjavik, for free.
For those that haven’t heard about the premium annual showcases for new music – both Icelandic and otherwise, can read all about it here.
For those that are coming to our little Rockland, don’t be shy, drop us an e-mail and let us know when you want to visit us at the Men & Mice headquarters, we'll of course play Of Monsters and Men!
Men & Mice is pleased to announce the relocation of its office to Kopavogur, Iceland. To support our growth as well as to improve our working environment we have moved the company's head office to a new premises.
As of September 1st, 2012 onwards, our office will be located at the following address:
Men & Mice
Come visit, we'd love to see you.