DNS connects a domain name with the services people need to reach. A business domain can direct website visitors to one system and email to another. Understanding the records, nameservers and cached answers helps you make controlled changes without assuming that everything moves together.
This guide explains the decisions behind a DNS change. Keep a copy of the existing zone and involve the authorised administrator before editing a live business domain. For practical help with your own domain, you can discuss the requirements with Giraffe Hosting.
Distinguish the registrar from the DNS provider
The registrar manages the domain registration relationship. The authoritative DNS provider holds the records that answer queries for the domain. The website host runs the website application. These roles can be supplied together or separately. Moving registration does not necessarily change authoritative nameservers, and moving the website does not necessarily change registration.
Find the domain's current authoritative nameservers before editing a zone. An old hosting account can contain a plausible-looking DNS editor even though its records are no longer used. Confirm the live delegation and ask who can change it. Otherwise, the team can spend hours editing an inactive copy while public answers remain unchanged.
Know which record you are changing
- A: associates a hostname with an IPv4 address.
- AAAA: associates a hostname with an IPv6 address. Check it alongside A when moving a dual-stack website.
- CNAME: makes one hostname an alias of another hostname. It is not an email address or a web-page redirect.
- MX: identifies mail delivery servers, with priorities used to select between them.
- TXT: carries text values used for purposes such as domain verification and email authentication.
- NS: identifies authoritative nameservers for a zone or delegated part of it.
Some platforms offer alias or CNAME-flattening features at the zone apex, where an ordinary CNAME conflicts with other required records. Ask how the provider implements the feature and what public answers it returns. Do not assume a vendor-specific record name can be imported unchanged into a different DNS service.
Understand what TTL does
Time to live, usually shortened to TTL, tells a caching resolver how long an answer can normally be retained. A lower TTL can help later changes be noticed sooner, at the cost of more frequent DNS lookups. The authoritative record and a resolver's cached answer are different observations, so both can be correct at different points during a planned change.
Reducing a TTL does not erase an answer that was already cached with a longer lifetime. For a migration, make the agreed reduction sufficiently far in advance for earlier caches to age out. Record the previous value, the new value and the time of the change. Avoid promises that every visitor will see the new service at precisely the same instant.
Inventory records before changing nameservers
Export the existing zone and compare it with a list of known business services. Include website hostnames, mail delivery, SPF, DKIM, DMARC, verification records and delegated subdomains. Check wildcards and records used by less visible services such as booking systems or customer portals. An automatic DNS scan is a starting point; it may miss records that cannot be discovered from ordinary public queries.
When importing a zone, check formatting, relative hostnames, trailing dots and record values. Confirm that provider-specific proxy settings, apex aliases and DNSSEC arrangements have an agreed equivalent. A file importing successfully proves that its syntax was accepted, not that every dependency is present or configured correctly.
Change website and email routing separately
If only website hosting changes, edit the required website records and preserve existing mail routing. If nameservers change, recreate the whole required zone at the destination before changing delegation. A missing MX record or authentication record can interrupt email even though the homepage works normally.
For business email, obtain the exact values from the authorised mail administrator. SPF is published as a TXT policy; DKIM uses selector-specific records; DMARC is normally published under the dedicated DMARC hostname. Do not add a second SPF policy as a quick fix. Record why each value exists and which sender or service depends on it.
Recognise proxy and certificate dependencies
Some DNS services can proxy supported web traffic instead of returning the origin address directly. A proxied record and a DNS-only record can therefore return different public addresses and behave differently for certificates, caching and origin access. Check the mode required by the application rather than switching it to match a screenshot from another account.
DNS pointing to the correct server does not prove HTTPS is configured for the requested hostname. Validate the public certificate, server routing and application response separately. Preserve encryption and certificate checks while diagnosing a problem. A connection warning is evidence to investigate, not a reason to disable protection for visitors.
Diagnose a change using specific observations
- Confirm the exact hostname, record type and expected value.
- Query the authoritative nameservers and compare their answers.
- Check answers through ordinary recursive resolvers and note remaining TTL values.
- Inspect the public website or mail route independently of an administrator preview.
- Check for a conflicting AAAA answer, old delegation, missing record or application configuration problem.
- Record the change and verification result before moving to the next edit.
If one resolver retains an old answer while the authoritative server returns the new value, caching is a plausible explanation. If authoritative nameservers disagree, inspect zone synchronisation or delegation. Correct DNS answers combined with the wrong website page call for an inspection of the receiving server and hostname configuration. Avoid labelling every connection problem as propagation.
Use controlled batch changes
For a larger edit, prepare a reviewed list of additions, changes and removals. Compare the proposed zone with the current export and check whether the tool applies the batch atomically or item by item. Preserve an undo plan and coordinate with other administrators. An unattended bulk import can overwrite a record added by another team after the export was taken.
Restore normal TTLs after the agreed verification period and keep a dated change record. Where DNSSEC is enabled, coordinate the signed zone and parent delegation through a separate checked sequence. For a website move, our hosting migration runbook explains how DNS fits into the wider customer journey and recovery plan.
