DNS changes may take time to reach recursive resolvers and devices.
Applies to: Web Hosting troubleshooting
Troubleshooting is fastest when you identify the layer that failed: DNS, TLS, web server, PHP, application, database or local device. Record exact error text and timestamps before changing configuration.
Before you start
- Sign in to the Customer Portal and open the affected hosting service.
- Take a current backup before changing website files, databases, DNS or application configuration.
- Allow for DNS caching and avoid making unrelated DNS changes during the same maintenance window.
Work through these checks
- Confirm the authoritative nameservers.
- Check the relevant A, AAAA or CNAME record.
- Allow for TTL and resolver caching.
- Test from another network or public resolver.
- Changing records repeatedly can extend confusion during propagation.
Confirm the result
- The intended hostname loads over HTTPS from a private browser session and serves the correct website.
- Forms, database-driven pages and the administration area work without a new PHP, permission or redirect error.
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. |
| The problem started immediately after a change. | A deployment, plugin, permission, PHP or configuration change introduced the fault. | Roll back only the last known change, clear caches and retest before making a second change. |
| The fault is intermittent. | Resource limits, traffic spikes, remote dependencies or scheduled work may be involved. | Record exact timestamps and compare them with CloudLinux usage, application logs and the Service Status page. |
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 affected domain and SiteWorx account
- The exact error text and time
- The last change made
- Relevant log lines with passwords and personal data removed
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
- Read website access and error logs
- Fix a 403 Forbidden error
- Fix a 404 Not Found error
- Fix a 500 Internal Server Error
- Hosting email is not sending or receiving
Last reviewed: 2026-07-18.
