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.
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 18.104.22.168 f.root-servers.net. 86400 IN AAAA 2001:500:2f::f c.root-servers.net. 86400 IN A 22.214.171.124 j.root-servers.net. 86400 IN A 126.96.36.199 j.root-servers.net. 86400 IN AAAA 2001:503:c27::2:30 d.root-servers.net. 86400 IN A 188.8.131.52 d.root-servers.net. 86400 IN AAAA 2001:500:2d::d g.root-servers.net. 86400 IN A 184.108.40.206 l.root-servers.net. 86400 IN A 220.127.116.11 l.root-servers.net. 86400 IN AAAA 2001:500:3::42 e.root-servers.net. 86400 IN A 18.104.22.168 b.root-servers.net. 86400 IN A 22.214.171.124 m.root-servers.net. 86400 IN A 126.96.36.199 m.root-servers.net. 86400 IN AAAA 2001:dc3::35 h.root-servers.net. 86400 IN A 188.8.131.52 h.root-servers.net. 86400 IN AAAA 2001:500:1::803f:235 i.root-servers.net. 86400 IN A 184.108.40.206 i.root-servers.net. 86400 IN AAAA 2001:7fe::53 a.root-servers.net. 86400 IN A 220.127.116.11 a.root-servers.net. 86400 IN AAAA 2001:503:ba3e::2:30 k.root-servers.net. 86400 IN A 18.104.22.168 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.