Back to Home

NXDOMAIN attack in Cloud DNS: zone migration

Case of anomalous NXDOMAIN traffic in Cloud DNS: metrics analysis, zone export via yc CLI, conversion to zone file and migration. Recommendations for monitoring and record review to prevent recurrences.

NXDOMAIN explosion in Cloud DNS: how the zone was migrated
Advertisement 728x90

Anomalous NXDOMAIN Traffic in Cloud DNS: Analysis, Migration, and Lessons Learned

In March 2026, a public DNS zone in Cloud DNS experienced anomalous traffic: queries with NXDOMAIN responses surged from 0.57 queries/sec to 2720 queries/sec. The total load jumped to 2951 queries/sec, leading to a sharp increase in billing. Support did not provide timely technical analysis, forcing an urgent migration of the zone to external hosting.

Metrics showed NXDOMAIN dominating over NOERROR queries. The traffic was deemed illegitimate due to the absence of business events, repeatability, and lack of explanations from the provider.

Details of the Anomaly

Normal baseline on March 22:

Google AdInline article slot
  • A noerror: 9.38 queries/sec
  • A nxdomain: 0.57 queries/sec
  • Total: 9.96 queries/sec

Anomaly on March 25:

  • A nxdomain: 2720.29 queries/sec
  • A noerror: 231.14 queries/sec
  • Total: 2951.43 queries/sec

The zone contained standard records: A, CNAME, MX, TXT, NS, and service records for DKIM, DMARC, ACME. The first alert occurred on March 7–10, with the main incident from March 24–31.

The traffic was classified as anomalous based on its profile: predominance of NXDOMAIN without legitimate reasons, recurrence of the episode, and lack of support response.

Google AdInline article slot

Support Response and Financial Impact

Contacting support yielded no results: instead of analyzing the traffic, we received a generic response about waiting for colleagues. Costs increased proportionally to queries for non-existent names.

Solution: file a claim in parallel while preparing for migration. We chose external DNS hosting with zone file import.

Migration Steps

  • Export records:
yc dns zone list-records example-zone --format json > zone-records.json

JSON structure:

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]\""
      ]
    }
  ]
}
  • Convert JSON to BIND zone file:
  • Use @ for origin
  • Remove old provider's NS records
  • Unwrap multi-TXT records
  • Check CNAME, ACME, DMARC records
  • Exclude SOA

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

Monitoring and Preparation Recommendations

For middle/senior DevOps and SRE:

  • Monitor metrics by response codes: noerror, nxdomain, load spikes.
  • Prepare a script for zone export/conversion.
  • Review records before migration: NS, TXT (ACME/DKIM), private IP.

Separate tickets: technical analysis separately from financial claims.

In case of an anomaly without a response—activate plan B: export, migrate, log everything.

Key Takeaways

  • Monitoring NXDOMAIN prevents billing surprises.
  • Export via yc dns zone list-records --format json is a key migration step.
  • Exclude provider NS records from the zone file to avoid conflicts.
  • Review TXT/ACME records: remove outdated ones.
  • Parallel tickets speed up resolution.

— Editorial Team

Advertisement 728x90

Read Next