You are here: Home > Analyse > DNS > DNSMON > About > Technical Documentation

Technical Documentation

What does DNSMON measure, exactly?

DNSMON measures all DNS root and many Top-Level Domain (TLD) name servers. For the full list, see the contents of the zone selector on the DNSMON opening page.

For each monitored zone in DNSMON, we look up all the name servers defined for that zone (as defined in the zone itself), and schedule RIPE Atlas DNS measurements against these. Specifically, the following measurements are defined (both IPv4 and IPv6, if possible):

Type
Protocol
Additional
Frequency (seconds)
 Retry on failure?
Usage

HOSTNAME.BIND1

 UDP   240 No Not currently visualised, but would be used by a potential "instances" view.
SOA UDP

NSID

(IPv4 EDNS: 1472 bytes, IPv6 EDNS: 1232 bytes)2

 300 No Servers + probes views (UDP).
SOA TCP NSID

300

 No Same as above, but using TCP queries.
Traceroute ICMP   300 N/A

Not visualised, but download links to RIPE Atlas traceroute data are provided.

VERSION.BIND1 UDP

NSID

(IPv4 EDNS: 1472 bytes, IPv6 EDNS: 1232 bytes)2

 86400 (daily) No Not visualised. Running primarily for studying long-term server version trends.

1 HOSTNAME.BIND and VERSION.BIND queries are used by default because of their widespread adoption. For servers that do not support these forms, ID.SERVER and VERSION.SERVER will be used instead.

2 We're using these values In order to maximise probability of avoiding fragmentation issues. (For IPv4: MTU of 1500 bytes minus 28 bytes for IPv4 packet header and UDP header. For IPv6: minimum MTU of 1280 bytes minus 48 bytes for IPv6 packet header and UDP header.)

These measurements are done by RIPE Atlas anchors. They are all public measurements; therefore, the results are publicly available in a raw format through the RIPE Atlas data API and are accessible via the interface.

The timeout for each measurement is set to 5 seconds.

How are nameserver changes applied?

DNS zones sometimes change the nameserver set: new servers are added, old ones are removed or replaced. DNSMON checks weekly for these changes (ie. the current set of servers defined to be monitored vs. the list of nameservers defined in the DNS zone). When changes are detected, it alerts the DNSMON operators in order to verify this. Once the changes are confirmed, we apply the changes inside DNSMON, and as a consquence we start or stop monitoring the affected nameservers.

This procedure does not require assistance from the zone operator.

The expected time to apply such changes is 2-3 weeks.

Can my DNS zone be monitored?

In mid-2014, the RIPE NCC proposed a set of criteria about how DNSMON should accept new zones to be monitored. You can follow and join this discussion on the RIPE DNS Working Group mailing list.

Differences between Atlas-DNSMON and the older TTM-DNSMON

The basic idea for the RIPE Atlas backed DNSMON service is essentially the same as before, but we rebuilt the machinery on a new foundation. Instead of TTM, it now uses RIPE Atlas as the data collection mechanism. Specifically, the RIPE Atlas anchors are involved in measuring the reachability and responses of the name servers of the monitored zones. We've also completely rewritten the visualisation side, to modernise it and make it more interactive. These changes result in a couple of consequences:

  • The set of vantage points is now different (RIPE Atlas anchors vs. TTM boxes).
  • RIPE Atlas is in the process of installing more anchors every week, and they are continuously added to the existing measurements, up until 50 anchors per measurement (zone).
  • The raw data format is different than the one used by RIPE Atlas. Also, this data is now accessed via the RIPE Atlas website and APIs.
  • The new system does a lot more than the previous one did, for example:
    • Support for TCP queries in addition to UDP
    • Support for traceroutes towards the servers, and access to these via the interface
    • (Potential) support for visualising server instances of an anycasted service
    • The client side interactivity allows zooming in on interesting details (e.g. servers, vantage points, time intervals)
    • User-defined thresholds for visualising the observed error rates (i.e. what's red, what's green and how wide the interval is between these)

There are some features of DNSMON that have not been migrated to the new implementation:

  • Data delay for non-DNSMON users; the measurements done by RIPE Atlas for the new DNSMON are public measurements; therefore, the results are publicly available.
  • Server-side generated RRD graphs; the client side visualisation is meant to provide a comparable replacement.
  • The RIPE Atlas measurements are not retried on failure.