Atak NXDOMAIN w Cloud DNS: migracja strefy

Anomalny ruch NXDOMAIN w Cloud DNS: analiza, migracja i wnioski

W marcu 2026 roku publiczna strefa DNS w Cloud DNS doświadczyła anomalnego ruchu: zapytania z odpowiedziami NXDOMAIN wzrosły z 0,57 zap./s do 2720 zap./s. Całkowite obciążenie skoczyło do 2951 zap./s, co doprowadziło do gwałtownego wzrostu rachunków. Wsparcie techniczne nie dostarczyło na czas analizy technicznej, zmuszając do pilnej migracji strefy na zewnętrzny hosting.

Metryki wykazały dominację NXDOMAIN nad zapytaniami NOERROR. Ruch uznano za nielegalny z powodu braku zdarzeń biznesowych, powtarzalności i braku wyjaśnień od dostawcy.

Szczegóły anomalii

Normalne tło 22 marca:

• A noerror: 9,38 zap./s
• A nxdomain: 0,57 zap./s
• Suma: 9,96 zap./s

Anomalia 25 marca:

• A nxdomain: 2720,29 zap./s
• A noerror: 231,14 zap./s
• Suma: 2951,43 zap./s

Strefa zawierała standardowe rekordy: A, CNAME, MX, TXT, NS, służbowe dla DKIM, DMARC, ACME. Pierwszy alarm pojawił się 7–10 marca, główny incydent — 24–31 marca.

Ruch zakwalifikowano jako anomalny według profilu: przewaga NXDOMAIN bez legalnych przyczyn, powtórzenie epizodu, brak reakcji wsparcia.

Reakcja wsparcia i konsekwencje finansowe

Zwrot do wsparcia nie przyniósł rezultatów: zamiast analizy ruchu otrzymano odpowiedź o oczekiwaniu na kolegów. Koszty rosły proporcjonalnie do zapytań o nieistniejące nazwy.

Rozwiązanie: równolegle zgłaszać reklamację i przygotowywać migrację. Wybrano zewnętrzny hosting DNS z importem pliku strefy.

Kroki migracji

• Eksport rekordów:

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

Struktura JSON:

{
  "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]\""
      ]
    }
  ]
}

• Konwersja JSON na plik strefy BIND:
• @ dla origin
• Usunięcie NS starego dostawcy
• Rozwinięcie multi-TXT
• Sprawdzenie CNAME, ACME, DMARC
• Wykluczenie SOA

Przykład pliku strefy:

$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.

Zalecenia dotyczące monitorowania i przygotowania

Dla middle/senior DevOps i SRE:

• Śledzić metryki według kodów odpowiedzi: noerror, nxdomain, szczyty obciążenia.
• Przygotować skrypt eksportu/konwersji strefy.
• Przeglądać rekordy przed przeniesieniem: NS, TXT (ACME/DKIM), prywatne IP.

Rozdzielać zgłoszenia: analiza techniczna osobno od reklamacji finansowych.

Przy anomalii bez odpowiedzi — uruchamiać plan B: eksport, migracja, utrwalanie logów.

Co jest ważne

• Monitorowanie NXDOMAIN zapobiega niespodziankom z wydatkami.
• Eksport przez yc dns zone list-records --format json — kluczowy krok migracji.
• Wykluczać NS dostawcy z pliku strefy, aby uniknąć konfliktów.
• Przegląd TXT/ACME jest obowiązkowy: usuwać przestarzałe.
• Równoległe zgłoszenia przyspieszają rozwiązanie.

— Editorial Team