Summary

  • RIPE NCC now automates DNS-prefix withdrawal and re-advertisement using local checks and reachability measurements from Atlas anchors.
  • When a firewall mistake blocked metric collection and every instance showed zero reachability, a common-mode fail-safe kept the prefixes advertised.
  • The test demonstrated a routing safeguard, not a DNS outage or measured customer impact.

A monitoring system produced a perfect disaster: every RIPE NCC DNS instance showed zero per cent reachability. The routes stayed put.

At RIPE 93, Systems Engineer Leon Grasmeijer described a control loop that can turn a measurement into a Border Gateway Protocol action. RIPE NCC first checks whether a local DNS daemon responds. If it does not, the instance’s service prefix is withdrawn. A later check looks for a default route or a full routing table; without either, the server prefix is withdrawn as well. RIPE NCC also keeps covering prefixes advertised from a core site, a backstop if the per-instance automation goes wrong.

The newer check asks whether each DNS instance can reach RIPE Atlas anchors. The system measures what share of anchors receives its messages. A low share points to a possible return-path problem, so the service prefix can be withdrawn. The procedure once required a person to withdraw and later restore the route. RIPE NCC now automates both steps: low reachability removes the advertisement; recovery brings it back.

Then came the useful edge case. A mistaken firewall change stopped collection of the anchor metrics. All instances suddenly read zero per cent at once. The fail-safe treated that synchronized collapse as suspicious and kept the last result. The prefixes remained advertised, as expected.

That is a more interesting decision than “automate the button.” One instance reporting a bad path can be a real service fault. Every instance reporting the same impossible result can be the measuring system failing in one place. If the controller treats both patterns alike, a broken collection path can withdraw the service it was meant to protect.

RIPE NCC’s public DNS page describes AuthDNS as an anycast service for reverse DNS, ripe.net, e164.arpa and other infrastructure zones. It lists the cluster announcements 193.0.9.0/24 and 2001:67c:e0::/48 from AS197000. BGP withdrawal tells peers that a previously advertised route is no longer available for use. RIPE NCC says the core site continues to announce covering prefixes, but that fact alone does not reveal which path any resolver takes.

The transcript reports no DNS outage or customer harm; it documents a test in which the monitoring feed failed and the routes stayed advertised. It does not say which exact advertisement that firewall test touched, or publish the anchor denominator, withdrawal and recovery thresholds, or hold time; those settings would determine how another operator could reproduce the safeguard.

The design makes a sharp bargain. A false low for one instance can remove its route. A common-mode zero can freeze the last route state. The core-site covering prefixes add another layer of continuity. Every layer is a different answer to a different failure: a broken server, a broken path, a broken monitor, or a broken route controller.

The success condition is not a dashboard full of green dots. It is a route decision that knows whether it is looking at a failed DNS instance or a failed measuring path—and leaves enough evidence to tell the two apart.

Sources