DNS traffic alerts: API routes and dashboard controls

We have added customer-managed DNS traffic alerts to DNScale.

Scale and custom plan customers can now create alert routes from the dashboard or the API, send notifications to email or webhooks, and tune thresholds per account or per zone.

Instead of asking customers to build alerting from raw DNS logs, DNScale now lets them configure DNS traffic alerts as a first-class part of the platform.

These alerts are for teams that run important DNS at scale: platform teams, MSPs, agencies, and SaaS operators. They do not need another chart to remember to check. They need a routed signal when a login hostname starts returning NXDOMAIN after a deploy, one customer zone begins returning SERVFAILs, or a resolver keeps asking for the same broken name. The useful part is the handoff: the alert tells the team which scope crossed which threshold, so they can go straight to the zone, customer, or integration that needs attention.

Why this matters

DNS problems often show up as patterns before they show up as a single clean failure.

A domain migration can create a sudden NXDOMAIN spike. A broken upstream or bad delegation can push SERVFAIL higher than usual. A crawler, botnet, or misconfigured client can turn one forgotten hostname into a noisy stream of queries. For teams that operate many zones, those signals are easy to miss if they only live inside a dashboard that someone checks later.

Alerts make those signals actionable. You can route a warning to the team that owns the zone, send critical events into your incident tooling, and keep lower priority noise out of the main on-call channel.

Useful during DNS attacks

Alerts are also useful when a zone is being abused or attacked.

DNS DDoS does not always look like one giant wall of traffic. It can show up as high QPS against a single zone, a random-subdomain attack that drives NXDOMAIN up, a refused-query pattern, or a small set of resolvers concentrating traffic on names that should not be hot.

DNScale already runs DNS traffic through an anycast edge and DDoS-aware controls. Customer alerts add the operational layer on top: your team can see that a zone crossed a suspicious threshold, which response code changed, and where the notification should go. That is useful during an active incident because the DNS provider may still be absorbing the traffic, while your team needs to know whether to contact a customer, pause a rollout, check a misbehaving integration, or open an incident internally.

More than graphs and query logs

Many managed DNS setups stop at analytics: they show query volume, response codes, or logs, and leave the customer to build the alerting path somewhere else.

That works if you have a platform team ready to export logs, write metric filters, maintain dashboards, and keep notification routing in sync with every zone owner. It is less useful when you manage hundreds of domains, customer zones, or environments and need the alert to go directly to the right team.

DNScale treats DNS traffic alerts as part of DNS operations. You can define the scope, thresholds, severity, cooldown, and notification channels where the DNS is managed, then automate the same setup through the API.

What you can configure

Alert routes have four main parts:

• Scope: one zone, or the whole customer account.
• Thresholds: QPS, NXDOMAIN ratio, SERVFAIL ratio, query-drop detection, and refused-query volume.
• Channels: email recipients and webhook targets.
• Controls: enabled or disabled status, minimum severity, and cooldown.

Account routes are useful when you want one baseline policy for all zones. Zone routes are better when one domain needs tighter thresholds, a different recipient list, or a webhook owned by a specific team.

Dashboard first when you want a quick change

The dashboard now includes an Alerts section for accounts with the DNS traffic alerts feature enabled.

From there you can list existing routes, create account or zone routes, edit thresholds, toggle a route on or off, and manage email or webhook channels. That is the right path for day-to-day changes: adding an on-call alias, raising a threshold after a known traffic change, or disabling a noisy route while you investigate.

Accounts without the feature will see the plan availability message instead of a broken page.

API when alerts are part of your workflow

The same route model is available through /v1/alerts, so teams can manage DNS traffic alerts from Terraform-adjacent tooling, internal control panels, or customer onboarding automation.

API keys need alerts:read for listing and inspecting routes, and alerts:write for creating, updating, or deleting them. The account also needs the dns_traffic_alerts feature entitlement, which is available on Scale and custom plans.

Here is a small zone-level example:

curl -X POST "https://api.dnscale.eu/v1/alerts" \
  -H "Authorization: Bearer $DNSCALE_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "scope_type": "zone",
    "scope_id": "zone_uuid_here",
    "thresholds": [80, 90],
    "threshold_config": {
      "qps_warning": 1000,
      "qps_critical": 5000,
      "nxdomain_ratio_warning": 0.3,
      "nxdomain_ratio_critical": 0.5,
      "servfail_ratio_warning": 0.1,
      "servfail_ratio_critical": 0.3
    },
    "status": "enabled",
    "severity": "warning",
    "cooldown_seconds": 900,
    "channels": [
      {
        "type": "email",
        "email_to": ["dns-oncall@example.com"],
        "enabled": true
      }
    ]
  }'

The full endpoint reference is in the Alerts API documentation.

Near real time, outside the DNS query path

Alerting is intentionally not synchronous with DNS resolution. Query handling stays fast, while alerting runs from collected telemetry.

In production, traffic is evaluated on a regular cadence over a short rolling window. Duplicate event creation is suppressed, and each route has its own cooldown so one noisy condition does not send the same notification every few seconds.

That makes the feature suitable for operational awareness and incident routing, without putting notification delivery in the critical path for DNS answers.

A few practical setups

For most customers, we recommend starting with one account-level route:

• Warning severity.
• Email to the DNS operations or platform team.
• Conservative thresholds based on the normal query volume of the account.
• A 15 to 30 minute cooldown.

Then add zone-level routes for the domains that need special handling. A high traffic production zone, a customer-facing SaaS domain, and a delegation used by automation usually deserve different thresholds and different notification targets.

If you already use an incident system, add a webhook channel for critical routes and keep email for human-readable follow-up. Email is good for context; webhooks are better for machines.

Availability

DNS traffic alerts are available for Scale and custom plan customers.

If your team wants alerts enabled for an existing account, open the dashboard and check the Alerts page. If the feature is not available on the account, the page will show the plan requirement instead of allowing partial configuration.

For API users, start with the Alerts API documentation, then create either an account route or a zone route depending on how narrowly you want notifications to be scoped.