The Men & Mice Blog

RIPE 72 – A Blog Report on DNS & IPv6

Posted by Carsten Strotmann on 6/22/16 5:30 AM

RIPE 72 took place in Copenhagen from 23-27 May 2016. This blog report shares some of my thoughts on interesting talks and presentations on DNS and IPv6.  

As always, this report cannot be exhaustive and I recommend that those interested browse the meeting archive of RIPE 72 for other interesting topics.

DNS

Victoria Risk from ISC reported on the changes in the upcoming BIND 9.11 release (BIND 9.11 Release Update) that is planned for August 2016. The new catalog zone feature allows automatic provisioning of slave zones from a central catalog zone. New zones are configured as a master zone on one server and a special entry is written into the catalog zone, a meta-data zone that is configured on the master and all secondary servers. The catalog zone will be replicated by zone-transfer and the secondary server will automatically configure a slave-zone for the newly added domain.

Men & Mice Trainer Jan-Piet Mens has already had a chance to test this new feature and wrote a blog article about it: Catalog zones in BIND 9.11. ISC has issued an Internet Draft in the IETF about catalog zones with the hope that other DNS software vendors will implement a compatible version.

BIND 9.11 will include a new, refined backend for storing DNS zone data in databases, called the dyndb api. This new API is much faster than the older DLZ API and also works with DNSSEC.

Speaking of DNSSEC, BIND 9.11 will come with a new component called dnssec-keymgr that will be able to automate DNSSEC key-rollover based on a policy, much like the external OpenDNSSEC tool. More improvements to BIND 9.11 can be found in the presentation and also in the upcoming Men & Mice Webinar What's new in BIND 9.11.

Jeff Osborn from ISC started a discussion on a license change of the BIND 9 DNS Server in his talk Changing the Open Source License on BIND. Today, the BIND 9 DNS server is licensed under the ISC license, which is a permissive BSD-style license. Jeff proposes a switch to the Mozilla Public License (MPL), which is a so-called copy-left license. Both licenses are open-source licenses, but the main difference is that the MPL requires all source code changes to the product to be made public. This license change will have no negative effect on anyone using the BIND 9 DNS server, but might affect companies that build products that incorporate the BIND 9 server code. As an overlay management solution, the Men & Mice Suite product works with an un-altered BIND 9, so customers using the Men & Mice Suite would also not be affected by such a license change. Jeff welcomes any feedback on the license change. His contact information can be found in the talk's slides, available in the link above.

Patrik Faltstrom, Chair of the Security and Stability Advisory Committee on the DNS root-server system, presented an alert on WPAD Name Collision Vulnerability. WPAD, the "Web Proxy Auto-Discovery", is a way to configure the Web-Proxy to be used by a Web-Browser using DNS. In this function, the special domain name "wpad" is resolved in the local domain name of the network the client is in. Collisions with internal, non-registered domain names and new top level domains in the Internet DNS system now create the vulnerability that external parties can control the internal proxy configuration inside a company's network. Internet Explorer on Windows systems have this function enabled by default, but it can also be enabled in Firefox, Safari or Chrome-Browsers on MacOS X, BSD and Linux. Running an unregistered TLD in an internal DNS deployment is not recommended, but DNS administrators will find it difficult to remove the sins of the past. Administrators should block DNS queries for internal-only domains at their DNS-resolvers, monitor DNS queries leaving the network for internal names and consider manually switching off the WPAD function in the browsers.

Duane Wessels from Verisign gave a talk on the size increase of the Root-Zone Zone-Signing-Key (ZSK). Since the beginning of the DNSSEC-signed root-zone, the ZSK was a 1024bit RSA key, as recommended by RFC 6781 - DNSSEC Operational Practices, Version 2. However, while not an immediate security threat, 1024bit RSA keys are now also seen as having a too small security margin when used for DNSSEC signatures (1024bit RSA keys have been too weak for encryption for many years). The new ZSK will be a 2048bit key and it will be introduced into the DNS root-zone on 20th September 2016. All testing done so far indicates that there should be no problems. Even though the DNS responses from the root zone during a ZSK rollover do increase from 883 to 1138 octets/bytes, the response is still below the 1232byte EDNS0 limit often used in the IPv6-DNS-Resolver or the 1500byte Ethernet MTU.

The Unbound DNS-Resolver now implements DNS Query Name Minimisation to Improve Privacy, RFC7816. Ralf Dolmans of NLnetLabs explains in his talk QNAME Minimization in Unbound how this new feature is implemented. In traditional DNS, a DNS resolver always asks the full question to all servers in the delegation chain. This is because the DNS resolver does not know about the delegation topology of the DNS system in use. In the Internet, there is a defined delegation structure for DNS, starting with the root-zone, the generic, new and country-code top-level-domains and second-level domains owned by companies and individuals below it. In the Internet, a DNS-resolver can shorten the query when asking at the root-zone or TLD level, enhancing the privacy of the users of the DNS resolver. QNAME minimization in the DNS resolver used by a client machine can be tested with a DNS lookup tool such as dig

 

% dig txt qnamemintest.internet.nl +short


IPv6

John Jason Brzozowski from US cable giant Comcast presented IPv6 @Comcast – Then, Now and Tomorrow about the challenges and successes in their deployment of IPv6 "large scale". Overall, IPv6 at Comcast is a success and they are now putting in motion the plan to phase out IPv4.

In the IPv6-Working-Group session, John reported on Community WiFi and IPv6 and how Comcast is using IPv6 to create public WIFI hotspots on CPE devices. Comcast is giving out a full "/64" network to every WIFI-device connected, in order to create easy network isolation and to reduce the multicast traffic over WLAN. This scheme could have even more benefits, such as assigning an IPv6 address for every service running on a host.

The Google public DNS resolver now supports DNS64-translation (currently in Beta) on the public DNS-resolver address "2001:4860:4860::6464" (IPv6-Only Has Never Been So Easy). DNS64 is a translation technology that works together with NAT64 to allow a client on an IPv6-only network to connect to IPv4-only services on the Internet. As DNS64 "re-writes" DNS content, it clashes with DNSSEC, as Jen Linkova from Google explains in IPv6-only and DNS(SEC|64).The workaround proposed in the talk got some criticism from the audience.

Enno Rey from the security company ERNW had a close look at the security issues of Multicast Listener Discovery MLD, a topic that has not seen much attention so far. He and his colleagues have found several issues that can be used for denial of service attacks or traffic redirection attacks by an intruder inside the local network. He recommends an (still to be developed) "MLD guard" function in switches (similar to DHCPv4- or RA-Guard) or to deploy port based ACL filtering of MLD traffic. Nobody should panic because of these findings, but every IPv6 network admin should know about MLD and the implications of having MLD active in their networks.

Vaibhav Bajpai had an interesting talk on Measuring Webpage Similarity from Dual-Stacked Hosts, looking at the differences in website content between a page fetched via IPv6 vs. IPv4. Differences coming from certain objects on the page (CSS, JavaScript, Advertisements …) are only available for one protocol, while the general website is dual-stacked and therefore available on both IPv4 and IPv6.

Two talks covered the topic of IPv6-only networks, but from very different angles. In How to Make Trouble for Yourself - You Build an IPv6-Only Network in 2016, Roger Jørgensen from Bredbandsfylket Troms in Norway reported on their project to build a new fiber optic network in the far north of Norway. The management part of this network is designed and operated as an IPv6-only network. Luuk Hendriks gave a report of his attempt at Going IPv6-only at Home while keeping the most important user of his home network, his girlfriend, happy.

Enno Rey talks about Real Life Use Cases and Challenges When Implementing Link-local Addressing Only Networks as of RFC 7404 from his experiences implementing a Link-Local-only addressing scheme in a larger enterprise network. The Link-Local-only addressing was chosen to simplify address management, as almost 50% of networks in this customer's environment are point-to-point links. There are still issues with vendor support in network devices when implementing Link-Local-only addressing. In the discussion following the talk, the audience gave a mixed message, with some people claiming success at running a Link-Local-only network.

Other topics

Mircea Ulinic presented a way to automate the provisioning and management of network devices (router, switches etc) using the configuration orchestration tool "SaltStack". SaltStack is usually used to automate the provisioning of server machines running a Salt-Agent (Minion). As it is difficult to install a customer agent on network gear, this talk presented a way to use proxy machines that act as the minions for network hardware. SaltStack automation can save a great deal of time when used in large deployments. Details can be found in Mircea's talk: Network Automation with Salt and NAPALM.

Shane Kerr, who we recently had as an interview guest in our latest Webinar on Yeti-DNS, gave a humorous talk about the "Internet of Things (IoT)" in IoT: What is the Problem or “How To Explain To Your Boss That IoT Won't Make the Company Rich….”.

Those of you hungry for more on RIPE 72, all the above talks and more can be found in the meeting archive of RIPE 72.

Topics: IPv6, DNSSEC, DNS

[Webinar] IETF 90 Report – DNS, DHCP, IPv6 and DANE

Posted by Men & Mice on 7/7/14 6:15 AM

Report from IETF 90 in Toronto 2014

The IETF, Internet Engineering Task Force, those that are working on new Internet Standards, met in Toronto in July 2014.IETF resized 600

Mr. Carsten Strotmann from the Men & Mice Services team gives an overview of interesting developments from the working groups inside the IETF, after attending online at the IETF 90 in Toronto.

Hear more on:

  • DNS
  • DNS-Privacy
  • IPv6
  • DANE
  • DHCP(v6)
  • and new RFCs that have been published since the last IETF in March 2014

Fetch the slides, webinar recording and link collection.

Topics: DNS, DHCP, IPv6, Webinars

RIPE 68 report

Posted by Men & Mice on 6/25/14 12:04 PM

Report from RIPE 68 in Warsaw, Poland

A RIPE Meeting is a five-day event where Internet Service Providers (ISPs), network operators and other interested parties from all over the world gather.

In this webinar, Carsten Strotmann from the Men & Mice Services team reports about what was new at the RIPE 68 meeting.

Hear what he had to say on:

  • Amplification DDoS Attacks – Defenses for Vulnerable Protocols
  • news from DNS-OARC meeting (DNS measurements, open resolver stats)
  • Strengthening the Internet Against Pervasive Monitoring
  • What Went Wrong With IPv6?
  • RIPE IPv6 Analyser
  • IPv6 troubleshooting procedures for helpdesks
  • Using DDoS to Trace the Source of a DDoS Attack
  • Measuring DNSSEC from the End User Perspective
  • Google DNS Hijacking in Turkey
  • The Rise and Fall of BIND 10
  • Knot DNS Update – DNSSEC and beyond
  • Bundy-DNS – the new life of BIND 10

Have a look at the slides and recording from the webinar to learn more.


 

Topics: DNSSEC, IPv6, BIND 10, Webinars

On-link vs Off-Link Packet Delivery: Unicast, Multicast, Anycast

Posted by Men & Mice on 5/6/14 9:29 AM

By David Beck, a Men & Mice trainer and course developer

Delivering IP packets within a subnet (on-link) is different than delivering between subnets (off-link). This article examines those differences for unicast, multicast, and anycast destination addresses. The goal is to shine a light on the differences for anycasts and to explain on-link anycasting. Everything is applicable to both IPv4 and IPv6, with one exception that is clearly noted. However, that difference is why this is fundamentally an IPv6 article. The IPv6 terminology "link" will be used in lieu of "subnet." "Node" will be used in lieu of "host."

UNICASTS

A unicast address uniquely identifies one interface on one node. It is used to deliver a packet to only one interface. It is the type of address that initially comes to mind, when one hears "IP address." A sender with a unicast destined packet looks up the packet's destination address in its routing table, and selects the longest-match.

The longest-match entry may indicate that the destination is on-link (OL). For an OL destination the sender uses the data link layer (DLL) protocol, e.g. Ethernet, to deliver the packet to the final destination. Alternatively, the longest-match may indicate that the destination is off-link (XL, external-link). The routing table entry for an XL destination includes an OL router that is closer to the destination. The sender uses the DLL protocol to deliver the packet to the router. The router repeats the same process sending the packet toward the final destination.

An internet is two or more links (networks) joined by a router. It is the need to deliver unicast packets to XL nodes, that spurred the creation of internet protocols such as IP. If all destinations were OL, packet delivery could be done with only the DLL protocol and DLL addresses. (Note that the Internet is a huge internet with links throughout the world joined by routers.)

MULTICASTS

A multicast address identifies multiple interfaces on multiple nodes. A packet is delivered to all identified interfaces. In both IPv4 and IPv6, multicast addresses are distinct from unicasts and easily identifiable. IPv4 multicasts are 224.0.0.0/4 (addresses starting with 224-239). IPv6 multicasts are ff00::/8. Multicasting was not always a part of IP. It was added at the end of the 1980s.

Delivery of OL IP multicasts relies on the capability of the underlying DLL protocol to support multicasting, or to at least support broadcasting. Happily, Ethernet and 802.11 wireless have multicasting functionality and there are multicast MAC addresses. This makes OL multicasting delivery simple. IP multicast addresses are mapped to MAC multicast addresses through a formula, for IPv4 that is defined in RFC "Host Extensions for IP Multicasting" (http://www.rfc-editor.org/rfc/rfc1112.txt), and for IPv6 in the RFC “Transmission of IPv6 Packets over Ethernet Networks” (http://www.rfc-editor.org/rfc/rfc2464.txt). A node assigned a multicast IP address configures its network interface to listen for the corresponding MAC multicast address. When a packet is sent to an OL IP multicast address, it is packed in a frame destined for the corresponding MAC multicast. All nodes listening for the MAC address, receive and process the frame and the packet. OL multicasting is easily implemented, and widely used.

Both IPv4 and IPv6 routing protocols rely on OL multicasting. A router sends one packet to notify all others of routing protocol information, such as a network topology change. (OL delivery of IP multicasts, with underlying DLL protocols that don't support multicasting or broadcasting, can be very challenging. That little nightmare is happily well outside the scope of this article.)

XL multicasting, with a multicast address assigned to nodes on different links, is far more challenging. A special multicasting routing protocol must be implemented. The sender generates one packet; multicasting routers must duplicate the packet to deliver it to nodes on different links. XL multicasting is not widely used. The mass majority of organizations doesn't implement multicasting routing protocols. Multicasting routing protocols are not used in the open Internet.

ANYCASTS

Now we're reaching the heart of this article.

Like a multicast, an anycast is an address assigned multiple interfaces on multiple nodes. Unlike a multicast, an anycast packet is delivered to only one node. The sender doesn't care which node receives the packet, all the destinations are equivalent.

Like multicasting, there is a wide chasm between OL and XL anycasting. For multicasting, OL is easy and widely used. XL multicasting is challenging and rare. It is the opposite for anycasting. XL anycasting is easy.

XL anycasts are used for root and TLD (Top Level Domain) DNS servers. For example, the F root server (f.root-servers.net) has the IPv4 address 192.5.5.241. The address is an anycast. It is currently assigned to fifty-five DNS servers throughout the world (http://www.isc.org/f-root/). For DNS, all these servers are identical. When a packet is sent to 192.5.5.241, the natural process of unicast routing delivers it to only one node (one DNS server). Since all the servers have the same information, it is unimportant which is reached. In order for administrators to manage individual servers, each also has a unicast address, but that address is not intended for answering DNS queries.

XL anycast addresses are indistinguishable from unicast addresses. When a unicast address is assigned to a second node, the address becomes an anycast. The various nodes assigned the address don't know that it is an anycast and not a unicast. No special handling is required by nodes assigned an anycast address. No special handling is required by a sender generating a packet to an anycast destination. There is no protocol supporting anycasts. None is needed. Normal unicast routing handles delivery of XL anycasts. The only requirements are that the nodes sharing an address are on different links, and routing is properly configured. There isn't even an RFC defining the technical specifics for XL anycasting. Note that several RFCs discuss anycasting. For example the RFC "Operation of Anycast Services" is a Best Current Practices (BCP) document (http://www.rfc-editor.org/rfc/rfc4786.txt).

While XL anycasting is found in IPv4 and IPv6, OL anycasting is only implemented in IPv6. Nodes on the same link share an address. A packet addressed to an OL anycast is still delivered to only one interface. However, because the nodes are on the same link, routing can't handle delivery. Unlike XL anycasting, OL anycasting requires a technical specification. RFC "IP Version 6 Addressing Architecture" (http://www.rfc-editor.org/rfc/rfc4291.txt) specifies OL anycasting.

A node assigned an OL anycast sends Neighbor Advertisements (NAs). The NAs associate the anycast address with the node's own DLL unicast address. The NAs are fundamentally the same as the node would send for an assigned unicast address. Mapping an OL anycast, to the DLL unicast of a node, was a fundamental implementation decision taken by the IPv6 designers. Without prejudice as to whether it was a good or bad decision, it is noteworthy that there were other options. For example, First Hop Redundancy Protocols (FHRPs), essentially implement an OL anycast address, but with a completely different approach. The IETF standardized FHRP is RFC specified: "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6" (http://www.rfc-editor.org/rfc/rfc5798.txt).

By definition, an anycast address is assigned to multiple nodes. Each node assigned an OL anycast sends NAs associating the address with its own DLL unicast. These NAs are basically competing with each other. Other nodes on the link associate the OL anycast with one DLL unicast address, with one of the nodes assigned the OL anycast. If, three nodes on an Ethernet share an anycast address, another OL node will use the unicast MAC address of one of the three. When a packet is sent to the anycast address, the DLL deliveries it to one node. In this way, the anycast requirement of delivery to a single node, is met.

It is worth considering why DLL unicasting is used for OL anycast delivery. While it isn't ideal, it is necessary because DLL protocols don't have anycast capabilities. If, for example, Ethernet had anycasting addresses and anycast functionality, an OL anycast could be mapped to a MAC anycast. OL anycasting would then be as trivial as OL unicasting, and OL multicasting. Since DLL anycasting doesn't exist, OL anycasts must be mapped to what DLLs provide, unicasts, broadcasts, or multicasts. DLLs broadcasting and multicasting functionality cannot be used, because they violate the anycast requirement of deliver to only one node. So delivery of an OL anycast is necessarily implemented by a DLL unicast.

XL anycast addressing require no special handling. OL anycast addressing does. A node assigned an OL anycast must be explicitly informed that the address is an anycast, requiring IPv6 systems to implement a technique to indicate anycasts. The OL anycast indication suppresses Duplicate Address Detection (DAD). When an IPv6 unicast is assigned, DAD tests if the address is assigned to another node on the link. The address isn't used if DAD reports duplication. Anycasts are purposely assigned to multiple nodes, so DAD is disabled for OL anycasts. Additionally, OL anycast NAs are sent with a slight delay, and, more importantly, with the Override flag cleared in the NA message.

A set Override flag tells the receiver to replace a previously cached entry for the advertised IPv6 address. For a unicast NA, the Override flag is set, so that a receiver uses the new advertisement. This makes sense since the unicast NA is coming from the same node that sent the older cached information. Newer unicast information is better. For an OL anycast, each node assigned the address sends an NA with its own DLL address. The cleared Override flag in these NAs means a receiver will use the DLL address from the first NA that arrives. Older anycast information is better.

The cleared Override flag prevents oscillating between different DLL addresses for the anycast destination. It additionally means that, at any given time, senders on a link are reaching different nodes that share the anycast address. This can be viewed positively, as it provides load balancing. However, it can't be controlled and all senders could also be sending to one DLL address (to one node). Unfortunately, if a cached OL anycast destination becomes unreachable, it can't be replaced until the cached entry times out. So for the unlucky nodes on the link with the unreachable address cached, the OL anycast is unreachable, but for all other nodes on the link the anycast is reachable.

So unlike an XL anycast, an OL anycast requires both special configuration and special handling on the nodes assigned the address. Neither OL or XL anycasts require special handling by senders.

RFCs define IPv6 OL anycast addresses. Being defined distinguishes them from other anycasts, which are purposely indistinguishable from unicasts. The most common OL anycast is the Subnet-Router anycast (SRA). Every link has an SRA address. All the interface identifier bits set to 0, identifies the SRA. For the link 2001:db8:cafe:fee::/64, the SRA is 2001:db8:cafe:fee::/128. The SRA is defined in RFC 4291. RFC "Reserved IPv6 Subnet Anycast Addresses" (http://www.rfc-editor.org/rfc/rfc2526.txt) reserves the highest 128 addresses on each link for OL anycasts.

Initially it may seem that the SRA would be an ideal way to implement a FHRP. However, the widely used FHRPs, HSRP, VRRP, GLBP and CARP all support IPv6 without using the SRA. Where is the SRA used? Saying it has not been widely implemented, is overstating its current uses. Depending on feedback, perhaps another article will delve deeper into the SRA.

So it ends on a whimper. IPv6 has added OL anycasting, but it is unused by any significant application, and its usefulness is questionable.

SUMMARY

IP unicasting, both OL (on-link) and XL (external-link, off-link), is easy and widely implemented.
OL IP multicasting is easy and common. XL multicasting is more involved and uncommon.
OL IP anycasting is extremely rarely used and limited to IPv6. XL anycasting is easy, and although not common, widely used for DNS.

Topics: IPv6, Anycast

Delve deep into DNSSEC

Posted by Men & Mice on 3/28/14 8:49 AM

By Mr. Carsten Strotmann, one of Men & Mice experts.

BIND 9.10 is the new version of the BIND 9 DNS server from ISC (not to be confused with BIND 10, which is a different DNS server product). We will report in a series of articles about the new features in BIND 9.10. The first beta version of BIND 9.10 was released this week and can be found at ftp://ftp.isc.org/isc/bind9/9.10.0b1/.

BIND 9.10 contains a new command-line tool to test DNSSEC installations. The tool is called delve and it works very much like the well-known dig, but with special DNSSEC validation powers.

delve checks the DNSSEC validation chain using the same code that is used by the BIND 9 DNS server itself. Compared with the DNSSEC testing function in dig +sigchase, delve is much closer to what really happens inside a DNS server.

1.1 A simple lookup

Without extra arguments, delve will query the local DNS server (taken from /etc/resolv.conf) for an IPv4-Address record at the given domain name. It tries to validate the answer received, prints the result of the validation, the requested data and the RRSIG Record (DNSSEC signature) used to verify the data.

1.2 pretty-printing

As with dig, resource record types and network classes can be given in almost any order on the commandline. The switch +multi (for multiline) enables pretty printing; human readable output that is neatly formatted for a 78 column screen.

and IPv6

1.3 tracing DNSSEC validation

delve comes with a set of trace switches that can help troubleshoot DNSSEC validation issues. The first switch, +rtrace, prints the extra DNS lookups delve performs to validate the answer:

In this example, in addition to the MX-Record (Mail-Exchanger) Record, the DNSKEY record (DNSSEC public key) and the DS record (Delegation signer) for dnsworkshop.org, as well as the DNSKEY and DS records for ORG and the DNSKEY for the root-zone "." have been requested. The trust-anchor for the Internet Root-Zone is compiled into delve and acts as the starting trust anchor for the validation.

The switch +mtrace prints the content of any additional DNS records that have been fetched for validation.

+vtrace prints out the DNSSEC chain of validation:

delve is a very useful tool, not only for BIND 9 admins, but for everyone who needs to troubleshoot and fix DNS- and DNSSEC related issues.

Topics: DNSSEC, IPv6, BIND 9

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

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

7 ways of easy access and visibility in the IP Address module

Posted by Dora Vigfusdottir on 11/15/11 9:55 AM

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.
Stay tuned for the next part!

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

ISC and Men & Mice raise the standard for DNS training

Posted by Dagmar Hilmarsdottir on 2/11/11 6:34 AM

Redwood City / Reykjavik – 11 February 2011

Today Internet Systems Consortium (ISC) and Men & Mice announced a joint training program to offer and develop courses on Internet protocols at the cutting edge of Internet operations technology.  Individually both firms provide highly rated training for core Internet technologies such as DNS, DHCP, IPv6 and more.  By combining their course offerings, locations, and teaching staff, the companies will each expand their curricula and their geographic reach. Initially there are five different courses and workshops offered including Introduction to DNS & BIND, advanced DNS & BIND, DHCP, IPv6 Fundamentals, and DNSSEC.

"Increasing knowledge and awareness on DNS, DHCP, IPv6 and DNSSEC is important to both ISC and Men & Mice. We see this partnership as a unique opportunity to jointly strengthen our training offerings and increase information sharing about these critical services at the core of the Internet”, said Jón R. Kristjánsson, CEO of Men & Mice."

ISC develops and distributes the industry leading core Internet software BIND and DHCP.  ISC offers training & consulting to aid in the deployment and the operational aspects of the software.  ISC has conducted training courses on its BIND and DHCP software since 2007.

Men & Mice develops and markets software for IP Address Management and offers training globally on topics including DNS and BIND, DHCP, and IPv6. Men & Mice has offered courses and workshops since 2001. Later this year ISC and Men & Mice will launch a testing and evaluation program by which individuals can be certified as technical or operational experts in these technologies.

"Men & Mice and ISC are both highly regarded technology trainers. Merging the best from our course offerings and increasing our geographic coverage will make quality professional training more widely accessible.  Both companies and their customers will benefit from this partnership and this will grow and strengthen both companies’ training programs,” said Barry Greene, President of ISC."

Read full press release here.

Read more about the training programs offered here DNS & BIND, IPv6, ISC DHCP, DNSSEC trainings.

Topics: IPv6, DNSSEC, DNS, DHCP, Men & Mice

The (IPv4) End is near

Posted by Arni Birgisson on 2/3/11 11:47 AM

On February 1st 2011, IANA allocated two of the remaining seven /8 address scopes to APNIC, which means that there are only 5 left in IANA's address pool.

This triggers a policy at IANA [1] which automatically allocates the five remaining /8's - one to each of the five Regional Internet Registries (RIR). This does not mean that all IPv4 address space is exhausted just yet, because the RIR's will allocate from these new /8's as well as their previous remaining pools, but clearly we are moving closer to the last allocations from the IPv4 address space.
 
Once all IPv4 addresses are allocated to companies and ISPs - all new IP allocations will come from the IPv6 address space only. The two protocols will be running side-by-side for some time, but if you want your content to be available to everybody regardless of IPv4 or IPv6 - now is the time to start planning. 
 
Are you ready for IPv6 yet?

Men & Mice IPv6 Training
 

 

 

Topics: IPv6, IPv4

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