Men & Mice, a leading provider of DNS, DHCP and IP Address Management (IPAM) solutions, announces the release of the Men & Mice Suite version 6.5.
The new release focuses on providing operational security and the ability to expand customer infrastructure.
Traditionally the Men & Mice Suite has been deployed as an overlay management solution for core DNS and DHCP services. As more customers become reliant on the Men & Mice Suite for the automation and control of their critical network infrastructure, any potential downtime can affect provisioning systems and other automated processes that must operate without interruption. To address the need for this absolute reliability, version 6.5 of the Men & Mice Suite comes with even more complete High Availability functionality.
Cloud environments have become an important part of the enterprise network, and traditionally the visibility into the DDI component of the cloud has been limited. Version 6.5 of the Men & Mice Suite now enables customers to manage core infrastructure services in the OpenStack cloud environment as seamlessly and easily as they manage their internal networks.
Version 6.5 of the Men & Mice Suite enables customers to configure and run Men & Mice Suite (Central) in a HA mode. This means that multiple copies of the Men & Mice Central can be run simultaneously on the network, and at any given time one of them will be the active instance. If an active instance of the Men & Mice Suite fails or is taken down for any reason, one of the other instances will assume the active role. When that happens all clients, whether they be regular user interfaces or script APIs, will automatically fail over to the new Central. With the new HA setup customers can run their critical automation processes without fear of interruption from possible downtime.
Software Defined Networking (SDN) and Cloud stack solutions that act as an IaaS platform are increasingly becoming a common part of the enterprise infrastructure. The Men & Mice Suite version 6.5 contains integration with OpenStack, an open source project for service providers, enterprises, government agencies and academic institutions that want to build public or private clouds. Multiple teams within an organization, each with their own cloud instances and multiple networks and subnets, are faced with the problem of limited visibility into their cloud environment. Men & Mice integrates the software defined networks with the traditional networks that exist in the enterprise environment enabling a global view into every aspect of the network infrastructure. The "good citizen" nature of the Men & Mice Suite continues to be preserved so the OpenStack networks can be created and configured through the Suite but the solution will also adapt to changes done outside of the Men & Mice Suite, either through the Horizon UI or through the OpenStack API.
Additionally, changes to OpenStack networking can be done through the Men & Mice Suite SOAP API, which can utilize the authentication, authorization and activity logging in Men & Mice. The result is gaining the flexibility of a cloud environment while still retaining all the security and control possible through the Men & Mice Suite.
In this new release the documentation and help has been moved from the operational manual format to a web based format. This change will ensure that all users get guaranteed access to the latest version of the help and documentation.
As in previous releases of the Men & Mice Suite, the new version contains various other enhancements that are intended to improve ease-of-use, stability and performance.
By Mr. Carsten Strotmann, one of Men & Mice experts.
BIND 9 and how a security issue demonstrates quality
Recently ISC issued a security warning (CVE-2014-0591) for several BIND versions.
The issue was that BIND 9 detects wrong data while working on NSEC3 records, and because the data is wrong, it opts to terminate itself instead of working with the wrong data (which could expose more serious security issues, esp. when handling DNSSEC data).
Shane Kerr of ISC described this behavior of BIND in the blog post "BIND 9′s Security Record": "The manner in which BIND 9 reacts to software bugs is to terminate. While unpleasant for administrators, the idea is to avoid the system running in an invalid state and causing more damage."
ISC's Michael McNally gave some background information on the security issue on the BIND users mailing list. The security issue has been caused by a change in the fundamental operating system library, the "libc". The implementation of the memcpy function has been changed in a recent update of the glibc library used on Linux systems. This change of implementation has triggered the bug to become visible. So far, the same bug has not been seen on other operating systems, or with other libc implementations. However, that does not mean that these systems are safe, just that the security issue does not show (but might still be there).
I'm happy about how BIND 9 handles this issue (terminating instead of ignoring the issue). This way the administrator notices (one hopes) and updates to a fixed version of BIND 9 and as binary installer packages for RedHat, Debian and Solaris from Men & Mice.
What scares me is all the other software out there (open source or commercial) that might be affected by this bug, but does not have the security net that BIND 9 has.
There could be similar security issues lurking in other software products. Stay vigilant! Monitor your servers.
As developers, we should scan our code for this error pattern (memcpy vs. memmove).
It is in this spirit we say,
simply but sincerely…
Thank you for your business
We wish you a happy holiday season,
and a new year of health,
happiness and prosperity.
Men & Mice staff
Did you know that Men & Mice are serious about your success and eager to share our knowledge with you?
Headquartered in Iceland with locations scattered around the world, Men & Mice is proud to have offices full of extremely intelligent minds that are eager to share their knowledge. The education takes place on our website, at our webinars & trainings, and through various social media channels like Twitter.
We gather interesting industry related knowledge that we read about, and impressive software and online tools that we discover, and then share that information during webinars, on our blog and thru social media. You'll learn what is new, what dangers you should be aware of and, how you can simplify your daily network management tasks.
At Men & Mice the aim is to offer state of the art software and hardware, great service, and last but not least, industry leading education. At the upcoming "DNS fragmentation attacks - the dangers of not validating DNSSEC" webinar in December, the focus will be on why these attacks work, why DNS caching servers that do not do DNSSEC validation are especially vulnerable, why DNSSEC signed zones can be used to launch these attacks, and how IPv6 and/or DNSSEC validation can stop these attacks.
If you have a question about DNS, IPAM, DHCP, DNSSEC, IPv6, or anything really, you can ask our Experts in the Services department.
You might also want to follow us so you don't miss out on what is hot and what is not!
Men & Mice on Twitter
Men & Mice on Facebook
Men & Mice on LinkedIn
Men & Mice on Google+
Men & Mice Webinars
Men & Mice Trainings
Men & Mice is pleased to announce the release of the new Men & Mice DNS/DHCP appliance. This new purpose-built appliance solution is specifically designed to maximize the performance of both hardware and software.
Security is built-in from the ground up, with a lean hardened Linux core that prevents both internal and external threats, including Distributed Denial of Services (DDoS) attacks.
Managed by the best
This new hardened appliance is centrally-managed through the acclaimed Men & Mice Suite, thus further extending the functionality and usability of the Men & Mice DNS, DHCP and IP Address Management solutions.
The Men & Mice Suite is trusted by some of the world's most high-profile organizations to manage their vast global networks. Combined with our new appliance product, we offer an unparalleled feature set that empowers administrators to easily manage complex DDI infrastructures from a single centralized user interface.
Together, our appliance and management solutions offer users the flexibility to build and adapt their network infrastructure as suits their business needs. Unlike other DDI solutions, we do not require our customers to replace their current servers, as our management solutions can be deployed as a management layer on top of the existing DNS/DHCP infrastructure. This enables customers to achieve all the benefits of security and high availability, while still being able to tailor the network to their needs.
Where they make sense, appliances can be added gradually and without the risk of network outages when existing servers are at the end of their lifetime or are difficult to maintain.
The Men & Mice Suite management solution supports industry-standard DNS/DHCP services including Microsoft and Linux, as well as DHCP services deployed on Cisco routers and a hybrid mixture thereof.
Offering secure and reliable DNS/DHCP services that improve the stability of core services while at the same time simplifying the task of managing the fast growing IP infrastructure has clear customer value. Maintaining the environment running the core DNS/DHCP services can be quite time consuming and has inherent security risks. By implementing our appliance-based solution, the task of information gathering, patching, and securing is handled by Men & Mice. Updates are then simple to implement through one source, thereby simplifying administration tasks.
The benefits are obvious: maximized ROI, low cost of ownership and dramatically decreased network risk.
Hardware or Virtual
The Men & Mice DNS/DHCP appliance can be deployed as either a hardware appliance or as a virtual appliance, bringing still greater flexibility to the client. Deployments of the Suite can be a mixture of hardware and/or virtual appliances in conjunction with standard Microsoft, Linux and Cisco core services- all without affecting the ability to manage the entire infrastructure from a single user interface.
Great Value Proposition
Offering competitive pricing, world class 24/7 service and support along with a strong warranty package, our appliances offer great value and ROI.
By Mr. Arno Meulenkamp, one of Men & Mice experts.
Since February 2013, to roughly coincide with the release of version 1.0 of BIND 10, Men & Mice, together with ISC, has been conducting BIND 10 workshops, allowing administrators to get a feel for the new software from ISC. The workshops have been a great success and feedback has been almost unanimously positive. In the workshops, several bug reports have been sent to ISC, with some fixes incorporated in the upcoming 1.2.0 release. In every workshop up to now (we won't guarantee it for future workshops!) we've had actual BIND 10 developers come in and talk about the development and answer questions. The BIND 10 team is very approachable and this has really helped with developing this workshop, but also in getting participants to think about what they need to implement BIND 10 best in their environment.
BIND 10 is a major change from BIND 9, not only in functionality (currently DNS *and* DHCP are supported, with no real limits on other additions later on), but also in configuration (no more named.conf!), flexibility (you only have to load the modules you need and you can relatively simply develop modules for features you miss) and development model (more bazaar than cathedral). In almost all cases, the people that came to the workshops have been impressed and sometimes even excited about the possibilities that BIND 10 will give.
At the same time, it became clear that the expectations of the big "1.0" release were different from reality. Lots of time and effort has been spent by the ISC developers to put a structure in place that is fast and stable and will allow for a scalable and flexible platform. That meant that some areas have gotten more attention than others, and this consequently means that the BIND 10 modules you need might not be feature complete or tested properly to be deployed in a production environment right now. You should make sure the functionality you need is ready or scheduled to be included soon before you create your deployment schedule.
That's not to say that BIND 10 now is not ready, but there are some very rough edges still and the expectations that we see in the workshop are for a much smoother ride. Until that smooth ride is here though, we have the BIND 10 workshop that will give you a look at this exciting new software and allows you to poke and prod and start imagining how this software will fit into your workflow, and what work needs to be done to get BIND 10 to be deployed in your network. You may just find yourself writing code for BIND 10 or sponsor the development of your killer feature.
We hope to see you soon in one of our workshops!
Men & Mice, a leading provider of DNS, DHCP and IP Address Management (IPAM) solutions, announces the release of the Men & Mice Suite version 6.4. The new release of the Men & Mice Suite shows continued commitment to provide a high quality and feature rich DNS, DHCP and IP address management product.
This new version of the Men & Mice Suite expands management flexibility by introducing appliance management, full-spectrum device management and an enhanced feature set which make the system uniquely powerful and flexible.
Management for the Men & Mice DNS/DHCP Appliance
Version 6.4 of the Men & Mice Suite contains management features for the Men & Mice DNS/DHP Appliance, it contains a hardened Linux kernel combined with secure DNS and DHCP servers and is available both as a hardware and a virtual appliance. The appliance manager handles all communications, updates and configuration settings of the new appliance product.
All DNS and DHCP management features of the Men & Mice Suite can be used for the service on the appliances, enabling flexible and secure end-to-end DNS, DHCP and IP infrastructure management from one console. The Men & Mice Suite user can as before manage most industry standard DNS/DHCP services, including Microsoft and Linux as well as DHCP services deployed on Cisco routers and a hybrid mixture thereof. This unique combination offers flexibility in deploying and using these solutions and allows customers to combine the Men & Mice appliance products in hybrid environments with industry standard DNS/DHCP services.
Management of Devices
Subnet utilization history
New Update Manager
A Migrate Zone Wizard has been added
Subnet containers can now be created and used to ease subnet management
Access is now inherited for subnets and scopes
Support for creation and modification of $GENERATE zone statements has been added
It is now possible to view and clear selected DNS Cache entries from BIND DNS servers and the DNS/DHCP appliances
Various new SOAP commands have been added, further extending the flexible usage of the Men & Mice Suite
As in previous releases of the Men & Mice Suite the new version contains various enhancements and improvements. Many of these improvements have been worked on in cooperation with our current customers to meet their needs.
For further information contact Men & Mice
How does the Internet sort out your request to read this blog article from all the request to look at, such as the newspapers online or videos about cute kittens?
Rules are the answer!
Rules come in the form of acronyms and an IP address in the world of computing. A Protocol is another name for a rule and an Internet Protocol (IP) address is a unique number assigned to every device on the Internet. But how does it all work? Take a look at James May's Q&A on "How the Internet works" to learn more.
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 184.108.40.206
f.root-servers.net. 86400 IN AAAA 2001:500:2f::f
c.root-servers.net. 86400 IN A 220.127.116.11
j.root-servers.net. 86400 IN A 18.104.22.168
j.root-servers.net. 86400 IN AAAA 2001:503:c27::2:30
d.root-servers.net. 86400 IN A 22.214.171.124
d.root-servers.net. 86400 IN AAAA 2001:500:2d::d
g.root-servers.net. 86400 IN A 126.96.36.199
l.root-servers.net. 86400 IN A 188.8.131.52
l.root-servers.net. 86400 IN AAAA 2001:500:3::42
e.root-servers.net. 86400 IN A 184.108.40.206
b.root-servers.net. 86400 IN A 220.127.116.11
m.root-servers.net. 86400 IN A 18.104.22.168
m.root-servers.net. 86400 IN AAAA 2001:dc3::35
h.root-servers.net. 86400 IN A 22.214.171.124
h.root-servers.net. 86400 IN AAAA 2001:500:1::803f:235
i.root-servers.net. 86400 IN A 126.96.36.199
i.root-servers.net. 86400 IN AAAA 2001:7fe::53
a.root-servers.net. 86400 IN A 188.8.131.52
a.root-servers.net. 86400 IN AAAA 2001:503:ba3e::2:30
k.root-servers.net. 86400 IN A 184.108.40.206
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.