What is DNS and why does it matter for visiting a website?

DNS (Domain Name System) is the system that turns a domain name such as www.superdevacademy.com into the IP address computers actually use to reach each other. It matters because it lets people remember a name instead of a number, and it also tells mail servers where to deliver a domain's email through MX records. If DNS cannot answer, the browser cannot find the website's server at all.

What is a DNS server?

A DNS server is a machine that answers which IP address a domain name points to, and it plays one of two main roles. A recursive resolver, such as Google's 8.8.8.8, asks on behalf of your device. An authoritative name server, such as fish.ns.cloudflare.com for superdevacademy.com, holds the domain's real records. The resolver works its way from a root server to a TLD server and finally to the authoritative name server.

What are the DNS settings on my phone or Wi-Fi?

The DNS setting on a phone or Wi-Fi network is the address of the resolver your device asks whenever it needs to turn a website name into an IP address. Devices normally receive it automatically from the router or internet provider, but you can set it yourself, for example to Google's 8.8.8.8 and 8.8.4.4 or Cloudflare's 1.1.1.1 and 1.0.0.1. Both providers publish two addresses so one can back up the other.

What does changing your DNS actually do?

Changing your DNS means changing the resolver your device uses to look up IP addresses, for example from your internet provider's resolver to Cloudflare's 1.1.1.1 or Google's 8.8.8.8. What changes is who finds the answer for you, not how fast files download. Whether lookups feel faster depends on your own network, so the most reliable check is to measure it yourself with dig, which prints a Query time line in milliseconds.

What is a DNS record and what types are there?

A DNS record is a single entry in DNS that says what a domain name is connected to. The five types beginners meet most are A for an IPv4 address, AAAA for IPv6, CNAME for an alias to another name, MX for the mail server, and TXT for text such as a verification code. Every record has a TTL in seconds, and you can inspect any type with a command like dig example.com MX.

What Is DNS and How It Works: From Domain Name to IP Address

One question our team hears again and again goes like this: "I bought the domain, I set up DNS, so why does the browser still show the old site?" Our usual answer is "nothing is broken, the old answer just hasn't expired yet." That tends to raise more questions than it settles, because the real question underneath is what DNS actually is and what happens between typing a name and seeing a page.

In this article, Superdev Academy walks through every step that happens after you type www.superdevacademy.com and press Enter. We ran the real commands, we show the real output, and you can repeat every one of them on your own machine.

Why your computer can't find a website by its name alone

Computers on the internet reach each other using numbers called IP addresses. People, on the other hand, remember names like superdevacademy.com far more easily. The system that turns a domain name into an IP address is DNS, the Domain Name System.

Think of an address book. You know your friend's name, but you have to open the book to find where they live. DNS is that book, except it isn't stored in one place. It is spread across the world, and each part of it is looked after by a different owner.

The founding standard for DNS is RFC 1034, which splits the system into three parts: the domain name space with the data attached to each name (resource records), the name servers that hold that data, and the resolvers that go and ask on behalf of your computer. Put simply, there is a book, there are people who keep the pages, and there is someone who runs off to look things up for you.

The four stops a lookup for www.superdevacademy.com makes

When your browser needs an IP address, it does not go around the world asking by itself. It hands the question to a recursive resolver, a middleman that asks on your behalf. That resolver usually belongs to your internet provider, or to Google or Cloudflare if you have set one of theirs. The resolver then works through these stops.

Root server: the top level. It does not know the final answer, but it knows who is responsible for .com.
TLD server: the .com servers do not know our site's IP either, but they know which name servers are responsible for superdevacademy.com.
Authoritative name server: the server that holds the real records for this domain and can answer with the IP.
Back to you: the resolver passes the IP to your browser and keeps a copy for a while in case someone asks again.

According to IANA, the root is configured as 13 named authorities, from a.root-servers.net to m.root-servers.net. That does not mean there are only 13 machines. IANA describes them as a network of hundreds of servers in many countries. You can see who operates each of the 13 on the IANA Root Servers page.

We had a machine walk all four stops for real with dig +trace on 30 September 2026. Trimmed to the lines that matter, it looked like this.

$ dig +trace www.superdevacademy.com
.           3858     IN NS  a.root-servers.net.
...
com.        172800   IN NS  a.gtld-servers.net.
...
superdevacademy.com. 172800 IN NS fish.ns.cloudflare.com.
superdevacademy.com. 172800 IN NS leonard.ns.cloudflare.com.
www.superdevacademy.com. 300 IN A 104.21.3.159
www.superdevacademy.com. 300 IN A 172.67.130.236

Read it from top to bottom. The root points to the .com servers, the .com servers point to Cloudflare's name servers, and fish.ns.cloudflare.com gives the final answer: two IP addresses, 104.21.3.159 and 172.67.130.236. These values are what we got on the day we ran it. If you run it later you may see different ones, and that is normal.

Run dig and nslookup yourself

You do not have to take our word for any of this. Open a terminal and try it. macOS ships with dig, and on Windows you can use nslookup in Command Prompt. If the terminal still feels unfamiliar, our guide to essential Terminal and command line commands is a good place to start.

$ dig www.superdevacademy.com +noall +answer
www.superdevacademy.com. 300 IN A 104.21.3.159
www.superdevacademy.com. 300 IN A 172.67.130.236

$ nslookup www.superdevacademy.com 8.8.8.8
Server:   8.8.8.8
Address:  8.8.8.8#53

Non-authoritative answer:
Name:    www.superdevacademy.com
Address: 104.21.3.159
Name:    www.superdevacademy.com
Address: 172.67.130.236

"Non-authoritative answer" in the nslookup output does not mean the answer is wrong. It only says the answer came from a resolver (8.8.8.8 here) rather than straight from the domain's authoritative name server. The number 300 in the dig output is the TTL, and it is the key to the "I changed it but nothing happened" problem we will get to in two sections.

The five record types beginners meet most

The DNS address book holds more than IP addresses. Its entries come in types called records, and each type answers a different question. Every example below comes from a real dig run.

A: which IPv4 address a name points to. RFC 1035 notes that a host with several addresses has several A records, which is exactly why superdevacademy.com came back with two.
AAAA: the same idea for IPv6, defined in RFC 3596. superdevacademy.com answered with 2606:4700:3032::6815:39f, among others.
CNAME: says a name is an alias for another name. www.github.com is a CNAME for github.com, so the resolver then goes on to look up the A record of github.com.
MX: tells mail servers where to deliver email for the domain. gmail.com has five MX records with preference values from 5 to 40, and RFC 1035 states that lower values are preferred.
TXT: holds text, often used to prove you own a domain. superdevacademy.com has TXT records starting with google-site-verification for exactly that purpose.

$ dig @1.1.1.1 www.github.com +noall +answer
www.github.com.  1395 IN CNAME github.com.
github.com.        60 IN A     20.205.243.166

Notice that superdevacademy.com returned no MX records at all when we checked. That is not an error. Which record types a domain has depends on what its owner uses it for.

TTL: why you changed DNS and the site didn't change

Back to the question from the start. Every record carries a TTL (time to live) measured in seconds. RFC 1035 describes it as how long the record may be cached before the original source should be asked again, and a TTL of zero means the record should not be cached at all.

The A record for www.superdevacademy.com has a TTL of 300 seconds. A resolver that just looked it up can keep using that answer for up to 5 minutes. If the owner switches to a new IP one minute later, anyone using that resolver still gets sent to the old IP until the time runs out. The site is not broken. The old answer simply has not expired.

The slower case is moving name servers. In the dig +trace output above, the .com servers returned the NS records for superdevacademy.com with a TTL of 172800 seconds, which is 48 hours. That is why moving a domain to a new DNS provider usually takes longer to settle than editing a plain A record.

Before you move a site: lower the TTL on the records you plan to change ahead of time, at least as far ahead as the old TTL, so that caches holding the long old value have expired by moving day.

What 8.8.8.8 and 1.1.1.1 are

Both are public DNS resolvers that anyone can use instead of the one their internet provider hands out. According to the Google Public DNS documentation, the IPv4 addresses are 8.8.8.8 and 8.8.4.4, the IPv6 addresses are 2001:4860:4860::8888 and 2001:4860:4860::8844, and Google recommends configuring at least two addresses.

Cloudflare's 1.1.1.1 documentation lists 1.1.1.1 and 1.0.0.1 for IPv4, and 2606:4700:4700::1111 and 2606:4700:4700::1001 for IPv6, with two addresses provided for redundancy.

We asked both 8.8.8.8 and 1.1.1.1 for www.superdevacademy.com and got the same pair of IPs, 104.21.3.159 and 172.67.130.236. That is what should happen, because both end up asking the same authoritative source. As for which one is faster, we are not going to call it. The result depends on your network and where you are, and we have no verifiable measurement to back a claim either way.

DNS, hosting and the domain registrar are three different things

Plenty of beginners mix these three up, and that is understandable, because some companies sell them together in one package. Their jobs are still clearly separate.

Domain registrar: where you register the domain name and renew it every year. It tells the .com registry which name servers your domain uses.
DNS (authoritative name servers): where the actual records live. In our example, that is fish.ns.cloudflare.com and leonard.ns.cloudflare.com.
Hosting: the machine that stores your site's files and code and sends back the page when a browser arrives at that IP. If you want to know what typically runs on that machine, read What is LAMP Stack?

All three can sit with different companies. Register the domain with one, run DNS with another, rent a server from a third, and everything still works. If you want to put a site running on your own laptop onto the internet under a real domain, How to Use Cloudflare Tunnel to Expose Localhost puts what you learned here straight to use.

DNS answers correctly, but the site still won't load

By now it might feel like DNS is the first thing to blame whenever a site does not open. It is a good first check, and it takes one command. But DNS only tells the browser where to go. If dig returns the right IP, the problem has moved to the next step: what the server at that IP sends back.

DNS gives you the address. It does not deliver the page.

The quickest way to tell them apart is to look at what the browser shows. If it says the server could not be found, go back to DNS. If you get an error page with a number such as 404 or 500, DNS has already done its job, and that number came from the server. Our guide to HTTP status codes explains what each one means.

Summary: what DNS is and how it works

DNS is the system that turns domain names into IP addresses. A resolver asks its way down from the root, to the TLD, to the authoritative name server, then remembers the answer for as long as the TTL allows. So when you change DNS and the site does not change, it is usually not a mistake at all. It is an old answer that has not expired yet.

Pick a domain you use every day and run dig +trace on it yourself. Read it line by line: who points to whom, and what the TTL is at each step. Do that once and DNS stops being a black box.

Follow more articles and tips for people starting out as programmers on our channels.

Facebook: Superdev Academy Thailand (https://www.facebook.com/superdev.academy.th)

YouTube: Superdev Academy Channel (https://www.youtube.com/@SuperdevAcademy)

Instagram: @superdevacademy (https://www.instagram.com/superdevacademy/)

TikTok: @superdevacademy (https://www.tiktok.com/@superdevacademy?lang=th-TH)