What Is DNS? How Domain Names Connect to IP Addresses

DNS, the Domain Name System, lets applications look up information associated with domain names, including the IP addresses used to reach websites. You enter a name such as app.example.net; a DNS lookup can return an address that your browser uses to start a connection.

DNS helps find the destination. The website still needs working routing, a reachable server, and the correct application configuration.

What happens during a DNS lookup?

Your device usually asks a recursive resolver to obtain an answer. That resolver might be supplied by your internet provider, workplace, or another DNS service. An application or browser can also use its own configured resolver.

If a usable answer is already cached, the lookup can stop there. Otherwise, the resolver follows the DNS hierarchy to find the relevant authoritative server.

For a simple lookup of app.example.net, the process can be illustrated as:

Device -> Recursive resolver
            -> Root server: where can I ask about .net?
            -> .net server: who serves example.net?
            -> Authoritative server: what is app.example.net's address?
Device <- Resolver returns the answer
Device -> Website endpoint

Delegations and aliases can add steps. Existing cached information can remove steps. This is a simplified lookup, not a sequence that every page visit must repeat. Cloudflare’s DNS explanation describes these resolver and server roles.

The distributed naming hierarchy itself is described in RFC 1034.

Which DNS records connect names to addresses?

DNS holds several kinds of records. These are particularly useful when setting up a website:

RFC 1035 defines the original record formats, including A, CNAME, and NS. RFC 3596 defines AAAA records for IPv6.

One name can have multiple addresses, and many website names can share an address. Publishing both A and AAAA records does not make either network path work automatically. See IPv4 vs IPv6 for the protocol distinction, and What Is Reverse DNS? for how PTR records map an address back to a hostname.

The example names and addresses are for documentation. The public address examples use the ranges reserved by RFC 5737 and RFC 3849.

What are caching and TTL?

A DNS cache stores an answer so the same lookup does not always require contacting authoritative servers again. TTL, or time to live, specifies the normal cache lifetime of a record, in seconds.

A TTL of 3600 means one hour. A cache receiving the record starts with that lifetime and counts down. Different resolvers can obtain the record at different times. Cloudflare’s TTL documentation explains how this affects when changes become visible.

Lowering the TTL at the authoritative server does not retroactively shorten the lifetime of answers already cached with an older TTL. Plan ahead when changing an address, and treat TTL as a caching control rather than a guaranteed global switchover time.

Example: a website moves to a new IP address

Imagine the team behind app.example.net moving its IPv4 endpoint:

Two visitors can therefore reach different endpoints without either typing the wrong name. The authoritative change happened once; cached copies are being refreshed on different schedules.

For this move, the team should prepare and test the new endpoint first, allow for existing cached answers, and observe traffic before retiring the old endpoint. Existing connections and application behavior also matter, so a successful lookup alone is not a complete migration test.

How do you distinguish DNS trouble from website trouble?

Start with the exact hostname and record type. Then work through these checks:

1. Inspect the answer. Use a DNS lookup tool to see which addresses are returned, which resolver answered, and the remaining TTL.
2. Compare with the published configuration. Confirm the authoritative records contain the intended values and that you edited the provider actually serving the zone.
3. Check both address families. A correct A record can coexist with a broken AAAA endpoint. Test the intended service over each supported protocol.
4. Test the application. Check the hostname, TLS certificate, and expected response. Entering a bare IP in a browser is not equivalent when hosting depends on the requested name.
5. Identify the scope. A failure limited to a workplace or VPN may involve private DNS or a different resolver configuration.

Changing resolvers can help investigate differing answers. It does not repair an incorrect authoritative record, a stopped application, or a blocked network path.

How does DNS relate to BYOIP?

Bring Your Own IP can preserve an address during a supported infrastructure move. If the relevant public endpoint stays the same, its address record may not need to change.

Routing and service readiness still need verification. Publishing an IP in DNS does not establish ownership, routing authorization, or global reachability. Our IP address guide explains the address’s role in delivering traffic.

FAQ

Related resources