DNSSEC for .nz: post-incident recovery and improvement (or, how to see the train coming down the tunnel next time. For Sure.)#

Paul Radford (InternetNZ)

• Why: A concrete, transferable postmortem in network security: the failure wasn't the zone data being internally consistent, it was that nobody validated how the zone behaves against caching recursive resolvers in the real world. The lesson — your correctness checks must model the consumer's cache, not just your own output — generalizes far beyond DNSSEC to any system validated in isolation from its consumers.
• What: The story of the .nz DNSSEC incident, what observability gaps it exposed, and the "fake root" validation system InternetNZ built afterward: a test harness with caching recursive resolvers in the loop that validates zone outputs against real-world query/validation behavior before publication. (from abstract only)
• How: Pre-release validation that replays the resolver ecosystem — not just checking zone files for internal consistency but exercising DNSSEC validation through caching recursive servers in scenarios approximating production, catching negative side effects before the zone ships.
• Where applicable: Broadly applicable to any DNS operator (TLD, enterprise authoritative, or hosted zones); the harness approach is adoptable by anyone running authoritative DNS with DNSSEC. Org-specific only in the incident details.