The Men & Mice Blog

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

Do great network teams need great DDI solutions?

Posted by Men & Mice on 7/22/16 8:59 AM

Did you have a look in the mirror this morning? Hair, face, teeth, lips, cheeks, clothes and other observable bits of body. Everything in the right place, relatively clean and looking as it should?

Regardless of what we see (or want to see), most of us spend quite a bit of time checking our appearance in a mirror. Few of us, however, get to shine a daily mirror on the parts of the body we don’t see. Our brains, hearts, lungs, intestines, bones, kidneys, veins and all those other critical bits and pieces remain largely unobserved under the human camouflage of skin and hair. Yet, much more than the appeal (or not) of our outer appearances, it is our insides that determine how well our bodies really function.

In many ways, networks and network activity are just like the inner workings of the human body: unseen and, unless something goes wrong, most often unnoticed. Billions of people use computer networks and the legion of devices connected to it in the same way we use our bodies. Few have any awareness of what’s inside or how it all functions. Fewer still consider the three critical components underlying network connectivity - the triad of DNS, DHCP and IP Address Management (DDI).

Just like doctors of internal medicine manage the unseen, but crucial, inner health of our bodies, network teams manage this unseen, but crucial, inner DDI health of a successful modern organization’s network. As a result, smart investments in a great network team can play a decisive role in business success.

But what does a great network team need to run a great network? In this new white paper, DDI specialists Men & Mice delve into how a comprehensive DNS, DHCP and IP Address Management solution can boost a network team’s productivity, performance and general well-being, thereby greatly enhancing network security and elevating business efficiency.

Topics explored include;

  • network administrators' DDI pain points
  • DDI solutions and network security
  • DDI solutions and network efficiency
  • DDI solutions and DDI teams
  • how to choose a DDI solution
  • the ups and downs of DDI

To find out whether great network teams need great DDI solutions, download your free copy of this Men & Mice white paper today.

DOWNLOAD_DDI.png 

Topics: DDI, IPAM

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

Men & Mice Suite Version 7.2 Released

Posted by Men & Mice on 5/19/16 10:38 AM

Flying High with Kea DHCP and Windows RRL

Men & Mice celebrates the arrival of the long, arctic summer nights with the release of Version 7.2 of the Men & Mice Suite.

This blog post offers a quick round-up of what’s new in Version 7.2.

Versatile simplicity, as always, forms our bottom line. Version 7.2 is no exception. This time around, support for the new ISC Kea DHCP server and a dedicated UI for Windows 2016 Response Rate Limiting (RRL) should warm the hearts of network administrators far and wide. At least, that’s what it’s been doing for us here in the North!

Let’s run through what major highlights Version 7.2 contains.

Taking flight with the new ISC Kea DHCP server

Men & Mice introduces support for the brand new ISC Kea DHCP server, the natural successor to the ISC DHCP server.

Like its namesake, the uniquely strong and intelligent New Zealand kea parrot, the brand new ISC Kea DHCP server is a powerful beast that reaches more than 1000 leases/second, allowing for clean and fast implementation of both DHCPv4 and DHCPv6.

Kea DHCP also boasts PXE Boot Support, DHCPv6 prefix delegation, dynamic reconfiguration and dynamic DNS updates.

As with other servers supported by the Men & Mice Suite, the Kea DHCP server functionality is fully controlled through the Men & Mice Management Console. This includes the effortless migration of IP subnets (scopes), including options, from ISC DHCP to Kea DHCP.

In the spirit of open source, Kea DHCP is released under the widely used Mozilla Public License 2.0, paving the way for collaborative improvements to the source code for many years to come. 

A taste of the Kea DHCP and how it integrates with the Men & Mice Suite, can be enjoyed in this recent webinar presented by Mr Carsten Strotmann.

For those interested in plunging into the Kea DHCP full force, Men & Mice, in cooperation with ISC, is offering intensive two-day hands-on training courses in Europe and the USA in the fall of 2016. The courses are aimed at small groups, so don’t forget to sign up in time! 


Scaling up with Windows Server 2016 support

The Men & Mice Suite’s architecture as an overlay solution exhibits a singular synergy with Windows Servers, making it the logical solution for any Microsoft-based network. Consequently, the Men & Mice Team is developing and releasing support for specific new Windows 2016 features as and when they are made available by Microsoft.

From Version 7.2, the Men & Mice Suite supports all of the primary Windows DNS and DHCP Server 2016 features.

Support for other new Microsoft Server 2016 features, such as DNS Zone Scopes and DNS policies, is scheduled for the Men & Mice Suite Version 7.3 release later this year.


Reinforcing DNS Security with Windows 2016 RRL

Security only works if you work it, and the more tools you have to work your security, the better. Adding to your menu of security options, the Men & Mice Suite Version 7.2 introduces a dedicated UI for the Windows 2016 Response Rate Limiting (RRL) feature.

Response Rate Limiting can make all the difference in the event of a Denial of Service (DoS) attack on DNS servers. During a DoS attack, the IP number of a victim computer is used to send high volumes of forged DNS queries to multiple DNS servers. DNS servers tricked into sending replies to these queries can push the number of DNS requests and replies over a manageable threshold and disable targeted networks. Restricting DNS servers’ response rate with Response Rate Limiting helps to control a suspicious volume of malicious enquiries and minimize the impact on the affected servers.

Microsoft sheds more light on Response Rate Limiting and how it works on their TechNet blog.

RRL.png


Men & Mice Suite Console Enhanced

Spring cleaning at the Men & Mice headquarters has resulted in a Management Console with a cleaner, and ultimately more manageable, look. From Version 7.2, windows in the Management Console are dockable, making it both simpler to manage and easier to navigate for the user.

MC.png

 

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

That wraps it up for a quick round-up of what Men & Mice Suite Version 7.2 has to offer. In the next months, Men & Mice will publish further blogs and webinars on installing and managing Kea DHCP, Windows 2016, Docker containers and Yeti. Watch this space! Or better yet, just watch Men & Mice.

Free Trial of Suite

 

Topics: Men & Mice Suite, DDI, IPAM