Summary

  • On 3 December 2020, two outside observers alerted RIPE NCC to DNS resolution failures for certain ripe.net names; Anand Buddhdev later identified spurious NSEC records left by its DNSSEC signer.
  • RIPE NCC forced a complete re-sign of the zone at about 20:00 CET, fixing the problem, and announced further monitoring and a report to the signing-software developers.

The warning did not come from a grand dashboard. At about 15:40 CET on 3 December 2020, Matt Nordhoff and Peter van Dijk told RIPE NCC that certain names under ripe.net were having trouble resolving. Anand Buddhdev's account to the DNS Working Group the next day gives both men credit and describes what the registry found. A recent zone update had changed the status of some address records into glue records. The DNSSEC signer mishandled that transition and left spurious NSEC records behind. Validating resolvers then failed to accept responses for some names.

This was a collision between two chores DNS operators ordinarily want to happen quietly. Glue records help a resolver reach the servers responsible for a delegated name. DNSSEC attaches cryptographic proof to the zone's answers, including proofs about names that do not exist. RFC 4035 describes how validators process signed DNS data. If the signed set contains inconsistent NSEC material, a validating resolver refuses the answer. The records had a respectable-looking signature and a bad underlying state: a neat demonstration that signing mistakes can make a service unavailable even while validation does its job.

Buddhdev's team did not try to talk validators into lenience. At around 20:00 CET, it forced the signer to re-sign the entire ripe.net zone. That cleared the observed failure, according to his message. From first alert to repair, the reported window was roughly four hours and twenty minutes. The RIPE NCC December member update also listed the DNSSEC validation problem among the month's service incidents.

The follow-up in Buddhdev's note is as revealing as the fix. RIPE NCC reported the issue to the developers of its signing software and said it was adding monitoring to catch similar trouble sooner. The public account establishes the reported corrective steps, with no tally of affected users or completed software patch. Its sturdy facts are already enough: a record changed role, the signer left false proof in the zone, outsiders noticed, and a full re-sign restored valid answers. A registry's DNS can stumble over a single administrative change while its cryptographic guard remains strict enough to refuse the result.