When you update DNS for a Tomcat-based site, the change does not reach every DNS resolver at the same moment. Some visitors may see the new destination within minutes, while others may keep using the old record until the previous cache expires. If you are switching a Tomcat application during a go-live or DNS cutover, it is important to check propagation from several angles, not only from your own browser.
In a managed hosting setup with Plesk and My App Server, this matters especially when your Java application runs on a private JVM or Apache Tomcat instance and you are moving a public domain to a new hosting account, changing an A record, updating a CNAME, or pointing the domain to a new server for deployment. The steps below will help you confirm whether DNS changes have propagated for a Tomcat site in the UK market, and how to tell the difference between DNS propagation, browser cache, and application-level issues.
What DNS propagation means for a Tomcat site
DNS propagation is the time it takes for updated DNS records to be seen by different resolvers across the internet. In practice, there is no single global switch. Each resolver caches records based on the TTL set on the previous answer, and some networks or ISPs may hold results longer than expected.
For a Tomcat site, DNS propagation only affects where the browser connects. It does not change your WAR file, JSP pages, servlet mappings, Java version, or the Tomcat service itself. After DNS has switched, your application still needs to be healthy on the destination server. That is why a go-live check should include both DNS validation and application validation.
Before you check propagation: confirm what was changed
Start with the exact DNS change you made. The verification method depends on the record type.
Common records used for a Tomcat deployment
- A record – points the hostname to an IPv4 address.
- AAAA record – points the hostname to an IPv6 address.
- CNAME record – points one hostname to another hostname.
- NS record – delegates DNS control to different nameservers.
- TXT record – often used for verification, SPF, DKIM, or other service checks.
For a Tomcat website, the most common cutover is an A or CNAME change for the main host name, such as www.example.co.uk or app.example.co.uk. If your Tomcat application is behind Apache, the DNS change usually directs traffic to the server where Apache and Tomcat are already configured.
Useful details to note
- The hostname you changed.
- The new IP address or target hostname.
- The old record value.
- The TTL before the change.
- The exact time the update was made.
These details help you decide whether a missing update is normal cache delay or a configuration problem.
How to check whether DNS has propagated
Use more than one method. A single browser test is not enough because local caching can hide the real situation.
1. Check the record from multiple DNS resolvers
Query the hostname against different public resolvers. If they all return the new value, the change has propagated widely. If some still return the old value, propagation is still in progress.
Examples of resolvers commonly used for checks include:
- Google Public DNS: 8.8.8.8
- Cloudflare DNS: 1.1.1.1
- Quad9: 9.9.9.9
You can use command-line tools such as nslookup or dig if you have access to them. For example, compare the answer from your local resolver and a public resolver. If the public resolver shows the new IP but your local one does not, the issue is usually cache-related.
2. Check from more than one network
Open the site from different internet connections, such as:
- Your office network.
- A mobile data connection.
- A home connection.
- A VPN endpoint, if available.
If the site resolves correctly on one network but not another, the problem may be an ISP cache rather than the DNS zone itself.
3. Use an online DNS propagation check
Propagation check tools query multiple locations around the world and show whether the new record is visible. This is useful when you are moving a UK-facing site and want to see if resolvers in different regions are still serving the old address.
Look for:
- The expected new IP address or target hostname.
- Consistency across several locations.
- Any locations still returning the old record.
If most locations show the new value, the cutover is likely close to complete even if a few resolvers are still lagging.
4. Check the authoritative nameservers directly
If you want to know whether the DNS zone itself was updated correctly, query the authoritative nameservers. This bypasses many layers of caching and shows what the zone currently publishes.
This is the best way to distinguish between:
- Zone not updated – the authoritative answer is still old.
- Propagation delay – the authoritative answer is new, but caches are still old.
- Wrong record – the authoritative answer is new, but not the value you intended.
How to tell if the problem is DNS or Tomcat
After a DNS change, a site may appear offline even when DNS is already correct. In a Tomcat hosting setup, the destination server may not yet serve the application properly. Check the following separately.
If DNS is correct but the site still fails
- Verify that Apache is responding on the target server.
- Check that the Tomcat service is running.
- Confirm the My App Server instance is started in Plesk.
- Make sure the application was deployed successfully.
- Review whether the correct Java version is selected.
- Test the site locally by hostname on the server if possible.
In a typical My App Server setup, the domain may already resolve to the correct machine, but the application will still fail if the Tomcat instance is stopped, the WAR deployment failed, or a servlet mapping is incorrect.
If the site works on the server but not publicly
This usually suggests one of the following:
- DNS propagation is still in progress.
- A local or ISP cache is serving the old answer.
- Your device has cached the previous IP.
- The browser has cached a redirect or connection state.
Practical propagation checks for Plesk and My App Server
If you manage the site in Plesk with My App Server, use a simple sequence to confirm the go-live:
- Verify the new DNS record in the DNS zone.
- Confirm the authoritative nameserver shows the updated value.
- Check the record from a public DNS resolver.
- Open the domain from a few different networks.
- Check the Tomcat service status in My App Server.
- Confirm the application responds with the expected page or status code.
This approach reduces confusion during cutover because DNS, web server, and application service are each checked on their own.
What to verify inside Plesk
- The domain points to the intended subscription or hosting account.
- The DNS zone contains the new A or CNAME record.
- The Apache virtual host is aligned with the domain.
- The My App Server instance is installed and running.
- The Java/Tomcat application is deployed to the correct context path.
If your deployment uses a private JVM or custom Tomcat version, also confirm that the service was restarted after the application update when required.
How TTL affects propagation time
TTL, or time to live, tells resolvers how long they may cache a DNS answer. A low TTL helps during planned cutovers because caches refresh sooner. A high TTL can keep visitors on the old address for longer.
For example, if the old record had a TTL of several hours, some resolvers may continue serving that cached answer until the timer expires, even after you update the zone. That is normal behaviour. The authoritative nameserver may already show the new value while some clients still see the old one.
If you plan a future cutover, lower the TTL in advance. Do this well before the go-live window so caches have time to refresh. Then perform the final DNS change when you are ready to switch traffic.
Common reasons DNS looks unpropagated
Old cache on your device
Your browser, operating system, or local DNS resolver may still keep the previous address. Try another network or use a public resolver to compare results.
ISP caching
Some internet providers cache records longer than expected, especially under heavier load or with recursive resolvers that do not refresh immediately.
Wrong record edited
It is easy to update www but not the root domain, or to change the A record while the site actually uses a CNAME. Check the exact hostname users visit.
Nameserver mismatch
If the domain is delegated to different nameservers than the ones you edited, your changes will not be visible publicly. Confirm the active authoritative nameservers first.
Application still serving the old site
After DNS points to the new server, the old content may still appear if Apache or Tomcat is serving an old deployment, a default page, or a stale virtual host configuration.
Recommended cutover checklist for a Tomcat site
- Lower TTL in advance if possible.
- Deploy and test the application on the destination Tomcat instance.
- Confirm the required Java version is installed and selected.
- Make sure the Tomcat service is running in My App Server.
- Update the DNS record to the new destination.
- Verify the authoritative nameserver shows the new value.
- Check several public resolvers.
- Test the domain from more than one network.
- Watch logs and service status after the switch.
This is especially useful for JSP, servlet, and small-to-medium Java applications where the domain switch is part of the final deployment step.
Example: switching a UK Tomcat application to a new IP
Suppose your public site is app.example.co.uk and it runs on a Tomcat instance managed through My App Server. You move the site to a new hosting account and update the A record to a new IP address.
What you should expect:
- The authoritative DNS should show the new IP immediately after the zone update.
- Some resolvers may still show the old IP for a while, based on TTL.
- Visitors on cached networks may briefly reach the old server.
- Once they resolve the new IP, they should land on the new Apache/Tomcat setup.
If the new server responds with an application error, the DNS change may already be complete and the issue is now in the Tomcat deployment, not propagation.
Troubleshooting when propagation seems stuck
If the record does not appear to change after a reasonable time:
- Double-check the DNS zone for typos.
- Confirm you edited the correct hostname.
- Verify the domain uses the nameservers you updated.
- Check whether the record is being overridden by another DNS provider.
- Clear your local DNS cache and retry from another network.
- Inspect whether the old record still exists alongside the new one.
If you manage multiple services on the same domain, make sure you did not change a record used by mail, verification, or a subdomain required by another application.
FAQ
How long does DNS propagation take for a Tomcat site?
It depends mainly on the TTL of the previous record and how quickly different resolvers refresh their cache. In many cases it can take from a few minutes to several hours. Occasionally some networks take longer.
Does DNS propagation affect the Tomcat service itself?
No. DNS only decides where the browser connects. Tomcat, Apache, and your Java application must still be running correctly on the target server.
How can I check if my browser is showing a cached result?
Test the domain from another browser, an incognito window, or a different network. You can also compare the result from a public DNS resolver. If those show the new address while your browser does not, local caching is likely the reason.
What should I verify in My App Server after a DNS cutover?
Check that the Tomcat service is running, the application is deployed, the chosen Java version is correct, and the site responds under the expected domain and context path.
Is it enough to check only one DNS propagation website?
No. Use several checks if the cutover is important. A single tool can miss local cache differences or resolver-specific behaviour.
Why does the site still show the old page after DNS changed?
Either some resolvers are still caching the old record, or the new server is serving the wrong virtual host, a default page, or an older Tomcat deployment. Check DNS and application response separately.
Conclusion
To confirm that DNS changes have propagated for a Tomcat site, check the record from authoritative nameservers, public resolvers, and multiple networks. Then verify the destination server, Apache, and Tomcat instance in Plesk or My App Server. This layered approach is the most reliable way to complete a cutover with minimal downtime.
If the DNS answer is already new but the site still does not load as expected, the issue is likely in the Java hosting setup rather than in propagation. In that case, review the Tomcat service status, deployment, Java version, and web server configuration before assuming the DNS change has failed.