Automate DNS checks in CI/CD pipelines

DNS checks can catch missing or unexpected records after infrastructure changes. Choose assertions for records your deployment owns, and run them from a network that can reach the appropriate resolver. Public DNS checks cannot validate a private zone that is visible only inside a virtual network.

Check an expected A record

The following shell step requires dig on the runner. Replace the documentation-only address and domain with your deployment's values. It succeeds if the expected address appears among the answers and fails on a lookup error or a missing address.

#!/bin/sh
set -eu
domain="www.example.com"
expected="192.0.2.10"
answers=$(dig +time=2 +tries=1 +short A "$domain")
printf '%s\n' "$answers"
if ! printf '%s\n' "$answers" | grep -Fx -- "$expected"; then
  echo "Expected A record not found for $domain" >&2
  exit 1
fi

Adapt the assertion to your setup: a CDN or load balancer may return multiple or changing addresses, and a CNAME can appear alongside the final address. For MX, TXT or CAA records, check the relevant fields rather than assuming a stable answer order. Use the domain DNS lookup to inspect records while investigating failures.

Account for propagation

Check authoritative name servers when verifying publication, and check the recursive resolvers used by clients when verifying what they can see. Cached positive and negative answers may persist after a change. Use bounded retries and a timeout appropriate to your TTLs; report the resolver, record type and actual answer on failure instead of silently passing.

Make the check operational

Place checks after DNS deployment, distinguish transient resolver failures from incorrect answers, and alert the responsible team if a timeout expires. Do not query or print private infrastructure details in public build logs. For reverse DNS, use the reverse IP lookup to inspect PTR results separately.

More guides