Since 2003, the RIPE NCC’s DNS Monitoring Service (DNSMON), has been providing a comprehensive, objective, and up-to-date overview on the quality of the service offered by TLD and other DNS operators. Due to technical advancements and in line with our aim to provide consolidated services, we are introducing a new DNSMON, currently running in parallel with the existing, "old" one.
As announced last year in the RIPE Labs article,
"Future of RIPE NCC Technical Services"
, we are in the process of integrating
DNSMON within RIPE Atlas
, using RIPE Atlas anchors as vantage points. The
is integrated within
, which will serve as the data collection mechanism, using RIPE Atlas anchors as vantage points. The interface, notably the data presentation and visualisation, has been updated. New features have also been added to the service, while some features of the
have not been carried over.
We started internal testing of the new DNSMON features and interface in January. In February, we opened up testing to a select group of 20 DNSMON users, including DNSMON customers, country code Top Level Domain (ccTLD) operators, and other volunteers. The new DNSMON service is now widely available in beta status, and we are inviting the general public to test it and provide feedback.
What We’ve Changed
The basic function of the DNS monitoring service remains the same, but we’ve rebuilt the machinery on a new foundation. Instead of TTM, new DNSMON uses RIPE Atlas as its data collection mechanism. Specifically,
RIPE Atlas anchors
measure the reachability and responses of the name servers of the monitored zones. By replacing TTM hosts with RIPE Atlas anchors, the DNSMON collection process is becoming more future-proof, more manageable, and expandable if needed. There are currently 44 RIPE Atlas anchors active worldwide, hosted by volunteers. Our plans are to extend this number to 100 by the end of 2014.
We've also updated DNSMON's data visualisation– it’s now more modern and more interactive. You can zoom in on interesting details, such as servers, vantage points and time intervals. You can also define your own thresholds for visualising the observed error rates (defined by colour codes). Additional data is accessible via the RIPE Atlas website and APIs. There’s also potential support for visualising server instances of an anycasted service, however, this is not currently available.
The system now supports TCP in addition to UDP queries. There is also support for traceroutes towards the server, which can be accessed via the standard user interface.
Features That Haven't Been Included
There are some features that we haven't migrated to the new DNSMON .
- Server-side generated RRD graphs have not been migrated because client-side visualisations provide a comparable replacement.
- The old DNSMON introduced an (artificial) delay for the presentation of measurement results when viewed by the public. We have not introduced a delay of visualisations and will not do so unless there is strong community demand for it.
- RIPE Atlas measurements are not retried on failure. Some members of the community expressed a preference to know immediately when attempts fail- so that any issue with their DNS servers can be quickly addressed.
We plan to conclude the migration process from the old to the new DNSMON in the second quarter of 2014. Details about the decommissioning of the old DNSMON interface will be published at a later date.
As we open testing of the new DNSMON to the community at large, we hope you will provide feedback. Please send your comments or questions to the DNS Working Group Mailing List at firstname.lastname@example.org .
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
will we be able to monitor also dns from atlas probes? thank you.
Hide one reply
Robert Kisteleki •
The (small) RIPE Atlas probes are not involved in the DNSMON service, but they are also capable of doing DNS measurements. You can schedule these at will using the RIPE Atlas UI or API.
Stéphane Bortzmeyer •
And it already helped us in finding a unsystematic problem located on one specific instance of an anycast name server, something which did not appear with ordinary monitoring tools. Thanks!