Verifying a DNS change before declaring it done
A resolver-by-resolver checklist for safe address migrations.
This note documents a practical approach used in Kin4 Notes. The goal is a setup that can be explained, reproduced, and checked from outside the machine.
Start with authority, not convenience
A successful lookup on your laptop proves only that one resolver returned an answer. Check the authoritative servers and at least two independent public resolvers. Compare both A and AAAA records; an old IPv6 address can keep breaking clients after IPv4 has been fixed.
dig +short @1.1.1.1 example.com A
dig +short @8.8.8.8 example.com AAAAMeasure the path a client actually uses
VPNs, mobile hotspots, and encrypted DNS can bypass the system resolver. Record the DNS server visible to the client and query it directly. Flush local caches only after identifying the source of a stale answer; otherwise the same upstream cache returns it again.
scutil --dns
dig +short @resolver.example example.comFinish with a real request
DNS is only the first step. Connect to the new address while pinning the expected hostname, then verify the certificate and response body. This catches stale proxies and listeners that were not moved along with the DNS record.
curl --resolve example.com:443:192.0.2.10 https://example.com/