A service hostname times out from one Linux host, yet a nearby machine reaches it normally. Before changing firewall rules, establish where their DNS answers diverge: the application, the host’s configured resolver, or an upstream DNS service. Each boundary calls for a different fix.
Compare resolver answers
Start with the affected hostname and query the host’s default resolver: dig +time=2 +tries=1 api.example.net A. Then repeat from a known-good host using the same record type and name. A timeout, an empty answer, and an unexpected address are different results; note which one you actually see.
If policy permits, compare the default result with a query to a specific resolver using dig @RESOLVER_IP api.example.net A, replacing RESOLVER_IP with an approved resolver address. A difference narrows the investigation to resolver configuration or the DNS path between that host and its resolver. It does not, by itself, show that the public resolver is the correct source of truth for an internal name.
Check the host resolver path
Applications do not always make DNS requests in the same way as dig. Check the system’s normal name lookup path with getent ahosts api.example.net, which uses the host’s configured name-service setup. If dig succeeds but getent fails, inspect that configuration before changing records.
On a system using systemd-resolved, resolvectl query api.example.net can show which resolver handled the lookup. Also review /etc/resolv.conf, but first check whether it is a symlink managed by another service. Editing a generated file may appear to help briefly, then disappear on the next network or resolver update.
Separate DNS from transport
Once the hostname returns an address, test the application path with curl -v –connect-timeout 3 https://api.example.net/health. A connection timeout, a refused connection, and a certificate error point to different layers; none is evidence of a DNS failure if name resolution already completed.
If you have a known service address, curl’s –resolve option can test that address while preserving the hostname used for HTTP and TLS: curl –resolve api.example.net:443:SERVICE_IP https://api.example.net/health. Replace SERVICE_IP with the actual address. Treat this as a diagnostic comparison, not a permanent workaround; the useful result is whether the failure follows the resolver answer or remains when the destination is held constant.