NXDOMAIN-Angriff in Cloud DNS: Zonenmigration

Anomale NXDOMAIN-Traffic in Cloud DNS: Analyse, Migration und Erkenntnisse

Im März 2026 verzeichnete eine öffentliche DNS-Zone in Cloud DNS anomale Traffic: Abfragen mit NXDOMAIN-Antworten stiegen von 0,57 Abfragen/Sekunde auf 2720 Abfragen/Sekunde. Die Gesamtlast sprang auf 2951 Abfragen/Sekunde, was zu einem starken Anstieg der Abrechnung führte. Der Support lieferte keine zeitnahe technische Analyse, sodass eine dringende Migration der Zone zu einem externen Hosting erforderlich wurde.

Metriken zeigten, dass NXDOMAIN-Abfragen NOERROR-Abfragen dominierten. Der Traffic wurde als illegitim eingestuft, da keine Geschäftsereignisse vorlagen, er wiederholt auftrat und der Anbieter keine Erklärungen lieferte.

Details der Anomalie

Normaler Basiswert am 22. März:

• A noerror: 9,38 Abfragen/Sekunde
• A nxdomain: 0,57 Abfragen/Sekunde
• Gesamt: 9,96 Abfragen/Sekunde

Anomalie am 25. März:

• A nxdomain: 2720,29 Abfragen/Sekunde
• A noerror: 231,14 Abfragen/Sekunde
• Gesamt: 2951,43 Abfragen/Sekunde

Die Zone enthielt Standardeinträge: A, CNAME, MX, TXT, NS und Service-Einträge für DKIM, DMARC, ACME. Die erste Warnung erfolgte am 7.–10. März, mit dem Hauptvorfall vom 24.–31. März.

Der Traffic wurde aufgrund seines Profils als anomal klassifiziert: Dominanz von NXDOMAIN ohne legitime Gründe, Wiederholung des Vorfalls und fehlende Support-Antwort.

Support-Reaktion und finanzielle Auswirkungen

Die Kontaktaufnahme mit dem Support brachte keine Ergebnisse: Statt einer Analyse des Traffics erhielten wir eine generische Antwort über das Warten auf Kollegen. Die Kosten stiegen proportional zu Abfragen nach nicht existierenden Namen.

Lösung: Parallel eine Reklamation einreichen und die Migration vorbereiten. Wir wählten externes DNS-Hosting mit Zone-File-Import.

Migrationsschritte

• Einträge exportieren:

yc dns zone list-records example-zone --format json > zone-records.json

JSON-Struktur:

{
  "record_sets": [
    {
      "name": "*.service.example-company.ru.",
      "type": "A",
      "ttl": "300",
      "data": [
        "203.0.113.10"
      ]
    },
    {
      "name": "_dmarc.example-company.ru.",
      "type": "TXT",
      "ttl": "300",
      "data": [
        "\"v=DMARC1; p=none; sp=none; rua=mailto:[email protected]\""
      ]
    }
  ]
}

• JSON in BIND-Zone-File konvertieren:
• @ für den Ursprung verwenden
• NS-Einträge des alten Anbieters entfernen
• Multi-TXT-Einträge entpacken
• CNAME-, ACME-, DMARC-Einträge prüfen
• SOA ausschließen

Beispiel-Zone-File:

$TTL 1d
example-company.ru. IN SOA ns1.provider.example. hostmaster.ns1.provider.example. (
        1
        14400
        3600
        604800
        10800
)

@       A       203.0.113.10
app     A       203.0.113.20
www     CNAME   infra.example-company.ru.

Überwachung und Vorbereitungsempfehlungen

Für mittlere/senior DevOps und SRE:

• Metriken nach Antwortcodes überwachen: noerror, nxdomain, Lastspitzen.
• Ein Skript für Zone-Export/Konvertierung vorbereiten.
• Einträge vor der Migration prüfen: NS, TXT (ACME/DKIM), private IP.

Separate Tickets: Technische Analyse getrennt von finanziellen Reklamationen.

Bei einer Anomalie ohne Antwort – Plan B aktivieren: exportieren, migrieren, alles protokollieren.

Wichtige Erkenntnisse

• Überwachung von NXDOMAIN verhindert Abrechnungsüberraschungen.
• Export via yc dns zone list-records --format json ist ein entscheidender Migrationsschritt.
• NS-Einträge des Anbieters aus dem Zone-File ausschließen, um Konflikte zu vermeiden.
• TXT/ACME-Einträge prüfen: veraltete entfernen.
• Parallele Tickets beschleunigen die Lösung.

— Editorial Team