What Is DNS and How to Request a DNS Change for Fludnox

In short: if your domain is registered with provider X, your current website is hosted with provider Y, and you want the domain to point to destination Z, prepare and test Z first, create a verified independent backup, obtain the exact DNS values from Z, and then submit an authenticated Fludnox support ticket from an authorised account contact. Keep Y active until the change has been verified.

Planning notice: allow a DNS transition window of 48–96 hours or longer. This is not a guaranteed propagation time, a completion promise, or guaranteed downtime. Some users may receive old answers while others receive new answers, and interruption is possible.

What is DNS?

The Domain Name System (DNS) connects a name such as example.com to the internet service that should answer for it. DNS records can direct website traffic, route email, publish verification information, or identify which nameservers are authoritative for a domain.

DNS is a routing system. Changing DNS does not copy website files, databases, mailboxes, redirects, application settings, licences, or TLS/SSL certificates from one provider to another.

Understand the X, Y, and Z setup

Role	Meaning	What to confirm
X — Domain registrar	The provider that keeps the domain registered.	Whether X also controls the domain's nameservers.
Authoritative DNS provider	The service that stores the live DNS zone and answers for its records.	This may be X, Fludnox, or a separate provider.
Y — Current hosting	The service currently hosting the website, application, email, or other workload.	Its cancellation date, backup/export options, and whether it must remain available during transition.
Z — New destination	The new hosting platform, service, IP address, hostname, or redirect endpoint.	That it is ready, tested, secured, and able to provide exact DNS values.

Who can make the change? For A, AAAA, CNAME, MX, and TXT changes, the provider operating the authoritative DNS zone must update the records. To change nameservers or parent-level DS data, registrar X must update the delegation after the complete zone and DNSSEC plan are ready at the new DNS provider. If Fludnox controls the relevant service, use the authenticated ticket process below. If X or the authoritative DNS provider is external, you may need to make the change there yourself or separately agree a supported coordination scope with Fludnox.

Which change do you need?

• DNS record change: update an A, AAAA, CNAME, MX, TXT, or other record in the current authoritative zone.
• Nameserver change: update the domain's delegation through registrar X so a different DNS provider becomes authoritative. Build and verify the complete new zone first.
• HTTP redirection: send a browser from one URL to another, such as from example.com/old to z.example/new. This normally requires a web server, application, CDN, or redirect service at the destination.
• Full migration: move website files, databases, email, certificates, or application configuration. This is separate from DNS.

If you need a full URL or path redirect, say so in the ticket. Do not request only “change the DNS,” because that may not produce the redirect you expect.

Before you request a DNS change

1. Keep X and the domain registration active and paid. A domain expiry can stop DNS, web, and email even when Y or Z is otherwise working.
2. Prepare Z. Open the destination account and make the website, application, email, redirect, and certificate configuration ready.
3. Create and verify an independent backup. Do not rely on Y or Fludnox as the only recovery source.
4. Get exact values from Z. Ask Z for the record name, record type, target/value, priority where relevant, and recommended TTL.
5. Inventory all affected services. Check the apex domain, www, subdomains, MX, SPF, DKIM, DMARC, verification records, certificates, the current DNSSEC state, and any parent-level DS record.
6. Record the current DNS configuration. This supports comparison and any separately agreed rollback plan. Never improvise the order of an NS, DS, or DNSSEC change: a stale parent DS record can cause validating resolvers to reject the domain.
7. Keep Y active. Do not cancel it or allow it to expire until Z and the DNS result are verified.

Submit the request

Open an authenticated support ticket for the DNS change.

You must sign in, or create a customer account first. Submit the ticket from an authorised account contact. Fludnox may verify identity, authority, account ownership, payment status, or the destination before acting.

Use a clear subject such as DNS change request — example.com — Y to Z and include:

Required detail	What to provide
Domain and hostnames	The registered domain and every affected hostname, such as @, www, mail, or another subdomain.
Providers	Registrar X, current authoritative DNS provider, current hosting Y, and destination Z.
Requested scope	State separately whether the request covers DNS records, nameservers, DS/DNSSEC, website migration, email migration, a domain transfer, a certificate, or an HTTP redirect.
Exact before → after values	For every record: hostname, type, current value, requested value, priority if applicable, and TTL if supplied by Z.
DNSSEC and DS	State whether DNSSEC is enabled, provide the current and target DS/DNSSEC details where relevant, and request a coordinated sequence.
Readiness	Confirm X and the domain registration are active and paid, Z is ready and tested, your independent backup is verified, and Y will remain active until verification.
Timing	Your preferred change window and time zone. A time is binding only after Fludnox confirms it in writing.
Current impact	Say whether the service is working, degraded, suspended, expired, or already unavailable.

Attach the destination provider's DNS instructions if helpful. Do not place passwords, private keys, recovery codes, or long-lived credentials in the ticket. If third-party access is expressly agreed, use limited temporary credentials through the approved secure method and revoke them after completion.

If the authenticated support channel is unavailable, the Fludnox policies also list support-fludnox@shared-services.co for operational requests. Use the authenticated ticket whenever available so the account context and change record remain together.

If Y is unpaid, cancelled, suspended, or expired

Ending or losing Y does not automatically point the domain to Z. It also does not automatically cancel or transfer a separately registered domain at X.

Keep X and the domain registration active and paid throughout the change. Hosting cancellation and domain cancellation are separate, but an expired domain can interrupt DNS, website, and email service.

• Submit the DNS request before Y ends whenever possible.
• Export required content, mail, configuration, and records before access stops.
• Keep or reactivate Y until Z is ready and the transition has been verified, where that option remains available.
• If Y is already unavailable, state the current outage and expiry/suspension status in the ticket. Service may remain down independently of DNS caching.
• Do not assume a backup, dashboard, mailbox, or rollback will remain available after expiry. Existing backups may continue to age out.
• Cancel or non-renew Y separately after verification. A DNS or migration request does not stop Y's billing or close the source account.

Custom exports, DNS coordination, destination configuration, out-of-hours work, or provider liaison may be outside the purchased scope and may require a separately confirmed, chargeable service.

Propagation, interruption, and downtime

DNS answers can be cached by applications, devices, recursive resolvers, and internet providers until the relevant time to live (TTL) expires. For a nameserver change, parent/TLD delegation answers can also remain cached, while registrar and registry processing can delay NS or DS updates. These third-party caches and processing times are outside Fludnox's direct control.

For planning, allow 48–96 hours or longer. During this period, one user may reach Y while another reaches Z. The actual transition can be shorter or longer. The 48–96+ hour allowance is not stated as a Fludnox policy commitment and must not be treated as an SLA, a guaranteed completion time, or an expected continuous outage.

Downtime can often be reduced when both Y and Z are correctly configured and available during the transition, but continuous service is not guaranteed. If Y has already stopped, the existing outage can continue while the request is reviewed and DNS caches refresh.

Avoid repeated DNS edits while caches are changing, because each edit makes diagnosis harder. A DNS checker such as WhatsMyDNS samples public recursive resolvers and can indicate mixed answers, but it is not proof that a change is complete. Compare those results with direct authoritative checks and the functional tests below. Flushing a local DNS cache can help diagnose one device, but it does not clear caches across the internet.

Common record types

• A / AAAA: point a hostname to an IPv4 or IPv6 address.
• CNAME: makes one hostname an alias of another hostname. It is commonly used for subdomains such as www.
• MX: routes email and includes a priority value.
• TXT: carries verification and policy data, including SPF, DKIM, and DMARC-related values.
• NS: identifies the authoritative nameservers. Changing the parent delegation through registrar X can move responsibility for the entire DNS zone, so all required records must exist at the new provider first.
• DS / DNSSEC: links the parent zone to DNSSEC material for the domain. Coordinate NS and DS changes carefully; stale or mismatched DS data can make the domain fail validation.

Verify before you cancel Y

• Check authoritative NS and the requested A, AAAA, CNAME, MX, and TXT records from more than one network or region.
• If DNSSEC is enabled or changed, confirm the parent DS record and validate the signed chain before treating the transition as complete.
• Test both the apex domain and www over HTTPS.
• Check the certificate, redirects, login, forms, checkout, APIs, uploads, scheduled jobs, and other business-critical functions.
• If email records changed, test sending and receiving in both directions and confirm SPF, DKIM, and DMARC behaviour.
• Test important subdomains and third-party verification records.
• Reply to the existing ticket if any result differs from the confirmed change scope.

Only after the agreed checks pass should you cancel or allow Y to expire under Y's own cancellation, payment, and retention terms.

Policy references

• Fludnox Domain Registration Agreement
• Fludnox Hosting and Infrastructure Policy
• Fludnox Hosting Migration, Suspension and Termination Procedure
• Fludnox Hosting Backup and Data Recovery Policy
• Fludnox Hosting Service Level Agreement

This article is operational guidance. The applicable Order Form, Individual Agreement, and published policies govern the service and take precedence if they differ.