DNS-NXDOMAIN-Spike: Fehlkonfiguration oder Angriff?

Ein DNS-NXDOMAIN-Spike ist eines dieser Ereignisse, die im NOC sofort Alarm auslösen: Plötzlich steigt der Anteil an DNS-Antworten mit „NXDOMAIN“ (Non-Existent Domain) stark an, Nutzer melden „Webseiten gehen nicht“, und Dashboards zeigen ungewöhnliche Muster bei Query-Volumen und Fehlerraten. Gleichzeitig ist NXDOMAIN per se kein „kaputter DNS-Server“, sondern häufig eine legitime Antwort: Der abgefragte Name existiert aus Sicht der autoritativen Zone nicht. Genau das macht die Lage operativ heikel. Ein NXDOMAIN-Spike kann aus einer einfachen Fehlkonfiguration entstehen (falscher CNAME, Tippfehler, Split-Horizon-Divergenz, abgelaufene Subdomain, fehlerhafte Service-Discovery) – oder er kann ein Symptom eines Angriffs sein, etwa eines DGA-basierten Malware-Ausbruchs, eines NXDOMAIN-Floods, eines Missbrauchs durch kompromittierte Clients oder eines DoH/DoT-Bypass-Versuchs. Dieser Artikel zeigt, wie Sie einen NXDOMAIN-Spike strukturiert einordnen, welche Telemetrie Sie in Minuten benötigen und wie Sie zwischen „Change-bedingter Konfiguration“ und „Security-Incident“ unterscheiden, ohne in Vermutungen abzurutschen. Ziel ist ein praxistaugliches Runbook, das sowohl Einsteigern als auch erfahrenen Engineers hilft, schnell zu stabilisieren, sauber zu eskalieren und wiederkehrende NXDOMAIN-Spitzen durch Prävention zu reduzieren.

NXDOMAIN operativ verstehen: Was sagt die Antwort wirklich aus?

NXDOMAIN bedeutet: „Dieser Domain-Name existiert nicht“ – bezogen auf die Abfrage, die beim Resolver einging, und bezogen auf den autoritativen Zustand, den der Resolver ermittelt oder aus dem Cache entnommen hat. Wichtig ist die Abgrenzung zu ähnlichen Fehlerbildern:

• NXDOMAIN: Der Name ist nicht vorhanden (oft negativ gecached).
• SERVFAIL: Der Resolver konnte die Auflösung nicht sauber abschließen (z. B. DNSSEC-Validierung, Upstream-Fehler, Timeouts).
• Timeout: Keine Antwort oder Paketverlust/Filtering auf dem Pfad.
• NODATA: Der Name existiert, aber der abgefragte Record-Typ nicht (z. B. AAAA fehlt, A existiert).

Für die Incident-Triage ist entscheidend: NXDOMAIN ist häufig ein Client-/Applikationsproblem (falsche Namen) oder ein Change-Problem (falsche Zone/Delegation). Gleichzeitig ist NXDOMAIN ein starkes Signal für DGA- und Scanning-Muster, weil Angreifer und Malware massenhaft zufällige oder generierte Namen abfragen, die naturgemäß nicht existieren.

Erste 5 Minuten: Minimaldaten, ohne die Sie nicht entscheiden können

Ein NXDOMAIN-Spike lässt sich nur sauber klassifizieren, wenn Sie sofort die wichtigsten Dimensionen erfassen. Ohne diese Daten eskalieren Teams aneinander vorbei (Netzwerk vs. DNS vs. Security vs. Application).

• Zeitraum: Startzeit, Peak, aktuelle Lage, ob es periodisch ist.
• Resolver-Scope: Betroffen sind Corporate Resolver, einzelne POPs, ein Standort oder alle?
• Top-N Query Names: Welche FQDNs erzeugen NXDOMAIN? Gibt es ein Muster (gleiche Zone, gleiche Suffixe, zufällig)?
• Top-N Clients: Welche Quell-IPs/VLANs/VDI-Pools verursachen die Anfragen?
• Query Rate: Absolute QPS und NXDOMAIN-QPS; Verhältnis NXDOMAIN/Total.
• Record-Typen: A/AAAA/SRV/TXT/HTTPS/SVCB – manche Typen sind bei bestimmten Clients „noisy“.
• Changes: DNS-, Proxy-, VPN-, Endpoint-, Service-Discovery- oder App-Change in den letzten Stunden?

Wenn Sie diese Punkte in ein Ticket schreiben, können Owner-Teams schnell handeln: DNS kann Zone/Delegation prüfen, Security kann DGA/Beaconing bewerten, Endpoint kann kompromittierte Hosts isolieren.

Baseline und Schwellwerte: Wann ist ein NXDOMAIN-Spike wirklich „ungewöhnlich“?

Jede Umgebung hat „natürliche“ NXDOMAIN-Raten. Browser, Telemetrie-Agenten, Auto-Discovery, alte Bookmarks oder Tippfehler erzeugen kontinuierlich negatives DNS. Deshalb sollte ein NOC nicht nur auf absolute NXDOMAIN-Zahlen schauen, sondern auf Anomalien gegenüber einer Baseline.

• NXDOMAIN-Anteil (%): Anteil NXDOMAIN an allen Antworten, pro Resolver-Cluster und pro Standort.
• NXDOMAIN-QPS: Absolute Rate, um „leise“ Probleme vs. volumetrische Ereignisse zu unterscheiden.
• Unique Query Names: Ein starker Anstieg einzigartiger Namen spricht eher für DGA/Scanning als für eine einzelne Fehlkonfiguration.
• Unique Clients: Viele Clients gleichzeitig deuten eher auf einen globalen Change oder ein externes Ereignis; wenige „Hot Clients“ eher auf kompromittierte Endpoints.

Ein praktischer Ansatz ist die Kombination aus relativer und absoluter Schwelle. Beispiel: Alarm auslösen, wenn NXDOMAIN-Anteil über Baseline + X% liegt und gleichzeitig NXDOMAIN-QPS über Y liegt. Dadurch reduzieren Sie False Positives bei Lastspitzen.

Ein einfacher Anomalie-Indikator mit MathML

Für Dashboards lässt sich ein leichter Score definieren, der Abweichungen sichtbar macht, ohne gleich Machine Learning zu benötigen:

$\mathrm{Score}=\left(\frac{\mathrm{NX}–\mathrm{NX}\_\mathrm{base}}{\mathrm{NX}\_\mathrm{base}}\right)\times \frac{U\_\mathrm{names}}{U\_\mathrm{names}\_\mathrm{base}}$

Dabei ist NX die aktuelle NXDOMAIN-QPS, NX_base die Baseline, U_names die Anzahl einzigartiger Query Names. Hohe Werte signalisieren: nicht nur mehr NXDOMAIN, sondern auch „mehr Vielfalt“ – ein typisches Angriffsmuster.

Typische Fehlkonfigurationen, die NXDOMAIN-Spikes auslösen

Viele NXDOMAIN-Spikes sind hausgemacht und treten kurz nach Changes auf. Die gute Nachricht: Sie lassen sich oft schnell eingrenzen, weil die betroffenen Namen „sinnvoll“ aussehen (Service-Namen, Subdomains, interne Zonen).

• Falscher CNAME-Target: CNAME zeigt auf einen nicht existierenden Namen, häufig nach Refactoring oder Tippfehlern.
• Split-Horizon-Divergenz: Intern existiert ein Name, extern nicht (oder umgekehrt). Clients außerhalb der erwarteten Resolver-Pfade laufen in NXDOMAIN.
• Service-Discovery-Drift: SRV-Records oder interne Naming-Konventionen ändern sich, Clients fragen aber alte Namen ab.
• Abgelaufene Subdomain/Deprovisioning: Ein Service wird entfernt, Clients versuchen weiter zu verbinden (Retry-Storm).
• Fehlerhafte Suchdomänen (Search Suffix): Clients hängen automatisch Suffixe an und erzeugen NXDOMAIN-Kaskaden.
• IPv6/NODATA als NXDOMAIN interpretiert: Manche Anwendungen behandeln „kein AAAA“ falsch und melden „DNS kaputt“.

Heuristik: Wenn die Top-N NXDOMAIN-Namen zu Ihrer eigenen Domain oder zu wenigen, klaren Zonen gehören, ist Fehlkonfiguration wahrscheinlicher als Angriff. Dann ist der schnellste Weg: Autoritative Wahrheit prüfen und Change-Historie matchen.

Angriffs- und Missbrauchsmuster: Wann NXDOMAIN auf Security hindeutet

Ein NXDOMAIN-Spike kann ein starkes Security-Signal sein – besonders, wenn viele einzigartige, zufällig wirkende Namen auftreten. Hier sind typische Muster, die ein NOC erkennen sollte, ohne sofort forensisch zu werden:

• DGA/Beaconing: Malware generiert Domains algorithmisch und versucht periodisch, Command-and-Control zu finden. Resultat: viele einzigartige NXDOMAINs mit scheinbar zufälligen Labels.
• Domain-Scanning: Tools probieren Subdomains massenhaft durch (z. B. „admin“, „api“, „staging“), um Fehlkonfigurationen zu finden.
• DoH/DoT-Umgehung: Clients nutzen alternative Resolver oder Tunnels; lokale Policies greifen nicht, NXDOMAIN-Muster ändern sich abrupt.
• Amplification-Vorbereitung: Ein Angreifer testet Resolver-Verhalten, auch wenn NXDOMAIN selbst nicht der Amplifier ist; dennoch können Peaks Vorboten sein.
• Kompromittierter Client: Wenige Quell-IPs erzeugen extrem hohe NXDOMAIN-QPS (Hotspot-Muster).

Heuristik: Attack/Missbrauch ist wahrscheinlicher, wenn (a) die Unique Query Names stark steigen, (b) die Top-N-Namen nicht zu Ihren Domains passen, (c) wenige Clients extrem auffällig sind, oder (d) der Spike zeitgleich mit EDR-/Proxy-Alerts auftritt.

Decision-Tree: Fehlkonfiguration oder Angriff in reproduzierbaren Schritten trennen

Das NOC braucht eine klare Ja/Nein-Logik, die ohne Spezialwissen funktioniert. Die folgenden Schritte sind bewusst pragmatisch formuliert.

• Schritt 1: Gehören die NXDOMAIN-Top-N-Namen zu unseren Zonen? Wenn ja, prüfen Sie zuerst Zone/Records/Change. Wenn nein, prüfen Sie Client- und Security-Signale.
• Schritt 2: Sind es wenige „Hot Clients“? Wenn ja, isolieren Sie diese Quellen (Segment/VLAN/VDI-Pool) und eskalieren an Security/Endpoint.
• Schritt 3: Steigt die Anzahl einzigartiger Namen stark an? Wenn ja, DGA/Scanning ist plausibel; sammeln Sie Samples und eskalieren an SOC.
• Schritt 4: Tritt es nur auf bestimmten Resolvern/Standorten auf? Wenn ja, Resolver-Konfiguration, Forwarding, Split-Horizon oder lokales Filtering prüfen.
• Schritt 5: Gibt es einen zeitnahen Change? Wenn ja, Change-Rollback oder Korrektur priorisieren; negative Caches beachten.

Wichtig: Der Decision-Tree ersetzt keine Security-Analyse, liefert aber eine belastbare Erstklassifizierung und verhindert, dass Infrastrukturteams stundenlang eine „Netzwerkstörung“ suchen, die eigentlich ein kompromittierter VDI-Pool ist.

Telemetrie, die Sie für saubere Beweise brauchen

Ob Fehlkonfiguration oder Angriff: Ohne Beweise eskalieren Sie nur „Gefühle“. Diese Datenquellen sind für NXDOMAIN-Incidents besonders wertvoll:

• Resolver-Logs: Query Name, Client-IP, Response Code, Antwortzeit, Cache-Hit/Miss, Upstream/Forwarder.
• DNS-Statistiken: NXDOMAIN-Ratio, QPS, Unique Names/Clients, Top-N, per View/Policy.
• Network Telemetry: Ausgehende DNS-Flows (UDP/TCP 53, ggf. 853 für DoT, 443 für DoH zu bekannten Endpoints).
• EDR/SIEM: Prozess, der DNS erzeugt; auffällige Hosts; Korrelation mit Malware-Indikatoren.
• Change- und Config-Historie: DNS-Zone, DHCP-Optionen, Search Suffix, Proxy/VPN-Routing, Resolver-Policies.

Eine einfache, aber wirkungsvolle Ergänzung ist das Sampling von NXDOMAIN-Query Names (z. B. 100–500 Beispiele) für Security. Damit kann das SOC oft schnell DGA-Ähnlichkeiten erkennen, ohne dass das NOC tiefe Malware-Expertise braucht.

Mitigation: Was das NOC sofort tun kann, ohne Folgeschäden zu erzeugen

Die Mitigation hängt stark davon ab, ob Sie Fehlkonfiguration oder Angriff vermuten. Trotzdem gibt es Maßnahmen, die in beiden Fällen helfen, die Resolver-Stabilität zu schützen.

• Rate-Limiting für problematische Clients: Wenn wenige Quellen dominieren, begrenzen Sie deren DNS-QPS (Policy/ACL/Resolver-Client-Limits), um Kollateralschäden zu vermeiden.
• Response Policy Zones (RPZ) / DNS-Policies: Blockieren oder „sinkholen“ Sie eindeutig bösartige Domains, sobald das SOC bestätigt.
• Negative Cache bewusst managen: Bei Fehlkonfigurationen kann NXDOMAIN nach Fix noch „kleben“. Planen Sie Cache-Flush in kontrollierten Resolver-Clustern ein.
• Fallback-Resolver: Bei Resolver-Überlast kann temporäres Failover helfen; dabei Policies und Logging-Anforderungen beachten.
• Change-Rollback: Wenn der Spike mit einer DNS-/DHCP-/Search-Suffix-Änderung korreliert, ist ein Rollback oft der schnellste Stabilitätsgewinn.

Wichtig: Unkoordiniertes „Flushen“ auf vielen Systemen kann zusätzliche Last erzeugen. Behandeln Sie Cache-Flush wie eine Change-Maßnahme, priorisieren Sie Resolver-seitig und segmentiert.

RCA-Ansatz: Häufige Root Causes und wie Sie sie belegen

Für einen belastbaren RCA sollten Sie die Kette „Ursache → Mechanismus → beobachtetes Symptom → Nachweis“ dokumentieren. Beispiele:

• Fehlerhafte CNAME-Kette: CNAME zeigt auf nicht existierenden Target → Resolver liefert NXDOMAIN → Top-N enthält den CNAME-Target → autoritativ ist Target nicht vorhanden.
• Search-Suffix-Fehlkonfiguration: Clients appendieren falsches Suffix → viele NXDOMAINs mit identischem Suffix → betroffenes VLAN/Standort nach DHCP/GPO-Change → Rollback senkt NXDOMAIN sofort.
• DGA-Ausbruch: Einzelne Hosts erzeugen sehr viele einzigartige Namen → NXDOMAIN-Unique-Namen steigen stark → EDR zeigt auffälligen Prozess → Isolierung stoppt Spike.
• Split-Horizon-Drift: Internes View liefert NXDOMAIN, extern nicht → nur Corporate Resolver betroffen → View-Konfig/Zone-Divergenz nach Change nachweisbar.

Diese Logik verhindert „RCA by Bauchgefühl“ und verbessert langfristig die Standardisierung der Incident-Klassifizierung im NOC.

Prävention: Wie Sie NXDOMAIN-Spikes seltener und weniger dramatisch machen

Viele Teams akzeptieren NXDOMAIN als „Noise“. Das ist riskant, weil echte Ausbrüche dann im Rauschen untergehen. Prävention bedeutet nicht, NXDOMAIN auf null zu drücken, sondern Muster besser kontrollierbar zu machen.

• DNS-Observability standardisieren: Top-N NXDOMAIN-Names/Clients, Unique Names, NXDOMAIN-Ratio pro Segment.
• Change-Governance: TTL- und Search-Suffix-Änderungen mit Impact-Analyse; Canary-Rollouts für Clients/Standorte.
• Segmentierung: VDI/IoT/Guest in getrennte Resolver-Policies, damit kompromittierte Bereiche nicht alles beeinträchtigen.
• Security-Integration: Automatische Übergabe von NXDOMAIN-Samples an SIEM/SOC, definierte Eskalationskriterien.
• Negative Caching bewusst konfigurieren: SOA/Negative TTL so wählen, dass Fehlkonfigurationen nicht zu lange „kleben“, ohne die Resolver-Last zu explodieren.

Wenn Sie die „normalen“ NXDOMAIN-Quellen kennen (Browser, OS, Telemetrie), können Sie diese in Dashboards ausklammern oder separat betrachten und gewinnen sofort an Signalqualität.

Outbound-Links für vertiefende Referenzen

• DNS Concepts and Facilities (RFC 1034) für Grundlagen der DNS-Logik.
• Domain Names – Implementation and Specification (RFC 1035) für technische Details und Response Codes.
• Negative Caching of DNS Queries (RFC 2308) für NXDOMAIN- und Negative-Caching-Verhalten.
• Unbound Resolver als Referenz für rekursive Resolver-Features und Logging.
• ISC BIND für Betrieb, Telemetrie und typische Konfigurationsmuster im DNS.
• Google Public DNS – Using the service als Vergleichspfad für Resolver-A/B-Tests.
• Cloudflare Learning Center: DNS-Grundlagen für anschauliche Erklärungen und operative Begriffe.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.