The Men & Mice Blog

Dora Vigfusdottir

Recent Posts

Men & Mice onsite at TechEd Amsterdam 2012

Posted by Dora Vigfusdottir on 6/27/12 12:11 PM

We have been having loads of fun in TechEd Amsterdam in the last couple of days, but the fun isn't over yet! Our very own Carsten Strotmann has been demonstrating a live managing of a DNSSEC signed zone, which has been eye-opening and informative to many guests. 

Our staff is ready, willing and able to assist, teach and inform in any way they can, so we encourage you to swing by our booth (nr. 66) and see if there isn't something new to be seen and learned! We'll be here until the 29th.

We have brought with us our brand new product, the DNS Caching Appliance. Click here to learn more!

TechEd Europe

Mr. Sebastiaan Kors from our reseller partner, WeSecure and our own Mr. Martin Metz really know their stuff! 

Topics: Men & Mice

Men & Mice at TechEd Amsterdam

Posted by Dora Vigfusdottir on 6/19/12 10:52 AM

 

Men & Mice Suite managing a DNSSEC signed zone on Windows DNS 2012 ( see it live @ TechEd Europe 2012 next week in Amsterdam).

Windows2012 dnssec

Topics: DNSSEC, Men & Mice Suite, TechEd, Men & Mice

Men & Mice at TechEd North America

Posted by Dora Vigfusdottir on 6/13/12 12:14 PM

We here at Men & Mice have our US reps in place at TechEd North America in Orlando these days. 

TechEd is Microsoft's premier technology conference for IT professionals and developers, offering the most comprehensive technical education across Microsoft's current and soon-to-be-released suite of products, solutions, tools, and services. 

 

Mark @ TechEd

Swing by our booth, say hi to Bob and Mark (pictured) and get scanned. We are looking forward to establishing new relationships on a solid common ground. 

 

Capturing the moment: 

Overview

 

Topics: TechEd, DDI, Men & Mice

World IPv6 Launch - are you ready?

Posted by Dora Vigfusdottir on 6/1/12 7:50 AM

IPv6 logo

This time it is for real!

Major Internet Service Providers (ISPs), home networking equipment manufacturers, and web companies around the world are coming together to permanently enable IPv6 for their products and services by June 6th 2012. 

As the successor to the current Internet Protocol, IPv4, IPv6 is critical to the Internet's continued growth as a platform for innovation and economic development. On June 8th 2011, was the successful one-day World IPv6 Day event held worldwide but in many cases companies reverted back to IPv4.

Men & Mice however continued on the IPv6 route and we haven't looked back since! 

Are you ready for the future?

IPv6 

Topics: Men & Mice, IPv6, IPv4

Terena Networking Conference 2012

Posted by Dora Vigfusdottir on 5/21/12 3:43 PM

The TERENA Networking Conference (TNC) is the largest and most prestigious European research networking conference - over 500 participants including decision makers, networking specialists and managers from all major European networking and research organisations, universities, worldwide sister institutions and industry representatives attend.

Through keynote speeches by renowned specialists and many parallel sessions, the Conference presents an overview of the latest developments in research networking, both in the technical field and in the areas of application and management.

Each day will include parallel sessions of presentations on a diverse range of topics, and there will be four more plenary talks, on Tuesday and Wednesday.

All streams are available live and will be made available in archive form immediately after each session. Most of the slides and some of the papers can be downloaded by clicking on the relevant session in the programme, at https://tnc2012.terena.org/core/schedule/list.

Streaming is undertaken by a technical team with members from the University of Iceland and RHnet, the Icelandic National Research and Education Network which are also kindly hosting the event.

The TNC2012 will be hosted by the Icelandic National Research and Education Network (RHnet) and the University of Iceland and held in the picturesque city of Reykjavik in Iceland from 21-24 May 2012. RHnet provides network connectivity to all state universities and research institutes. With respect to its research activities and accomplishments, RHnet represents Iceland in the development of the Nordic network, NORDUnet, that takes part in the pan-European network GÉANT and participates actively in the project implementation. This sets the perfect scene for TNC2012.

Here is our very own Carsten Strotmann, ready in our booth at the conference. He will also be giving a talk later on. 

Carsten TNC2012

For those interested in how the Icelandic language sounds, here is a short news clip about the conference: 

http://mbl.is/frettir/innlent/2012/05/21/netkerfi_kortlogd_i_haskolabioi/


Topics: Men & Mice

Gartner - Marketscope on the DDI market 2012

Posted by Dora Vigfusdottir on 5/21/12 7:29 AM

Gartner has released its annual Marketscope on the DDI market for 2011-2012. 

Market rating

In 2011, Gartner estimated that the DDI market generated approximately $290 million, representing a 36% increase over 2010.  Gartner estimates that the market will grow another 29% in 2012, to approximately $380 million, as more enterprises seek tools to improve the operational effectiveness and the overall stability of DNS and DHCP.  Gartner estimates that IPAM is the primary driver in more than 60% of DDI projects.  Many enterprise networks are still managing their IP address space manually via spreadsheets (approximately 75%), via homegrown applications or a combination of the two.  Microsoft’s entrance to this market highlights the increase importance of the DDI market.

 

Gartner 2012

Men & Mice rating

Men & Mice moves into the Caution category from last year’s Promising status.  Men & Mice is the only global vendor solely focusing on Overlay solutions and as before Gartner recommends that SMBs as well as large enterprises seeking an Overlay solution with strong administrative controls should consider the Men & Mice Suite.   Gartner highlights external factors as our main challenges.  With Windows Server 8, Microsoft is entering this market segment.  This is considered a challenge and the same applies to Overlay market shrinking.   The fact that Microsoft is entering this market with an Overlay solution suggests increased focus on the Overlay market segment which contradicts market shrinking. 

Men & Mice has primary focus on medium to large enterprise networks so the overlap with Microsoft SMB product will be limited.  Instead our solution is a natural extension and a professional upgrade of the Microsoft tools as it has been in the past with Microsoft snap-in.

Gartner also mentions our hardware plans.  Explosion in cloud based services and virtualization requires flexible DDI and focus on hardware based appliances will decrease, except for more dedicated purposes.  Based on this Men & Mice has started to offer DNS caching only appliance but that is outside of the scope of the Gartner report.  Men & Mice will continue to keep strong focus on the Overlay market segment and further build on our success there.  Men & Mice will also in the near future expand its product offerings using the core developed both in the Men & Mice Suite and in the Men & Mice DNS caching appliance.

We at Men & Mice have continued to add to our growing customer base and today Men & Mice is stronger than ever.  We see new opportunities with Microsoft putting more focus and effort into our market segment as well as through new Men & Mice products. 

Gartner continues to highlight 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

We at Men & Mice have continued to add to our growing customer base and today Men & Mice is stronger than ever.  We see new opportunities with Microsoft putting more focus and effort into our market segment as well as through new Men & Mice products. 

 

 

 

 

 

 

Topics: Men & Mice Suite, DDI, Men & Mice

A visit from an ISC BIND 10 team to Iceland

Posted by Dora Vigfusdottir on 4/26/12 12:36 PM

We here at Men & Mice have been playing host to a very happy and eager group of people from ISC this week. The purpose of their visit to Iceland has been to meet up, work together, learn from us and vice versa. 

isc

I was able to lure Shane Kerr out of a meeting for a minute and asked him some questions!

So Shane, what exactly is BIND 10? 

BIND 10 is the next-generation DNS server currently being developed by ISC, with financial and coding support from several generous sponsors. It is intended not only to fix limitations found in all current DNS servers, but also to allow DNS administrators to better intigrate BIND into their operations and use the DNS in new and interesting ways. 

And how is the progress so far in the project?

We've gotten to the point where the server is useful as an authoritative server, but we've had to do quite a bit more refactoring of the code than I would have preferred. My feeling is that this is because we're trying to do things in ways that have never been attempted before, so it should not be surprising that we have made some imperfect decisions early on.

Some pioneer work going on then, exciting! But when should users download and test BIND 10 in their environment?

This depends on what each user does with DNS, and also how comfortable they are with experimental code.

Right now users interested in looking at BIND 10 from a software or system level should go ahead and download it immediately.

Users who are more interested in installing production software should wait until October 2012, when we are going to be putting out either a beta or alpha version of the authoritative server. (If we have completed feature work it will be a beta, otherwise it will be an alpha).

Users who run recursive resolvers should wait until mid-2013, when we hope to release the results of our recursive work. We have a basic resolver now, but we are looking at architectural changes needed to improve performance so we can run faster than any alternatives.

Makes sense, but is there a way for users to participate in or comment on the BIND 10 project?

Right now we have a user mailing list which is designed for people with operational questions or suggestions:

https://lists.isc.org/mailman/listinfo/bind10-users

We also have a development mailing list where all of the development discussions happen. This is a bit high-volume, and probably only interesting for DNS developers, but it is open for all:

https://lists.isc.org/mailman/listinfo/bind10-dev

We periodically invite anyone interested to join us for a day of discussion with the developers, which we call the BIND Open Day. We've had two so far, and tend to have them around our face to face team meetings. These get announced on our mailing lists, as well as all the usual social media sites. We hope to see you at one! :)

Excellent, lots of ways to stay tuned. But how does the BIND 10 team like Iceland?

Well, a number of the team were really looking forward to the trip, and several have taken the opportunity to plan their holidays around the meeting. We generally like it so far and some of us are going on a day tour this weekend to see your geysers and other nature wonders. 

 

It's been a pleasure to have all these wonderful people gathered here at our offices.

Everyone hard at workHard at work and keeping busy!
 

 

Topics: DNS, Men & Mice, ISC, BIND

A new product - The Men& Mice DNS Caching Appliance

Posted by Dora Vigfusdottir on 4/2/12 7:35 AM

Men & Mice is proud to introduce a world class solution for high performance, secure DNS caching; The Men & Mice DNS Caching Appliance!

describe the image

 

The Men & Mice DNS Caching Appliance is built using the open source Unbound DNS Caching resolver. Unbound has excelled in security tests and fully supports DNSSEC validation. Unbound is also designed for dual-stack environments and IPv6-only setup.

Service providers rely on caching DNS services in their business and enterprises are increasingly operating their caching DNS separately for security reasons.  Our goal with the Men & Mice DNS Caching appliance is to provide a robust, fast and simple appliance for a fair price.

The Men & Mice DNS Caching appliance is a single purpose appliance, designed and built to maximize the performance of both hardware and software. Your Internet service is only as fast and reliable as your DNS Caching Servers. Benchmarking shows it to be up to two times faster than conventional DNS Caching servers! The appliance runs on a proven, solid hardware and comes with built in fault tolerance.  The appliance manager is available, either in a separate hardware box or as a virtual appliance.

Ease of installation and excellent management capabilities make our DNS Caching Appliance the perfect choice. Insert the SD card provided and you will be up and running within minutes. In the same way, replacing and adding new devices is a simple task.

Benefits of the Men & Mice DNS Caching Appliance include: 
  • Up to twice as fast as comparable solutions,
  • Tested to handle more than 150k QPS,
  • Designed for maximum security and stability,
  • Web GUI for central management,
  • Simple Installation and operation
  • Global support and warranty
  • and much, much more, just give it a try!

 

Go ahead, fill out the form and we will be in touch! 

 

 

 

Topics: Unbound Support, DNS, Men & Mice, IPv6, Monitoring

Men & Mice Suite Version 6.3.1 is now available

Posted by Dora Vigfusdottir on 1/30/12 11:24 AM


Men & Mice Suite Version 6.3.1 is now available

Men & Mice, a leading provider of DNS, DHCP and IP Address Management (IPAM) solutions, has announced the release of Men & Mice Suite version 6.3.1. Version 6.3.1 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:

  • Support for multiple address spaces has been added.  Each address space can contain its own subnets, DHCP servers, DHCP scopes, DNS servers and DNS zones
  • Custom DHCP options can be defined for Microsoft and ISC DHCP servers
  • Users of the DNS and IPAM modules can generate reverse DNS zones directly from the IPAM subnet view
  • Ranges created under DHCP scopes can be viewed in the DHCP scope view and it is possible to manage DHCP reservations inside those ranges
  • Documentation for the SOAP interface can be retrieved directly from Men & Mice Central

 

This release various other improvements like:

  • DHCP leases can now be released from the web interface and DHCP reservations can be moved to a different IP address
  • Custom DHCP options are now available for Cisco DHCP servers
  • DHCP Scope utilization calculations in the web interface have been improved
  • Support has been added for options of type 'record' on ISC DHCP servers
  • AD sites are synchronized automatically
  • It is now possible to show a visual indication of gaps between subnets in the Windows Management Console
  • Subnet hierarchy is now shown in folders
  • Regular expression support in the Quick Filter has been improved
  • New commands have been added to the SOAP interface
  • Performance has been optimized for large and active environments
For full release notes, please visit: 

https://support.menandmice.com/jforum/forums/show/9.page

Topics: DNS, IPAM, DHCP, Men & Mice Suite

Take your DNSSEC with a grain of salt

Posted by Dora Vigfusdottir on 1/12/12 8:22 AM

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:

 

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

Topics: DNSSEC, DNS, Men & Mice, DNS Zone

Why follow Men & Mice?

The Men & Mice blog publishes educational, informational, as well as product-related material for everyone and anyone interested in IP Address Management, DNS, DHCP, IPv6, DNSSEC and more.

Subscribe to Email Updates

Recent Posts