Why DNS matters to your website, email and business continuity

Your website can be running correctly while customers still cannot reach it by name. If DNS cannot provide the necessary answers, a working server alone is not enough. The same dependency applies to email and many connected business applications.

DNS therefore belongs in business-continuity planning alongside hosting, backups and account security. Its role is specific: it publishes and resolves information associated with names. It does not replace a web server, secure every application or make all outages impossible.

The systems involved in a lookup

A device usually asks a recursive resolver for DNS information. The resolver may answer from cache or obtain information by following referrals through the hierarchy. Root and top-level-domain services help it find the relevant authoritative nameservers.

The authoritative DNS service publishes the zone's answers. That service may be operated by your registrar, host or an independent platform. Knowing which provider is authoritative is essential when an urgent record change is needed.

The registry, registrar and DNS provider are distinct roles. A domain renewal problem is different from an incorrect A record, even though both can stop people reaching a website. Record which organisation controls each layer.

DNS supports more than the homepage

A DNS migration must account for all these dependencies. Moving only the records visible on the first screen of an old panel can leave a newsletter sender, customer portal or staff email service behind.

Caching improves efficiency and complicates changes

Resolvers can retain answers for their permitted cache lifetime. This reduces repeated work and can speed subsequent lookups. It also means a newly saved record does not instantly replace every earlier answer held across the internet.

TTL is one important part of that behaviour. Different records and delegation information can have different lifetimes, and negative answers can be cached too. Diagnose the actual answer rather than assuming every discrepancy is the same kind of delay.

For a planned move, lower relevant TTLs sufficiently in advance if appropriate. Keep the old service available during the transition and avoid unnecessary simultaneous changes. Reducing TTL at the moment of cutover cannot recall data already cached under an earlier value.

DNS helps with flexibility, but does not move content

A domain can continue to identify the same business while the website moves between hosts. Updating its relevant records directs future connections to the new destination after caches update.

The files, database and application configuration still need a separate migration. The destination must recognise the hostname and have suitable HTTPS configuration. DNS cannot copy a shop's orders or create redirects for changed page paths.

Similarly, a DNS alias is not a browser redirect. If you want one URL to redirect to another, configure the web service to issue the appropriate HTTP response.

Security has several separate layers

Attackers may try to obtain account access, change delegation or publish unauthorised records. Protect registrar and DNS accounts with strong credentials, available multifactor authentication and controlled administrator access.

Cache poisoning is another class of threat: false DNS information can misdirect a resolver's users. DNSSEC provides a way to validate signed DNS data through a chain of trust when deployed correctly.

DNSSEC does not encrypt website traffic and does not stop an authorised account from publishing a harmful change. HTTPS, application security, mail authentication and account controls remain separate requirements.

A signed domain's migration needs careful DS and key handling. Leaving a parent DS record that does not match the new authoritative service can cause validating resolvers to reject answers. Follow a documented provider-specific transition.

Choose a DNS provider for operational needs

Consider resilience, supported record types, account controls, DNSSEC capabilities, zone export and support escalation. Ask how changes are audited and how the service fits your registrar and application setup.

Do not choose only from an unverified claim that one provider is the fastest. Meaningful DNS performance measurement needs defined locations, resolver conditions, record types and repeated observations. A single lookup from one laptop does not establish global customer experience.

Check what happens during an account or billing problem too. If DNS is bundled with hosting, find out whether cancelling the hosting affects the zone. This dependency matters when the website and mail live with different suppliers.

Maintain a usable record inventory

For each important entry, record its name, type, destination, TTL, purpose and requesting service. Keep an export outside the DNS platform. Add the responsible contact and review date for less obvious verification records.

Review old subdomains and retired suppliers. A record pointing at a service the organisation no longer controls can need careful removal. Confirm dependencies first, then retire it through the relevant platform's instructions.

Document renewal and recovery arrangements for the domain itself. A well-maintained DNS zone is less useful if the registration expires or nobody can access the registrar account.

Try a dependency review

Choose one customer-facing task, such as booking a service, and list every hostname it needs. Include the main page, form endpoint, confirmation mail and any external application. Identify which entries your business controls and which belong to suppliers. This exercise often reveals that a working homepage is only one part of the customer journey, and gives the team a more useful monitoring and recovery checklist.

Monitor what customers actually use

Check the main website, important subdomains and mail routing, rather than only whether one nameserver responds. Service monitoring should also test HTTPS and application behaviour where appropriate.

Set an alert destination that remains usable during the incident. If every monitoring notification goes to the affected domain's email, the team may have difficulty receiving the evidence it needs.

Record who will investigate, who can approve a change and how to contact suppliers. A monitoring tool is useful only when someone can interpret and act on its result.

A practical DNS fault-finding sequence

1. Record the exact hostname, record type, error, time and network.
2. Check registration status and current delegation.
3. Query the authoritative service for the expected answer.
4. Compare a recursive resolver's answer and remaining TTL.
5. Investigate DNSSEC validation if errors suggest a broken chain.
6. Once resolution is correct, test the destination and application separately.

Tools such as dig and nslookup can inspect individual record types. An authoritative query helps distinguish incorrect source data from a stale cached response. Avoid making several unrelated edits before testing the first correction.

Prepare a recovery plan before the incident

Keep the current zone export, account recovery routes, supplier contacts and previous working values. For major changes, define acceptance checks and a realistic rollback decision before the cutover.

A rollback is another DNS change and may also be cached. Restoring one missing record can be better than reversing an entire delegation, depending on the fault. Make the decision from observed answers and the agreed plan.

For a small business, the most valuable improvement is often simple documentation: who controls the domain, where the zone lives and what its records support. That turns DNS from an invisible dependency into a service the team can maintain deliberately.