Take your DNSSEC with a grain of salt

Take your DNSSEC with a grain of salt

by Carsten Strotmann 
originally published at DNS Workshop.

DNSSEC has many useful properties. One is called 'Authenticated denial of existence'. This basically means that a DNSSEC validating DNS Server can prove that domain-names and resource records do not exist in the DNS.

But how does NSEC and NSEC3 work. And how to choose good values for NSEC3 salt and iterations?

Authenticated denial of existence

It requires some 'out of the box' thinking to understand how DNSSEC can prove things that do not exist. The solution is to list all the things (DNS Names and Resource Records) that do exist, and secure that list. If that list can be proven, then everything not listed must not exist. This property of DNSSEC prevents an attacker from sending fake negative DNS responses, like 'google.com -> NXDOMAIN', which could be used for denial of service attacks.

This list of things that do exist in a DNS zone is created by the NSEC (or NSEC3) records. These records build a linked-list from every domain name in a DNS zone, listing all resource record types for each name. Lets have a look at an example, the simple DNS zone 'myzone.example.com.'. Here is the plain DNS zone-file, without DNSSEC:

 

myzone.example.com.   3600 IN SOA  dns1.myinfrastructure.org.  hostmaster.myinfrastructure.org. (
              2011123001
              2h
              1h
              1000h
              1h )
myzone.example.com.     3600 IN NS dns1.myinfrastructure.org.
myzone.example.com.     3600 IN NS dns2.myinfrastructure.org.
myzone.example.com.     3600 IN MX 10 mail.myinfrastructure.org.
www.myzone.example.com. 3600 IN A 192.0.2.100
www.myzone.example.com. 3600 IN AAAA 2001:db6:100::80

The zone including the NSEC records will look like this (I'm omitting all RRSIG signature-records and DNSSEC key records here, because the focus is on the NSEC records):

 

myzone.example.com.     3600    IN SOA  dns1.myinfrastructure.org. hostmaster.myinfrastructure.org. (
                                        2011123001 ; serial
                                        7200       ; refresh (2 hours)
                                        3600       ; retry (1 hour)
                                        3600000    ; expire (5 weeks 6 days 16 hours)
                                        3600       ; minimum (1 hour)
                                        )

                        3600    NS      dns1.myinfrastructure.org.
                        3600    NS      dns2.myinfrastructure.org.
                        3600    MX      10 mail.myinfrastructure.org.
                        3600    NSEC    www.myzone.example.com. NS SOA MX NSEC
www.myzone.example.com. 3600    IN A    192.0.2.100
                        3600    AAAA    2001:db6:100::80
                        3600    NSEC    myzone.example.com. A AAAA NSEC

In this simple zone, we have two domain names (myzone.example.com. and www.myzone.example.com.), and each domain name owns one NSEC record, listing all the resource record types that exist for that name, and pointing to the next domain name in the zone (in lexicographical order). The last NSEC record wraps around and points to the very first domain name in the zone.

 

Walking a DNS zone

Using NSEC is relatively simple, but it has a nasty side-effect: it allows anyone to list the zone content by following the linked list of NSEC records. This is called 'zone walking'. The 'ldns' library contains an tool called 'ldns-walk' that can be used to list all records inside a DNSSEC signed zone that uses NSEC:

 

$ ldns-walk paypal.com
paypal.com.     paypal.com. A NS SOA MX TXT RRSIG NSEC DNSKEY TYPE65534 
3pimages.paypal.com. A RRSIG NSEC 
_dmarc.paypal.com. TXT RRSIG NSEC 
ym2._domainkey.paypal.com. TXT RRSIG NSEC 
3rdparty._spf.paypal.com. TXT RRSIG NSEC 
3rdparty1._spf.paypal.com. TXT RRSIG NSEC 
3rdparty2._spf.paypal.com. TXT RRSIG NSEC 
pp._spf.paypal.com. TXT RRSIG NSEC 
_autodiscover._tcp.paypal.com. SRV RRSIG NSEC 
accounts.paypal.com. CNAME RRSIG NSEC 
active-history.paypal.com. A RRSIG NSEC 
active-www.paypal.com. A RRSIG NSEC 
adnormserv.paypal.com. A RRSIG NSEC 
adnormserv-dft.paypal.com. A RRSIG NSEC 
adnormserv-phx.paypal.com. A RRSIG NSEC 
adnormserv-slc-a.paypal.com. A RRSIG NSEC 
adnormserv-slc-b.paypal.com. A RRSIG NSEC 
....

For some DNS zones, this is an issue. The NSEC3 record option in DNSSEC solves this by creating the linked list using hashed domain-names, instead of clear-text domain names.

It is important to know that NSEC3 also enables a new function in DNSSEC, called 'opt-out'. With 'opt-out', it is possible to 'jump-over' (delegation) domain names in a zone where the child zone itself is not DNSSEC signed (it does not increase the security to provide a secure delegation in case the child itself is insecure). Zone administrators can decide to deploy NSEC3 to prevent zone walking, or to use 'opt-out', or both. Top-Level zone administrators choose NSEC3 because of this 'opt-out' function. This needs to be taken into account when looking at the NSEC3 parameters of DNSSEC signed zones.

In this blog post I will look into the NSEC3 parameters that prevent 'zone-walking', and I will not discuss 'opt-out'.

NSEC3 cannot prevent 'zone-walking' entirely, but it can make 'zone-walking' more expensive for the attacker. There are two parameters in NSEC3 that can be set by the administrator of a zone to fine tune the amount of work required on the attacker side to 'walk' a DNSSEC signed zone with NSEC3 records: the salt and the number of iterations.

 

The salt

NSEC3 is using a hashing algorithm to disguise the real DNS domain names used. It is impossible to recreate the original domain names from the hash name. Here is our zone, but now using NSEC3 (again, RRSIG and DNSKEY records have been removed):

 

myzone.example.com.     3600    IN SOA  dns1.myinfrastructure.org. hostmaster.myinfrastructure.org. (
                                        2011123001 ; serial
                                        7200       ; refresh (2 hours)
                                        3600       ; retry (1 hour)
                                        3600000    ; expire (5 weeks 6 days 16 hours)
                                        3600       ; minimum (1 hour)
                                        )
                        3600    NS      dns1.myinfrastructure.org.
                        3600    NS      dns2.myinfrastructure.org.
                        3600    MX      10 mail.myinfrastructure.org.
                        0       NSEC3PARAM 1 0 10 1A2B3C4D5E6F
6HAUGENGIFFS98J25KBEASD720PGAN36.myzone.example.com. 3600 IN NSEC3 1 0 10 1A2B3C4D5E6F (
                          BE61EEUDCS4VQO71L3LFJMRKEL16S534 A AAAA )
www.myzone.example.com. 3600    IN A    192.0.2.100
                        3600    AAAA    2001:db6:100::80
BE61EEUDCS4VQO71L3LFJMRKEL16S534.myzone.example.com. 3600 IN NSEC3 1 0 10 1A2B3C4D5E6F (
                          6HAUGENGIFFS98J25KBEASD720PGAN36 NS SOA MX NSEC3PARAM )

The first NSEC3 record is for the name "www.myzone.example.com.", while the last one is for the zones apex ("myzone.example.com."). The NSEC3 records in a DNSSEC signed zone are not in the proximity of the domain names they are securing (but the list of record types can give a hint).

An attacker needs to create a rainbow table to be able to 'walk' a NSEC3 zone. A rainbow table lists precomputed hashes for common domain names in that zone. The attacker will take the hashed domain names returned in an NSEC3 resource record and will compare the hash with the values in the rainbow table. If the hash matches one entry in the table, the clear text of the domain name is found. The alternative approach would be to brute force try all possible domain names and send queries to the zone. However this approach might be detected if the DNS queries towards the authoritative DNS servers are monitored (and you monitor the queries towards your DNS, do you?).

Using a rainbow table the attacker can first collect all hashed domain names by following the NSEC3 linked-list, and then try to reverse the hashes using the rainbow table in the privacy of his own environment.

The input to the hash is always the full qualified domain name (like 'www.myzone.example.com.'), so the address records pointing to a web-service "www" in two different zones will hash into different hash values. An attacker will need to create a dedicated rainbow table for each DNS zone. But once the table is calculated and working, the attacker can re-use the table for every subsequent scan.

To prevent the re-use (or even the first use of a rainbow table), there is the salt. The salt is a random, hexadecimal string that is appended to the domain name before applying the hash function to the name. The salt in the example above is '1A2B3C4D5E6F' (the last parameter in the NSEC3PARAM record, and the 4th parameter of every NSEC3 record). This salt is appended to the domain name 'www.myzone.example.com.1A2B3C4D5E6F' (but the domain name would be in wire format, and the hash in binary, not hexadecimal!) and then the hash function (today SHA1) is applied. The tool 'ldns-nsec3-hash' can be used to hash a domain name on the command line:

$ ldns-nsec3-hash -t 10 -s 1A2B3C4D5E6F  www.myzone.example.com 
6haugengiffs98j25kbeasd720pgan36.

The salt value is public (it is in the NSEC3PARAM record in the zone, and in every NSEC3 record). It must be public, because a validating DNS server must know the salt value to be able to validate the NSEC3 records coming in a negative DNS answer. Because it is public, attackers can fetch the value from the zone to generate a rainbow-table. Therefore, the salt needs to be changed from time to time.

Whenever the salt is changed in a zone, the attacker needs to throw away any pre-computed rainbow-table for the zone and start re-creating the table from scratch. If the salt is changed in intervals shorter than the time it takes to compute a reasonable large rainbow-table, it makes 'zone walking' impossible.

RFC 5155 that defines the NSEC3 record recommends to change the salt whenever a zone is signed. Because a new salt will change all NSEC3 records, and all RRSIG records for the NSEC3 records, this is quite some overhead for a large zone. The RFC draft 'draft-ietf-dnsop-rfc4641bis-08' recommends to change the salt whenever the zone signing key is rolled (because that triggers re-generation of all signatures anyway).

The salt can be up to 510 hexadecimal characters, but in practice, using 8-16 hexadecimal characters is a good value (32-64 bit). It is recommended to automate the salt generation: whenever a new zone signing key (ZSK) is generated, there should be a new salt generated.

One possible way to generate the salt is to use 16 characters out of the SHA1 hash of the current date and time:

$ date | sha1sum | cut -b 1-16
784d739287d3336

If the salt is generated from a cron script, using the date as the input to the hashing function might be predictable by an attacker. In that case, using 512 byte of randomness can be used as an alternative:

 

$ head -c 512 /dev/random | sha1sum | cut -b 1-16
7ac59a6dd87fa477

It is possible to use NSEC3 without a salt. In the signing command, and in the NSEC3PARAM resource record, an empty salt value is written with a single dash '-' (NSEC3PARAM 1 0 0 -). Not using a salt still protects again basic zone walking, but it allows an attacker to create and re-use a rainbow table. The 'com' gTLD is using an empty salt:

 

$ dig com nsec3param
; <<>> DiG 9.7.3 <<>> com nsec3param
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1835
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;com.                           IN      NSEC3PARAM

;; ANSWER SECTION:
com.                    86400   IN      NSEC3PARAM 1 0 0 -

;; Query time: 154 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 30 14:03:48 2011
;; MSG SIZE  rcvd: 262

 

The iterations

The second parameter important for the NSEC3 hash function is the number of iterations (3rd field in the NSEC3 and NSEC3PARAM records). As computer become more powerful over time, it might be possible to calculate rainbow tables in a short amount of time. The number of iterations in NSEC3 controls how often the result of the first hash operation is hashed again (so even with iterations=0, the domain names are hashed once). By increasing the number if iterations, calculating a rainbow table can be made more expensive. But it also makes sending negative answers more expensive for authoritative DNS servers hosting the zone, as well as validating these answers on the receiver side. The number of iterations must be carfully balanced, a too high number can invite denial-of-service attacks agains the zones authoritative servers.

The current default value for NSEC3 iterations in BIND 9.8 is 10 iterations. the number of iterations is always a compromise between security and CPU usage. The default in the BIND signing tool is a good value for most zones, but every administrator should evaluate if the default is also good for her/his zones.

The number of iterations have a dependency on the size of the smallest zone-signing key in the zone (see RFC 5155, Section 10.3). These are the upper limit values (do not use higher values for the iteration field!):

smallest ZSK Key Size in zone	max possible NSEC3 iterations	recommended by RFC 4641bis
1024	150	100
2048	500	330
4096	2500	1600

NSEC3 records that use too high iteration values will be seen as 'insecure' by a validating DNSSEC resolver! (see RFC 5155, 12.1.4). RFC 4641bis recommends 2/3 of the maximum value. For a 1024 bit ZSK this would be 100 iterations.

 

Conclusion

 

• If you wish to prevent 'zone walking', then sign your zone with NSEC3. If you don't mind (DNS data is public data), use plain NSEC.
• if your domain is a 'important enough target' (whatever that might be), and there is risk that someone creates a rainbow-table for your zone, schedule a change of the NSEC3 salt parameter every time you roll your zone signing key.
• from time to time re-evaluate the number of hash iterations used in your NSEC3 signed zone, based on the advances in computing power that might be available to a potential attacker.

 

References:

 

• SIDN NSEC3 Whitepaper (PDF)
• RFC 5155 'DNS Security (DNSSEC) Hashed Authenticated Denial of Existence'
• RFC 4641bis draft 'DNSSEC Operational Practices, Version 2'
• Minimizing Information Leakage in the DNS (PDF)
• NIST Secure Domain Name System (DNS) Deployment Guide (PDF)
• What values do the others use? Dmitry Kohmanyuk was on a "NSEC3PARAM salt hunt"
• How Rainbow Tables work by Kestas Kuliukas

Thanks to Peter Koch, Alan Clegg and Miek Gieben for valuable input and answering my questions.

Daily work tools

The fourth and final installment on the IPAM Module in the Men & Mice Suite!

Daily work tools

In addition to the mentioned functionality, the Men & Mice Suite IP Address Module brings several helpful tools, which make the daily work much easier:

• Move Device: When a device (e.g. a server) gets a new IP address this functionality helps to accomplish the task with one click. Merely mark the IP address, select ‘Move’ and select the new IP address.

• Search & Update Wizard: This tool allows you to bulk changes or to search for a certain data. Changing e.g. an office number for hundreds of machines can be done in one step.

• Split subnets: With a simple dialog you can split up a base subnet into possible subnets, e.g. a 10.1.2.0/22 into 4 times 724

• Join Subnets: Just by marking the ranges and pressing the Join button will merge the subnets (if possible) into a base subnet, e.g. 4 times /24 into a /22

• Allocation Wizard: Allows an easy allocation of certain number of subnets, e.g. 2 times a /24, which should be allocated underneath a /16. No manual search for free blocks – the allocation wizard takes care of this.

• Find next free address in range: Imagine a partly used IPv4/IPv6 subnet and you need to find a free IP address for a host. With the help of ‘Find the next free address’ –functionality, the Men & Mice Suite will find the next free IP address for you.

We hope these four posts on the IPAM Module have been informative and useful.  Why not getting a free trial of the Men & Mice Suite? 

Season's greetings!

From all of us here at Men & Mice, we wish you and your family Happy Holidays!  

Click here to view the holidaycard with motion.

All the best, 

Men & Mice staff

 

 

Monitoring, Alerting and Access Restriction

The overview of the IPAM Module of the Men & Mice Suite continues!

The Men & Mice IP Address Module pt. 3:

Monitoring, Alerting and Access Restriction

Monitoring and alerting can be configured as such:

• Subnet Monitoring: The minimal number of free IP addresses can be defined as threshold. This can be done either on subnet level or globally for all subnets.
• Alerting: When a threshold is exceeded, different actions can be triggered:
  • Alerting by SNMP
  • Alerting by email.
  • In combination with the DHCP module you can also define monitoring/alerting for dynamic address ranges (scopes).
  • Execution of a script (A subnet monitoring script can be configured to be called either when the threshold is exceeded and when the issue has been fixed, e.g. by freeing up used addresses or resizing of the subnet.)

Access Restriction

Users and groups can be defined in the Men & Mice Suite. The authentication can be done with the built-in methods: M&M internal, Radius or Active Directory.

• Granular Access Control: For the defined groups and users the access can be granular restricted on IP address range level. E.g. allow a group only to view certain subnets for informational purpose, whereas another group might have editor rights, to assign hosts to IP addresses and change or define the meta data.
• Locking of Subnets: With the necessary permission subnets can be locked, which automatically blocks the access to the IP addresses that are inside of the locked subnet.
• Claiming of IP Addresses: IP addresses can be claimed/waived. This allows users to signal other users that an IP Address should not be allocated. A user who tries to allocate a claimed IP Address will be prompted.

3 Points on Connectivity

 

The Men & Mice IP Address Module pt. 2:

3 Points on Connectivity

The Men & Mice Suite brings several ways to customize operations, to connect to existing software or to import/export data, e.g. from spread sheets or existing databases:

• Script hooks: Scripts (scripting language doesn’t matter) can be attached to basic objects in the M&M Suite, e.g. to the type “IP Address Rage” or “IP Address”. The scripts are called by the system when an object is being changed. A script, which is attached to a script hook can return a success flag. When a success flag false is returned, it can be accompanied by an error message, which will be presented to the user and the change in the system will be denied. The success flag set to true will make the change.
• Web Service: The M&M Suite’s Web Interface automatically provides a Web Service defined by the well-known SOAP standard.
•  All languages, which are able to support SOAP calls, like Python, Powershell, C# or Java can be used to call the SOAP methods of the Men & Mice Central.  This allows for instance the automation of processes, export of subnet or device data, or integration of the Men & Mice Suite in existing environments.
• CLI: A third method to import/export data is provided by the Men & Mice command line interface (mmcmd), which is available for all major platforms (Linux, Solaris (X86/Sparc), Windows, Mac OS X).

 

More to come!

 

7 ways of easy access and visibility!

Mr. Martin Metz at Men & Mice put together a simple overview of the IP Address Module. Read on and learn more.

The Men & Mice IP Address Module pt. 1:

-7 ways of easy access and visibility!-

• Correct IP-/network-address sorting: The sorting of the IP addresses/network addresses is not done alphabetically. The M&M IP Address Module sorts the addresses correctly by their IP Address.
• Flat or Hierarchical view: Hierarchy is preserved when filtering is applied in the networks.
• Meta data can easily be attached to the IP Address ranges and IP Addresses.
• Quick filtering subnets or IP Addresses using your own Meta data.
• Build-in discovery functionality:
• by ICMP (ping sweeps over IP Addresses in subnets)
• by ARP cache reading (define an SNMP community on routers and add the routers to the subnets. The ARP cache is then read by M&M Central, using the defined community string.)
• Reporting on new devices (Device discovery report – using the ICMP and ARP cache data).
• Reporting on devices which were not seen for a certain period (IP reconciliation report).
• Integrated IPv6 support, which enables you to view both IPv4 and IPv6 with one unified interface.
• Audit Trail: All changes done to the IP Address ranges/IP Addresses are logged in the audit trail. The log contains all changes that have been made to any object such as the date and time of the change, the name of the user who made it, the actions performed, and any comments entered by the user.

• In combination with the M&M DNS management module all DNS records are automatically synched into the IP address module. So there is no need to press a synchronize button for DNS records. The correct data shows up directly from within the IP Address module.

• In combination with the DHCP module also the scope data/leases/reservations and so on gets pulled automatically into the IP address module. You can work seamless with static IP address ranges and dynamic scopes.

The Men & Mice Suite Version 6.3

Men & Mice, a leading provider of DNS, DHCP and IP Address Management (IPAM) solutions, is proud to announce the release of Men & Mice Suite version 6.3.

Version 6.3 of the Men & Mice Suite contains various new features and usability enhancements, making the system more powerful and easier to use.

The new release contains agent –free Microsoft DNS management, support for distinction between dynamic and static DNS records on MS DNS server and improved DNS scope migration tools and improved super scope management for MS DHCP management, to name a few exciting features.  Through automatic updates it is possible to configure the system so that the server controllers and the Management Consoles are automatically updated when a new version of Men & Mice Central is installed.

These are just a few of the exciting features version 6.3 entails.  On our website you can view the whole list of features and download the new version.

Wanna try out the latest version?

DNSSEC monitoring tools

Mr.Carsten Strotmann, one of Men & Mice Experts has created a list of tools that can help in verifying a DNSSEC signed zone.

Symptom: A newly DNSSEC signed zone should be monitored to detect potential DNSSEC validation issues before the zone goes public.

Problem: A DNSSEC signed zone is much more vulnerable to software errors and operational errors, a small misconfiguration can render the whole zone invalid.

Solution: Below is a list of tools that can help verifying a DNSSEC signed zone. DNSSEC verification can be done in different stages of DNSSEC zone deployment.

Verisign jdnssec-tools

jdnssec-verifyzone: This is a tool to verify a signed zone for DNSSEC correctness. This tool verifies that a zone was correctly signed. It checks that all signatures are valid, all expected signatures exist, all expected NSEC or NSEC3 records exist and are correctly formed, and that the NSEC/NSEC3 chain is correctly formed.

java-based
http://www.verisignlabs.com/dnssec-tools/

---

AFNIC ZoneCheck

a generic DNS zone checker, include some DNSSEC checks
can be augmented with other tools
delivers a solid framework for DNS checks 

ruby-based
http://www.zonecheck.fr/features.shtml

---

.SE dnssec-monitor

a small set of DNSSEC related tools .SE use for monitor DNSSEC-signed zones

perl-based
https://github.com/dotse/dnssec-monitor

---

SurfNet DNSSEC Checker

the DNSSEC Checker is a script that uses ubound-host and dnspython to verify DNSSEC information

python-based / unbound based
http://www.dnssecmonitor.org/source.php

---

YAZVS — Yet Another Zone Validation Script

yazvs.pl is one of the utilities that VeriSign uses daily to validate new versions of the root and arpa zones before they are published to the distribution masters.

perl-based
http://yazvs.verisignlabs.com/

---

Vantages D-Sync

"D-Sync" monitors the secure delegation state between a child zone's DNSKEY(s) and the parent zone's DS record(s) for that child.  D-Sync uses a state-engine to track consistency during DNSKEY rollovers and DS record updates and alerts operators to various events.

C++-based
http://www.vantage-points.org/index.html

---

NlNetLabs ldns-verify-zone (part of ldns)

ldns-verify-zone reads a DNS zone file and verifies it. RRSIG  resource  records are checked against the DNSKEY set at the zone apex. Each name is checked for an NSEC(3), if appropriate

C-based
http://www.nlnetlabs.nl/projects/ldns/

---

nagval

nagval - Nagios/Icinga plugin to check validity of one or more DNSSEC domains

C-based
https://github.com/jpmens/nagval

---

Keychecker

Monitor and analyze DNSSEC key rollovers

python based
https://github.com/bortzmeyer/key-checker

---

OpenDNSSEC auditor

The OpenDNSSEC DNSSEC automation suite contains a module (the auditor) that checks the DNSSEC signed zone created by the OpenDNSSEC signer. The list of checks done by the auditor can be found at 
http://trac.opendnssec.org/wiki/Signer/AuditorRequirements

ruby-based
http://www.opendnssec.org/

---

OpenDNSSEC monitor

This project contains tools to monitor a DNSSEC-signed zone,
including a NAGIOS plug-in.

ruby-based
http://trac.opendnssec.org/wiki/Signer/MonitorRequirements
http://svn.opendnssec.org/trunk/monitor/

---

Do you know of any other DNSSEC monitoring tools that can help verifying a DNSSEC signed zone?

Knowing Men & Mice pays off

Men & Mice proudly exhibited its solutions at the TechEd Europe 2010 event in Berlin,Germany.  Attendance to our stand exceeded our expectations and we tell ourselves that it was because of the interest in our products rather than the excitement around the „Free Trip to Iceland“ that a lucky visitor had a chance to win, after shaking hands with the smiling Men & Mice representatives at our booth. Which ever may be the case we ended up with a few hundred names of in our jackpot.

As you can imagine, a trip to Iceland can entail some unique adventures, ranging from an unchartered expedition on one of the country´s many glaciers to a wild exploration through the capital´s restaurant and entertainment scene. Whatever suits your taste, you´ll be sure to find it in Iceland . . . which also happens to be the home to Men & Mice´s headquarters. We like to think that the clean fresh air and open spaces contribute to the ingenuity that we deploy in the Men & Mice software solutions . . . but maybe that´s just us!

 

In the inset photos you can see Mr. Jon Georg Adalsteinsson, Men & Mice´s VP of Business Development, drawing the name of Mr. Thomas Jegust of Sasol in Germany out of the helmet that Darth Vader was kind enough to lend us for this historic event. We congratulate Mr. Jegust on his prize and are very pleased to present him with a travel voucher to cover a week-end trip to Iceland, including flight and accommodation. We hope that Mr. Jegust will pack for an adventure in Iceland soon and are looking forward to adding him to the ever growing list of „the Friends of Iceland“.

 

 

 

---

Gartner Report - Marketscope for the DNS, DHCP and IPAM market in 2011

Men & Mice: A promising vendor in a promising market

Men & Mice rating

Gartner has released its annual marketscope on the DNS, DHCP and IP address market (DDI) and moves Men & Mice into the Promising category.  Closure of large deals and strong customer feedback secured this change.  This highlights the company’s emphasis on customer care and high level of expertise and quality.

Gartner recommends that SMBs and large enterprises seeking an Overlay solution with strong administrative controls should consider the Men & Mice Suite.

Gartner highlights some of the Men & Mice Suite strengths:

• Easy deployment
• Broad overlay support as the solution can centrally manage Microsoft, Linux and Cisco DNS and DHCP services.
• Tight MS Active Directory integration

Market rating

Gartner’s marketscope also reveals interesting estimates and predictions for the DDI market.  Gartner estimates the DDI market as promising and that the market will grow 28% in 2011 and grew 23% from 2009 to 2010.  Gartner predicts total spending of $276 million in 2011.  Widespread adoption of DNS Security Extensions (DNSSEC) and IPv6 in 2011 can accelerate growth, contributing to faster growth than predicted.  Gartner expects that by 2014, only 30% of all DNS look-ups will be signed with DNSSEC and by 2015, 17% of global Internet users will use IPv6, with 28% of new Internet connections running the protocol

Gartner has identified two main drivers for adoption of DNS, DHCP and IP Address Management (DDI) solutions:

• Management of the IP address space - 80%
• Stability. Critical to the overall IT environment - 20%

Most organizations rely on the embedded DNS/DHCP services included in Windows Server, despite the fact that Microsoft does not offer an IPAM tool and its Microsoft Management Console (MMC) provides primitive administrative capabilities.  Still standard appliances are the biggest part of the DDI market.  This fact implies that most organization have yet to deploy a professional tool to manage these core services effectively.

Gartner’s predictions indicate that new adoption as well as IPv6 and DNSSEC will funnel at least 25% CAGR growth in the coming years.

---

 Try the Men & Mice Suite, a professional tool to manage the core services effectively. 

---

Disclaimer

The MarketScope is copyrighted 2011 by Gartner, Inc. and is reused with permission. The MarketScope is an evaluation of a marketplace at and for a specific time period. It depicts Gartner's analysis of how certain vendors measure against criteria for that marketplace, as defined by Gartner. Gartner does not endorse any vendor, product or service depicted in the MarketScope, and does not advise technology users to select only those vendors with the highest rating. Gartner disclaims all warranties, express or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.