DNS Resolution

DNS translates human-readable hostnames such as `api.example.com` into IP addresses that clients can use to reach servers. A typical lookup involves a recursive resolver obtaining information from authoritative DNS servers, often using cached results when available.

When a Java backend connects to a hostname, the application generally relies on the operating system or JVM networking APIs rather than implementing DNS itself. The resolver checks available caches and, if necessary, performs DNS queries to obtain the address associated with the hostname.

A recursive DNS resolver performs the lookup on the client's behalf. If it does not already have the answer cached, it can query DNS infrastructure beginning with a root server, then the appropriate top-level-domain server, and finally an authoritative server for the domain. The authoritative server provides the records it controls, such as an `A` record for IPv4 or an `AAAA` record for IPv6.

DNS responses include a TTL (time to live), which tells caches how long the result may be retained. Caching reduces latency and DNS traffic, but it also means that changes to DNS records may not become visible everywhere immediately.

For Java backend systems, DNS behavior matters when calling databases, HTTP services, message brokers, or other hosts by name. Connection failures can result from DNS problems before the application ever establishes a TCP connection, so troubleshooting should distinguish name resolution from later networking stages.

Key points

• DNS maps names to resource records, commonly IP addresses.
• A recursive resolver performs DNS lookup work for the client when the answer is not cached.
• Authoritative name servers provide DNS data for domains they serve.
• `A` records map names to IPv4 addresses; `AAAA` records map names to IPv6 addresses.
• TTL controls how long DNS responses can generally remain cached.

Interview questions

What happens when an application resolves `api.example.com`?

The application asks the system's DNS resolution mechanism for the hostname's address. A recursive resolver may return a cached response, or it may query other DNS servers to obtain the answer. The lookup can ultimately reach an authoritative server for the domain. The resulting DNS record gives the client information needed to contact the destination.

What is the difference between recursive and authoritative DNS servers?

A recursive resolver accepts a client's request and finds an answer, potentially querying several DNS servers and caching the result. An authoritative server is responsible for DNS records in a particular zone. It answers from the data for which it is authoritative rather than recursively searching the DNS hierarchy for the client.

Why can a DNS record change take time to become visible?

DNS responses can be cached by recursive resolvers and other intermediaries. The record's TTL determines how long a cached response may normally be reused. Until a cache expires or is otherwise refreshed, clients can continue receiving the older value. This is why changing a DNS record does not necessarily cause an immediate global change.

How would you troubleshoot a Java service that cannot connect to a hostname?

First, I would determine whether the hostname resolves from the same environment where the service runs. I would inspect DNS errors separately from TCP connection errors, because a successful lookup does not guarantee that the destination is reachable. I would also check the returned records, resolver configuration, caching behavior, and whether IPv4 and IPv6 produce different results. Finally, I would use application and system-level logs to correlate the failure with the actual request.

Why can DNS behavior matter in backend systems even when the application code is unchanged?

A backend can depend on hostname resolution for external services, databases, APIs, or internal infrastructure. Changes to DNS records, resolver behavior, TTLs, or network configuration can therefore alter the destination without changing application code. DNS can also introduce latency or failures before an application establishes its connection. In distributed systems, these effects make DNS configuration and caching part of operational behavior rather than merely application configuration.