DNS checks after moving a service
A practical sequence for checking DNS, redirects and TLS after moving a service or reverse proxy target.
Moving a service is rarely finished when one local lookup returns the expected address. DNS changes are distributed, cached and often tied to HTTP redirects, TLS certificates and reverse proxy behavior.
The useful check is therefore a short sequence: confirm who is authoritative, compare resolver answers, verify the application path and keep the rollback window visible.
Start with authority
Before comparing public resolvers, confirm which nameservers are authoritative for the zone. If the delegation is wrong, resolver output can look random because different clients may still be walking different paths.
- `dig example.com NS +short`
- `dig @<authoritative-ns> example.com A +short`
- `dig @<authoritative-ns> www.example.com CNAME +short`
Replace the authoritative nameserver and hostnames with public values that are safe to share.
Compare resolver paths
After the authoritative answer looks correct, compare at least two resolver paths. The goal is not to prove that every cache has expired, but to notice obvious mismatches before declaring the move done.
- `dig @1.1.1.1 example.com A +short`
- `dig @8.8.8.8 example.com A +short`
- `dig @9.9.9.9 example.com A +short`
If the answers differ, check TTLs and the timing of the last change before changing more variables.
Verify the service path
DNS can be correct while the user-visible service is still wrong. Follow the HTTP layer after DNS resolves:
- `curl -I https://www.example.com/`
- Confirm the expected status code.
- Confirm redirects point to the intended canonical host.
- Confirm the certificate covers the host being checked.
This catches the common case where a record points to the right target, but the reverse proxy, redirect policy or certificate configuration still belongs to the old path.
Keep rollback visible
During a migration, TTLs are operational state. They determine how quickly a bad change can be backed out and how long mixed answers may be normal.
Write down the expected TTL before the move, the time of the change and the earliest point where stale answers should no longer be expected. That note is usually more useful than another round of random lookups.
Publish safely
For public writeups, use example domains and sanitized outputs. Do not publish internal hostnames, private IP ranges, customer names, tokens or incident-only details. The method is useful without exposing the environment.