We implemented a new concept user interface for DNSMON and conducted a survey of our existing subscribers, collecting their feedback and suggestions for future work. You can find the results and the changes described in this article.
Recently, we’ve been working on some improvements to our DNSMON service . As with any work of this sort, it’s always useful to look back over the original purpose and scope of the service – is the problem statement still valid, does our solution still fit?
Back in 2005, Daniel Karrenberg wrote in 'DNS Monitoring Service for TLD Administrators' ( ripe-342 ):
“For the DNS service to work properly, two things are essential: the server machines should be working correctly and the clients using the server should be able to reach it through the network. Monitoring the latter is difficult, as the clients can be thousands of kilometres and a few dozen network hops away.”
At that time, it became clear that the Test Traffic Measurement (TTM) boxes could be used as simulated clients to carry out precisely those measurements. Software was developed and deployed, and the rest is history.
Much has changed since 2005 – we now have a proliferation of anycasted DNS servers, we find many servers running over IPv6, we’ve introduced monitoring for ENUM domains, and most recently, we’ve seen DNSSEC rolled out in production environments. Despite these changes, DNSMON remains a strong and innovative product for its use of widely distributed measurement probes, and the way in which it presents data.
However, the DNSMON back end wasn’t built to understand things like DNSSEC, and the original design omitted support for things like TCP queries. On the front end, web technologies have advanced, as have graphing frameworks, giving improved possibilities for better presentation. From the user perspective, ever more complex server topologies and the resulting monitoring demands call for more powerful query tools, and easier access to data.
Another change since 2005 has been in our coding standards. We’ve moved from perl to python, and are now influenced by test driven development and agile methodologies. Because of this, when we began to look at DNSMON, our initial reaction was to start from scratch to bring the codebase up to the standards of our other new software, rather than patching something 5 years old.
During the re-implementation of the back-end, our biggest focus was on creating a more flexible and scalable system. We wanted the design to allow us to add new types of measurements in the future, such as DNSSEC, traceroutes or special anycast measurements. Some new measurements would benefit from a more diverse measurement network, so we also designed the new system to allow for easy expansion of the underlying network.
Our current implementation uses a task dispatching system called “ celery ”. The framework allows us to expand our processing capacity by simply adding a new node and subscribing it to the task dispatcher.
We further wanted to give our users a better experience when using DNSMON. We implemented a new concept user interface and conducted a survey of our existing subscribers, collecting their feedback and suggestions for future work.
The new user interface is currently available to DNSMON subscribers for a trial period. We are actively incorporating feedback from those users and from you, so that we can improve the service before its public launch later this year.
We hope that the Internet community finds this service and this work useful, and we invite feedback either through the forum on RIPE Labs (see link under this article), or by email directly to the development team via firstname.lastname@example.org .