Check a DNS A record before changing an IPv4 destination
Read a DNS A record, compare authoritative and cached answers, and validate an IPv4 change. Follow a worked example without confusing DNS with web hosting.
Written byYiyao
An A record maps a name to an IPv4 address
A DNS A record associates a hostname with a 32-bit IPv4 address. It helps a client find an address for a named service. It does not specify a URL path, choose an HTTP redirect, install a certificate, or configure the application at the destination.
Before editing anything, identify the exact hostname that users request. example.com and www.example.com are separate DNS names. A correct record for one does not prove the other has been configured. Query the name that actually appears in the failing URL.
Read the record as a complete row
| Field | Illustrative value | Meaning |
|---|---|---|
| Name | app.example.com. | Hostname being mapped |
| Type | A | IPv4 address record |
| TTL | 300 | Cache lifetime expressed in seconds |
| Value | 192.0.2.10 | Documentation-only IPv4 example, not a deployment target |
This row is an invented teaching example. The trailing dot represents a fully qualified DNS name. A provider's interface may add the zone name automatically; entering a full name into a relative-label field can create the wrong record. Check the provider's preview or resulting public query.
Several A records may exist for the same name. Compare the answer set rather than assuming the first displayed address is the only destination. Record ordering is not a reliable priority mechanism.
Establish the current answer before the change
nslookup -type=A example.com
Use the actual hostname you control for a production check, and keep its existing value and TTL in a change record. In Arcvenza NSLookup, authoritative mode can help show the currently published answer reached through delegation. Recursive mode represents a resolver's view, which may still contain a cached answer.
Confirm the destination with the hosting or application owner. An address copied from an unrelated diagnostic service may identify a proxy, outbound gateway, or shared service rather than the host that should receive visitors.
For SOA timing fields and negative-cache behavior, read the SOA record guide.
Plan a change that can be reversed
Agree on the new destination, intended cutover, validation method, and rollback value before editing. Ensure the destination is ready for the hostname and its HTTPS certificate. Lowering a TTL at the moment of a change does not instantly remove answers already cached under the previous TTL.
Where operationally possible, make a TTL adjustment in advance and allow the previous cache lifetime to pass. Keep both DNS and application owners involved. A DNS update can direct traffic successfully to an application that still serves the wrong site.
Compare the answers after publication
| Check | Desired evidence | If it differs |
|---|---|---|
| Authoritative query | Intended answer set for the exact name | Review zone, record and delegation |
| Permitted recursive query | Expected answer after applicable caching | Record resolver and remaining TTL |
| HTTPS request to the hostname | Correct certificate and expected page | Investigate TLS or application routing |
| Application task | Required page or endpoint actually works | Inspect application logs and content |
An illustrative migration moves app.example.com from 192.0.2.10 to 192.0.2.20. Both are documentation addresses, not usable production targets. If the authoritative answer is new but a recursive answer is old, that observation points toward cache state. If both are new but the site is wrong, DNS has not established application correctness.
Avoid confusing adjacent record types
AAAA records answer the IPv6 part of the same question. CNAME records identify another DNS name rather than storing an IPv4 address. Use the AAAA guide to check an IPv6 destination and the CNAME lookup guide when an alias is involved.
Do not insert a full https:// URL, a port, or a page path into an A-record value. If a service asks for a hostname alias, follow its documented CNAME or provider-specific setup rather than forcing that name into an address field.
FAQ and next action
Will changing an A record redirect visitors to a different page path? No. Configure the relevant HTTP redirect separately.
Why does one location still see the old address? Preserve the exact resolver, time, and TTL; caching and network-specific answers can differ. Run an authoritative comparison in NSLookup, then verify the real website from the affected environment.