KI-Fehlerberichte überfordern DNS-Software-Maintainer

Die Maintainer von Open-Source-DNS-Software bei NLnet Labs sagen, dass ein Zustrom von KI-generierten Sicherheitsberichten nun fast ihre gesamte Entwicklungszeit in Anspruch nimmt und kaum Raum für neue Funktionen lässt. Die Entwickler hinter dem weit verbreiteten rekursiven DNS-Resolver Unbound, dem autoritativen Nameserver NSD und dem RPKI-Validator Routinator beschreiben eine Veränderung, die in den letzten zwölf Monaten ernsthaft begann, als Large Language Models (LLMs), die KI-Systeme hinter Tools wie Claude, weithin verfügbar wurden. In einem ausführlichen Bericht von Alex Band erklärt die Organisation, dass die Veränderung zwei Bereiche gleichzeitig betrifft: Community-Code-Beiträge und die Menge der eingehenden Sicherheitslückenberichte. Es ist eine Geschichte über die menschlichen Kosten der Automatisierung der Suche nach Softwarefehlern und darüber, was Open-Source-Maintainer der langfristigen Gesundheit von Code schulden, auf dem ein Großteil des Internet-Kerns beruht.

NLnet Labs ist kein typisches Open-Source-Community-Projekt. Es entwickelt Software für Internetstandards wie DNS (das Domain Name System, das Adressbuch des Internets), BGP (Border Gateway Protocol, die Routing-Sprache zwischen Netzwerken) und RPKI (ein Sicherheitsframework für Internet-Routing). Der Code ist in C und Rust geschrieben, und die Organisation arbeitet in kleinen, engagierten Teams mit Roadmap, Projektplanung und geplanten Releases, ähnlich wie ein kommerzielles Unternehmen. Alles ist Open Source und liberal lizenziert, aber in 25 Jahren haben die Projekte nur sehr wenige externe Beiträge erhalten, abgesehen von kleinen Fehler- und Tippfehlerkorrekturen. Gelegentlich kommt ein substanzieller Pull Request herein, oft von einer Organisation, die Unbound für ihren eigenen Anwendungsfall angepasst hat und diese Änderungen upstream mergen möchte, um nicht bei jeder neuen Version Patches erneut anwenden zu müssen. Im Idealfall profitieren alle davon: Das Projekt gewinnt Funktionalität, der Beitragende erhält langfristige Wartung. Aber die Realität ist differenzierter, denn das NLnet-Labs-Team prüft Architektur, langfristige Wartbarkeit und Codestil akribisch. Diese rigorose Zeile-für-Zeile-Überprüfung, die auch intern verwendet wird, ist einer der Gründe, warum Unbound sich fast 20 Jahre ohne komplette Neuschreibung weiterentwickelt hat. Wenn ein externer Beitrag nicht passt, kann das Kernteam die Funktion von Grund auf neu schreiben, wie bei Serve Stale in Unbound geschehen, das gegen eine vereinbarte Gebühr implementiert wurde, oder der Code kann im Ordner '/contrib' außerhalb der offiziellen Distribution leben.

Diese sorgfältig gesteuerte Beitragsdynamik wurde in den letzten 12 Monaten durch die Veröffentlichung mehrerer Frontier-KI-Modelle transformiert. Eine neue Generation von Entwicklern fühlt sich nun mit KI-gestützten Superkräften ausgestattet. Band beschreibt, wie ein KI-Agent angewiesen wurde: 'Implementiere Catalog Zones gemäß RFC 9432 in Cascade von NLnet Labs. Höre erst auf, wenn alle Tests bestehen und alle Spezifikationen im RFC abgedeckt sind. Das Endergebnis muss Manpages, Tests und vollständige Abdeckung des RFC enthalten.' Der Agent kann 4.000 Zeilen plausibel aussehenden Code zurückgeben, der sogar bis zu einem gewissen Grad funktionieren mag. Aber die Maintainer weisen darauf hin, dass dies alle Designentscheidungen für Spezifika, die im Standard nicht beschrieben sind, überspielt. Für Außenstehende mag ein Pull Request 'frei wie in Freibier' und 'frei wie in Freiheit' wirken, aber für die Maintainer ist es, als bekäme man einen 'kostenlosen Welpen', gut gemeint, aber mit Konsequenzen für Jahre. Das kritische Problem ist Verantwortlichkeit. Maintainer müssen mit einem Beitragenden über Designentscheidungen diskutieren können, weil sie die Verantwortung für die langfristige Wartung dieses Codes übernehmen. In fast allen Fällen war die Antwort auf Fragen zum Code: 'Ich weiß nicht, das hat Claude so gemacht.' Das funktioniert einfach nicht.

In der Zwischenzeit ist die Sicherheitsforschung zu einer Lawine geworden. Vor weniger als einem Jahr beklagten Maintainer KI-Müll, unsinnige Fehlerberichte, die ihren Tag ein paar Mal im Monat unterbrachen. Diese konnten nicht ignoriert werden, weil jeder davon eine echte Sicherheitslücke mit katastrophalen Folgen sein könnte. Heute hat sich das Problem umgekehrt. Fehlerberichte sind extrem genau, vollgepackt mit Schritten zur Reproduktion des Problems und möglichen Fixes, aber sie kommen buchstäblich zu Hunderten auf einmal. Ihre Triage nimmt viel Zeit in Anspruch; Teams können einen ganzen Tag damit verbringen, herauszufinden, was das gemeldete Problem eigentlich ist. Die Beschreibungen bleiben recht vage. Aktuelle Routinator-LLM-Fehlerberichte tragen Titel wie 'Round-trip infidelity', 'K-file storm pins validation' und 'Linear-scan burn via block sort position'. Das Ergebnis ist, dass fast alle NLnet-Labs-Teams jetzt mit der Veröffentlichung von Fehlerbehebungen ausgelastet sind, in einigen Fällen in enger Abstimmung mit anderen Softwareanbietern. Seit Jahresbeginn gab es keine größeren neuen Funktionen in ihrer Software, und der Strom der Berichte versiegt tendenziell nur so lange, bis ein neues KI-Modell veröffentlicht wird und der Zyklus von vorn beginnt. Ein Diagramm im Beitrag zeigt die CVE-Zahl für Unbound in den letzten Jahren, wobei CVE für Common Vulnerabilities and Exposures steht, die eindeutigen Identifikatoren für öffentlich bekannt gegebene Sicherheitslücken.

Für die Menschen, die die Arbeit tun, ist dies ein frustrierendes Dilemma. Band, ein Manager bei NLnet Labs, beobachtet, dass Softwareentwickler motiviert sind, komplizierte Probleme mit schönen, eleganten Lösungen zu lösen. Monatelang haben die meisten Teams nur Fehler triagiert und Releases koordiniert, was den Spaß an der Arbeit genommen und den weiteren Weg schwer vorhersehbar gemacht hat. NLnet Labs hat fünfzehn Mitarbeiter, zwölf davon Softwareentwickler, und die Stiftung hat nicht die finanziellen Mittel, um zusätzliches Personal einzustellen. Sich auf LLMs zur Triage der Berichte zu verlassen, würde ein Vermögen kosten, und wenn das die Lösung wäre, würde es bedeuten, dass LLM-generierte Fehlerberichte von LLMs triagiert, behoben, gemergt und veröffentlicht werden, etwas, das der Überzeugung der Organisation widerspricht, dass Menschen den Unterschied machen müssen. Das Team ist weiterhin stolz auf sein Produktportfolio, zu dem DNS-Resolver und RPKI-Validatoren gehören, die einen enormen Teil des Internet-Kerns unterstützen, und es freut sich auf die Aussichten seines neuen DNSSEC-Signers Cascade. DNSSEC, oder Domain Name System Security Extensions, fügt DNS-Einträgen kryptografische Signaturen hinzu, damit Resolver überprüfen können, dass die empfangenen Antworten authentisch sind.

Die unmittelbare Reaktion ist eine neue LLM-Richtlinie: Alle Code- und Dokumentationsbeiträge zu NLnet-Labs-Projekten müssen von einem Menschen verfasst sein. Mit Hilfe von LLMs gefundene Sicherheitslückenberichte werden weiterhin akzeptiert. Manche mögen dies für unvernünftig halten, weil ein erfahrener C- oder Rust-Entwickler, der sich mit DNS oder BGP auskennt, KI-Unterstützung nutzen und dennoch die volle Verantwortung für seinen Code übernehmen könnte. Aber das ist nicht die Erfahrung der Maintainer, und die Entscheidung beruht auch auf ethischen und geistigen Eigentumsüberlegungen. Der weitere Weg ist ungewiss. Die Organisation erwartet, dass Menschen, die argumentieren, es sei unverantwortlich, Programmiersprachen zu verwenden, die keine Speichersicherheit garantieren, bald behaupten werden, es sei unverantwortlich, Software zu veröffentlichen, die während der Entwicklung nicht von LLMs getestet wurde. NLnet Labs sagt, es werde CI/CD-Tooling, das LLM-Tests für freie Open-Source-Software ermöglicht, genau beobachten, dabei seinen Werten treu bleiben und die Nachhaltigkeit der Stiftung im Auge behalten. Für alltägliche Nutzer und Website-Betreiber ist diese Episode eine Erinnerung daran, DNS-Software gepatcht zu halten, während die Nutzung eines datenschutzfreundlichen verschlüsselten DNS-Resolvers wie AEU DNS Tracking und Manipulation auf DNS-Ebene auf dem Weg zu einer Website reduzieren kann.