DNS Monitoring

DNS Monitoring tracks configured hostnames and DNS records from Bitaic-managed resolver regions so operations teams can detect lookup failures, unexpected answers, slow resolution, propagation drift, TTL drift, and DNSSEC validation problems before they affect services.

What DNS Monitoring Checks

• Lookup success, response code, and current DNS state.
• Observed recursive resolver results from configured regions.
• Authoritative nameserver answers when authoritative checks are enabled.
• Expected record value mismatches when expected values are configured.
• DNS latency, TTL values, DNSSEC state, and propagation state.
• Last check time, recent state changes, and alert state.

Product Boundaries

• Use DNS Monitoring to understand whether DNS records resolve correctly and reliably.
• Use Domain Monitoring to understand whether a domain itself is healthy and operationally safe.
• Use Endpoint Monitoring to confirm that a specific URL, application, or service responds successfully after DNS resolution.

Launch Record Types

SRV, PTR, SOA, DNSKEY, DS, HTTPS, SVCB, and provider-specific synthetic checks are outside the launch DNS Monitoring scope.

Resolver Behavior

Configuration Example

dns_checks:
  - name: www.example.com
    record_type: A
    resolver_regions:
      - us-east
      - us-west
      - eu-west
    expected_values:
      - 203.0.113.10
    alert_on_mismatch: true
    max_latency_ms: 500
    check_interval_seconds: 60
    timeout_ms: 2000
    authoritative_check: true
    expected_ttl_seconds:
      min: 60
      max: 3600
    dnssec_validation: observe
    propagation_grace_period_minutes: 30

Data And Alerts

DNS Monitoring records resolver evidence and alert context on each check.

• record_name
• record_type
• resolver_regions
• resolver_results
• authoritative_result
• response_code
• expected_values
• match_state
• ttl_seconds
• ttl_state
• dnssec_state
• propagation_state
• latency_ms
• dns_state
• alert_state
• checked_at

Bitaic uses warning severity for single-region degradation, latency threshold crossings, TTL drift, and propagation mismatches still inside the grace window. Bitaic uses critical severity when all selected resolver regions fail, a positive record check returns NXDOMAIN, NODATA, or REFUSED, required DNSSEC validation fails, or an expected-value mismatch remains after the propagation grace window.

Status Labels

DNS alert states use clear, warning, critical, and unknown.

Example Workflow: Watch a Critical DNS Record

Goal: monitor the record that sends users to a critical service, alert on unexpected answers, and keep resolver latency visible during normal operations.

1. Choose the hostname and record type that determine how users reach the service.
2. Select the resolver regions that should represent user-facing DNS behavior.
3. Add expected values, mismatch alert behavior, latency threshold, and any TTL, DNSSEC, or authoritative checks your team wants enforced.
4. Connect lookup failure, record mismatch, slow-resolution, propagation, DNSSEC, and TTL alerts to the operational alert route for the service.
5. Run or wait for the first check, then confirm the dashboard shows resolver results, authoritative results when enabled, TTL, DNSSEC state, latency, last check time, and alert state.
6. After an intentional DNS change, keep the propagation grace window active until recursive and authoritative answers converge.

CLI And API

Bitaic CLI and API workflows cover running DNS checks and managing configured DNS checks.

bitaic dns add <record_name> --type <record_type> --expected-value <value> --max-latency-ms <ms> --alert-on-mismatch
bitaic dns list
bitaic dns status <record_name> --type <record_type>
bitaic dns check <record_name> --type <record_type> --expected-value <value>
bitaic dns remove <record_name> --type <record_type> --yes

DNS CLI output includes record_name, record_type, resolver_regions, resolver_results, authoritative_result, response_code, expected_values, match_state, ttl_seconds, ttl_state, dnssec_state, propagation_state, latency_ms, dns_state, alert_state, and checked_at when those checks are configured or observed.

• Create or list monitored DNS records with /v1/workspaces/{workspace_id}/targets and type: "dns_record".
• Attach resolver checks with /v1/workspaces/{workspace_id}/targets/{target_id}/checks and type: "dns_resolution".
• Update DNS check behavior with /v1/workspaces/{workspace_id}/checks/{check_id}.
• Retrieve DNS latency data with /v1/workspaces/{workspace_id}/metrics and metric=dns.latency_ms.

Troubleshooting