The Men & Mice Blog

Secure Your DNS Across Multiple DNS Service Platforms with Men & Mice xDNS Redundancy

Posted by Men & Mice on 7/10/17 12:50 PM

DNS (Domain Name System) is the most critical aspect of any network’s availability. When DNS services are halted, or slowed down significantly, networks become inaccessible, leading to damaging losses in revenue and reputation for enterprises.

To ensure optimal network availability, many enterprises depend on top-tier managed DNS service providers for their external DNS needs. The basic “table stakes” characteristics of an enterprise-class managed DNS service are high reliability, high availability, high performance and traffic management. However, even the most robust DNS infrastructure is not immune to outages.

Outages may be localized, in which only certain DNS servers in the network are not responding, or, less commonly, system-wide. A system-wide DNS failure can take an entire business offline - the equivalent of power failure in every one of their data centers.

To prevent this, top-tier managed DNS systems have a great deal of built-in redundancy and fault tolerance, yet the danger of a single point of failure remains for enterprises that rely solely on a single-source DNS service.

If no system of DNS is failure proof, this begs the question: what should an enterprise do about it?

Using multiple DNS service providers for ultimate DNS redundancy

DNS availability statistics for managed DNS providers shows that the industry norm exceeds 5 nines (99.999%) uptime. This is the equivalent of about 5 minutes per year downtime. However, this top line number does not provide any detail on the impact of degraded performance, or the cascading effect of a system-wide outage of various duration, on individual enterprises.

To discover the true impact of a potential loss of DNS availability, enterprises need to properly assess the business risk associated with relying on a sole source provider, and compare that with the cost of a second source DNS service. What would a 30-minute loss of DNS cost the business in terms of revenue loss, reputation damage, support costs and recovery? What does it cost to maintain a second source DNS service?

Research amongst enterprises for whom online services are mission critical generally concludes that the cost ratios are in the range of 10:1 – one order of magnitude. Put another way, the cost of one outage is roughly estimated to be ten times the annual cost of a maintaining a second service. A business would have to have second source DNS for ten years to equal the cost of one major DNS outage.

Looking at the odds and costs of outages, many enterprises are opting to bring in a second, or even a third, DNS service to hold copies of critical DNS master zones.

This system of external DNS redundancy boosts DNS availability by:

External-DNS-Redundancy.png

1. removing the danger of exposure to a single point of DNS failure.

2. reducing traditional master-slave DNS redundancy vulnerabilities, where slave zones can’t be changed if the master becomes unavailable.

3. improving infrastructure resilience by hosting critical zones with multiple providers, ensuring continued service availability and updates of changes if one DNS service provider becomes unavailable.

The risky business of maintaining DNS redundancy across platforms

In theory, DNS redundancy across multiple DNS service provider platforms should be the best solution for optimal DNS high reliability, high availability and high performance. In practice, however, the complexity of tasks and scope for error involved in replicating and maintaining identical DNS zones on multiple platforms pose additional threats to DNS availability. The situation is made worse by:

  • A lack of centralized views
  • A lack of workflow automation
  • The difficulty of coordinating multiple platform APIs

This inability to view, synchronize and update identical zones’ data simultaneously can, in itself, lead to errors and conflicts in DNS configuration and result in a degradation of network performance, or even a network outage – the very events that multi-provider DNS redundancy is intended to prevent.

Protect your DNS on multiple platforms with Men & Mice xDNS Redundancy

Breaking new ground in the battle against DNS disruption, the Men & Mice xDNS Redundancy feature provides the abstraction level necessary to replicate and synchronize critical DNS master zones across multiple DNS service provider platforms, on-premises, in the cloud, or in hybrid or multi-cloud environments.

Men & Mice xDNS provides a unified view and centralized management of DNS data, regardless of the DNS service provider platform. Network administrators and other authorized users can use xDNS to perform necessary updates to their network’s DNS, as well as benefit from building automation with the powerful Men & Mice API, instead of having to dig around in different DNS platforms and deal with coordinating conflicting APIs. DNS-redundancy-and-Men-and-mice-suite.png

Combined with the flexibility of building automation on top of the Men & Mice Suite, xDNS offers you the freedom to better distribute your DNS load based on zone priority, performance requirements and accompanying costs. With xDNS, you are better equipped to steer the tiered price points of externally hosting, for example, critical high-performance or less essential low-performance zones, and utilize the DNS service best suited to your situation at a given time.

 


How xDNS Redundancy Works

Using the Men & Mice xDNS feature, create a zone redundancy group by selecting critical zones from DNS servers and services such as BIND, Windows DNS, Azure DNS, Amazon Route 53, NS1, Dyn and Akamai Fast DNS.

Once an xDNS zone redundancy group has been created, xDNS assists the administrator in creating identically replicated zone content, resulting in multiple identical master zones. Additional zones can be added or removed from the xDNS group as required.

All changes initiated by the user through Men & Mice, both the UI and API, will be applied to all zone instances in the group. All changes made externally to zones existing in the xDNS group, will be synchronized to all zones in that particular xDNS group. However, if DNS record conflicts arise, xDNS will alert the user and provide an option on how to resolve conflicts before the group is re-synchronized.

If an xDNS zone is not available for updating, for instance if one DNS service provider experiences an outage, that zone will be marked as out-of-sync. Once the zone becomes available again, it will be automatically re-synchronized and will receive all updates that were made while the DNS service was unavailable.

Men & Mice and NS1

NS1, the leading intelligent DNS and traffic management provider, recognizes the growing need for diverse application resiliency. NS1 has joined forces with Men & Mice in improving the efficacy of external DNS redundancy. Kris Beevers, Co-founder and CEO, says:

"Leveraging multiple managed DNS networks is the clear best practice for maintaining 100% uptime in today's rapidly evolving operational environment.  Configuring and operating multiple managed DNS services can be a complex, time-consuming process.  NS1 is excited to partner with Men & Mice to help enterprises minimize management overhead and seamlessly enable redundant DNS. xDNS Redundancy is well-suited to enable multi-network DNS without the usual headaches."

Men & Mice xDNS – making external DNS redundancy truly resilient

DNS redundancy is a great concept on paper, but a daunting challenge in practice. With xDNS, enterprises can seek out second, or even third source DNS services, confident in the knowledge that their DNS, and ultimately their business, will truly be safer that way.

Magnus Bjornsson, Men & Mice CEO, considers xDNS an important step towards providing enterprises with greater, and more reliable, network availability.
“Recent prominent network outages once again illustrate the critical importance of building more effective network resiliency through a powerful and secure system of DNS redundancy. Men & Mice xDNS provides a simple way for companies to manage their DNS on multiple external platforms, with the Men & Mice Suite software automatically taking care of the replication and synchronization of data in a reliable and consistent manner. We are looking forward to cooperating with NS1 on developing xDNS and extending DNS redundancy offerings.”

Men & Mice xDNS takes the ‘daunt’ out of maintaining external DNS redundancy, providing the centralized views and control necessary to reduce the risk of network exposure to a single point of failure, improve network reliability and performance and bolster the successful mitigation of DDoS attacks and other potentially harmful DNS incidents.

To learn more about xDNS Redundancy, check out the xDNS webinar, jointly presented by Men & Mice and NS1.

Check out the video to discover how it DDI all comes together:

Or try it out in the Men & Mice Suite:

New Call-to-action

Topics: DNS, Security, High availability, DNS redundancy, DDoS, External DNS, Failover

Men & Mice Breaks New DDI Ground with xDNS Redundancy and Multi-Cloud IPAM

Posted by Men & Mice on 6/29/17 1:30 PM

The joke goes: “How did God create the universe in seven days? No legacy infrastructure.”

Funny (or not) as that may be, how to make the most of legacy infrastructure in the age of accelerating technological disruption and rapid cloud services adoption, is the harsh reality most enterprises face today.

Well-known for its fast, reliable and efficient performance on large enterprise networks, the Men & Mice Suite already has a reputation as the go-to, enterprise-class, software overlay DNS, DHCP and IP Address Management (DDI) solution. With the release of Version 8.2 of the Suite, Men & Mice further solidifies our position as the commercial DDI solution best equipped to help large enterprises capitalize on legacy infrastructure, while adopting cloud services to advance business agility and scalability.

The Men & Mice Suite – IP wherever you are 

architecture.png

Almost three decades of expert innovation in DNS, DHCP and IP Address Management has given Men & Mice unique insight and expertise into creating solutions that confidently mitigate the shocks of technological disruption.

Built as an enterprise-grade, back-end agnostic solution and deployed on top of DNS and DHCP infrastructure, the Men & Mice DDI Suite pulls together critical network data from wherever it is kept, on-premises, in the cloud, hybrid cloud or multi-cloud, and turns a potential hot mess into a comprehensive overview, accessed and controlled from a single pane of glass.

The Men & Mice Suite provides consistent administrative controls on heterogeneous networks, with unparalleled support for Windows DNS and DHCP, BIND, Unbound, PowerDNS, ISC DHCP, Kea DHCP, Cisco IOS, OpenStack and Azure DNS and Amazon Route 53.

Designed to integrate seamlessly with the VMware Orchestrator framework, the Men & Mice Suite VMware vRealize Orchestrator plug-in allows for fast and efficient provisioning of virtual machines.

The first DDI solution to fully integrate with Microsoft Active Directory (AD), the Men & Mice Suite incorporates management of users and groups through AD, while granting access rights and building up roles and responsibilities through the Men & Mice Suite, ensuring advanced and secure granular role-based access management.

Offering you the flexibility to control your network as it suits you best, the Men & Mice Suite provides three powerful interfaces: the Men & Mice management console, the Men & Mice web interface, and, the strong and consistent Men & Mice API, communicating in SOAP, JSON-RPC and REST. The Men & Mice API, especially popular with our customers, provides the robust abstraction tools necessary to build and extend automation.

New in Men & Mice Suite Version 8.2

From Version 8.2, the Men & Mice Suite’s back-end agnostic capabilities are extended to include advanced, multi-cloud IP Address Management and integrated support for external DNS service providers.

Building on the flexibility of its architecture, Men & Mice Suite Version 8.2 consolidates on-premises and cloud networks in one view and point of access through support for IPAM in Azure and AWS, and by adding support for DNS service providers NS1 and Dyn to existing Men & Mice support for Azure DNS and Amazon Route 53.

Unique on the DDI market, and new in Version 8.2, the Men & Mice xDNS redundancy feature enables multi-platform DNS redundancy for ultimate network high availability, and successful mitigation of the fallout from DDoS attacks and other DNS failures.

xDNS redundancy provides the abstraction level necessary to replicate and synchronize critical DNS zones across multiple DNS service provider platforms, eliminating the possibility of a single point of failure resulting from dependency on one external DNS service provider.

Men & Mice - Changing the way the world sees networks

As IT matures into a key element for easily scalable business development and product delivery, and ultimately a driver of business growth, the need for high network availability, reliability and performance escalates.

For Magnus Bjornsson, Men & Mice CEO, delivering DDI products that boost business performance by bridging the gap between on-premises, cloud, hybrid cloud and multi-cloud network environments, is a challenge happily accepted. “We live in a world that’s getting more complicated by the minute. Cloud vendors are continuously bringing powerful new services online and enterprises are wrestling with how and when to best utilize them. Men & Mice Suite Version 8.2 is a landmark release, tackling this great challenge with innovative new features. Consolidating hybrid and multi-cloud IP Address Management in a single view and bolstering DNS availability across service provider platforms with xDNS redundancy, are great steps towards strategically improving the most critical of a company’s IT assets – its network. The Men & Mice Suite, used to run some of the largest corporate networks on the planet, is designed to give you the freedom and flexibility to use the back-end platform you want, to build the network you need.”

Looking for more?

Follow these links for more information on Men & Mice xDNS redundancy feature, or multi-cloud IP Address Management.

To see Men & Mice xDNS redundancy in action, check out the xDNS Redundancy webinar, jointly presented by Men & Mice and NS1.

Curious about how the Men & Mice Suite can benefit your network? Get in touch with one of our Men & Mice Sales Engineersor get your free Version 8.2 license for a complimentary 30-day trial experience.

New Call-to-action

Topics: IPAM, DNS, Security, CLOUD, High availability, DNS redundancy

Keep IT outages off your network with redundant DNS

Posted by Men & Mice on 5/31/17 11:43 AM

British Airways is still reeling after a weekend IT system outage that affected more than 1,000 flights and stranded approximately 75,000 passengers at Heathrow and Gatwick airports. Some sources speculate that the compensation costs could be similar, if not considerably more than the $100 million that last year’s crippling IT failure cost Delta Airways.

Statements from British Airways blamed the IT meltdown on a power supply issue at a data center, while ruling out any possibility of a cyber attack. Though it’s far too early to speculate on exactly how a power supply problem could knock a thousand flights off schedule, one thing is certain: British Airways’ Disaster Recovery Plan failed spectacularly - where system redundancy should’ve kicked in, there was none.

British Airways’ woes serve as an unpleasant, but urgent, reminder that the way we back up our systems is sometimes even more critical than how we run it day-to-day. As it goes with life insurance or a last will and testament, there’s no point in waiting until your plane goes down (or fails to go up) before you start getting your house in order.

The most effective way of providing ‘life insurance’ for your network, is to make sure that exactly mirrored copies of critical parts, such as DNS, are replicated to other locations away from your own data centers, thereby providing system redundancy. That way, if your data centers are knocked out, due to power failure, human error or malicious cyber activity, this critical service is still active, ensuring service continuity and retaining critical operational data – and keeping your passengers happy in the air, instead of sleeping on yoga mats in conference centers.

So how do you make your DNS redundant?

In a traditional DNS setup, a DNS master-slave deployment is used to maintain network availability, with one DNS server as the single writable source, or the master (see Diagram 1). Other DNS servers, or slaves, serve as back-ups, but rely on the availability of the master for new data. If the master becomes unavailable, critical DNS zones cannot be changed, and as ‘inferior’ entities, slaves can only serve zones temporarily in absence of their master.

Reduntant-dns-1.png

(Diagram 1)

Depending exclusively on a master-slave deployment poses a significant risk to a company in the event of any DNS outage. The risk is compounded when automation has been built on top of the DNS infrastructure, as the automation piece will halt until the master has been restored, or a slave has been manually promoted to the status of master. However, manual change, especially on networks serving hundreds of thousands internal and external customers, is not only very complicated, but carries a huge potential for error. When combined with the time factor and the complexities related to siloed teams and applications, reverting to manual change can too easily lead to disaster.

DNS redundancy is the process of expanding the choice of available DNS nameservers and distributing them between separate networks - basically keeping your DNS servers replicated in a lot of places, and pointing it at a lot of places.

To further limit risk, companies are increasingly turning to storing their critical external DNS zones on-premises, as well as with more than one specialized DNS or cloud provider that possesses the security, equipment and expertise to handle large amounts of DNS traffic from a variety of sources successfully. Ideally, the most effective redundant DNS architecture will have multiple masters, each possessing the advanced functionality to act as a primary server responding to DNS queries (see Diagram 2). Keeping the multiple master DNS records up to date and in sync can prove a challenge, but one that is totally outweighed by the ultimate benefits of continuous high availability.

Reduntant-DNS.png

(Diagram 2)

Why make your DNS redundant?

Sensible as it may seem, maintaining DNS redundancy is an IT expense that many enterprises try to avoid in order to keep operational costs down – a bit like putting off getting life insurance because it feels like such a waste to spend on the what ifs of tomorrow when all systems seem to be running just fine today. Yet these kinds of short-term savings can too easily turn into a “save a million, lose a billion” scenario, as (quite possibly) several airline bosses have recently discovered the hard way.

Keeping the running of your DNS diverse and distributed is an essential backup mechanism for any company wishing to stay connected, providing services and generating income 24/7/365.

For more information on how to manage redundant DNS complexity from one point of access, gain secure versatility and keep down unexpected expenses.

Topics: Redundant DNS, High availability

Ready for another look at DNSSEC?

Posted by Men & Mice on 4/12/17 8:32 AM

dnssec.pngSince the dawn of DNS, it has been a system regularly experiencing phases of increased vulnerability. Yet never before has it been as vulnerable to the escalating size of DNS attacks as in recent years, most notably in 2016.

Advice on how to prevent, or at least mitigate, all manner of attacks on DNS proliferates, and every security vendor and his uncle promises heaven and earth, if only you bought into their solutions. While you should investigate all options and carefully devise a wholescale security strategy, together with overhauling your network’s architecture design to close unnecessary gaps and eliminate weak links, it is critical that you don’t leave one of the most obvious DNS security stones unturned – DNSSEC. 

After Dyn went down so spectacularly last October during the biggest DDoS attack recorded to date, Geoff Huston gave an excellent talk at RIPE 73, speculating on possible ways to mitigate DNS attacks. In the process, he also managed to remind the audience that one of the ways to make DNS (and conversely, the internet) safer would be to fully implement DNSSEC. Fully deployed, DNSSEC ensures that the end user is connecting to the intended, and verified, website or service corresponding to a specific domain name. In this way, DNSSEC protects the directory lookup and complements other security technologies, such as TLS (https:). DNSSEC is not a magic bullet and won’t solve all internet security issues, but in a world of constantly multiplying mutations of attacks on DNS availability, it sure can’t hurt to add it to your DNS security repertoire.

That said, DNSSEC would be a much happier prospect for most of us if it were not so tedious to set up. Still, like all things worthwhile, a little bit of initial effort can take you a long way. To help you get a grip on the ins and outs of DNSSEC, Men & Mice’s DNS expert Carsten Strotmann recently added a DNSSEC zone signing tutorial to our useful selection of DNSSEC resources, all bound to help you take steps towards DNSSEC with greater confidence. The DNSSEC zone signing tutorial follows on from Carsten’s highly rated November 2016 webinar on DNS and DNSSEC monitoring – Strategy and Tools. An added bonus is the scripts of 15 essential DNS and DNSSEC monitoring tests which can come in pretty handy once you’ve set the DNSSEC wheels in motion.

In the greater scheme of dealing with DNS vulnerabilities, it’s reassuring to know that organizations such as the IETF are dedicated to coming up with solutions to better protect the internet at the top levels of design. The DNS PRIVate Exchange Working Group (DPRIVE – a simply brilliant acronym, as they go) is tasked with developing mechanisms to enable the confidentiality of DNS transactions. While DNSSEC revolves around ensuring that data remains unchanged during communication, the data itself remains open, so to speak. DPRIVE is working towards concealing the data, primarily focusing on providing confidentiality between DNS Clients and Iterative Resolvers, but perhaps later on progressing towards providing end-to-end confidentiality of DNS transactions. In practice, these developments mean that somewhere down the road, it will hopefully be possible to:

  1. provide DNS servers with knowledge on how the structure of the internet works so DNS queries will have a straighter and narrower path, only asking for the data that is really required and not having to put in full requests that have to go all the way to the root name servers.

  2. encrypt communication between the DNS resolver (usually on the internet provider’s network) and authoritative servers on the internet so that data transmitted can’t be harvested by ill-intentioned entities.

One of the side benefits of this type of encryption is that the underlying transport protocol will likely switch from UDP to TCP, thereby providing the ‘handshake’ required for secure communication and making spoofing so resource intensive that it will take the easy fun out of the kind of DoS attacks we’ve seen escalating in recent years.  

With all new and generic top level domains, as well as country code top level domains DNSSEC signed today, the implementation of DNSSEC to make the internet more robust and secure is quickly turning into the rule, rather than the exception. Which begs the question: why wait till tomorrow when you can begin implementing DNSSEC on your domain today?

Free trial of the Men & Mice Suite

 

Topics: DNSSEC, DNS, DANE

Men & Mice Suite Version 8.1 – Loving you long time

Posted by Men & Mice on 1/24/17 10:10 AM

It’s January, so it must be time for the annual Men & Mice Suite LTS release, aka long term support release.

A version upgrade of the Men & Mice Suite is scheduled for release three times a year. The versions are differentiated as Long Term Support (LTS) releases, and feature releases.

The first release in January of every year is an LTS release. By LTS we mean this version will be supported for two years after its initial release date. The two feature releases have a shorter LTS.pngsupport cycle.

While the primary focus of the feature releases is to introduce new functionality and features, the primary focus of the LTS releases is to fine-tune and improve newly introduced features, as well as to improve the stability and performance of the Men & Mice Suite in general. We like to see our annual LTS release as the prime example of our commitment to quality, superior functionality and keeping our solution as fast, simple and stable as our customers have become accustomed to.

To have a peek at what good features found their way into the Suite in 2016 and are fine-tuned in Version 8.1, check out details on our Windows Server 2016 support, REST API and VMware plug-in here. If you want to sink your teeth into the REST API, read our detailed article on the subject. And if you’re curious about support for ISC Kea DHCP and Windows Server 2016 Response Rate Limiting, look no further than here.

Finally, read more on how Men & Mice also made inroads into the cloud in 2016 with support for Azure DNS, developed in close cooperation with the Microsoft Azure Team.

One brand new tidbit added to 8.1. is a beautiful new look to the console. A new, fresher font and some easy-to-follow icons are sure to make the superior Men & Mice Suite ergonomic experience all that much more visually pleasing. Enjoy!

All further information on Men & Mice Suite Version 8.1 is obtainable from the Documentation Release Notes.

New Call-to-action


If you’d like to meet up with Men & Mice in person, please come and visit us at Booth E54 at Cisco Live Berlin at the end of February.

If you can’t make it to Berlin, let Men & Mice come to you - sign up for the Bind 9 Logging Best Practices webinar on February 2nd!

Happy January all the way from a not-so-chilly Iceland,

The Men & Mice Team

 

Topics: Men & Mice Suite, DDI

5 ways to have fun while not doing IPAM this Christmas

Posted by Men & Mice on 12/23/16 7:06 AM

At the end of a year overshadowed by Mirai botnets, leaked emails, late-night Twitter rants and talk of upgrading the dormant Cold War to Version 2.0,  perhaps this Christmas is the ideal time to sit back, pop that (nut) roast in the oven and relax with a little something different. Have your pick from this short collection of fun IPAM-like things to enjoy this festive season.jolakort2016.jpg

  1. First up, a highly entertaining TED talk by Mikko Hypponen, well-known security specialist from F-Secure. Hilarious anecdotes, most notably when tracing the makers of the first PC virus (Brain A), help to make Mikko’s talk on all things cybercrime just as relevant today as it was when he first delivered it in 2011.
  2. If Mikko’s talk set in motion a nostalgic longing for the good old days of ‘hobby’ viruses, what better place to visit than the Malware Museum? Take a walk on this ‘formerly’ wild side and rediscover the almost cutesy retroviruses of yore. OK, not quite so yore, only the 80s and 90s, but still tech yore, really.

It’s hard to believe Casino and Walker may have paved the way for the massive effects of a Mirai botnet or bizarre developments such as ransomware as a service, but hey, everything’s got to start somewhere, doesn’t it?   

  1. Speaking of Mirai. Not satisfied with taking the DNS out of Dyn in October in the biggest DDoS attack witnessed so far, a new Mirai strain set its sights on routers and modems in November, causing an outage affecting 900,000 Deutsche Telekom users and possibly leaving up to 5 million devices vulnerable With commercial routers biting the malware dust in such spectacular fashion, perhaps it’s just better to build your own. This handy Ars Technica guide to building a Linux router makes it look easy. Well, at least for some of us.
     
  2. Lets face it. All things DDI arent very funny. Actually, very little is. But that doesnt stop some of us from trying to make it funny. And the rest of us from trying to explain the trying to everyone who doesnt get it. If you are really at a loss for fun things to do this Christmas, then maybe this SysAdmin thread will liven it up for you. Or maybe not. Worth a shot for some of the comments on the comments, though!
  1. Last but not least. Some useful DDI tips and tricks as described by the 13 Icelandic Yule Lads. Monitoring DNSSEC, doing IPAM subnet discovery or sniffing out rogue IP addresses take on a whole new meaning if you do it with the help of the ogress Grylas boys. What can possibly go wrong if Doorway Sniffer, Pot Scraper and Sausage Swiper try to find ways to do DDI better? This seasonal eBook compilation makes for easy bed-time reading.
    Be warned: not for the faint of heart!

Merry Christmas from the very merry bunch at Men & Mice! 

Topics: IPAM

Men & Mice Suite Version 7.3 – Plugging into VMware while having a REST

Posted by Men & Mice on 11/10/16 9:12 AM

Men & Mice Suite Version 7.3 has arrived - and not a minute too soon! Yet considering that it’s jam-packed with goodies such as a brand-new REST API, VMware vRealize Orchestrator plug-in and further support for Windows Server 2016, it was definitely worth the wait.

Let’s take a quick peek at what Version 7.3 has in store for our customers.

Taking a break with the REST API

API.png

API. In the world of the Internet, it means Application Programming Interface. In the world of the Icelandic language (where Men & Mice has its roots) it means … monkey. Literally. And maybe just as well – a good API, with or without hair, really does seem to make life so much better.

Monkey business or no monkey business, the Men & Mice REST API is sure to offer customers a very welcome extra set of hands - and feet, so to speak – with which to create workflows and write handy scripts for the import and export of data, amongst other things.

Used by browsers, REST (Representational State Transfer) is often considered to be the language of the internet. By using HTTP requests to GET, POST, PUT and DELETE data, REST paves the way for two computers to communicate over the internet by one acting as a web server and the other as a web browser. Making use of a stateless protocol, RESTful services exhibit particularly fast performance, reliability and scalability.

The Men & Mice REST API includes all the functionality of the existing Men & Mice SOAP API and JSON-RPC, but delivers the added advantages of ease of use, combined with a rich set of tools and support libraries. Additionally REST, as a resource-based instead of a standards-based API, means users gain considerably greater operational flexibility.

More information on how to get the most out of REST can be found in the Men & Mice REST API article.

Plugging in where it matters – VMware vRealize Orchestrator Plug-In

Men & Mice takes a further step towards simplifying virtualization by introducing the VMware vRealize Orchestrator plug-in. Designed to integrate seamlessly within the VMware Orchestrator framework, the Men & Mice Suite VMware plug-in allows for fast and efficient provisioning of virtual machines.

 

vmware_plugin.png

 

When a Men & Mice Suite user puts in a request for a new virtual machine (VM), the vRealize Orchestrator receives the next available IP address from the requested subnet, together with other essential configuration information. vCenter creates the VM and communicates the changes back to the Men & Mice Suite, which then updates DNS infrastructure accordingly. Additionally:

  • the Men & Mice Suite’s custom properties allow further customization of the VM’s visibility and status.
  • VM information retained in the Men & Mice Suite enables VM tracking, synchronization and updates, including the release of IP addresses after a virtual server is taken down.
  • the Men & Mice Suite talks to DNS servers and registers DNS entries and other changes, such as updates to DNS policies, thereby consolidating DNS data required by the vRealize Orchestrator.

By plugging into the vRealize Orchestrator, the Men & Mice Suite enables integrated functionality that not only saves time, but also strengthens security, eliminates errors of configuration and ensures improved and continuously synchronized network manageability.

Windows Server 2016 Support Released in Tandem with General Availability

Men & Mice Suite support for primary Windows Server 2016 DNS and DHCP features was already included in Version 7.2, released in May 2016. A stand-out feature was support for Response Rate Limiting, which significantly reduces the impact of a Denial of Service (DoS) attack on servers.

With Windows Server 2016 achieving General Availability in September 2016, Men & Mice expands its support for the following additional Windows Server 2016 features:

DNS policies

DNS policies grant a user control over how queries are handled based on specific criteria. These criteria can, for example, be used in the following scenarios:

  • High availability of DNS services
  • Traffic management
  • Split brain DNS 
  • Filtering
  • Forensics
  • Redirection based on date/time

Specific types of policies are:

  • Zone transfer policies
    Essentially used to define how zone transfers take place, zone transfer policies control zone transfer permission on the server level or the zone level. 
  • Recursion policies
    Control how the DNS server performs recursion for a query. 
  • DNS query resolution policies
    Used to specify how incoming DNS queries are handled by the DNS server. 

IPv6 root hints

The IPv6 root servers can now be used for performing name resolution. 

DANE TLSA records

DANE, or DNS-based Authentication of Named Entities, allows a domain owner to specify in a particular DNS record which certificates authorities are allowed to issue for the domain.

The Men & Mice Suite Release Notes provide more detail on other minor improvements and fixes that form part of the Version 7.3 Release.

That wraps it up for a quick round-up of all things new and shiny that the Men & Mice Suite Version 7.3 has to offer. If you’d like to jump right in and try out these new features, treat yourself to a Version 7.3 free trial. 

Men & Mice Suite trial

 

Coming up in December is the last in our 2016 series of webinars, this time focusing on DNS high availability tools. Don’t forget to sign up!

 

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

Men & Mice Web Service: REST API

Posted by Men & Mice on 11/10/16 6:42 AM

Introduction

Men & Mice is expanding our web service offerings by adding a REST API web service to the existing SOAP/XML and JSON-RPC services.

This article serves as an introduction to the Men & Mice REST API, providing information on background, purpose and functionality.

What is REST?

REST, or more specifically Representational State Transfer, is often described as the language of the Internet. An architectural style for distributed hypermedia systems, REST was first introduced by Roy Fielding in his doctoral dissertation at UC Irvine in the year 2000.

Fielding’s experience as one of the principal authors of the HTTP specification led to his development of REST as a set of principles and constraints for communication between computers on the Internet. The six architectural constraints unique to REST are client-server separation, statelessness, cacheability, uniform interface, layered systems and code on demand – the latter being the only constraint that is optional.

According to Fielding, the purpose of creating REST was to simplify and enhance the distribution of data between systems. Given how widespread REST has become, it’s safe to say Fielding’s mission has been accomplished. Architectural properties affected by REST are performance, scalability, simplicity of a uniform interface, modifiability of components, visibility of communication between components, portability of components and reliability.

Since its introduction, REST has gained much popularity, likely due to its positive effect on architectural properties and its simplicity, both particularly critical in the era of exponential increases in cloud usage offerings. Today, the majority of new web services are designed as RESTful[1] services instead of SOAP/XML, JSON-RPC, or other types of communications.


Why add a REST API to the Men & Mice Suite?

Men & Mice web services in the form of SOAP/XML and JSON-RPC provide an extensive set of commands to configure and control all aspects of the Men & Mice Suite. However, REST has become the first choice of communication for web service applications. By making use of a stateless protocol, RESTful services exhibit particularly fast performance, reliability and scalability. Additionally, REST’s simplicity generally makes it easier for users to get started and engage with the service.

The greatest difference for users between SOAP and REST is that SOAP as a standards-based web service access protocol is more rigid in execution, whereas REST as a resource-based web service provides greater flexibility. In most cases, a user will only need a browser or a simple command line tool such as cURL to access data from a RESTful web service.


How does the Men & Mice REST API work?                                               

In REST, the focus is on resources. You specify a resource with a URL (Uniform Resource Location) and then apply an operation on the resource using an HTTP method.

The Men & Mice REST API supports the four most common HTTP methods: GET, PUT, POST and DELETE.

  • GET – Retrieve a resource (read)
  • PUT - Modify an existing resource (update)
  • POST - Add a new resource (create)
  • DELETE - Remove a resource (delete)

The resources or the objects found in the Men & Mice Suite are:

  • AddressSpaces
  • ADForests
  • ADSiteLinks
  • ADSites
  • ChangeRequests
  • CloudNetworks
  • Clouds
  • Devices
  • DHCPAddressPools
  • DHCPExclusions
  • DHCPGroups
  • DHCPReservations
  • DHCPScopes
  • DHCPServers
  • DNSRecords
  • DNSServers
  • DNSViews
  • DNSZones
  • Folders
  • Groups
  • Interfaces
  • IPAMRecords
  • Ranges
  • Roles
  • Users

 
An example of a URL referring to a DNS zone would be:

            http://mmsuite.company.com/mmws/api/DNSZones


To get all the zones defined in the Men & Mice Suite you would use HTTP GET:

            GET http://mmsuite.company.com/mmws/api/DNSZones


To get a specified zone, e.g. test.menandmice.com, you would also use HTTP GET, but with a reference to the specific zone:

            GET http://mmsuite.company.com/mmws/api/DNSZones/test.menandmice.com.

 
The Men & Mice REST API understands two types of content: JSON and XML. The content type of the response will depend on the type of content in the request. If there is no content in the body of the request, the web service will check for a clue in the HTTP header fields "Content-Type" and "Accept". If either of the fields exist and contain "application/json", it will return a JSON formatted response. If either of the fields exist and contain "application/xml" or "application/soap+xml", it will return an XML formatted response. If no clues can be found, it will select JSON as the response format.

It’s also possible to mix these two content types during the same session and the web service will simply respond with JSON if this was a JSON request, or XML if the content type detected was XML.

The Men & Mice REST API is built on the same code base as both SOAP/XML and JSON-RPC. However, some of the commands you will see in SOAP/XML and JSON-RPC are not a part of the REST API. The reason for this is that in REST, the focus is on resources, not commands. You can, however, execute all the commands found in SOAP/XML and JSON-RPC using the URL: api/command/<command>.  For example, to get all orphan DNS records found in your Men & Mice Suite, you can say: 

            GET http://mmsuite.company.com/mmws/api/command/GetOrphanReverseDNSRecords


Orphan DNS records are PTR records where the corresponding A/AAAA record is missing.

For possible commands, please refer to the Men & Mice SOAP reference manual.


Arguments

The Men & Mice REST API supports many arguments that can be added to the URL. For example, when getting zones you can say:

            GET http://mmsuite.company.com/mmws/api/DNSZones?limit=2&pretty=true

This would return to you a list of zones in the Men & Mice Suite. At the most two lists would be returned, with the output made easier to read by adding lines and spaces.

There are a few arguments that are always available, no matter what resource you are referring to:

  • pretty – If set to ‘true’ it will make the response more readable.
  • server - Name or address of a Men & Mice Central server to connect to.
  • loginName - The name of the user who wants to log in.
  • password - The password for the user.
  • session - An ID of a valid session.

These arguments are only optional. You don't need to use arguments to log on to a server. The Men & Mice REST API offers different types of authentication, such as Basic Authentication, Windows NTLM and Kerberos. Note that in order for a user to be able to use the REST web service, the user has to have the applicable permission to use the web user interface.

There are some arguments that you can provide in many cases when using the HTTP GET method:

  • filter - Filtering criteria for the result returned.
  • offset - Specifies the offset to use when listing the results. A value of 0 starts with the first result.
  • limit - The maximum number of results to return.
  • sortBy - The name of the field to sort by.
  • sortOrder - The sort order to use.

When adding, or changing a resource, you will need to provide some data. In most cases the data will be provided as a body of the HTTP request. Data can also be provided as an argument. The server will understand that you are providing something that should be a part of the data. For example, when adding a DNS record, instead of providing a body with the HTTP method POST, you can say instead:

            POST http://mmsuite.company.com/mmws/api/DNSZones/test.menandmice.com./

                        DNSRecords?dnsRecord={ "name": "restest", "type": "A", "data": "1.2.3.11"}

 

Filter arguments

The filter argument is a powerful argument that can be provided with most of the HTTP GET methods. It allows you to limit the result you get to only the items you want to see. You can use wildcards and regular expressions with a filter.

The filter has the following format:

            [<property>:][!][^]<value>[$]

Both <property> and <value> can be quoted using " in case they contain characters that might confuse the filter, such as a space. The "!", "^" and "$" are all optional where the "!" symbol means ‘does-not-match’, the "^" sign means ‘starts-with’, and the "$" sign means ‘ends-with’.

 

Some examples:

Filtering by string "mycorp" on all properties:

            filter=mycorp

Filtering by string "mycorp" on property "name":

            filter=name:mycorp

Filtering by string starting with "mycorp" on property "name":

            filter=name:^mycorp

Filtering by string not ending with "mycorp" on property "name":

            filter=name:!mycorp$


If the text must contain whitespace, it must be quoted to filter by string, not starting with "requested by" on property "comment":

            filter=comment:"!^requested by"


The same applies if the property name contains whitespace, so to filter by string "mycorp" on property "Company Name":

            filter="Company Name":mycorp


When getting zones, the following filter can be used to get all master zones, excluding reverse zones:

            filter=type:^Master$ name:!arpa.$


Getting only zones with name "domain.com.":

            filter=name:^domain.com.$


Getting only zones ending with the name "domain.com.":

            filter=name:domain.com.$


The following examples illustrate the usage of a filter when getting DNSRecords. The next filter will get all records containing the name "time" from within the specified zone:

            filter=name:^time$

Getting all A records from within the specified zone:

            filter=type:^A$

Getting all records with data "ntp":

            filter=data:^ntp$

Getting all A records with the name "time":

            filter=type:^A$ name:^time$

 

Men & Mice REST API in action - examples 

Several great tools are available for working with web services, such as Postman and cURL.

Postman is highly recommended, especially for those interested in testing web services. Postman allows the testing of requests, after which it can be asked to generate code snippets for that request in different programming languages.

cURL is a popular command line tool that is available on most platforms. It is installed by default on most Unix flavors. For Windows, it can be downloaded from https://curl.haxx.se  

cURLl can be handy when you want to export data or combine data with simple scripts. The examples on the following pages were created by trying out the REST API using cURL.

For these examples, let's assume that our web service is running on the server mmsuite.company.com, our user name is "john" and our password is "secret". 

$ curl --user john:secret -X GET http://mmsuite.company.com/mmws/api/DNSServers

{

  "result": {

    "dnsServers": [

      {

        "ref": "DNSServers/3",

        "name": "a-win2008r2.mmsuite.company.com.",

        "resolvedAddress": "172.17.0.17",

        "port": 1337,

        "type": "MS",

        "state": "OK",

        "customProperties": {},

        "subtype": "Win2008",

        "enabled": true

      }

    ],

    "totalResults": 1

  }

}


Since we didn’t provide any information about what kind of content type we wanted, the server responded with JSON output. If we want to get the result back in XML format, we can simply add the XML "Content-Type".

$ curl --user john:secret --header "Content-Type: application/xml" -X GET http://mmsuite.company.com/mmws/api/DNSServers

<response>

  <result>

    <dnsServers>

      <dnsServer>

        <ref>DNSServers/3</ref>

        <name>a-win2008r2.mmsuite.company.com.</name>

        <resolvedAddress>172.17.0.17</resolvedAddress>

        <port>1337</port>

        <type>MS</type>

        <state>OK</state>

        <customProperties />

        <subtype>Win2008</subtype>

        <enabled>1</enabled>

      </dnsServer>

    </dnsServers>

    <totalResults>1</totalResults>

  </result>

</response>

 

 
Now let's try to use filters and get a list of all reverse zones in the Men & Mice Suite.

$ curl --user john:secret -X GET "http://mmsuite.company.com/mmws/api/ DNSZones?filter=name:in-addr.arpa.&pretty=true"

{

  "result": {

    "dnsZones": [

      {

        "ref": "DNSZones/10",

        "name": "1.5.2.in-addr.arpa.",

        "dynamic": false,

        "adIntegrated": false,

        "dnsViewRef": "DNSViews/3",

        "authority": "a-win2008r2.remote.mm.lab.",

        "type": "Slave",

        "dnssecSigned": false,

        "kskIDs": "",

        "zskIDs": "",

        "customProperties": {}

      },

      {

        "ref": "DNSZones/11",

        "name": "10.in-addr.arpa.",

        "dynamic": false,

        "adIntegrated": false,

        "dnsViewRef": "DNSViews/3",

        "authority": "a-win2008r2.remote.mm.lab.",

        "type": "Slave",

        "dnssecSigned": false,

        "kskIDs": "",

        "zskIDs": "",

        "customProperties": {}

      }

    ],

    "totalResults": 2

  }

}


Notice the quotation marks around the URL and the arguments. The reason for this is that we are using characters such as "&" that might confuse the command line. By putting quotation marks around it, we are saying that everything inside the quote is a part of the data and should not be interpreted in a different way.

Here is another great example of how powerful the filters are. Let's find all A records starting with “vm” in the zone dev.lab.

$ curl --user john:secret -X GET "http://mmsuite.company.com/mmws/api/ DNSZones/dev.lab./DNSRecords?filter=type:^A$ name:^vm&pretty=true"

{

  "result": {

    "dnsRecords": [

      {

        "ref": "DNSRecords/374",

        "name": "vm-1",

        "type": "A",

        "ttl": "",

        "data": "10.4.4.3",

        "comment": "",

        "enabled": true,

        "dnsZoneRef": "DNSZones/20"

      },

      {

        "ref": "DNSRecords/376",

        "name": "vm-1",

        "type": "A",

        "ttl": "",

        "data": "10.4.4.1",

        "comment": "",

        "enabled": true,

        "dnsZoneRef": "DNSZones/20"

      },

      {

        "ref": "DNSRecords/377",

        "name": "vm-1",

        "type": "A",

        "ttl": "",

        "data": "10.4.4.2",

        "comment": "",

        "enabled": true,

        "dnsZoneRef": "DNSZones/20"

      }

    ],

    "totalResults": 3

  }

}


Note that all of the GET commands can be executed in a simple browser. When you enter a URL in a browser, it will send an HTTP GET command to the server you are referring to. This can become handy if you don't have cURL installed. You can try this by opening a browser, entering the address of your Men & Mice Web Server and appropriating a REST resource, e.g.

            http://menandmice.com mmws/mmws/api/DNSZones&pretty=true

If your Men & Mice web service is configured to allow Basic Authentication or Windows Authentication (NTLM or Kerberos), it will prompt you for a user name and password.


Scripts or programming languages

Now what about scripts or programming languages? Because, as mentioned earlier, REST is the simplest and most popular choice when creating a web service, it is usually well supported in all languages. As an example, let's look at how we would list out all records in a reverse zone that are suspicious. A reverse zone usually only contains NS and PTR records. Other record types are allowed, but usually don't appear there.

We wrote this script using Python. Python is a great scripting language and well-suited to smaller scripts, especially when dealing with JSON and strings. It is a pretty comprehensive language, yet there are plenty of additional libraries to be explored, if one should need something more.

From Python 3 onwards you can use the http.client library to create a REST request. Bear in mind that Python 2.7, however, does not include the http.client library. Since we will be using Python 2.7, we will be using the requests library which is not a part of the standard installation. For information on how to install the requests library, see http://docs.python-requests.org/en/latest/

#!/usr/bin/env python

#

# restDemo.py - list all suspicious records found in

# reverse zones

import requests

 

username = 'john'

password = 'secret'

headers = {'content-type':'application/json'}

url = 'http://mmsuite.company.com/mmws/api/'

params= {'filter' : 'name:in-addr.arpa.'}

 

sess = requests.Session()

resp = sess.get(url + 'DNSZones', params=params, auth=(username, password), headers=headers)

# resp should now contain a list of all reverse zone

if resp.ok:

    for zone in resp.json()['result']['dnsZones']:

        print 'checking zone: ' + zone['name']

        # for each zone get all the records

        resp = sess.get(url + zone['ref'] + '/DNSRecords'

                    , auth=(username, password), headers=headers)

        if resp.ok:

            for rec in resp.json()['result']['dnsRecords']:

                if rec['type'] not in ['SOA', 'NS', 'PTR']:

                    print '\t!!!\t' + rec['name'] + '\t' +

                          rec['type'] + '\t' + rec['data']

 


The output resulting from the script is illustrated in the next box.
 

$ ./restDemo.py

checking zone: 1.5.2.in-addr.arpa.

checking zone: 10.in-addr.arpa.

checking zone: 137.168.192.in-addr.arpa.

checking zone: 4.6.2.in-addr.arpa.

checking zone: 49.10.in-addr.arpa.

checking zone: 7.3.2.in-addr.arpa.

checking zone: 2.2.63.in-addr.arpa.

      !!!   jonas TXT   test

 

 

The script found 7 reverse zones. One of them contained a TXT record which we consider suspicious.

And just for fun, because we love those filters, we could have used them to retrieve only the records that are not of the type SOA, NS and PTR. So the last part of our Python script could have been written like this:

...

        print 'checking zone: ' + zone['name']

 

        params= {'filter' : 'type:!^(SOA or NS or PTR)$'}

        # for each zone get all the records, only get records of

        # all types other then SOA, NS or PTR

        resp = sess.get(url + zone['ref'] + '/DNSRecords', params=params

                    , auth=(username, password), headers=headers)

        if resp.ok:

            for rec in resp.json()['result']['dnsRecords']:

                print '\t!!!\t' + rec['name'] + '\t' +

                       rec['type'] + '\t' + rec['data']

 

Writing the script this way leads to less traffic and less load, which can make a difference if the reverse zones are large.

When creating scripts, it is best to create a new, dedicated user account that only has access to the objects the script needs to function. If you are running Microsoft Windows in an AD environment, the web service can also be configured to allow single sign-on.

Men & Mice REST API: Summary

The primary focus of the Men & Mice development team has always been to simplify the complex task of administering a DDI[2] environment, while retaining network flexibility and maintaining speed, as different network environments and different types of users have very different needs. To achieve this flexibility, our mission has been, and continues to be, developing and providing a rich set of commands, combined with easy user access through a web service interface.

Extending the Men & Mice Suite to include a REST API creates a powerful additional tool for users. With the Men & Mice REST API, users gain easier access to data in the Men & Mice Suite, as well as the means to process it according to their particular needs. The Men & Mice REST API therefore extends the range of tools with which customers can create workflows, write handy scripts to import and export data or generally just develop customized ways to lighten the load of administering the often complex, but vital, daily tasks existing in our technical lives.

[1] REST or RESTful?

REST is the set of architectural constraints and is not dependent on any protocol. Web service APIs are typically called RESTful when they adhere to the REST architectural constraints. Practically every RESTful service uses HTTP as its underlying protocol.

[2] DNS, DHCP and IP Address Management

Topics: Men & Mice Suite, API

Microsoft Azure DNS and Men & Mice Making More Sparks Together

Posted by Men & Mice on 9/29/16 10:57 PM

Chemistry. Sometimes, when two separate entities meet, they just have it. Sometimes they don’t. When it comes to Men & Mice and Microsoft, it’s definitely a case of the former. There’s surefire chemistry, and, even though the relationship already dates back to way back when, we’ve never been stronger together than we are now.

Just this week, Microsoft Azure announced General Availability of their domain hosting service, Azure DNS, in a joint statement with Men & Mice, released on September 26th at the Microsoft Ignite conference in Atlanta, USA. The General Availability announcement comes slightly more than a year after Microsoft first unveiled the public preview of this new addition to their cloud network offerings at Microsoft Ignite in Chicago in 2015. Men & Mice had already announced support for Microsoft Azure DNS in January of this year, with the release of the Men & Mice Suite Version 7.1. Now everyone is able to pick the fully ripe fruits of this productive partnership.

According to Jonathan Tuliani, Program Manager for Azure Networking – DNS and Traffic Manager, with this announcement Azure DNS is now ready to be used for production workloads. Given that Azure DNS “is supported via Azure Support and is backed by a 99.99% availability SLA” this means that Men & Mice Suite customers can now sit back and enjoy the high availability, performance, low cost and convenience of hosting their domains in the cloud with Azure DNS, while maintaining full control of their DNS domains and IP address blocks with the help of the powerful DNS, DHCP and IP Address Management (DDI) tools provided by the Men & Mice Suite.

azure_dns.jpg

Magnus E. Bjornsson, CEO of Men & Mice, sees this as one more positive step towards the continued development of third-party support products in close cooperation with Microsoft. “We are proud partners of Microsoft and embrace the opportunity to join forces with this leader in the field of IT. Our mutual collaboration enhances the value of the open and adaptable Men & Mice Suite to our customers.”

The Men & Mice Suite already exhibits a core, unfettered synergy with Microsoft Active Directory, which helps to make it one of the world’s top choice suppliers of DNS, DHCP and IP Address Management software solutions. With the addition of support for Azure DNS, as well as support for Windows Server 2016, there’s no telling where this juicing up of existing chemistry will take us next. If the past is anything to go by, it’s bound to be a happy combination of small steps and giant leaps towards collaborative, innovative creation.

The full General Availability announcement can be accessed on the Microsoft Azure blog.

 

Topics: Men & Mice Suite, DNS

Winter is coming ... time to Go & go DDI

Posted by Men & Mice on 9/12/16 10:56 AM

OK, that may be jumping the gun - it’s only September, some might say. But seriously, this is Iceland. Once the darkness sets in early enough to put on a dazzling display of Northern Lights, as it has done the last few nights, we know it’s game over for summer.go.jpg

But perhaps the peace that comes with a blanket of darkness and the silence of snow is not a bad thing. We at Men & Mice need the time to turn inwards after being out and about all summer doing tradeshows, webinars and, outside of catching the midnight sun, indulging in a strong dose of R&D (as always).

So what have we been up to this summer?

A number of industry trade shows saw Men & Mice on-site, spinning up demos on great demand and dishing out opportunities to win a free trip to Iceland. If you happened to miss us in Las Vegas or New York, don’t forget to drop by to meet with us at booth #1960 at Microsoft Ignite in Atlanta end of September!

Speaking of which. Microsoft is planning the official release of its Windows Server 2016 for Microsoft Ignite. As it happens, Carsten Strotmann from Men & Mice Professional services presented a webinar on Windows Server 2016 (based on Technical Preview 5) in May. For those who’d like to dig a little deeper into what’s on offer in Windows Server 2016, the webinar covers things such as DNS policies, application load-distribution with DNS, IPv6 root-hints, and possibly one of the most exciting features of the new Windows Server 2016, Response Rate Limiting. Carsten’s webinar recording and slides are available on our website.

Outside of dabbling in Windows Server 2016 features, Carsten spent some time in June to roll out a deeper understanding of experiments at the root of DNS in the form of a webinar on the Yeti-DNS project. Yeti-DNS is an international research project with the purpose of testing new technologies and procedures in running the Internet root zone. The Yeti-DNS webinar also includes an interview with Shane Kerr, a coordinator for the Yeti-DNS project, in which he divulges all kinds of fascinating information straight from the horse’s mouth, so to speak.

Two more webinars followed in August, this time focused on new features in the popular BIND Version 9.11 DNS server, as well as best practices for a secure BIND 9. For people curious about catalog zones, new *rndc* functions, “chroot” vs “container” or BIND 9 configuration hardening, don’t miss the opportunity to check out these webinars at your earliest convenience.

Though the Men & Mice R&D crew spent a large part of the summer working hard on, amongst other things, new features for Men & Mice Suite Version 7.3 that is scheduled for release this fall, one of our programmers dashed off to go and, well Go, in Russia. For those who don’t know, ‘Go’ is the ancient Chinese board game which has more recently posed a seemingly insurmountable challenge in the field of artificial intelligence: building a computer that can beat a human at Go. Whereas the renowned chess Grandmaster Gary Kasparov already suffered defeat at the ‘hands’ of the IBM supercomputer Deep Blue in 1997, no computer could manage to beat a human at Go. That is, until March this year, when Google DeepMind’s AlphaGo computer defeated the best Go player in the world over the last decade, Lee Sedol. 

Interestingly, just as with any human, AlphaGo has had to spend years learning, training and playing literally millions of matches to emerge the victor at this level of Go. To some, AlphaGo’s victory signifies a watershed moment in the supposed battle of man versus machine. This, they believe, will inevitably lead man to a dark, dystopian future. To others, the match paves the way to greater understanding of the infinity of potential contained in a future forged by the power of teaming man and machine, instead of thinking of it as a death race of one against the other.

Either way, AlphaGo or no-go, humans still very avidly compete amongst each other in Go (as they do, for that matter, in chess). To this end, our very own Hallbjörn Guðmundsson, managed no small feat by finishing 87th out of 601 participants during the European Go Championships held recently in St Petersburg. Way to Go, Hallbjörn!

So what next is in stall here at Men & Mice? Webinars, trade shows, the release of Men & Mice Suite Version 7.3 and perhaps a volcanic eruption courtesy of Iceland’s biggest volcano, Katla (this webcam allows you to keep an eye on her). Katla, being a force of nature and all, isn’t really under our control, but everything that is under our control at Men & Mice is taking place with a brand new CEO at the helm. Magnús E. Björnsson, formerly Senior Director of Engineering at Oracle, brings fresh blood and fresh perspectives into the Men & Mice stable. We bid him a happy welcome - and welcome back to Iceland!

Wishing all of you a happy shoulder season (a.k.a. fall/autumn)!

The Men & Mice Team

 

Topics: DDI, Webinars