CenturionDNS bei Nacht

Informationsüberfluss ist ein operatives Sicherheitsproblem. Wer heute eine ernsthaft gehärtete DNS-Infrastruktur betreibt, kämpft nicht nur gegen Fehlkonfiguration, Missbrauch, Reflection, frische Schwachstellen, DGA-Muster, missbrauchte Resolver, kaputte Upstreams und die üblichen industriellen Grobheiten des Netzes. Er kämpft auch gegen das Volumen. Vendor-Advisories, CERT-Meldungen, Mailinglisten, Abuse-Feeds, Forschungsbeiträge, Release Notes, kampagnenbezogene Indikatoren, dazu der tägliche Schmutz der halbgaren Security-Blogosphäre, alles fliesst gleichzeitig ein. Dass etablierte Akteure längst mit kuratierten Digests und Automatisierung arbeiten, ist kein Zufall. SANS beschreibt NewsBites selbst als halbwochentliche Executive Summary der wichtigsten Cybersicherheitsmeldungen mit zusätzlicher Einordnung durch Fachleute.1 Radware bewirbt sein Daily Digest ausdrücklich als Antwort auf verstreute, unstrukturierte und schwer verwertbare Threat-Intel-Signale.2 Recorded Future argumentiert in derselben Richtung, nur in der Sprache grosser Plattformen: Menschliche Auswertung ist zu langsam, wenn sich eine Lage in Minuten statt in Tagen verschiebt.3

Genau dort liegt der sachliche Ausgangspunkt dieses Textes. Nicht in der naiven Vorstellung, man könne Verantwortung elegant an ein Modell delegieren und sich dann mit maschineller Eloquenz aus der Zuständigkeit schleichen. Der eigentliche Engpass ist banaler und härter zugleich: Als einzelner Betreiber kann ich nicht täglich hunderte Quellen manuell sichten, priorisieren, gewichten und in eine belastbare operative Lage übersetzen, ohne an anderer Stelle Substanz zu verlieren. Wer diesen Engpass verschweigt, erzählt Märchen über Handwerk, das in Wahrheit längst an der Aufmerksamkeitsökonomie scheitert. Mein jüngster Schritt in der CenturionDNS4 Serie5 beantwortet deshalb keine Modefrage, sondern eine Betriebsfrage: Wie verteidigt man eine bereits gehärtete Infrastruktur nicht nur technisch, sondern auch kognitiv und organisatorisch, ohne ihr eine zusätzliche ferngesteuerte Angriffsoberfläche anzuschrauben.

Der vorangehende Beitrag über CenturionDNS hat die bauliche Logik offengelegt. Dort habe ich den Resolver nicht als geschichtete Architektur mit klaren Rollen, mit Frontend, Policy-Ebene und rekursiver Validierung, getragen von eigener autoritativer Basis beschrieben. Der Text hielt ebenso fest, dass die öffentliche Resolver-Ebene aus drei Instanzen in Deutschland, Finnland und Österreich besteht, verschlüsselte Zugänge über DoH, DoT, DoQ und DNSCrypt anbietet, ohne Query-Logging arbeitet und auf eine Nameserver-Unterseite verweist, die vollständig unter eigener Hoheit im Hidden-Master-Betrieb geführt wird und DNSSEC-dual-signed abgesichert ist. Auf der öffentlichen Projektseite wird diese Linie noch einmal in betrieblicher Kurzform sichtbar: Query Log ist auf off, ANY wird gedroppt, QNAME-Minimisation ist aktiv, die Nameserver stehen unter eigener Hoheit, Limits sind gesetzt, und die Seite nennt ausdrücklich meinen „Dedicated, unconnected CenturionDNS ChatGPT Pro 5.5 Agent“ 6 als CVE-Monitoring-Komponente.

Die operative Frage lautet damit nicht mehr, ob überhaupt gehärtet wurde. Sie lautet, wie man diese Härtung im Alltag gegen Zeitverlust, Feed-Rauschen und Prioritätszerfall verteidigt. Ein sauber gebauter Resolver ist noch kein sauber betriebener Resolver. Ein Hidden Master mit DNSSEC, Transportverschlüsselung und Policy-Layer kann hervorragend dastehen und dennoch kognitiv erodieren, wenn die Auswertung der Aussenlage in die Mechanik „ich lese dann irgendwann mal alles selbst“ abrutscht. Genau an dieser Stelle beginnt mein Agent.

Er läuft einmal pro Nacht um 03:00 Uhr. Er bekommt einen präzise formulierten Monitoring-Prompt.7 Er liest ausschliesslich öffentlich zugängliche Quellen. Er erzeugt daraus einen technischen Lagebericht, der strikt zwischen rekursiver Resolver-Ebene und autoritativer Nameserver-Ebene trennt. Er priorisiert Primärquellen, beschränkt die Aktualitätslinse auf die letzten 24 Stunden, bewertet nur solche CVEs, Kampagnen oder Missbrauchsmuster, die für meine konkrete Betriebswirklichkeit realistisch relevant sind, und er vermeidet absichtlich die billige Unsitte, längst umgesetzte Baselines jeden Morgen erneut als sensationelle Empfehlung zu verkaufen. Er arbeitet delta-orientiert oder er meldet Nullbefund. Text hinein, Bericht hinaus. Mehr nicht. KISS.

Gerade dieses mehr nicht ist der eigentliche Punkt. Mein Agent hat keinen Zugriff auf Server. Er besitzt keine Credentials. Er kennt kein SSH. Er hält keine API-Tokens für produktive Systeme. Er hat keinen Zugang zu Management-Oberflächen. Er ändert keine Konfiguration. Er triagiert nicht direkt in laufenden Systemen. Er meldet sich nirgends an. Er führt nichts auf produktiven Hosts aus. Er hängt an keinem Deployment-Pfad, an keinem Admin-Panel, an keiner Remediation-Kette und an keinem jener hübsch benannten on behalf of Mechanismen, mit denen man heute gern technische Verantwortung in semantische Nebelwände verpackt. Der Agent liest, filtert, gewichtet und formuliert. Anfassen darf er nichts. Genau deshalb ist er nützlich.

Die Branche diskutiert diese Trennung inzwischen mit einiger Verspätung in formaler Sprache nach. NIST formuliert im Entwurf seines Cybersecurity Framework Profile for AI unmissverständlich, dass AI-Systeme innerhalb eines Netzes getrennt von anderen Entitäten behandelt werden und ihre eigenen Berechtigungs- und Autorisierungsrichtlinien benötigen. Für AI-Agenten sei das Prinzip des Least Privilege anzuwenden, also genau nur jene Rechte zu vergeben, die zur Rollenerfüllung erforderlich sind. Dieselbe Publikation hält an anderer Stelle fest, dass die Fähigkeit, beliebigen Code auszuführen, in den meisten Anwendungen eingeschränkt, gesandboxed, an Genehmigung und Überwachung gebunden oder vollständig untersagt werden sollte.8

NCCoE legt im Konzeptpapier zur Identität und Autorisierung von Software- und AI-Agenten nach und benennt die offenen Kernprobleme direkt: Wie definiert man Least Privilege für Agenten, deren erforderliche Handlungen nicht vollständig vorhersagbar sind. Wie weist ein Agent seine Befugnis für eine konkrete Aktion nach. Wie geht man mit Delegation on behalf of um. Wie bindet man Agentenidentität an menschliche Identität, damit Human-in-the-Loop-Autorisierung überhaupt belastbar funktioniert. Wie werden Aktionen und Absichten protokolliert, damit Auditierbarkeit und Nichtabstreitbarkeit nicht bloss Folklore bleiben. Wer diese Dokumente liest, erkennt rasch, wie naiv die infantile Behauptung ist, ein Agent sei einfach ein weiterer Nutzer mit API-Schlüssel. Er ist gerade nicht einfach nur das. Darum muss man ihn entweder eng regieren oder besser ausnahmslos von produktiver Macht fernhalten.9 Das gilt sogar noch mehr für private Nutzer.

Mein eigener Ansatz entscheidet sich bewusst für die zweite Variante. Kein Agenten-Identitätsapparat, kein Rechtebaum, keine nachträgliche Feindifferenzierung von Delegation, keine künstliche Begründung, warum ein Modell nun doch irgendwo live hinschreiben darf. Ich spare mir diese Governance-Last nicht aus Faulheit, sondern weil sie in meinem konkreten Kontext unnötig und sicherheitlich unklug wäre. Ein einzelner Betreiber mit einer hochgehärteten DNS-Infrastruktur gewinnt wenig, wenn er ein Modell direkt in sein eigenes Kontrollgewebe einwebt. Er handelt sich zusätzliche Zustände, zusätzliche Fehlerklassen, zusätzliche Auditpflichten und zusätzliche Pfade ein, die er später wieder mühsam schliessen muss. Eine kleine, disziplinierte Infrastruktur lebt nicht von maximaler Autonomie, sondern von maximaler Hebelwirkung bei minimaler Angriffsfläche.

Der Kontrast zu tatsächlich verbundenen Agenten ist lehrreich. Microsofts Phishing Triage Agent für Defender ist ein reales Praxisbeispiel dafür, wie komplex es wird, sobald ein Agent nicht bloss analysiert, sondern in einem produktiven Sicherheitskontext operiert. Der Agent benötigt Security Copilot, provisionierte Security Compute Units, Unified RBAC, eine eigene Identität, zugewiesene Rollen und präzise festgelegte Berechtigungen. Die Dokumentation empfiehlt explizit eine dedizierte Identität mit minimal erforderlichen Rechten. Sie hält fest, dass Microsoft Entra eigens Agent IDs für AI-Agenten bereitstellt, damit der Zugriff enger, sicherer und besser verwaltbar bleibt. Bereits diese kurze Dokumentation zeigt, was connected agent in der Wirklichkeit bedeutet: Es bedeutet Identitätsverwaltung, Rechtezuweisung, Kapazitätsplanung, Portalkopplung, Überwachung und laufende Governance. Für grosse Organisationen kann das sinnvoll sein. Für meinen konkreten Anwendungsfall wäre es vor allem ein teurer und unnötiger Weg, eine gut gezogene Trennlinie mutwillig zu verwischen.10

Mein Modell lautet deshalb bewusst einfacher, härter und defensiver. Die Maschine komprimiert Informationsflut. Der Mensch behält Entscheidung, Haftung und Eingriffsrecht. Die Maschine darf die Welt beschreiben, aber sie darf meine Infrastruktur nicht verändern. Sie darf Relevanz verdichten, aber sie darf keine operative Tatsachen schaffen. Sie darf mir Arbeit aus den Augen nehmen, aber nicht Verantwortung aus den Händen. Für einen Ein-Mann-Betrieb ist genau diese Asymmetrie rational. Sie vergrössert meinen kognitiven Hebel, ohne die Zahl meiner Produktivrisiken proportional mitwachsen zu lassen.

Wer meint, diese Strenge sei übertrieben, sollte einen Blick auf die schmutzigere Seite scheinbar isolierter AI-Laufzeitumgebungen werfen. Check Point Research beschrieb 2026 einen Angriffsweg in einer ChatGPT-Codeausführungsumgebung, bei dem herkömmlicher ausgehender Internetzugriff blockiert war, DNS-Auflösung aber dennoch als schmaler Kommunikationspfad verfügbar blieb. Die Forscher zeigten, wie DNS dabei als verdeckter Transportkanal für Datenexfiltration und Befehlsaustausch missbraucht werden konnte. Genau dieses Beispiel taugt nicht als billige Endzeit-Polemik gegen AI, wohl aber als nüchterne Erinnerung an etwas sehr Altes: Isolierung ist selten absolut, und DNS ist nicht nur Namensauflösung, sondern im Missbrauchsfall auch ein Transportpfad. Wer aus solcher Realität die Lehre zieht, einem Modell vorsorglich keine operative Nähe zu produktiven Servern zu gewähren, reagiert nicht hysterisch, sondern normal.11

Aus demselben Grund ist mein Offline Approach kein nostalgischer Reflex gegen moderne Werkzeuge, sondern eine Zuständigkeitsgrenze. Offline heisst in diesem Zusammenhang nicht, dass der Agent keine Quellen lesen darf. Offline heisst, dass zwischen Analyse und Aktion ein harter Bruch bleibt. Keine Direktkopplung an produktive APIs. Keine stillen Schreibrechte. Keine implizite Vollmacht. Kein Modell, das irgendwo hinter meinem Rücken hilfreich meine Backups und das Produktivsystem ins null device schiebt. Gerade das Wort hilfreich ist im Sicherheitsbereich fatal, weil es oft nur eine sentimentale Umschreibung für unkontrollierte Seiteneffekte ist. Ein System, das nur Bericht erzeugt, kann sich irren. Ein System, das Bericht erzeugt und zugleich handelt, kann sich irren und diesen Irrtum materialisieren. Darum ist die zweite Kategorie gefährlicher, auch dann, wenn sie auf Werbefolien imposanter aussieht.

Die Vorzüge dieses Ansatzes sind deshalb handfest. Least Privilege erscheint hier in seiner strengsten Form, weil Null operative Berechtigung noch immer weniger ist als minimal operative Berechtigung. Die Angriffsfläche schrumpft, weil weder Zugangsdaten noch Steuerpfade für den Agenten existieren. Der Blast Radius reduziert sich drastisch, weil Fehlklassifikation, Halluzination, manipulierter Input oder schlicht schlechte Priorisierung keinen unmittelbaren Systemzustand verändern. Die Verantwortungszuordnung bleibt glasklar, weil jede Handlung weiterhin durch mich selbst erfolgt. Auditierbarkeit verbessert sich, weil die maschinelle Rolle auf ein Artefakt begrenzt bleibt, nämlich den Bericht. Analyseebene und Handlungsebene werden nicht vermischt. Genau dort beginnt erwachsene Systemarchitektur: nicht im Versprechen, alles automatisieren zu können, sondern in der Disziplin, genau zu entscheiden, was gerade nicht automatisiert werden darf.

Der Sicherheitsbetrieb grosser Plattformen verfolgt andere Ziele. Dort lohnt sich die aufwendige Konstruktion dedizierter Agentenidentitäten, Rollenmodelle, Compute-Quoten und zentraler Aufsicht womöglich, weil skalierte Bearbeitung hunderter oder tausender Fälle täglich anders gar nicht zu schaffen ist. Mein Ziel ist ein anderes. Ich betreibe keine Sicherheitsfabrik mit mehreren Analystenschichten, sondern eine eigene, bewusst kontrollierte Infrastruktur. Mein Problem ist nicht, dass zu wenig Systeme irgendwo automatisiert triagieren. Mein Problem ist, dass ein einzelner Betreiber nicht jeden Tag gleichzeitig Architekt, Administrator, Auditor, Herausgeber, Forscher und menschlicher Feed-Parser sein kann. Für dieses Problem ist ein nicht verbundener, eng geführter Berichtsgenerator oft schlicht die bessere Lösung.

Dass die Branche auf Verdichtung setzt, macht diese Einsicht nicht kleiner, sondern bestätigt sie. SANS NewsBites ist genau deshalb seit Jahren nützlich, weil niemand die wesentlichen Meldungen in roher Form sinnvoll durcharbeiten will. Radware beschreibt den eigenen Daily Digest als Reaktion auf zerstreute, unstrukturierte Signale, die Analysten sonst in manueller Sucharbeit versenken würden. Recorded Future spricht die industrielle Variante aus: Automatisierte Threat Protection sammelt, korreliert und verarbeitet Signale in einer Grössenordnung, die menschlich nicht mehr sinnvoll zu bewältigen ist. Man kann diese Quellen kommerziell, kuratorisch oder strategisch unterschiedlich gewichten. Der gemeinsame Nenner bleibt derselbe. Sicherheit scheitert nicht nur an fehlendem Wissen, sondern oft an der Unmöglichkeit, Wissen rechtzeitig zu verdichten.

Auch ausserhalb der grossen Anbieterlandschaft findet man inzwischen öffentliche Beispiele, die genau diese Richtung illustrieren. Sie sind keine normativen Autoritäten und taugen nicht als Primärgrundlage für sicherheitsarchitektonische Prinzipien. Als Anschauungsmaterial sind sie gleichwohl aufschlussreich. ThreatWatch beschreibt sich als selbstgehostete Threat-Intelligence-Plattform, die über 155 Feeds aggregiert, klassifiziert, dedupliziert und mit kuratierten Digests arbeitet.12 Das Projekt Matcha beschreibt sich als täglicher Digest-Generator für RSS-Feeds und Themeninteressen, inklusive geplanter Cron-Ausführung und optionaler LLM-Analyse.13 Ein weiteres öffentliches Projekt, sec-daily-digest, schildert das tägliche Scraping von Sicherheitsquellen, AI-basierte Bewertung und die Ausgabe eines täglichen kuratierten Digests, wiederum einschliesslich Cron-Integration.14 Diese Beispiele ersetzen keine Standards. Sie belegen aber, dass der Grundgedanke, Feed-Flut durch lokale oder halbselbstgehostete Digest-Mechanik zu bändigen, weder exotisch noch konzeptionell abwegig ist. Er ist vielmehr ein naheliegender Antwortversuch auf ein reales Problem.

Der Unterschied zu meinem Ansatz liegt weniger im Grundmotiv als in der sicherheitlichen Schranke. Ich will nicht bloss irgendeinen Digest. Ich will einen Digest, der methodisch diszipliniert, auf meinen Betriebsfall zugeschnitten und vor allem deltageführt ist. Genau deshalb ist mein Monitoring-Prompt so gebaut, wie er gebaut ist. Primärquellen zuerst, nicht weil das stilistisch vornehmer aussieht, sondern weil Vendor-Advisories, CERT-Meldungen und offizielle Dokumentation der Ort sind, an dem technische Tatsachen in der Regel zuerst und präzisesten auftauchen. Das 24-Stunden-Fenster, nicht weil längere Horizonte unwichtig wären, sondern weil ein täglicher Nachtlauf mit enger Zeitlinse den Bericht operational hält statt ihn in eine Wochenchronik zu verwässern. Die Trennung zwischen Resolver- und Authoritative-Layer, weil beides zwar DNS heisst, aber andere Bedrohungsprofile, andere Artefakte und andere geeignete Reaktionen besitzt. Die Delta-Orientierung, weil es methodisch mühsam ist, dieselbe Baseline jeden Tag als sensationelle Einsicht erneut zu verkaufen. Die Nullbefund-Regel, weil ein guter Bericht auch dann sauber sein muss, wenn nichts Neues zu tun ist. Gerade diese Regel wird erstaunlich oft unterschätzt. Systeme, die permanent Alarm produzieren, machen aus Überwachung keine Sicherheit.

Viele Agenten-Demonstrationen beeindrucken nur deshalb kurz, weil sie keinerlei Respekt vor Negativraum haben. Sie wollen stets etwas tun, stets etwas anstossen, stets irgendeine Aktivität erzeugen, damit die Maschine lebendig wirkt. Mein Agent hat diese narzisstische Erzählpflicht nicht. Er darf mitteilen, dass in den letzten 24 Stunden keine neuen DNS-relevanten Bedrohungen oder Advisories mit Handlungsbedarf erkennbar waren und dass die Baseline unverändert ausreichend bleibt. Diese Fähigkeit zum sauberen Nullbefund ist kein Defizit, sondern ein Gütemerkmal. Sie schützt vor künstlicher Betriebsamkeit, also vor jener typisch modernen Unsitte, Handlung mit Leistung zu verwechseln.

An dieser Stelle wird die Trennung zwischen Beobachtung, Modell, Interpretation und Werturteil nützlich. Beobachtung: Die verfügbare Sicherheitsinformation ist zerstreut, laut und zeitkritisch. Das ist keine Meinung, sondern durch die Existenz industrieller und kuratierter Digest-Formate selbst belegt. Beobachtung: Verbundene Agenten verlangen Identität, Autorisierung, Rollen, Überwachung und Governance. Auch das ist kein Bauchgefühl, sondern steht in den einschlägigen NIST- und Microsoft-Dokumenten. Beobachtung: Selbst scheinbar abgeschottete Laufzeitumgebungen können unerwartete Exfiltrations- oder Steuerpfade offenlassen. Das zeigt der Check-Point-Fall exemplarisch.

Mein Modell lautet aus diesen Beobachtungen heraus: Für kleine, gehärtete Infrastrukturen ist ein nicht verbundener Analyseagent oft das bessere Verhältnis aus Nutzen und Risiko als ein operativ eingebundener Agent. Er liefert einen zusätzlichen Lagevorsprung, ohne Identitäts- und Rechteapparate in den Produktivpfad einzuziehen. Dieses Modell ist plausibel, aber es bleibt ein Modell. Es ist kein Naturgesetz. In anderen Umgebungen, mit anderen Teamgrössen, anderen Volumina und anderer Prozessreife, kann die Abwägung anders ausfallen.

Die aktuelle Begeisterung für connected und autonomous Agenten leidet an einer strukturellen Blindstelle. Sie behandelt Eingriffsfähigkeit zu oft als Selbstwert, statt sie als Risiko zu verbuchen, das erst sehr gründlich gerechtfertigt werden muss. Dort kippt Technik in Ideologie. Denn je näher ein Agent an produktive Systeme rückt, desto höher steigen nicht nur Bequemlichkeit und Geschwindigkeit, sondern ebenso die Kosten der Fehlannahme, der Prompt-Manipulation, der Autorisierungsverwechslung, der Halluzination und der verdeckten Seiteneffekte. Das ist kein Argument gegen Automatisierung. Es ist ein Argument gegen die infantile Gleichsetzung von Automatisierung mit ungebremster Zugriffsnähe.

Mein Werturteil fällt darum klar aus. Für meine Infrastruktur wäre es unvernünftig, einem Modell operative Hände zu verleihen, nur weil der Zeitgeist auf agentische Dramatik dressiert wurde. Vernünftig ist, maschinelle Verdichtung genau dort zu nutzen, wo sie menschliche Kapazität ergänzt, und sie genau dort brutal abzuschneiden, wo aus Analyse Eingriff würde. Wer hier Mut zur Innovation fordert, meint häufig nur Mut zur Nachlässigkeit. Mich interessiert weder Mut noch Mode, sondern Belastbarkeit.

Technische Seriosität verlangt zudem nicht, jedes Detail der eigenen Schutzmechanik als frei zugängliches Recon-Material ins Netz zu kippen. Zwischen ehrlicher Dokumentation und fahrlässiger Selbstoffenlegung liegt eine einfache, aber in der Branche überraschend selten eingehaltene Grenze. Es ist sinnvoll, über Prinzipien zu schreiben, etwa über Primärquellenpriorisierung, 24-Stunden-Fenster, Layer-Trennung, Delta-Logik und Nullbefund. Es ist weniger sinnvoll, fein granulare Rate-Limits, Response-Size-Parameter, exakte Transportdetails, konkrete Zertifikats- und PKI-Merkmale oder interne Filtermechaniken in genau jener Dichte offen zu legen, aus der fremde Augen später operative Hypothesen bauen können. Dass ein öffentlicher Resolver dokumentiert ist, bedeutet nicht, dass jede innere Schraube publizistisch ausgestellt werden muss. Genau darin liegt der Unterschied zwischen Aufklärung und Eitelkeit.

Die öffentliche Projektseite zu CenturionDNS zeigt bereits bewusst genug, um die Grundrichtung zu verstehen: keine Query-Logs, QNAME-Minimisation, ANY-Drop, Hidden-Master-Betrieb, DNSSEC-Validierung, Limits, Threat-Handling, ein dedizierter unverbundener Monitoring-Agent.

Bleibt die Grenze des Agenten selbst. Der Agent ersetzt keine Urteilskraft. Er ersetzt keinen Administrator. Er ersetzt keine Betriebserfahrung. Er kann priorisieren, aber nicht verantworten. Er kann verdichten, aber nicht haften. Er kann Hinweise formulieren, aber keine Wahrheitsgarantie erzeugen. Dass dies keine Schwäche, sondern Teil der Architektur ist, gehört zu den wenigen schlichten Einsichten, die in der aktuellen Debatte erstaunlich selten offen ausgesprochen werden. Ein guter Bericht ist ein Instrument. Er ist kein Richter, kein Operator und kein Souverän.

Darum lautet die eigentliche Schlussformel auch nicht: Jetzt überwacht mein Agent mein DNS. Das wäre grober Unsinn. Richtiger lautet sie so: Ich nutze maschinelle Verdichtung, um meine eigene Aufmerksamkeitsgrenze zu verschieben, ohne die Hoheit über Handlung, Risiko und Eingriff abzugeben. Nicht die Maschine übernimmt Verantwortung. Ich verschaffe mir mit ihrer Hilfe einen zusätzlichen Lagevorsprung, aber ich bleibe derjenige, der Entscheidungen trifft, Änderungen verantwortet und im Zweifel auch die Folgen trägt. Für eine One-Man-Show ist das keine bescheidene Lösung. Es ist die präzisere.

In eigener Sache

Unabhängige DNS Sicherheitsarbeit dieser Art entsteht nicht aus freundlichen Absichtserklärungen, sondern aus Zeit, Präzision, Infrastruktur und laufenden Kosten. Wer möchte, dass CenturionDNS nicht bei einem geordneten Istzustand stehenbleibt, sondern technisch weiter verdichtet wird, kann meine Arbeit direkt unterstützen. Jede konkrete Hilfe schafft mir Raum, die Resolver Architektur weiter zu härten, die Dokumentation sauber nachzuführen, Prüfpfade und Betriebsdisziplin zu verfeinern und die Trennlinie zwischen öffentlichem Resolver, eigener Nameserver Infrastruktur und belastbarer Vertrauenskette weiter auszubauen. Genau solche Projekte wachsen nicht aus institutioneller Grosszügigkeit, sondern aus konzentrierter, unabhängiger Arbeit gegen den üblichen Strom aus Bequemlichkeit, Kurzfristigkeit und billigem Sicherheitsgerede.

Spenden

Mille fois an alle Spender.

Quellen

  1. https://www.sans.org/newsletters/newsbites ↩︎
  2. https://www.radware.com/blog/threat-intelligence/the-fastest-way-to-turn-cyber-noise-into-clear-insight/ ↩︎
  3. https://www.recordedfuture.com/blog/threat-intelligence-automation ↩︎
  4. CenturionDNS Projektseite eddns.eu beziehungsweise dns01.eddns.eu, abgerufen am 3. Mai 2026. Öffentliche Merkmale der Resolver-Plattform, darunter Query Log off, ANY-Drop, QNAME-Minimisation, Hidden-Master-Hinweis, Limits und öffentlicher Verweis auf einen „Dedicated, unconnected CenturionDNS ChatGPT Pro 5.5 Agent“. https://eddns.eu/ ↩︎
  5. Marc Weidner, „CenturionDNS. Architektur, Grenzen, Härtung.“, CenturionBlog, 31. März 2026. Angaben zu Rolle des DNS, Architektur, Protokollschichten und eigener Resolver- sowie Hidden-Master-Basis. https://coresecret.eu/2026/03/31/centuriondns-architektur-grenzen-haertung/ ↩︎
  6. Dedicated, unconnected CenturionDNS ChatGPT Pro 5.5 Agent Prompt ↩︎
  7. Ebd. ↩︎
  8. NIST, „Cybersecurity Framework Profile for Artificial Intelligence“, Initial Preliminary Draft, Dezember 2025, insbesondere PR.AA-05 auf S. 61 sowie PR.PS-05 auf S. 69. Aussagen zu separaten Berechtigungs- und Autorisierungsrichtlinien für AI-Systeme, Least Privilege, Separation of Duties sowie Beschränkung oder vollständigem Verbot beliebiger Codeausführung. https://nvlpubs.nist.gov/nistpubs/ir/2025/NIST.IR.8596.iprd.pdf ↩︎
  9. NIST NCCoE, „Accelerating the Adoption of Software and AI Agent Identity and Authorization“, Concept Paper, Februar 2026, sowie begleitende NCCoE-Ankündigung vom 5. Februar 2026. Aussagen zu Identifikation, Authentisierung, Autorisierung, Least Privilege, „on behalf of“, Human-in-the-Loop, Auditing, Non-Repudiation und Prompt-Injection als Kernprobleme agentischer Architekturen. https://www.nccoe.nist.gov/sites/default/files/2026-02/accelerating-the-adoption-of-software-and-ai-agent-identity-and-authorization-concept-paper.pdf ↩︎
  10. Microsoft Learn, „Microsoft Security Copilot Phishing Triage Agent in Microsoft Defender“, Stand 22. Februar 2026. Angaben zu Voraussetzungen, Security Compute Units, URBAC, dedizierter Agentenidentität, minimalen Rechten und Administratorenkontrolle. https://learn.microsoft.com/en-us/defender-xdr/phishing-triage-agent ↩︎
  11. Check Point Research, „ChatGPT Data Leakage via a Hidden Outbound Channel in the Code Execution Runtime“, 2026. Beschreibung eines DNS-basierten verdeckten Kanals für Exfiltration und Befehlsübertragung in einer AI-Codeausführungsumgebung. Relevanz hier als Anschauungsfall für Restrisiken vermeintlich isolierter Laufzeitumgebungen. https://research.checkpoint.com/2026/chatgpt-data-leakage-via-a-hidden-outbound-channel-in-the-code-execution-runtime/ ↩︎
  12. AuvaLabs, „ThreatWatch“, GitHub-Repository, abgerufen am 3. Mai 2026. Illustratives öffentliches Beispiel für eine selbstgehostete, aggregierende Threat-Intel-Digest-Pipeline mit grosser Feed-Zahl. Nicht als normative Primärquelle behandelt. https://github.com/AuvaLabs/threatwatch ↩︎
  13. piqoni/matcha, „Matcha“, GitHub-README, abgerufen am 3. Mai 2026. Öffentliches Beispiel eines täglichen Digest-Generators für RSS-Feeds und Themeninteressen mit optionaler LLM-Analyse und Cron-Ausführung. Illustrativ, nicht normativ. https://github.com/piqoni/matcha/blob/main/README.md ↩︎
  14. zer0yu/sec-daily-digest, GitHub-README, abgerufen am 3. Mai 2026. Öffentliches Beispiel für tägliches Scraping, AI-basierte Bewertung und kuratierte Digest-Ausgabe mit Cron-Integration. Illustrativ, nicht normativ. https://github.com/zer0yu/sec-daily-digest ↩︎

CenturionDNS ChatGPT Pro 5.5 Agent Prompt

[MODE: GPT-5.5 Extended Thinking]

Use explicit deep, multi-step analysis and prioritize primary sources wherever possible.
If information is missing, state the gap clearly instead of speculating.

Language and style:
- English
- Technical, concise, operationally useful
- No marketing language, no unnecessary repetition

────────────────────────────────────
PROJECT: DNS Security Monitoring
────────────────────────────────────

Focus and scope
- Focus on current threats relevant to operators of:
  - recursive resolvers
  - authoritative DNS infrastructure
- Priority topics:
  - amplification and reflection abuse
  - abuse of open resolvers
  - newly disclosed or materially updated vulnerabilities in major DNS software
  - DGA domains and malware / botnet infrastructure
  - DNS abuse patterns involving oversized TXT / ANY responses
  - abuse or operational misuse of DoH / DoT / DoQ
- Goal:
  - Produce a daily technical report with directly actionable recommendations for monitoring, patching, and configuration hardening
- Coverage:
  - Evaluate both layers separately:
    - recursive DNS
    - authoritative DNS

Sources and recency
- Recency target:
  - last 24 hours
- Source priority:
  1. Vendor advisories and release notes
  2. Reputable CERTs and national cyber authorities
  3. High-quality threat intelligence and abuse tracking sources with DNS relevance
  4. Technically credible security research and blogs

Operator baseline
- Assume the environment is already hardened and operationally mature.
- Do not repeat generic best practices as recommendations unless there is a clear delta.
- Existing baseline controls include:
  - suppression of unnecessary legacy disclosure surfaces
  - separation of recursive and authoritative roles
  - baseline DNS abuse controls
  - response-size hardening
  - transport hardening where appropriate
  - basic rate limiting
  - anti-drift operational discipline
  - baseline filtering against young / suspicious domains and known malicious patterns

Important constraints
- This is an advisory-only workflow.
- Do not assume direct access to production systems, credentials, management interfaces, APIs, SSH, or change mechanisms.
- Recommendations must be delta-oriented:
  only suggest measures that go beyond the assumed baseline, or where the baseline is insufficient against a newly observed threat, campaign, exploit pattern, or software issue.
- For authoritative DNS specifically:
  recommendations about zone transfer protection, transfer encryption, mutual authentication, or access controls are only valid if there is a concrete delta case such as:
  - a newly disclosed vulnerability
  - an interoperability issue
  - a PKI or certificate-related attack pattern
  - a new threat model directly affecting transfer security

Daily task / output title
- Title format:
  - "DNS Security Monitoring – [today’s date]"

Task
- Review the last 24 hours for threats, advisories, abuse developments, and exploit status changes that are realistically relevant to a hardened DNS operator.
- Distinguish clearly between recursive and authoritative relevance.
- Prioritize practical impact over news volume.
- Include CVEs only if they are:
  - newly disclosed
  - materially updated
  - newly exploitable in practice
  - added to a known exploited list
  - associated with a public PoC or meaningful exploit signal
- Include DGA / campaign material only if there is a meaningful pattern change or a gap relative to the baseline.

Required output structure

1) Executive Summary
- 5 to 10 sentences
- Maximum one screen length
- State clearly whether there is immediate action pressure or not, and why

2) Technical Report
- Separate:
  A) Recursive / resolver layer
  B) Authoritative layer
- For each relevant issue include:
  - modus operandi
  - affected components
  - expected artifacts
  - likely impact paths
  - why it matters or does not matter in a hardened environment
- Where possible, include compact, high-value indicators such as:
  - domains
  - IPs
  - ASNs
  - query patterns
  - heuristics
  - concise detection snippets
- Avoid large indicator dumps

3) Actionable Recommendations
- Separate clearly:
  A) Recursive / resolver layer
  B) Authoritative layer
- For each recommendation provide:
  - what to change
  - why
  - risk / side effects
  - how to test or monitor it
- Focus areas may include:
  - rate limits / RRL / slip / jitter, only if contextually justified
  - response-size and EDNS strategy
  - layer-appropriate hardening flags
  - patch and update guidance with concrete versions where available
  - monitoring and alerting thresholds for anomalies such as:
    - QTYPE spikes
    - NXDOMAIN anomalies
    - SERVFAIL shifts
    - TCP fallback spikes
    - resolver transport failure rates
    - unusual QNAME entropy or length
    - abnormal response-size patterns

4) Null finding rule
- If there is nothing materially relevant in the last 24 hours, state explicitly:
  "No new DNS-relevant threats or advisories requiring action in the last 24 hours. Current baseline remains sufficient."

Categories: Digitalisierung, IT, IT-Security, Linux
Tags: , , , ,

You may also like

Search: