ComputeSphereLearn
Console
Learning paths / Cloud foundations / DNS

From a name to an address

Reading · 5 min · Module 5, lesson 1 of 421 min left in this module

Module 5 · DNSLesson 1 of 4

Goal: Trace how a name like app.example.com becomes an IP address, and say who answers at each step.

3:31 · captions and chapters · narrated with an AI-generated voice
Transcript

Narration uses an AI-generated voice.

[00:00] Where we're going

By the end of this video, you'll be able to trace how a name like app dot example dot com becomes an address. And you'll know who answers at each step along the way.

[00:11] Names and addresses

Computers connect to IP addresses. But people type names. DNS turns one into the other. Here's the part that surprises people. No single server knows every name. Instead, a resolver asks a chain of servers. Each one points to the next.

[00:29] The resolver

Let's follow one lookup. You type app dot example dot com into your browser. Your device doesn't go looking itself. It asks a resolver. That's usually run by your network, or your internet provider. Or it's a public one you've chosen. Either way, the resolver does the walking for you.

[00:51] Root and .com

First stop, a root server. It doesn't know the address. It knows who runs each top-level domain, like dot com. So it answers: ask the dot com servers. Next, the dot com servers. They don't know it either. They know which nameservers example dot com uses. So they say: ask those.

[01:13] The answer

Last stop, example dot com's own nameservers. These are called authoritative. They hold the domain's records. They're the only ones that know the answer for certain. So they reply with a record. A name, a type, and a value. Here, the value is the address. The resolver hands that address to your browser. DNS is done, and the browser can connect. So remember: each server only knows the next place to ask. The resolver does the walking.

[01:47] Why it's fast anyway

Four round trips for every page would be slow. It rarely happens. Answers are cached at every level. Your browser, your operating system, and the resolver all keep recent answers. The resolver almost always knows where dot com is already. And popular names are answered straight from its memory.

[02:10] Time to live

So how long can an answer be reused? That's set by its TTL, the time to live. Our record came back with a TTL of three hundred seconds. That's five minutes. Until it runs out, the resolver answers from its cache. After that, it asks again. That caching is also why a DNS change doesn't show up everywhere at once.

[02:33] On ComputeSphere

On ComputeSphere, every web service gets a name under computesphere dot app as soon as it's deployed. It resolves with nothing for you to set up. Pointing your own domain at it comes a little later in this module.

[02:48] Recap

So, a quick recap. Your browser asks a resolver, and the resolver does the walking. The root points to dot com. Dot com points to the domain's own nameservers. Those authoritative nameservers hold the record. And the answer is cached for as long as its TTL allows.

Here's a question to check yourself. Which server holds the actual record for app dot example dot com? Its own nameservers. The root and dot com only point the way. Next, you'll meet the record types you'll use. I'll see you in the next lesson.

DNS at a glance

Resolver
Does the lookup for you, and caches answers.
Nameserver
Holds a domain's records.
Record
One fact: a name, a type, a value.
TTL
How long an answer may be reused.
A resolver walks from the root to a domain's nameservers, reads a record, and remembers it for its TTL.

Key idea

Computers connect to IP addresses, but people type names. DNS turns one into the other. No single server knows every name: a resolver asks a chain of servers, each pointing to the next, until it reaches the one that holds the answer.

Step through a lookup for app.example.com:

From a name to an address

Browser
Resolver
Root
.com
example.com
1Where is app.example.com?
  1. 1Browser Resolver Where is app.example.com?

Step 1 of 6

Your device asks a resolver, usually run by your network or a public service. If the resolver answered this recently, it replies from its cache and the lookup ends here.

Each server only knows the next place to ask. The resolver does the walking, then remembers the answer for as long as the record's TTL allows.

The cast

  • Your device doesn't do the walking. It asks a resolver, usually run by your network or internet provider, or a public one you've chosen.
  • Root servers know who runs each top-level domain, like .com or .org.
  • Top-level domain servers know which nameservers each domain uses.
  • A domain's own nameservers, called authoritative, hold its records. They're the only ones that know the answer for certain.

Why it's fast anyway

Four round trips for every page would be slow. It rarely happens, because answers are cached at every level: your browser, your operating system and the resolver all keep recent answers. The resolver almost always knows where .com is already, and popular names are answered straight from its memory.

That caching is also why DNS changes don't show up everywhere at once. Lesson 1.5.3 covers how long answers are kept.

What you get back

The answer is a record: the name, its type, and a value. For a website that's usually an address, like 203.0.113.10. The next lesson covers the record types you'll use.

Once the browser has the address, DNS is done and the browser connects to it. The name still travels inside the request, which is how one server can host many sites (lesson 1.6.1).

Where your computer looks first

Before asking a resolver, your computer checks its hosts file (/etc/hosts on macOS and Linux, C:\Windows\System32\drivers\etc\hosts on Windows). A line there overrides DNS for that machine only. localhost never needs DNS either: your own computer answers it.

Check yourself

Which server holds the actual record for app.example.com?