← Linux administration for operations
06 / 12 · 20 MIN

Separate DNS, connections, TLS, and the application

Locate the failure layer and prepare a change with validation and rollback.

A connection crosses several stages

A call can fail during name resolution, routing, TCP establishment, TLS negotiation, or HTTP response. Examine the relevant stage from the affected context: host, container, identity, and network may change the outcome. getent uses configured system resolution sources; an isolated DNS query may not exactly reproduce the application’s path.

Interpret signals without overclaiming

Connection refused is consistent with active rejection, such as no listener or a reject rule; it does not prove the database failed. Timeouts have multiple possible causes, including filtering, routing, or saturation. A listening socket does not demonstrate functional health. For TLS, check name, validity, chain, and trust; disabling verification is not a certificate fix.

Apply and validate a change

Distinguish observation from actions with effects. Even an HTTP GET can have effects in a poorly designed application; use the approved health endpoint. Before changing configuration, preserve the current state and rollback criteria, respect the window, and coordinate dependencies. Afterward, validate service, logs, connectivity, and behavior at the next startup when that is part of the objective.

Workplace application

Trace the connection from the affected context: name resolution, routing, TCP, TLS, and application response. A host getent query can differ from an application inside a container using another resolver. A LISTEN socket does not confirm authentication or dependencies. If TLS reports an incorrect name, compare the requested name, SNI, and certificate identity while retaining security validation in the final check.

getent ahosts api.example.test
ip route get 192.0.2.10
ss -lnt
# Example documentation addresses only; use an approved target and endpoint.
curl --connect-timeout 3 --max-time 8 -I https://api.example.test/health
IN PRACTICE

DNS returns the expected address, TCP connects, but TLS fails with a hostname mismatch. Investigate the name used and the certificate presented at that endpoint. Restarting the application or ignoring validation does not establish correct trust.

Common pitfalls

Testing only from a laptop, treating LISTEN as functional health, or disabling TLS validation as a fix.

Related topics: Shell: arguments, pipelines, and exit codes · Maintenance and demonstrated recovery

Take this idea with you

Locate the failed stage and validate service recovery while retaining security controls.

Create account

Reference: getent(1): name service databases · DR Linux 2026.4; networking and Bash manuals reviewed 2026-10-01; cgroup v2 and upstream systemd manuals reviewed 2026-10-01; RHEL 10 examples; Linux man-pages 6.19; OpenSSL 3.5