[Home](https://hmbastion.com/) [Blog](https://hmbastion.com/blog/) Infrastructure Infrastructure 5 min read # DNS records and TTLs: prepare a change you can verify DNS tells clients where to look for a service. It does not move application data, install a certificate or make a new server ready. A reliable change begins with a record inventory and ends with both DNS evidence and a working application. HM Bastion Editorial Published 2026-10-26 ## In this guide - [Identify the authoritative zone and the people who control it](https://hmbastion.com/blog/dns-records-ttl-cutover-checklist/#find-authoritative-zone) - [Know what each record contributes](https://hmbastion.com/blog/dns-records-ttl-cutover-checklist/#map-record-types) - [Plan for answers already in caches](https://hmbastion.com/blog/dns-records-ttl-cutover-checklist/#understand-cache-time) - [Verify the DNS answer, then the service behind it](https://hmbastion.com/blog/dns-records-ttl-cutover-checklist/#verify-change-by-layer) - [Protect DNSSEC validation and keep rollback realistic](https://hmbastion.com/blog/dns-records-ttl-cutover-checklist/#preserve-validation-and-rollback) [All hosting guides](https://hmbastion.com/blog/) ## The practical takeaway Change the records that actually control the service, account for existing cache lifetimes, verify authoritative and recursive answers separately and keep the previous endpoint under control. ## Identify the authoritative zone and the people who control it Separate the domain registrar, authoritative DNS provider and hosting destination in your notes. They may be operated through different accounts. The registrar controls domain registration and delegation, while the authoritative DNS service publishes the zone records that resolvers query. Moving a website to a new host does not necessarily require changing either the registrar or the nameservers. Find the active authoritative nameservers and export or privately record the current zone before editing it. Include exact names, types, values and TTLs, not only a screenshot of the main website record. Confirm who can approve and restore a change. A DNS dashboard in an old account is not evidence that its records are still authoritative for the domain. Treat a nameserver migration as a separate change with its own validation. It can affect the entire zone, including email and verification records. When only the web destination is changing, keeping the existing DNS authority and editing the relevant address or alias record often makes the scope easier to review. ## Know what each record contributes | Type | Purpose | Check before a hosting change | | --- | --- | --- | | A | Maps a name to an IPv4 address | The target serves the intended hostname and HTTPS configuration | | AAAA | Maps a name to an IPv6 address | IPv6 reaches the same working service as IPv4 | | CNAME | Aliases one name to another name | The target is a hostname, not an IP address or full URL | | MX | Identifies mail delivery destinations | Website changes do not unintentionally redirect inbound mail | | TXT | Carries verification and other text policies | Required ownership and mail-authentication records remain intact | | CAA | Constrains certificate-authority issuance | The intended certificate issuer is compatible with the policy | For example, example.com may have an A record and www.example.com may alias it through a CNAME. Review both user-facing names. An address change for the first can affect the alias, while an unrelated hostname may still point directly at the old server. Zone-apex alias features vary by DNS provider; follow its documented mechanism rather than assuming every interface accepts an ordinary apex CNAME. Do not leave an old AAAA record behind when the IPv4 destination moves. Some clients may continue reaching the obsolete IPv6 service while others use the new IPv4 address. Confirm the intended IPv6 availability before publishing that path. Likewise, a website move is not a reason to replace MX or TXT records when the mail service is staying where it is. ## Plan for answers already in caches TTL gives a DNS answer a cache lifetime. Reducing it on the authoritative record does not shorten an older answer already cached elsewhere. If the existing value is 86,400 seconds and you want a 300-second value for a planned switch, lower it sufficiently in advance for the previous lifetime to pass. Those values illustrate planning; the options available depend on the DNS service and record. DNS can also cache an answer saying a name does not exist or has no requested record. That negative cache is governed by DNS rules and zone information, rather than the TTL of a record you add afterwards. Avoid discovering this during a launch by testing the new hostname only after it has deliberately been published and allowed for in the plan. A TTL is not a countdown to a simultaneous worldwide switch. Clients, recursive resolvers and existing application connections do not all refresh together. Keep the previous endpoint controlled through the overlap. If the application accepts writes, the migration plan must define a single data authority while traffic can still arrive at more than one address. ## Verify the DNS answer, then the service behind it - Record the previous value and the exact intended replacement. - Query each authoritative nameserver for the affected name and record type. - Compare responses from more than one recursive resolver and note remaining TTLs. - Check every public hostname and both IP families that are actually published. - Test HTTPS and representative application behaviour using the real hostname. - Observe residual traffic before raising the TTL or retiring the old endpoint. Differentiate an authoritative mistake from a cached old response. If the authoritative servers disagree, investigate the zone publication or delegation. If authority is correct but one resolver still has an older answer, compare its remaining lifetime before making another unrelated edit. Repeatedly changing values can make the observation window harder to interpret. A correct address answer does not prove a valid certificate or working virtual host. HTTPS uses the requested hostname, and the application must recognise it. If a proxy or CDN is part of the design, understand which returned address represents that intermediary and which origin setting controls its backend. Keep the DNS result and origin-service test as separate checks. ## Protect DNSSEC validation and keep rollback realistic If DNSSEC is enabled, a nameserver or signing-provider migration must account for the parent DS record and the new signing keys. A mismatch can cause validating resolvers to reject answers. Follow the documented migration procedure for both providers and the registrar, including applicable cache lifetimes. Do not delete trust records or disable validation as an improvised first response to an unexplained web error. Keep the previous DNS values with the change record, but remember what they can reverse. Restoring an old address changes where future resolutions lead; it does not copy back customer data accepted by the new application. Use the separate migration plan to decide when traffic rollback is safe and when data reconciliation is required. Finish only after the application, mail dependencies and recovery copies have been checked. Product examples use the published HM Bastion catalogue. Availability, prices and selectable options are shown when you configure an order. ## Choose your next foundation. [Coordinate the complete hosting migration](https://hmbastion.com/blog/hosting-migration-cutover-rollback/) [Choose Switzerland or Germany](https://hmbastion.com/blog/switzerland-or-germany-hosting/) [Confirm hosting and network requirements](https://hmbastion.com/support/) ## Sources and further reading - [Cloudflare DNS documentation: record types](https://developers.cloudflare.com/dns/manage-dns-records/reference/dns-record-types/) - [Cloudflare DNS documentation: TTL](https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/) - [IETF RFC 2308: negative DNS caching](https://www.rfc-editor.org/rfc/rfc2308) - [Cloudflare DNS documentation: DNSSEC and migrations](https://developers.cloudflare.com/dns/dnssec/) ## Keep exploring [ Planning 3 min read ## VPS, dedicated or web hosting: choose the responsibility you need Match your application, operating responsibilities and resource needs to the three HM Bastion hosting families. ](https://hmbastion.com/blog/vps-dedicated-or-web-hosting/) [ Infrastructure 4 min read ## Switzerland or Germany: choose a hosting region with a practical checklist Compare audience routes, application dependencies, regional prices and deployment requirements before choosing Switzerland or Germany. ](https://hmbastion.com/blog/switzerland-or-germany-hosting/)