DNS changes can interrupt websites and email and should be planned, recorded and tested.
Applies to: Service policies and customer responsibilities
This operational guidance complements Tudor Internet's formal terms and policies. Where there is a conflict, the current contract, product description and published legal terms take priority.
Before you start
- Confirm the active product or addon and the domain or user it protects.
- Record the current settings before changing them.
- Allow for DNS caching and avoid making unrelated DNS changes during the same maintenance window.
What you need to do
- Confirm the authoritative provider and current records.
- Lower TTL in advance where appropriate.
- Avoid deleting records unrelated to the intended change.
- Keep rollback values and allow for caching.
Confirm the result
- The service dashboard shows the intended setting or activation state after reload.
- A live test from a separate session or device confirms that the customer-facing service works as expected.
Common problems
| Symptom | Likely cause | What to do |
|---|---|---|
| Some networks show the new result while others show the old one. | Recursive DNS caches have not expired or authoritative nameservers do not return consistent data. | Check the authoritative answer first, compare all listed nameservers and wait for the previous TTL before making another change. |
| The domain returns NXDOMAIN or SERVFAIL. | The zone is missing, delegation is wrong, DNSSEC is broken or an authoritative server is not responding. | Verify delegation at the registry, confirm the zone exists on every authoritative server and remove stale DS records only through a controlled DNSSEC rollback. |
Important notes
- Make production changes in a planned window, keep the old configuration recorded and avoid changing several dependent services at the same time.
When to contact Tudor Internet
Open a ticket through the Customer Portal when the checks above do not resolve the issue, when an action is unavailable for your service, or when continuing could risk data loss or service interruption. Include the following so the request can be investigated efficiently:
- The customer account email address
- The affected invoice, service, domain or ticket number
- The exact message and the time it appeared
Do not send passwords, private keys, full payment-card details, one-time authentication codes or unredacted identity documents in an ordinary support reply.
Related articles
- Keep a change and rollback record for production services
- Cancel an addon without losing required data or protection
- Remove secrets and personal data from screenshots and logs
- Prepare safe diagnostics for a support ticket
- Report abuse or security concerns
Last reviewed: 2026-07-18.
