How to check whether DNS changes have propagated for a Tomcat site

When you update DNS for a Tomcat site, propagation is not always visible from one browser or one device. Different resolvers cache records for different lengths of time, and your visitors may be routed to the old server for a while even after the zone has been changed. The most reliable way to confirm cutover is to check the DNS record itself, then verify that the domain resolves to the expected IP address from more than one network, and finally test the application through the Tomcat host and control panel.

For Java hosting and Tomcat hosting environments managed through Plesk, this is especially important during a go-live or server move. A Tomcat application may already be deployed and running correctly, but if the A, AAAA, or CNAME record has not fully propagated, requests may still reach the previous host. This guide explains how to check propagation safely and what to verify before you consider the DNS change complete.

What DNS propagation means for a Tomcat site

DNS propagation is the time it takes for updated DNS data to be seen by recursive resolvers, ISPs, corporate networks, and local caches. In practical terms, it means the domain name may point to the new Tomcat server for some users while others still see the old destination.

For a Tomcat site, the relevant records are usually:

  • A record for IPv4 address changes.
  • AAAA record for IPv6 address changes.
  • CNAME record if the domain points to another hostname.
  • NS records if you changed nameservers.
  • TXT records when you also need to confirm SPF, DKIM, or domain ownership settings.

If your app uses the My App Server Java hosting setup in Plesk, DNS propagation does not affect the Tomcat process itself. It affects whether traffic reaches that Tomcat instance. In other words, your application can be healthy and still appear unavailable if DNS is not fully switched.

How to tell whether the DNS change has propagated

Start by checking the authoritative source, then compare results from external resolvers. Do not rely on your browser cache alone.

1. Check the authoritative DNS zone

First confirm that the domain zone contains the correct target values. In a hosting control panel such as Plesk, verify that the domain’s DNS settings point to the new server IP or hostname.

Look for:

  • The correct A record for the main hostname.
  • The correct AAAA record if IPv6 is used.
  • The correct CNAME for www if the website uses a canonical host name.
  • Consistent values between the apex domain and the www version, if both should resolve to the same application.

If you manage DNS separately from the web hosting account, make sure the live zone at your DNS provider has been updated, not just the settings in your app server panel.

2. Compare results from multiple DNS resolvers

Query the domain from several public resolvers and compare the returned IP address. If different resolvers show different answers, propagation is still in progress or cached data is still active.

Useful checks include:

  • Google Public DNS
  • Cloudflare DNS
  • OpenDNS
  • Your local ISP resolver

If the domain points to the new Tomcat server on some resolvers but not others, that is normal during cutover. The remaining delay depends on the record TTL and cache behaviour upstream.

3. Test from an external network, not just your own browser

Open the site from a mobile network, another Wi-Fi network, or an online DNS lookup tool. Your own device may still use cached DNS information even after the public change is live.

A simple browser refresh is not enough because:

  • the browser may cache DNS data temporarily;
  • the operating system may also cache DNS results;
  • the ISP resolver may still return the old IP during TTL expiry.

4. Verify the HTTP response from the new Tomcat host

Once the domain resolves to the new address, confirm that the application responds correctly. A successful DNS update does not guarantee that the Tomcat site is serving the correct content.

Check that:

  • the correct virtual host is attached to the domain;
  • the Tomcat service is running in My App Server or in your custom app server setup;
  • the WAR file or JSP application is deployed;
  • the application context path is correct;
  • HTTPS certificates are valid if the site uses SSL.

Practical DNS checks you can use during cutover

There are several easy ways to confirm whether propagation has finished. Use more than one method if the site is business critical.

Check the DNS answer with a lookup tool

A DNS lookup tool can show the current public answer for your domain. Compare the returned IP with the new Tomcat server address.

What to confirm:

  • the apex domain resolves to the expected IP;
  • www resolves to the same place, if required;
  • both IPv4 and IPv6 records are correct, if both are in use.

Check the TTL value

TTL, or time to live, controls how long resolvers may cache a DNS record. Lower TTL values are often used before a planned cutover so the change spreads faster.

For example:

  • a record with a 300-second TTL may update relatively quickly;
  • a record with a 3600-second TTL may remain cached for up to an hour;
  • some resolvers or networks may hold data even longer in edge cases.

If you reduced the TTL before migration, wait at least that amount of time after the DNS update before drawing conclusions.

Check reverse consistency by hostname

If your Tomcat application uses both the bare domain and www, verify that both names reach the same site or the intended routing target. Mixed results can happen when one record has propagated and the other has not.

This is particularly useful for:

  • redirect setups from non-www to www;
  • sites with HTTPS certificates issued for both names;
  • applications deployed under a single Tomcat host name.

How this applies in Plesk and My App Server environments

In a managed hosting environment with Plesk and the My App Server extension, the DNS change and the Java application setup are related but separate tasks. You may already have created the Tomcat instance, selected the Java version, and deployed your application. The remaining step is to make sure the public DNS name points to that service.

When checking propagation in this context, also confirm the following inside the hosting panel:

  • the domain is assigned to the correct subscription or hosting space;
  • the application server service is started;
  • the expected Tomcat version is active;
  • the app listens on the correct internal port or connector;
  • the web root or proxy configuration matches the domain.

If you use a custom app server setup, verify the same points for your custom Apache Tomcat installation. The DNS record may be correct while the service itself is still offline, which can look like a propagation problem from the outside.

Step-by-step: confirm DNS propagation for a Tomcat site

Use this sequence during go-live to reduce confusion and downtime.

  1. Update the DNS zone with the new A, AAAA, or CNAME record.
  2. Lower TTL in advance if you planned the migration ahead of time.
  3. Wait for the old TTL to expire before expecting universal visibility.
  4. Check the authoritative DNS settings in your control panel or DNS provider.
  5. Query several public resolvers and compare the answers.
  6. Test the site from another network to avoid local cache effects.
  7. Open the domain in a browser and confirm the Tomcat application loads.
  8. Review Tomcat logs if the domain resolves correctly but the app does not respond as expected.
  9. Confirm HTTPS if the site is secured with SSL.

What to do if some users still reach the old server

If the DNS record looks correct but traffic still goes to the previous server for some visitors, do not change multiple things at once. The goal is to isolate whether the issue is DNS caching, service routing, or application deployment.

Use this checklist:

  • confirm the new IP address is present in the live DNS zone;
  • verify the old server still has the previous record cached;
  • check whether the TTL had been high before the cutover;
  • make sure there are no conflicting records for the same hostname;
  • ensure both apex and www records are aligned;
  • check whether IPv6 is sending some clients to a different destination.

If you recently changed nameservers, remember that nameserver delegation can take time to become visible everywhere. In that case, even correct zone data may not be enough until the new delegation is seen by resolvers worldwide.

Common mistakes during Tomcat DNS cutover

Some issues are caused by DNS itself, while others are caused by how the web application is published. The most common mistakes are:

  • changing the DNS record but forgetting to lower TTL beforehand;
  • checking the site only from the same browser or device;
  • updating the zone in the control panel but not at the active nameserver provider;
  • leaving an old AAAA record in place after moving only the IPv4 address;
  • pointing www to the new host but not the root domain, or vice versa;
  • assuming Tomcat is down when the browser is still using cached DNS data;
  • forgetting that a reverse proxy or frontend Apache layer may also need adjustment.

In Java hosting setups, one more common issue is that the domain resolves correctly but the application context was deployed under a different path. In that case, DNS has propagated, but the expected page is not available at the requested URL.

How long should DNS propagation take?

There is no single fixed time. Propagation depends on TTL, resolver cache behaviour, and whether you changed records or nameserver delegation.

As a general guide:

  • low TTL values may update in minutes;
  • typical TTL values may take up to an hour or longer;
  • nameserver changes can take longer to be seen consistently across all networks.

For a Tomcat site, the safest approach is to plan the cutover with time for overlap. Keep the old server available until you have verified that the new DNS target is visible and the application is responding correctly for enough users and networks.

Recommended go-live approach for Tomcat hosting

If you are moving a Java application to a new Tomcat instance in My App Server, use a staged cutover:

  • prepare the new Tomcat application in Plesk;
  • deploy and test it on the temporary or internal URL;
  • reduce DNS TTL ahead of the move;
  • switch the A or CNAME record at the planned time;
  • monitor resolution and application responses after the change;
  • keep an eye on logs for unexpected requests or old hostnames.

This approach is well suited to shared hosting, small and medium Java applications, and Tomcat-based sites that need a controlled DNS cutover without unnecessary downtime.

FAQ

How can I check if DNS has propagated for my Tomcat site?

Compare the domain’s DNS answer from multiple public resolvers, then test the site from a different network. If the domain resolves to the new server IP and the Tomcat application loads correctly, propagation is effectively complete for most users.

Why does my domain still open the old server after I changed the record?

The most common reasons are DNS caching, a high TTL, an unchanged AAAA record, or a local browser or ISP cache. It can also happen if you updated the wrong DNS zone or if nameserver delegation has not fully switched.

Does changing DNS stop the Tomcat service?

No. DNS only controls where the domain points. The Tomcat service, JVM, and application deployment remain separate. You must verify both DNS and the application layer.

Should I wait for DNS propagation before testing the app?

You can test the app immediately on the new server using its temporary address or internal host name, but public testing through the domain should wait until the DNS change is visible from multiple resolvers.

How do I know if www and the root domain both propagated?

Check both hostnames separately. They may have different records and different TTL values. For a clean go-live, both should resolve to the intended Tomcat destination.

What if I use a custom Apache Tomcat setup?

The validation steps are the same. Confirm the DNS record, then verify that your custom Tomcat instance is running, the connector or proxy is configured correctly, and the site responds on the expected host name.

Conclusion

To check whether DNS changes have propagated for a Tomcat site, confirm the live DNS zone, compare the response from multiple resolvers, test from an external network, and make sure the Tomcat application itself is serving the expected content. In managed Java hosting environments such as My App Server in Plesk, this method helps separate DNS delay from application or service issues.

For the smoothest cutover, lower TTL before the move, keep the old server available during the transition, and verify both the domain and the application layer after the change. That is the most reliable way to bring a Tomcat site live with less downtime.

  • 0 Users Found This Useful
Was this answer helpful?