Loading

CloudHub 2.0 Private Space: Intermittent UnknownHostException Caused by a DNS Race Condition Across Multiple Internal DNS Servers

Veröffentlichungsdatum: Jul 30, 2026
Beschreibung

SYMPTOM

Mule applications deployed in a CloudHub 2.0 Private Space intermittently fail to resolve an internal (on-premises) hostname — for example, an on-premises message broker reached over a VPN or Transit Gateway connection — even though the same hostname resolves successfully at other times. The application throws java.net.UnknownHostException for the target hostname. The failures are intermittent rather than constant, which often makes the issue look like a flaky VPN or network problem rather than a DNS configuration issue.

CAUSE

When a Private Space is configured with more than one internal (custom) DNS server, CloudHub 2.0 sends each DNS query to all configured internal DNS servers at the same time and accepts whichever response arrives first — it does not prioritize a specific server, and it does not retry with another server once any response is received, including a negative one. If one configured DNS server is unhealthy in a way that still produces a fast, valid-looking negative response (for example, returning NXDOMAIN / "domain does not exist" because it is missing the zone or records for that internal domain), that server can intermittently "win the race" against a healthy server purely due to response timing. The application receives the negative response and immediately raises UnknownHostException, even though another configured server would have resolved the name correctly a moment later. Because winning the race is timing-dependent, the failures appear intermittent rather than constant.

A separate DNS server that is simply timing out (for example, because a firewall is silently dropping UDP port 53 traffic) does not itself cause this race-losing behavior, but it reduces redundancy and should be fixed as well.

Lösung
  1. From a location with access to the Private Space's internal DNS servers(like net-tools app or internally in your own network), test name resolution against each configured internal DNS server individually for the specific hostname that is failing - for example, dig @<dns_server_ip> <hostname> or nslookup <hostname> <dns_server_ip> - rather than testing DNS resolution in aggregate.
  2. Compare the responses: identify which server(s) return the correct IP address, which return a fast negative response (NXDOMAIN / "domain does not exist" / "no such name"), and which time out.
  3. In Runtime Manager, go to the affected Private Space's network configuration and internal DNS settings, and remove the DNS server(s) that return an incorrect or negative response for the domain in question, keeping only the server(s) confirmed to resolve it correctly.
  4. If a remaining server is timing out rather than answering, engage your network team to check whether a firewall or routing rule is silently dropping UDP port 53 traffic from the Private Space's CIDR range to that server. Resolving this restores DNS redundancy without reintroducing the race condition.
  5. Re-test the previously failing connection from the affected application to confirm resolution is now consistent.
Nummer des Knowledge-Artikels

005390313

 
Laden
Salesforce Help | Article