When you change DNS for a Java site, the update does not reach every resolver at the same time. Some visitors may already see the new Tomcat or application server destination, while others still get the old one for a short period. In a UK hosting scenario, the safest way to confirm propagation is to check the record from several independent networks, verify the authoritative nameservers, and compare the result with what your hosting control panel shows for the domain and application route.
If your Java application is hosted with Plesk and the My App Server extension, DNS checks are especially useful during a cutover because the service may depend on the correct domain, A record, AAAA record, or CNAME before the WAR, JSP, or servlet app responds as expected. The goal is not just to see a changed IP address, but to confirm that the public name now points to the right destination and that requests are reaching the intended Apache Tomcat instance or private JVM.
What DNS propagation means for a Java site
DNS propagation is the period after you update a DNS record when the change spreads through the internet’s caching layers. In practice, that means a browser or recursive resolver may keep using an older answer until the cached time-to-live, or TTL, expires. This is normal and does not indicate a fault in your hosting platform.
For Java hosting, the practical impact is simple: one visitor may load the new application deployment, while another still reaches the previous server or a parked page. If you are moving a site to a My App Server setup, you may also see different behavior between the web root, the Tomcat context, and the domain name itself if the DNS change is only partly live.
The most common records involved are:
- A record for an IPv4 address
- AAAA record for an IPv6 address
- CNAME record for aliasing one name to another
- NS records for delegated nameservers
In a go-live scenario, you usually want to confirm the final public hostname, not only the server IP. That is important if your Java app uses HTTPS, virtual hosts, or a Tomcat context path behind Apache.
Before you test propagation, confirm the expected DNS change
Start by writing down the exact change you made and what the final answer should be. This avoids confusion when multiple records exist.
Check the record type
Identify whether you changed:
- the root domain, such as example.co.uk
- a subdomain, such as app.example.co.uk
- the nameservers at the registrar
- an A or AAAA record for the application host
- a CNAME that points the application name to another host
Confirm the target in Plesk or your DNS panel
If you use Plesk, open the domain’s DNS settings and compare the live values with your planned cutover values. For a Java site hosted with My App Server, also check that the domain is assigned to the correct subscription or service and that the Tomcat application endpoint is prepared for the new traffic.
It is easy to mistake a successful DNS update for a complete cutover. A domain may resolve correctly, but the application itself may still need the final WAR upload, context configuration, or service start in My App Server.
How to check whether DNS changes have propagated
Use more than one method. A single test from your own connection only shows one resolver path and one cache. For a reliable result, combine local checks, online checks, and authoritative checks.
1. Check the domain from your own connection
Open the site in a browser and note what loads. If the previous version appears, clear the browser cache or use a private window before assuming DNS is still stale. Browser cache and DNS cache are not the same thing, so a simple refresh is not enough.
You can also query the name from your device if you have access to DNS tools. On many systems, you can use commands such as nslookup or dig. A useful check is to confirm both the resolved IP address and the response time.
- Does the hostname resolve?
- Does it resolve to the expected IP address?
- Does the result include the record you changed?
- Is there both an A and AAAA record, and are both correct?
2. Query multiple public resolvers
Public resolvers help you see whether the update has reached different parts of the DNS cache network. Check the same hostname through several resolvers, for example:
- Google Public DNS
- Cloudflare DNS
- Quad9
- Your ISP resolver
If these resolvers return the new value, propagation is well underway or complete for most users. If some still return the old answer, the record has not fully aged out everywhere yet.
When testing a UK customer-facing site, it is useful to confirm from at least one resolver path outside your own office network as well. That gives you a better picture of what first-time visitors are likely to see.
3. Check the authoritative nameserver directly
The authoritative nameserver is the source of truth. If that server already shows the new record, then the remaining delay is mostly cache-related. If the authoritative server still shows the old value, the change has not been applied correctly.
Compare the authoritative answer with the public answer. If they do not match, the issue is usually one of these:
- the change was made at the wrong DNS provider
- the domain delegates to different nameservers than expected
- the registrar has not yet updated the NS set
- the record was edited in a zone that is not currently authoritative
4. Verify both IPv4 and IPv6 answers
Many modern browsers and networks prefer IPv6 when it is available. If you only updated the A record and forgot the AAAA record, some users may still reach the old environment. This matters during Java site migrations because partial reachability can look like intermittent failure.
Check whether:
- the A record points to the new host
- the AAAA record points to the new host, if you use IPv6
- the application answers correctly over both protocols
5. Test the application, not just the DNS record
For a Java site, the final proof is an HTTP or HTTPS response from the correct Tomcat application. After the DNS change resolves, open the site and confirm that:
- the expected page loads
- the HTTPS certificate matches the hostname
- the application context is correct
- the deployed WAR or JSP app is the latest version
- forms, login, and API endpoints behave as expected
In My App Server, a correct DNS record and a running service usually go hand in hand, but they are separate layers. DNS only sends traffic to the right address; the application server still needs to be active and correctly configured.
Recommended propagation check workflow for a UK Java hosting cutover
Use the following sequence when switching a Java site live.
- Lower the TTL ahead of the change if possible.
- Update the A, AAAA, or CNAME record in the correct DNS zone.
- Confirm the authoritative nameserver shows the new value.
- Check the domain from at least two public resolvers.
- Validate the site in a browser from a different network.
- Confirm the Java application in Plesk or My App Server is serving the expected build.
- Monitor logs for old traffic, 404s, SSL errors, or redirect loops.
This process reduces downtime because you are not waiting blindly for propagation. You are verifying each stage of the cutover separately.
How TTL affects propagation time
TTL, or time to live, tells resolvers how long they may cache a DNS answer before asking again. A lower TTL usually means faster updates, but it also increases query frequency. A higher TTL reduces DNS traffic but can keep old records visible for longer after a migration.
During a planned go-live, it is common to lower the TTL in advance so the new record spreads more quickly when the switch happens. If you did not lower it beforehand, the old answer may remain visible until the previous TTL expires. That is especially noticeable when a domain is used by a busy Java application or a site with many repeat visitors.
Keep in mind that propagation is affected by:
- the TTL on the previous record
- recursive resolver caching behavior
- browser and operating system caches
- ISP DNS caching policies
- the use of a CDN or proxy in front of the site
How to tell whether the issue is DNS or the Java application
Sometimes a site looks unavailable after a DNS change, but the real cause is not DNS at all. Separate the layers before troubleshooting further.
Signs it is still a DNS issue
- different devices resolve the hostname to different IPs
- public resolvers still show the old record
- the authoritative answer differs from the public answer
- the hostname sometimes opens the old site and sometimes the new one
Signs the DNS is fine but the app is not
- the hostname resolves to the correct IP, but the site returns 500 errors
- HTTPS works, but the application context returns 404
- Tomcat is not running or the service is stopped
- the wrong WAR is deployed
- the hostname points to the server, but the virtual host or proxy route is missing
With My App Server, you can usually check the service status and control the Java runtime from Plesk. That helps you confirm whether the issue is in DNS, Apache, Tomcat, or the application package.
What to check in Plesk and My App Server
If your Java site is hosted through Plesk with My App Server, use the control panel to confirm the application side of the cutover.
- Check that the domain is assigned to the correct hosting subscription.
- Confirm the selected Java version matches the app requirements.
- Verify that the Tomcat service is running.
- Check whether the application has been deployed successfully.
- Review any custom app server settings if you use a manually installed version.
- Ensure the document root or context path matches the public hostname.
If you use a private JVM or a separate Tomcat instance, DNS propagation may finish before the service is fully ready. In that case, visitors can reach the server but still see a maintenance page, a default Tomcat response, or an application error. A complete go-live check should cover both the DNS layer and the service layer.
Common reasons a DNS change seems not to have propagated
Many apparent propagation problems are actually configuration mistakes. The most common ones are:
- editing the wrong DNS provider
- updating the wrong subdomain
- leaving an old AAAA record in place
- forgetting that the registrar uses different nameservers
- testing from a cached browser session
- not waiting for the original TTL to expire
- having a proxy or CDN still pointing to the old origin
- the site using multiple records and one of them still being old
For Java hosting, another common issue is that the application server was updated, but the public DNS name was not aligned with the server name, SSL certificate, or Tomcat configuration. The result is a site that resolves correctly but does not load the expected app.
Practical example of a clean cutover
Imagine you are moving app.example.co.uk to a new My App Server deployment. You first lower the TTL the day before, then deploy the new WAR to Tomcat, then update the A record to the new IP. After that, you:
- check the authoritative nameserver and see the new IP
- query two public resolvers and get the same result
- test the site from a mobile network and a desktop network
- confirm the HTTPS certificate still matches
app.example.co.uk - review the application logs for clean traffic on the new host
If all of those checks pass, propagation is effectively complete for most users. Any remaining old responses are likely due to resolver caches that will expire soon.
FAQ
How long does DNS propagation take?
It depends on the TTL and on how long recursive resolvers cache the previous answer. Some users may see the change within minutes, while others may continue to see the old record for several hours. In some cases, cached data can last up to the previous TTL.
Why does my site still open the old server after I changed DNS?
The most common reason is cached DNS data on your device, browser, router, or ISP resolver. Another possibility is that the change was made in the wrong DNS zone or that an AAAA record still points to the old server.
How can I check if my DNS change is live everywhere?
You cannot prove that every resolver worldwide has refreshed at exactly the same moment, but you can check the authoritative nameserver and several public resolvers. If they all return the new record, the change is widely propagated.
Do I need to check both A and AAAA records?
Yes, if your domain uses IPv6. A correct A record is not enough if the AAAA record still points elsewhere, because some visitors will prefer IPv6 and may reach the wrong destination.
My DNS is correct, but the Java site still fails. What should I inspect?
Check the Tomcat or private JVM service, the application deployment, the SSL certificate, and the virtual host or context path in Plesk or My App Server. DNS only directs traffic; it does not validate the app itself.
Can I speed up propagation?
You cannot force every resolver to refresh immediately, but you can lower TTL before the change, make sure the new record is correct, and avoid unnecessary additional DNS edits during the cutover.
Summary
To check whether DNS changes have propagated for a Java site in the UK, verify the record at the authoritative source, compare it with multiple public resolvers, and then confirm that the site actually loads from the new Apache Tomcat or private JVM environment. In a My App Server setup, the best results come from checking DNS and the application layer together in Plesk. That approach gives you a clear answer during go-live and helps you spot whether any issue is still caused by caching, record mismatch, or service configuration.