After you update DNS for a Java site, the safest way to confirm propagation is to check the record from more than one network, compare the old and new answers, and then test the site itself over HTTP and HTTPS. For Java hosting setups that use Plesk and a service such as My App Server with Apache Tomcat, DNS propagation is only one part of the go-live process: the domain must resolve to the new hosting target, the web server must answer on the correct IP, and your Java application must still be running correctly behind Tomcat.
DNS changes do not always appear everywhere at the same time. Some resolvers update within minutes, while others may cache the previous record until the TTL expires. That is why a domain can work from one location and still point to the old server from another. If you are moving a JSP, servlet, or WAR-based application, you should verify both the DNS layer and the application layer before you consider the cutover complete.
What “DNS propagation” means for a Java site
DNS propagation is the process by which updated DNS records are seen by different recursive resolvers around the world. In practice, this means that when you change an A record, AAAA record, CNAME, or nameserver, some users may reach the new server immediately while others continue to see the old destination for a period of time.
For a Java site hosted on a control panel such as Plesk, this matters because the domain is often tied to a hosting subscription, a Tomcat service, and a specific IP address. If the DNS still points to the old server, users may reach the previous environment even after you have deployed the new Java application. If the DNS already points to the new server but Tomcat is not ready, the domain may resolve but the site will still fail.
Common DNS changes during a Java go-live
- A record changes to point the domain to a new IPv4 address.
- AAAA record changes for IPv6-based resolution.
- CNAME updates when a subdomain points to another host name.
- Nameserver changes when DNS hosting is moved.
- TXT updates sometimes needed for verification, SPF, DKIM, or domain control.
Before you check propagation, confirm the expected target
First, make sure you know what the domain should resolve to. For a Java hosting migration, this is usually the new server IP or a hostname used by your platform. In Plesk, you may see the assigned IP in the subscription settings, while a My App Server installation may use a specific virtual host configuration tied to Apache and Tomcat.
Write down these details before testing:
- Domain name and any relevant subdomains, such as www or app.
- Expected A and AAAA records.
- Whether the domain should resolve directly or via CNAME.
- Expected nameservers, if you changed DNS hosting.
- The old server IP, for comparison.
- The new server IP, hosting node, or DNS target.
If you use My App Server, also confirm that the correct Tomcat instance, Java version, and deployment are active. DNS can point to the right machine, but the site will still fail if the Java service is stopped or the application is not deployed.
How to check whether DNS changes have propagated
The most reliable method is to compare DNS answers from multiple resolvers and then verify the application response from the browser and the command line. You should not rely on just one online checker or just your local device, because local caching can hide the real state.
1. Check the current DNS record from your local machine
Start with a local lookup to see what your computer currently receives. This is useful, but it does not prove global propagation because your resolver may have cached an older answer.
On Windows, use:
- nslookup example.com
On Linux or macOS, use:
- dig example.com
- dig www.example.com
Look at the returned IP address or canonical name and compare it with the expected value. If the result still shows the old server, the record may not have expired everywhere yet.
2. Query public DNS resolvers directly
To see whether the updated record is visible outside your network, test well-known public resolvers such as:
- Google DNS: 8.8.8.8 and 8.8.4.4
- Cloudflare DNS: 1.1.1.1
- OpenDNS: 208.67.222.222
When checking from the command line, query each resolver directly. If they all return the new IP, propagation is likely complete for many users. If some still return the old answer, caching is still in progress.
3. Check the record from different geographic locations
Propagation is not the same as geolocation, but testing from multiple regions helps identify resolver caching differences. Use online DNS lookup tools or remote shell access where available. If your hosting provider offers a control panel with DNS tools, that is also helpful for a quick comparison.
For a Java site, it is useful to test from:
- Your own network.
- A mobile network.
- A VPN or remote office location.
- Public DNS resolvers.
If all of them show the same new destination, DNS propagation is likely complete or close to complete.
4. Verify that the TTL has expired
TTL, or time to live, tells resolvers how long to cache a record. A low TTL before the migration usually helps changes spread faster. If the original record had a long TTL, old answers may persist for longer even after you update the zone.
Check the TTL on the changed record and keep in mind:
- A lower TTL usually means faster visibility of changes.
- A higher TTL usually means longer caching.
- Some resolvers may ignore ideal timing and keep cached data a bit longer.
If you are planning a future cutover for a Java app, reduce TTL in advance rather than on the day of the change.
5. Test the site in the browser
Once the DNS answer points to the expected server, open the site in a browser and confirm the real application response. For a Java hosting environment, the browser test should prove more than DNS resolution. It should confirm that Apache, Tomcat, and the deployed application are working together correctly.
Check for:
- The correct home page or application route.
- No stale content from the old server.
- No certificate warning on HTTPS.
- No application error page, 404, or 502/503 response.
6. Test HTTP and HTTPS separately
DNS may be correct while HTTPS still fails because of certificate mismatch, incomplete virtual host setup, or proxy configuration. This is particularly important when a domain has just been moved to a new Plesk subscription or a new Tomcat instance.
Check both:
- http:// version of the site
- https:// version of the site
If the HTTPS site fails but HTTP works, the DNS cutover may be complete but the SSL configuration still needs attention.
What to check in a Plesk and My App Server Java hosting setup
When the domain now points to the new hosting account, the next step is to confirm the Java stack is healthy. In a managed hosting environment with Plesk and My App Server, the site may depend on a private JVM, a selected Java version, Apache integration, and a Tomcat service that must be running.
Confirm the domain is assigned to the correct subscription
In Plesk, the domain should exist under the right subscription or site configuration. If it was created in the wrong place, the web server may answer with the default page or a different application.
Confirm the Tomcat or Java service is running
For Java sites using My App Server, make sure the service is started. A DNS change can be perfectly propagated, but if Tomcat is stopped, the domain will not serve the application.
Typical symptoms of a service issue include:
- Blank page or generic server error.
- HTTP 502 or 503 response.
- Application files exist but the site does not load.
- Log entries showing Java or servlet startup problems.
Check the Java version and deployment path
If you recently switched to a different Java version, verify that the application supports it. Some JSP or servlet applications behave differently when moved between versions. Also confirm that the WAR file, exploded application directory, or custom application path is correct.
Review Apache and virtual host settings
In many Java hosting setups, Apache handles the public request and passes traffic to Tomcat or the Java backend. If the DNS now resolves to the new server but the virtual host is wrong, the request may not reach the application. Make sure the domain is linked to the correct host configuration, document root, and proxy rules where applicable.
Step-by-step checklist for checking propagation
Use this checklist when switching a Java site to a new host or a new IP:
- Confirm the new DNS target and note the old value for comparison.
- Check the updated record with nslookup, dig, or a similar tool.
- Query several public resolvers directly.
- Check both the root domain and common subdomains such as www.
- Verify the TTL and allow enough time for caches to expire.
- Open the site over HTTP and HTTPS.
- Confirm the Java application loads correctly in Plesk/My App Server.
- Inspect logs if the domain resolves but the site is not responding as expected.
How to tell whether the old or new server is answering
Sometimes a site loads, but you are not sure which server is serving it. This is common during migration windows, especially when both the old and new server host similar content. To avoid confusion, check for identifying details such as:
- A temporary test page placed only on the new server.
- A small header change in the application.
- A server-specific response in the HTML source.
- Different certificate details if the SSL setup changed.
For Java applications, a simple version string, environment label, or custom footer can help you confirm you are reaching the new Tomcat instance. Remove any temporary identifier after the cutover is complete.
Common reasons DNS seems not to have propagated
Sometimes the DNS has actually changed, but the result still looks old because of caching or a configuration issue. The most common causes are:
- Local DNS cache on your computer or router.
- ISP resolver cache still holding the old answer.
- Long TTL from the previous record.
- Wrong record type updated, such as changing A but forgetting AAAA.
- Missing subdomain update for www or app.
- Nameserver mismatch if the zone was moved but delegation was not updated.
- Application issue on the new Java host that looks like a DNS problem.
If the domain resolves correctly from public resolvers but your browser still shows the old result, flush your local DNS cache or test from a different network.
How to speed up a Java site cutover safely
You cannot force the whole internet to update instantly, but you can reduce the impact of caching during a migration. For a Java hosting move, the best practice is to prepare early and keep both environments available during the transition if possible.
- Lower the TTL at least a day before the change.
- Deploy and test the Java app on the new server before switching DNS.
- Keep the old site available long enough to catch cached requests.
- Update the root domain and key subdomains together.
- Check both DNS and Tomcat service status after the cutover.
For smaller and medium Java applications hosted through My App Server, this approach usually provides a smoother go-live than trying to switch everything at once.
Troubleshooting when DNS is propagated but the site still fails
If the DNS record already points to the new server and multiple resolvers confirm it, then the problem is usually not DNS anymore. Move to the application layer and check the hosting stack.
- Confirm the Tomcat service is running.
- Check the Java application logs for startup errors.
- Verify the correct Java version is selected.
- Confirm the domain is mapped to the right Apache virtual host.
- Check SSL certificate binding for the domain.
- Make sure firewall or service rules are not blocking access.
In a managed hosting environment, these checks are often faster than repeating DNS tests once propagation has clearly completed.
FAQ
How long does DNS propagation usually take?
It depends on the TTL, the type of change, and how resolvers cache data. Some users may see the new record within minutes, while others may take several hours or longer. If nameservers changed, the process can take more time than a simple A record update.
Why do I still see the old server after changing the A record?
Your local resolver, ISP, or browser may still be using a cached response. It is also possible that the AAAA record still points to the old server, so the browser is using IPv6 instead of IPv4. Check both record types and compare results from public resolvers.
Does DNS propagation affect my Java application itself?
DNS does not change the application code, but it decides where users are sent. If the new server has the wrong Tomcat setup, wrong Java version, or missing deployment, users may think the DNS change failed when the real issue is on the host.
What should I check first if my Java site is down after a DNS change?
First confirm the domain resolves to the expected IP from public resolvers. Then check whether the Tomcat service is running, the application is deployed, and the SSL configuration is correct. In many cases, the DNS is already fine and the issue is in the Java service or web server setup.
Should I test both the root domain and www?
Yes. They may use different records. It is common for the root domain to have an A record while www uses a CNAME. During migration, both should be checked to avoid partial cutovers.
Conclusion
To check whether DNS changes have propagated for a Java site, compare the updated records from multiple resolvers, verify TTL-related caching, and then test the live site over HTTP and HTTPS. In a Plesk-based Java hosting environment using My App Server, always confirm that the domain is pointing to the correct host and that the Tomcat service, Java version, and application deployment are working as expected. DNS propagation is only one part of the go-live process, but with the right checks you can separate resolver delay from actual hosting issues and complete the cutover with less downtime.