DNS Record Types: What to Check Before a Change

The most common DNS record types answer different questions. An A or AAAA record supplies an address for a name. A CNAME points one name to another name.

MX records identify mail exchangers, TXT records carry text used by services such as verification systems, and NS records identify name servers. Before changing any of them, write down the exact owner name, type, current value and intended value. Then check the answer at the authoritative server and through a resolver used by the people who depend on that name. A change saved in a DNS dashboard is one step in that process. The outcome you need is an answer that matches the intended service from the appropriate network.

Illustrative zone fragment using documentation names and addresses, not a live or complete zone. Each row inherits TTL 300 and class IN. The MX value begins with preference 10; CNAME uses a separate owner. SOA and target address records are omitted.

Start with the name and the answer you expect

Illustrative record, not a live lookup: read the exact owner, type and complete value set before editing.

Write the full name you intend to change before opening the zone editor. An interface might display just a label such as www, while the actual owner name is www.example.com. Other interfaces expect a full name or use an at sign to represent the zone apex. Check the interface convention on the system you are using. An incorrect owner can leave the existing service in place and create an unrelated record that looks plausible in the dashboard. A direct query for the exact name is a faster way to detect the mistake than reading through every entry in the zone.

Keep a copy of the existing record set rather than a screenshot of a single value. A record set can have more than one value of the same type at the same owner name. For example, a service may publish several addresses. A change that replaces an entire set when the request was to add one address can remove a working endpoint. Conversely, adding an address when the request was to replace an old one may leave both in use. Write down whether the operation is an addition, a removal or a replacement, and include the expected final set in the change ticket.

Confirm which DNS view is in scope. An internal client and an external client may intentionally see different answers for the same name. The right result for a private application could be a private address that a public resolver should never receive. Document where you expect the new answer to appear and where the old behavior should remain. If another team owns one of those views, agree on the verification steps before requesting the change.

Choose A, AAAA or CNAME for a service name

Use an A record when the DNS answer should contain an IPv4 address, and an AAAA record for an IPv6 address. For a site served over both protocols, verify both record types if they exist. An address change for one family can leave the other pointing at a different deployment. That can produce reports that the site works for some users while others see an old page or a connection error. Testing both the DNS answer and the service over the intended address families makes those reports easier to interpret.

A CNAME is appropriate when the owner name should act as an alias of another DNS name. For example, a hosting provider might give you a target hostname for a subdomain. Verify the exact target and the destination service configuration. A correct alias can lead to a host that still serves the wrong application if the provider has not configured the incoming hostname. When checking the result, record the alias and the ultimate address answer separately. That separates a change to your record from changes the target owner may make later.

Check for records already attached to the alias owner. Standard CNAME rules generally prevent an alias from coexisting with other ordinary data at that name. The zone apex already needs records that describe the zone and its name servers, so a standard CNAME at the apex conflicts with those records. Some providers offer a separate feature that synthesizes address answers for an apex alias. If you use that feature, verify its actual wire response and provider behavior before treating it as equivalent to a CNAME. RFC 2181 clarifies the DNS alias rule.

Check mail, verification and name server records separately

For mail routing, an MX record identifies a mail exchanger and includes a preference number. Lower preference values take precedence when choosing among exchangers. Before replacing MX records, confirm all intended targets with the mail owner, including any host that should remain as a backup. The target is a hostname and should resolve directly to address records. A successful lookup of an MX record confirms the DNS data you received. Mail delivery still depends on the receiving service and its configuration, so agree with the mail owner on a separate authorized delivery check.

For TXT verification, start with the requesting service's instructions. Different services may require a token at the apex or at a specific subdomain. Keep existing TXT values that serve other purposes unless the approved change says to remove them. If an interface displays surrounding quotes, check the provider's input convention and compare the returned text with the expected value. A successful DNS response can still fail verification when the text was saved under the wrong name or contains an extra character. For an operational record such as an email policy, have the service owner verify the meaning of the final value as well as its presence.

NS records involve a different responsibility. A delegation at the parent and the authoritative data at the child are related, but updating a record in the child zone alone does not change where the parent sends resolvers. If the request is to change hosting providers or delegate a subdomain, review the parent delegation, the child name servers and any required address information together. Treat that as a zone change with a coordinated verification and rollback plan. For a routine web address change, keep unrelated delegation settings out of the change.

Plan for what caches can return

Illustrative timeline: a cache may retain an earlier answer after the authority changes. TTL and cache behavior determine when it refreshes.

Time to live, or TTL, describes how long a DNS record may remain in a cache. Reducing it at the authoritative source affects replies issued with the new TTL. A resolver that already cached the previous reply may still retain that copy under its earlier lifetime. If a planned change relies on shorter cache retention, lower the value in advance and account for the previous lifetime in the change schedule. Record the original TTL so you can restore it after the service is stable.

Caches can also retain negative answers. If a name was queried before you created it, one resolver may continue reporting that it does not exist while the authoritative server already returns the new record. An existing name with no record of the requested type is also different from a name that does not exist. Capture the response code, answer and relevant authority information rather than reducing both outcomes to “DNS failed.” RFC 2308 explains negative caching.

Avoid assuming that a dashboard status or one public lookup represents every client. Check a resolver in the affected environment and write down the test time. If the authoritative answer is correct and the recursive answer still differs, investigate cache lifetime, forwarding and the selected view before repeating the change. If the authoritative answers disagree across the expected name servers, investigate the zone publication path before expecting clients to converge.

Verify a realistic change from both sides

Imagine moving an application subdomain to a new hosting service. The change request calls for a CNAME to the provider's hostname, but the old owner name has an A record and the public service still uses that address. Record the old address and TTL. Confirm that the provider has provisioned the hostname and that the application owner has a service test. Decide whether the window permits replacing the old A record and adding the alias as one coordinated operation. Check for any other record types at the owner name before approving the plan.

After saving the change, query the authoritative servers for the alias. Verify the owner, record type and target. Then query from the resolver used by the application audience and follow the alias chain far enough to confirm the destination address. Finally, run the agreed service check. For a website, that may mean opening the exact URL and confirming that it serves the intended site, with the expected hostname and certificate. Correct DNS data and correct application behavior are separate pieces of acceptance evidence.

Prepare the rollback before the window. Record which values will be restored, who owns the action and what observation triggers it. Restoring the old data at authority is an important step, but some resolvers may still have cached the changed answer. Verify both the authoritative response and representative client responses after the rollback. For changes involving several internal DNS views, preserve each view's original values individually rather than assuming they all shared the same configuration.

Close the change with a record that someone can reproduce. Include the exact DNS name and type, expected record set, observed authoritative and recursive answers, resolver addresses, timestamps and the result of the application check. If you are selecting a platform for enterprise record management, use the ZDNS DNS product information as a starting point and verify the actual version and workflow against the changes your team needs to run.