DNS Deep Dive: From Domain Name to Server

Concept

DNS (Domain Name System) is the internet's phone book. It is a system that turns a name into an IP address. Computers find each other with IP addresses like 52.66.12.9. People cannot remember so many numbers. So you type yourapp.com, and DNS looks up the right IP address for you each time you visit.

Why this matters

Route 53 is the AWS DNS service. It is the last piece that connects your finished setup to a domain name people can type. DNS also helps a SaaS builder with subdomains. A subdomain is a name added in front of your domain. In a multi-tenant product (many customers share one app), each customer can get their own name, such as acme.yourapp.com or rathod-electricals.yourapp.com. One DNS record can do this. You will see it later in this lesson.

Architecture — how DNS resolution works

This chain runs the first time someone looks up your domain. After that, the answer is cached (saved for a while). The TTL setting, explained below, decides how long. So repeat visits skip most of the chain. The resolver in the chain is the server (often run by your internet provider) that does the lookup for you.

DNS record types explained

Why TTL matters practically

TTL (Time To Live) is the number of seconds a resolver may keep an answer before it asks again. Say you set TTL to 300 seconds and then change your server's IP. Most of the internet catches up within 5 minutes. Many domain providers use a default of 3600 seconds (1 hour) or more. With that, some visitors keep going to the old IP for up to an hour.

Real example — setting up a domain on Route 53

1. Buy the domain

   Buy it through Route 53, or through GoDaddy or Namecheap (often cheaper). A registrar is a company that sells domain names. After you buy, both ways work the same.

2. Create a Hosted Zone in Route 53

   A hosted zone is Route 53's container for all the DNS records of one domain. A, CNAME, MX and all other records live inside one hosted zone.

3. Point your domain's nameservers to Route 53

   If you bought the domain elsewhere, change the nameservers at your registrar to the four nameservers that Route 53 gives you. This step links “who sold you the name” to “who decides where the name points.”

4. Add an A record

   yourapp.com → 52.66.12.9

   This points your bare domain (the name with nothing in front, like yourapp.com) to your EC2's public IP. Later it will point to your load balancer. (For a load balancer, Route 53 uses an “alias” A record, because a CNAME is not allowed on the bare domain.)

5. Add a CNAME for www

   www.yourapp.com → yourapp.com

   Now both the bare domain and the www version reach the same place.

The subdomain trick for multi-tenant SaaS

This matters most for a multi-tenant product. One DNS record can serve any number of customer subdomains, with no extra DNS work for each new customer.

Type:  A
Name:  *.yourapp.com   (the * is a wildcard)
Value: 52.66.12.9

Now acme.yourapp.com, rathod-electricals.yourapp.com, and any other subdomain all go to the same server. (The wildcard does not cover the bare yourapp.com. That needs its own record.) Your Next.js app reads the subdomain from the incoming request (req.headers.host, the Host header that holds the address the user typed) and decides which tenant's data to load. For HTTPS you will also need a certificate that covers *.yourapp.com.

Looking it up yourself

You can ask DNS questions from any laptop with dig, a tool that looks up DNS records. Three lookups cover most cases: “what IP does this name point to?”, “show me every step of the chain”, and “ask Google's resolver directly, not my local one”. You can also ask for one record type, such as NS, MX or TXT.

Creating a record in Route 53

In Route 53 you create a record by giving it a name, picking a type (A, CNAME and so on), setting a TTL and giving the value. Every DNS provider uses these same four fields. The console is fine for this. Lesson 13 does it properly for production.

Why “propagation takes 24–48 hours” is mostly a myth

People often say DNS takes 24 to 48 hours to propagate (spread across the internet). This is mostly old advice from the days of high default TTL values. The authoritative answer (the one on Route 53's own servers) is usually updated everywhere in Route 53 within about 60 seconds after you save it.

Practice task before Lesson 4

You do not need to own a domain. Every command below only reads data and works on any public domain. Use a site you know. Then try your own domain if you have one.

dig github.com +short          # the IP it resolves to
dig github.com +trace          # root → .com → GitHub's nameservers → answer
dig github.com                 # run twice: the TTL in the ANSWER counts down

Then answer these in your own words:

1. In the +trace output, which server answered the final question, and what record type did it return?
2. You will move your app to a new EC2 tomorrow at 10am. What do you change today? Why does the order matter?
3. Explain the difference between an A record and a CNAME. Why can you not use a CNAME for the bare domain yourapp.com? (Hint: the bare domain, called the zone apex, must also hold NS and SOA records, and a CNAME cannot sit beside other records.)
4. Your customer acme signs up. What DNS work do you need for acme.yourapp.com to work? What must your Next.js app do?

Conclusion

DNS is a phone book with a cache in front of it. The real (authoritative) answer lives in one place. For you, that is a Route 53 hosted zone. Resolvers around the world keep a copy for as long as the TTL allows.

• Resolution chain: browser → resolver → root → TLD → authoritative (Route 53) → IP. It runs once per TTL period. After that, the answer comes from the cache.
• Records you'll actually use: A for the bare domain → IP, CNAME for www → bare domain, NS to hand control to Route 53, TXT for verification.
• TTL is your cutover dial: lower it to 300 a day before a change, make the change, then raise it again. “24–48 hours” is old advice, not a rule.
• One wildcard record (*.yourapp.com) serves every customer subdomain. Adding a new customer is then done in your app, using the Host header, not in DNS.

In Lesson 2 you learned how a request reaches an IP and a port. Now you know how a name becomes that IP. Next, we lock the door: HTTPS and TLS.

End of Lesson 3. Next: Lesson 4 — HTTPS, SSL and TLS.