AI bug reports overwhelm DNS software maintainers

Open-source DNS software maintainers at NLnet Labs say an influx of AI-generated security reports is now consuming nearly all of their development time, leaving little room for new features. The developers behind the widely used Unbound recursive DNS resolver, the NSD authoritative name server and the Routinator RPKI validator describe a shift that began in earnest over the last twelve months as Large Language Models (LLMs), the artificial intelligence systems that power tools like Claude, became widely available. In a detailed account by Alex Band, the organisation explains that the change touches two areas at once: community code contributions and the volume of security vulnerability reports arriving at their door. It is a story about the human cost of automating the search for software flaws, and about what open source maintainers owe to the long-term health of code that much of the internet's core depends on.

NLnet Labs is not a typical open source community project. It develops software for internet standards like DNS (the Domain Name System, the internet's address book), BGP (Border Gateway Protocol, the routing language between networks) and RPKI (a security framework for internet routing). The code is written in C and Rust, and the organisation operates in small, dedicated teams with a roadmap, project planning and scheduled releases, much like a commercial company. Everything is open source and liberally licensed, but in 25 years the projects have received very few external contributions beyond small bug and typo fixes. Occasionally a substantial pull request arrives, often from an organisation that has customised Unbound for its own use case and wants to merge those changes upstream so it no longer has to reapply patches to each new release. In an ideal scenario this benefits everyone, the project gains functionality and the contributor gains long-term maintenance. But the reality is more nuanced, because the NLnet Labs team meticulously reviews architecture, long-term maintainability and coding style. This rigorous line-by-line review, also used internally, is one reason Unbound has evolved for almost 20 years without a complete rewrite. When an external contribution does not fit, the core team may rewrite the feature from scratch, as happened with Serve Stale in Unbound, which was implemented for an agreed fee, or the code may live in the '/contrib' folder, outside the official distribution.

That carefully managed contribution dynamic has been transformed in the last 12 months by the release of several frontier AI models. A new league of developers now feels they have AI-fueled superpowers. Band describes watching an AI agent being told: 'Implement Catalog Zones defined in RFC 9432 in Cascade by NLnet Labs. Stop only when all the tests pass and all specifications in the RFC are covered. The final result must include man pages, tests and full coverage of the RFC.' The agent can return 4,000 lines of plausible-looking code that may even work to some extent. But the maintainers point out that this glosses over all the design choices needed for specifics not described in the standard. To an outsider a pull request may feel 'free as in beer' and 'free as in speech', but to the maintainers it is like being handed a 'free puppy', well intended but carrying consequences for years to come. The critical issue is accountability. Maintainers must be able to reason with a contributor about design choices because they are taking on the responsibility of maintaining that code long term. In almost all cases, the response to any question about the code has been along the lines of 'I dunno, it's what Claude came up with'. That simply does not work.

Meanwhile, the security research side has become an avalanche. Less than a year ago, maintainers were lamenting AI-slop, nonsensical bug reports that interrupted their day a few times a month. Those could not be ignored because any one of them might be a real vulnerability with catastrophic consequences. Today the problem has flipped. Bug reports are extremely accurate, packed with steps to reproduce the problem and potential fixes, but they arrive literally hundreds at a time. Triaging them takes a significant amount of time; teams can spend an entire day just figuring out what the reported issue actually is. The descriptions remain quite vague. Recent Routinator LLM bug reports include titles like 'Round-trip infidelity', 'K-file storm pins validation' and 'Linear-scan burn via block sort position'. The result is that almost all NLnet Labs teams are now maxed out releasing bug fixes, in some cases coordinating closely with other software vendors. There have been no major new features in their software since the beginning of the year, and the stream of reports tends to dry up only until a new AI model is released and the cycle starts again. A chart in the post shows the CVE count for Unbound over recent years, where CVE stands for Common Vulnerabilities and Exposures, the unique identifiers assigned to publicly disclosed security flaws.

For the people doing the work, this is a frustrating dilemma. Band, a manager at NLnet Labs, observes that software developers are motivated by solving complicated problems with beautiful, elegant solutions. For months on end, most teams have just been triaging bugs and coordinating releases, which has taken the fun out of the job and made the road ahead difficult to predict. NLnet Labs has fifteen employees, twelve of whom are software developers, and the foundation does not have the financial means to add additional headcount. Relying on LLMs to triage the reports would cost a fortune, and if that were the solution, it would mean LLM-generated bug reports being triaged, fixed, merged and released by LLMs, something that goes against the organisation's belief that humans need to make the difference. The team remains proud of its product portfolio, which includes DNS resolvers and RPKI validators that support an enormous part of the internet's core, and it is excited about the prospects of its new DNSSEC signer Cascade. DNSSEC, or Domain Name System Security Extensions, adds cryptographic signatures to DNS records so that resolvers can verify the answers they receive are authentic.

The immediate response is a new LLM policy: all code and documentation contributions to NLnet Labs projects must be authored by a human. Vulnerability reports found with the help of LLMs are still accepted. Some may think this is unreasonable, because a seasoned C or Rust developer who is well versed in DNS or BGP could use AI assistance and still take complete responsibility for their code. But that is not the experience the maintainers have had, and the decision also rests on ethical and intellectual property considerations. The road ahead is uncertain. The organisation expects that people who argue it is irresponsible to use programming languages that do not guarantee memory safety will soon claim it is irrespo