DNS, HTTP, and TLS

A successful HTTPS request depends on several independent systems. Test them separately so a DNS problem is not mistaken for an application problem.

Resolve the name

getent ahosts api.example.com
resolvectl query api.example.com
dig api.example.com A
dig api.example.com AAAA
dig api.example.com CNAME

getent uses the host’s configured name-service path and is closest to what many applications see. dig shows DNS records directly and makes it easier to compare resolvers.

dig @1.1.1.1 api.example.com A
dig +trace api.example.com

Querying another resolver can reveal a caching or split-DNS difference. +trace follows delegation from the DNS root and may be blocked on restricted networks. Do not use either result as proof that the application itself uses the same resolver path.

DNS changes are not immediate everywhere. Resolvers and clients can retain the previous answer until its TTL expires. Before a planned cutover, lower the TTL far enough in advance, confirm the new value is being served, and keep the old endpoint available during the transition.

Test the port

nc -vz api.example.com 443

A successful connection proves a TCP handshake completed. A refusal usually means the destination replied but nothing accepted that port. A timeout can indicate a drop, missing route, unavailable host, or asymmetric return path; it does not identify which one by itself.

Inspect TLS and HTTP

curl -vI https://api.example.com
curl -sS -o /dev/null \
  -w 'code=%{http_code} connect=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n' \
  https://api.example.com/health

Verbose curl output shows the selected address, connection, TLS negotiation, certificate result, request headers, and response headers. It can also expose credentials or tokens, so remove sensitive values before sharing it.

Test a new backend before changing public DNS:

curl --resolve api.example.com:443:203.0.113.25 \
  -I https://api.example.com/health

--resolve directs this curl request to the chosen address while preserving the hostname for TLS and HTTP. It does not alter system DNS.

For certificate details:

openssl s_client \
  -connect api.example.com:443 \
  -servername api.example.com \
  -verify_return_error </dev/null

Check that the certificate covers the requested hostname, is within its validity period, chains to a trusted issuer, and is served with the required intermediates.

Understand the proxy boundary

A load balancer or reverse proxy terminates the client connection and opens a separate connection to the backend. Troubleshoot both sides:

client ── TLS :443 ──> load balancer ── HTTP :3000 ──> application

The application should trust forwarded client headers only from known proxies that replace, rather than blindly append to, untrusted values. Keep a request ID across proxy and application logs so one failed request can be followed through both connections.

References

• DNS concepts and facilities
• dig manual
• HTTP semantics
• curl manual