The Men & Mice Blog

Men & Mice Suite Version 6.8 Released

Posted by Men & Mice on 4/28/15 7:49 AM

Reykjavik, Iceland, April 28th 2015 - Men & Mice announces the release of version 6.8 of the Men & Mice Suite.

The Men & Mice Suite is the ideal tool for network managers who desire minimal daily management, featuring planning, reporting, and auditing of growing dynamic IP networks, with the added benefit of delivering improved network security as well. The Men & Mice Suite version 6.8 can be deployed as a software solution on top of existing DNS/DHCP servers or as hardened DNS/DHCP virtual appliances.

Subnet Discovery and Ease of Use

Version 6.8 introduces several new features designed to streamline both initial deployment of the Men & Mice Suite, and day-to-day management of enterprise networks by way of automatic discovery and intuitive user interface improvements.

The new Subnet Discovery feature allows the Men & Mice Suite to directly query network routers for subnet information, making it far easier to add new subnets, and reducing administration time by eliminating the need for tedious manual input of new subnets. Meanwhile, the First Use Wizard allows new users to rapidly gain complete control over their networks by automating DNS/DHCP server and Active Directory Subnet discovery, and intelligently guiding administrators through the initial setup process.

Enhanced System Support

The Unbound Caching DNS Server now enjoys the same management utility as the Men & Mice Virtual Caching Appliance in the Men & Mice Suite, and can be simply added to the Men & Mice Suite Management Console like any other supported DNS server. With version 6.8 the Men & Mice Suite now also features native support for 64-bit Linux systems, and support for systemd integration on Linux installers.

Other Improvements

Version 6.8 also improves other aspects of the suite, featuring enhanced Windows DNSSEC support, improved failover handling on Microsoft DHCP servers, and a number of performance improvements to both the Men & Mice Suite and the Men & Mice Virtual Appliance products.

For a complete list of new features and enhancements:
Release notes on version 6.8.


Men & Mice Suite version 6.8 Free Trial


Topics: Men & Mice Suite, DDI, DNSSEC, IPAM, DHCP, Windows, Unbound

End-to-End DNSSEC using Unbound DNS

Posted by Patrick Piper on 5/18/10 7:42 AM

End to end DNSSECGiven all the hoopla surrounding the topic of DNSSEC, it's definitely time to get prepared for it.  After all, the last of the root name servers ( J-ROOT ) will all be serving a Deliberately Unvalidatable Root Zone or (DURZ) by May 5th

On July 1st however, there will be distribution of a validatable, production, signed root zone. Signing of the root zone is key for creating the "chain of trust" or a secure delegation hierarchy.   DNSSEC securely signed zones vouch for their children's keys, but some higher level entity must vouch for the keys of these zones.  The signing of the root will act as a trust anchor for top-level domains such as .com, .edu, etc.  These zones will trust on down the hierarchy when configured to do so. 

Please see for details on the DNSSEC Signing of the root name servers.  In the last article, we discussed 10 reasons to use the Unbound DNS Server.  One of Unbound's main capabilities is its ability to perform DNSSEC validation.  So, we thought we'd write an article explaining how you can setup the Unbound DNS server to perform DNSSEC validation as part of an end-to-end example of how DNSSEC works.

Installing Unbound DNS

For the purposes of this exercise, we installed Unbound on the Fedora 12 distribution.  A minimal install of the base 200 packages or RPMs was performed. Given the option of installing from source code or pre-built binaries, we opted to install from source to ensure the latest version of Unbound DNS software was used.  The following prerequisites were required for building Unbound:

yum install subversion
yum install libevent libevent-devel
yum install openssl openssl-devel
yum install gcc make

Linux package names and their versions will vary between different Linux distributions, so you should consult your distribution’s package repositories and documentation prior to preparing to configure, build, and install Unbound.

Following the installation of the above dependencies, build Unbound from source as follows:

svn co unbound
cd unbound
./configure && make && make install

Once Unbound is configured, built and installed from source, enable the remote management component. A set of self-signed SSL keys are installed into the /usr/local/etc/unbound directory that will allow us to control the Unbound DNS server.  This is performed using the unbound-control-setup as shown:

# unbound-control-setup
setup in directory /usr/local/etc/unbound
generating unbound_server.key
Generating RSA private key, 1536 bit long modulus
e is 65537 (0x10001)
generating unbound_control.key
Generating RSA private key, 1536 bit long modulus
e is 65537 (0x10001)
create unbound_server.pem (self signed certificate)
create unbound_control.pem (signed client certificate)
Signature ok
Getting CA Private Key
Setup success. Certificates created. Enable in unbound.conf file to use

For the purposes of this demonstration, we chose to install from source code.  Production servers should never have development libraries, compilers, and build tools installed, so it's strongly recommended that you do not build software on the same systems that are targeted for production.

Configuring Unbound

We'll start by using a minimal configuration of Unbound which launches unbound in a chroot owned and run as the user unbound:unbound.  The following is a basic configuration for setting up the Unbound DNS server:


        verbosity: 1
        access-control: allow
        chroot: "/usr/local/etc/unbound"
        username: "unbound"
        directory: "/usr/local/etc/unbound"
        pidfile: "/usr/local/etc/unbound/"
        root-hints: "root-hints.txt"


        control-enable: yes
        control-port: 953
        server-key-file: "/usr/local/etc/unbound/unbound_server.key"
        control-cert file:"/usr/local/etc/unbound/unbound_control.pem"

In our configuration we specify the interface directive to bind the DNS service to the loopback and primary Ethernet (eth0) interface on our system. The access-control directive configures an Access Control List of sorts by defining and allowing an address range to query our name server with recursive queries.

NOTE: it is also important to ensure that if you are running iptables, that you include udp/53 and tcp/53 inbound rules so that remote client workstations can query the name server. In writing this blog, we ended up adding the following rules to /etc/sysconfig/iptables:
-A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT

While it is true that you can run the Unbound DNS server without having to configure the root-hints, we will use this directive in the server section because we want to force our server to use special DNSSEC Demo root name servers operated by IANA which have a signed copy of the root zone. Create the root-hints.txt file in /usr/local/etc/unbound and populate it by using the data from the following link: Make sure it is owned by the unbound:unbound user.

Enabling DNSSEC In Unbound

There are numerous ways to configure and enable DNSSEC validation in Unbound:

1. Use trust-anchor to directly embed DS and/or DNSKEY records in the unbound.conf file
2. Use trust-anchor-file for supplying large numbers of DS and/or DNSKEY records using include or trust anchor files
3. Use auto-trust-anchor-file to specify RFC 5011 style auto-updatable trust anchor files for specific zone(s)
4. Use trusted-keys-file directive for supporting a Bind 9 style formatted trusted-keys block
5. Use dlv-anchor-file to specify DS and/or DNSKEY records for DNSSEC Lookaside Validation or DLV (

Since this is an introduction to end-to-end testing, we demonstrate how to enable DNSSEC validation using the auto-trust-anchor-file directive in the server block of the configuration. For production installations of Unbound, it is highly recommended to either use RFC 5011 style auto-update of trust anchors (supported by the auto-trust-anchor-file directive), or to use DLV ( as mentioned above.

To configure the Unbound server with the auto-trust-anchor-file, create one (1) trust anchor file per zone, and populate that trust anchor file with only those DS or DNSKEY records that are associated with that zone. Make sure that the key material is up to date and is valid before you begin. Start by creating the file /usr/local/etc/unbound/root-ta.txt, and populate it with the DS record set found at  Next, create the file /usr/local/etc/unbound/arpa-ta.txt, and populate it with the DS record set found at Ensure that both of these files are owned by the unbound user with read/write permissions.

Additional details about the IANA Demo DNSSEC environment and key material can be found at

Our final Unbound configuration should look like this when using the DS record format for the trusted-key directive:


        verbosity: 1
        access-control: allow
        chroot: "/usr/local/etc/unbound"
        username: "unbound"
        directory: "/usr/local/etc/unbound"
        pidfile: "/usr/local/etc/unbound/"
        root-hints: "root-hints.txt"
        auto-trust-anchor-file: "root-ta.txt"
        auto-trust-anchor-file: "arpa-ta.txt"


        control-enable: yes
        control-port: 953
        server-key-file: "/usr/local/etc/unbound/unbound_server.key"
        server-cert-file: "/usr/local/etc/unbound/unbound_server.pem"
        control-key-file: "/usr/local/etc/unbound/unbound_control.key"
        control-cert-file: "/usr/local/etc/unbound/unbound_control.pem"

The contents of the /usr/local/etc/unbound/root-ta.txt file should appear like the following

IN DS 25546 5 1 EB79CCBB73DF86E527F2BD7DEDCBE083F6024E62 
IN DS 25546 5 2 8C820F26C36215C94DC1797AB44E9E9C04B8FCA49CCC6E72BE26DCF2 BA3A7F42
IN DS 28567 5 1 1C625C7017299CEF715E19F62D5E210EA6E96D9D
IN DS 28567 5 2 9610F9726A508AE8AC3B8D07887DFB5EC09804FF7B159A7352AB84A6 B468B08C

The contents of the /usr/local/etc/unbound/arpa-ta.txt file should appear like the following:

arpa. IN DS 13589 5 1 5FCEEA550A000E2EE9F1365ACC9A7D12A95E3679
arpa. IN DS 13589 5 2 1866807648777CACAE3D0006C2CEABFDBA9CBCC664DB739E615E7BEA 35197DD7
arpa. IN DS 46793 5 1 DCED635B6D0033D3AEC4D9A9A23F28EE38273A01
arpa. IN DS 46793 5 2 1BA7AADC6E73DC2CFBFA252393EDFB387768FF180A68C3D52B8A48A4 1E86787A

Operating the Unbound DNS Server

At this point, we should be able to start the Unbound recursive, caching, and validating name server. To start the server, run the following command:

unbound-control start

To check that the server has started and get its status:

unbound-control status

To stop the running Unbound DNS server:

unbound-control stop

A handy utility called unbound-host is provided that uses the libunbound library just as our Unbound DNS server does to test resolution and validation. It requires the -C command line argument enabling it to use the same unbound.conf file as the server uses.  Let's check to see if we're getting successful resolution and DNSSEC validation:

#  unbound-host -C /etc/unbound/unbound.conf -v[1272999684] libunbound[12835:0] notice: init module 0: validator[1272999684] libunbound[12835:0] notice: init module 1: iterator has address (secure) has IPv6 address 2001:1488:0:3::2 (secure) has no mail handler record (secure)

Alternatively, we could issue queries to our Unbound Server using dig with the +dnssec option and check the response from our Unbound Server.  If the response from Unbound returns AD in the flags section of the reply message, we have established that the data was authentic.  If you achieve these same results, then you've successfully configured a recursive validating server with Unbound! Congratulations.

End-to-End DNSSEC Validation

To complete an end-to-end test of DNSSEC validation, we thought we'd recommend using the Mozilla Firefox browser, along with a DNSSEC validation Add-on to demonstrate how DNSSEC validation will be supported in the future. We installed the DNSSEC Validator version 0.15.1alpha using the latest version of the Mozilla Firefox browser. You can obtain the add-on by navigating to There is a link to perform the installation on that page. Once installed, modify the Validator's Preferences.

End to end DNSSEC

Modify the settings so that the Resolver used by the Add-on is defined using the IP address of our Unbound DNS validating resolver.  In our example, we show the add-on to be configured with, the IP address we assigned to our Unbound server.  Click OK and save the configuration.
Test the following URLS in the table shown below.  You should get the same Indicator as shown for each of the URLs.  The indicator will appear immediately to the left of the URL in the URL/Address entry field.

DNSSEC validator









The domain name is secure using DNSSEC technology and the integrity of the DNS Response has not been breached during transmission.  The browser uses IP addresses that have been validated by DNSSEC Validator using DNSSEC and are trusted.     DNSSEC indicator

The domain name is secured with DNSSEC technology, but the DNS server resolver used cannot verify the signature validity.     DNSSEC WARNING! The domain name is secured by DNSSEC technology but the IP addresses to which your browser is connecting have been changed, or the DNSSEC signature validity was broken. The IP address could have been changed during transmission to your computer by an unknown attacker, or it may be a local settings conflict on your computer.

These are just a few URLs to get you started, with known results.  Safely surf the web now, and try some of your old Internet haunts.  See who's signing and who's not.  See who has been potentially compromised, and whose zone(s) are invalid or improperly signed. 

This blog entry was written to demonstrate how DNSSEC works end-to-end using the Unbound DNS Server to provide recursive caching and validating DNS service.  Come July 1st, the production root name servers on the Internet will be fully signed, and the next big phase of DNSSEC will begin, the Adoption Phase.  It is during this cycle of DNSSEC rollout that the TLDs like .com and .edu will be signed. Additionally, we'll begin to see more and more ISPs offering DNSSEC signing for customers to have their own zones signed. 
Widespread adoption will require more add-ons like the one we demonstrated in the latter part of the article, as well as, having more tools, applications, and operating systems with built-in DNSSEC validators. If you haven't worked with Unbound, we urge you to do so. 
Unbound is very lightweight, high-performing, and easy to configure.  It brings software diversity to the DNS monoculture that has been primarily owned by the ISC's BIND software.  Every ISP and/or Enterprise should consider incorporating Unbound into future deployments of DNS serving software and especially when DNSSEC widespread adoption takes hold.

Men & Mice is now offering enterprise grade support for the Unbound DNS Server.

Take a look at the Men & Mice Unbound Support Contracts

Topics: Unbound, DNSSEC

10 Reasons to use Unbound DNS

Posted by Patrick H. Piper on 3/29/10 11:01 AM

UnboundUnbound is a validating, recursive, and caching DNS resolver.
Unbound is developed and currently maintained by NLnet Labs, a non-profit, public benefit foundation.
It is based on the ideas and algorithms taken from a Java prototype developed by Verisign Labs, Nominet, Kirei, and
Unbound was released to the public in May 2008 under the BSD Licensing model which allows its use in other products without any major restrictions.

In this article, we'll discuss ten (10) reasons to use Unbound as a validating, recursive, and caching DNS service part of your Core Network Services (CNS) Infrastructure.

  1. Lightweight - Unbound was originally developed in C based from a Java prototype. Its authors wrote the source code to be very modular in design, and to be very lightweight.  They wanted to design a solution that would be the smallest possible that would achieve the minimal requirements as a validator, resolver, and caching server. In addition to meeting these requirements, they wanted the server to achieve very high-performance. Unbound's minimalistic design will be a recurring theme throughout the rest of this article.
  2. Easy to configure - Unbound is very easy to configure. It is configured through a configuration file that is quite like YAML (Yet Another Markup Language).  There are not a great number of configuration directives needed to set up Unbound since the service has a relatively simple and single role.

    Example 1 - minimal configuration for caching-only DNS

    # unbound.conf for a local subnet.
          interface: FD00:2216:9203:2::4
          access-control: allow 
          access-control: ::1 allow
          verbosity: 1

    Example 2 - enabling DNSSEC validation

    # chroot disabled here as example, to make pathnames work
    chroot: ""
    directory: "/etc/unbound"

          # trust anchors. In separate files, to be updated from cron.
          trust-anchor-file: "/etc/unbound/anchors/root.anchor"
          # ... more trust anchors
          trust-anchor-file: "/etc/unbound/anchors/br.anchor"
          trust-anchor-file: "/etc/unbound/anchors/se.anchor"
          trust-anchor-file: "/etc/unbound/anchors/bg.anchor"
          trust-anchor-file: "/etc/unbound/anchors/pr.anchor"

    As you can see, it's quite easy to set up and configure Unbound.

  3. High performance - Unbound's lightweight code structure, simple and modular design contribute to making Unbound an extremely high-performing recursive name server. Initial benchmark testing has shown Unbound to offer up to 2x the performance over other name servers (with or without DNSSEC Validation enabled).  Unbound essentially has two (2) modes of operation:

    Threaded mode - uses the Libevent cross compiled wrapper library for added scalability
    Forked mode - allows Unbound to operate unthreaded and forks separate processes

  4. Supports DNSSEC validation - Unbound was designed to perform DNSSEC validation, a mechanism to protect DNS data, from the ground up. DNSSEC validation is not implemented as a plug-in or bolt-on like some other DNS servers. It was designed integral to Unbound at its inception. This makes Unbound a higher performing solution than the others, because validation code was optimized in Unbound. Additional features for trust anchor management (RFC 5011) are in the works and that will only serve to enhance an already great product.
  5. Adds software diversity - Enterprise customers and ISPs can now introduce a proven and reliable alternative to BIND for providing a validating, recursive, caching-only layer of DNS servers with Unbound. Unbound introduces software diversity to the masses.  BIND DNS is at the center of what has been termed a "monoculture".  Software diversity is good for the Internet, and it's good for the ISP and Enterprise too.  Software and code diversity allow us to mix different DNS vendor solutions to provide the same or better service.  A bug in one vendor's product will not likely be visible in the others.
  6. Production-Ready - announced back in September 2009 that all SURFnet DNS resolvers were DNSSEC capable. Their implementation of DNSSEC validation relied on the Unbound DNS server package.  Other major carriers and ISPs ( I cannot name for obvious reasons ), are about to deploy Unbound probably for all the same reasons stated in this blog post.  If major carriers are starting to put Unbound into service for their customers, it makes sense that it's ready for the enterprise as well.
  7. Single-purpose - Because Unbound was coded to be a validating, recursive, and caching resolver, it doesn't suffer from split- or dual personalities that DNS server solutions do.  Unbound is, for the most part, a single-purpose server. Since Unbound is not authoritative for data, the code and function becomes simplified.  There is no code to support Dynamic DNS updates, or zone transfers, etc. Instead, this single purpose server is best-in-class at what it was coded to support: recursion, validation, and caching resolution.
  8. Security - Unbound has not skimped on DNS Security at the expense of simplicity and performance.  On the contrary. Unbound is feature-rich with DNS Security with its harden-glue, access control, max randomness for query ID and ports, response scrubbing, case preservation, and Denial of Service or DoS protection features.  These are just some of the features that make Unbound one of the most secure DNS server implementations.
  9. Manageability - Unbound has an extended management command line interface or CLI that provides remote management capabilities, as well as, an extensive set of network monitoring statistics. Unbound-control uses a secure connection from the client to the server running Unbound using Secure Sockets Layer or SSL.  Commands are sent from the client and responses from the server are displayed as output.  An additional CLI called, unbound-control-setup, is provided to assist in the OpenSSL shared keys and configuration directives for getting unbound-control operational.  The statistics output can be used to "feed" known capacity planning tools such as Munin, or Cacti for graphing many of the different baseline and extended statistics that Unbound tracks.
  10. Portable solution - Unbound has been ported to run on a wide range of hardware OS platforms, including Linux, BSD, Solaris SPARC and X86, MacOS/X, and Windows.  Windows 32-bit pre-compiled binary packages are available directly from NLnet Labs, or you can download the source package and compile it yourself.

Get help from Men & Mice

Men & Mice offer Unbound DNS Support contracts that cover issues, such as;

  • installation, maintenance, updates, configuration, logging, troubleshooting and generic DNS questions and DNSSEC.

Get your quote for Unbound support here


Topics: Unbound