Zpět na domů

NXDOMAIN útok v Cloud DNS: migrace zóny

Případ anomalního NXDOMAIN-provozu v Cloud DNS: analýza metrik, export zóny přes yc CLI, konverze do zone file a migrace. Doporučení pro monitorování a revizi záznamů k prevenci opakování.

Výbuch NXDOMAIN v Cloud DNS: jak migrovali zónu
Advertisement 728x90

Anomální NXDOMAIN provoz v Cloud DNS: analýza, migrace a ponaučení

V březnu 2026 byla veřejná DNS zóna v Cloud DNS vystavena anomálnímu provozu: dotazy s odpověďmi NXDOMAIN vzrostly z 0,57 dotazů/s na 2720 dotazů/s. Celková zátěž vyskočila na 2951 dotazů/s, což vedlo k prudkému nárůstu fakturace. Podpora neposkytla včasnou technickou analýzu, což donutilo k urgentní migraci zóny na externí hosting.

Metriky ukázaly dominanci NXDOMAIN nad NOERROR dotazy. Provoz byl považován za nelegitimní kvůli absenci obchodních událostí, opakování a nedostatku vysvětlení od poskytovatele.

Detaily anomálie

Normální pozadí 22. března:

Google AdInline article slot
  • A noerror: 9,38 dotazů/s
  • A nxdomain: 0,57 dotazů/s
  • Součet: 9,96 dotazů/s

Anomálie 25. března:

  • A nxdomain: 2720,29 dotazů/s
  • A noerror: 231,14 dotazů/s
  • Součet: 2951,43 dotazů/s

Zóna obsahovala standardní záznamy: A, CNAME, MX, TXT, NS, služební pro DKIM, DMARC, ACME. První varování vzniklo 7.–10. března, hlavní incident – 24.–31. března.

Provoz byl kvalifikován jako anomální podle profilu: převaha NXDOMAIN bez legitimních důvodů, opakování epizody, absence reakce podpory.

Google AdInline article slot

Reakce podpory a finanční důsledky

Oslovení podpory nepřineslo výsledky: místo rozboru provozu jsme dostali odkaz na čekání na kolegy. Náklady rostly úměrně dotazům na neexistující jména.

Řešení: paralelně zaznamenat reklamaci a připravit migraci. Vybrali jsme externí DNS hosting s importem zone file.

Kroky migrace

  • Export záznamů:
yc dns zone list-records example-zone --format json > zone-records.json

JSON struktura:

Google AdInline article slot
{
  "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]\""
      ]
    }
  ]
}
  • Konverze JSON na BIND zone file:
  • @ pro origin
  • Odstranění NS starého poskytovatele
  • Rozvinutí multi-TXT
  • Kontrola CNAME, ACME, DMARC
  • Vyloučení SOA

Příklad 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.

Doporučení pro monitoring a přípravu

Pro middle/senior DevOps a SRE:

  • Sledovat metriky podle kódů odpovědí: noerror, nxdomain, špičky zátěže.
  • Připravit skript pro export/konverzi zóny.
  • Revidovat záznamy před přenosem: NS, TXT (ACME/DKIM), private IP.

Oddělovat tickety: technická analýza zvlášť od finančních reklamací.

Při anomálii bez odpovědi – spustit plán B: export, migrace, zaznamenání logů.

Co je důležité

  • Monitoring NXDOMAIN předchází překvapením s náklady.
  • Export přes yc dns zone list-records --format json – klíčový krok migrace.
  • Vyloučit NS poskytovatele z zone file, aby se předešlo konfliktům.
  • Revize TXT/ACME je povinná: odstranit zastaralé.
  • Paralelní tickety urychlují řešení.

— Editorial Team

Advertisement 728x90

Číst dál