The Great DNS Trail

DNS or domain naming system is commonly utilized to allow websites the ability to be represented by a specific name. We'll be looking at the underlying parts of DNS in some detail to see much of what is normally abstracted away.

IP Addresses

In order to understand DNS, it's important to first understand what DNS is mapped to. A domain name by itself can't do anything which is why DNS exists in the first place. The actual means of accessing another system is done through IP addresses. As an example if I ping the dev.to site the address 151.101.66.217 comes back.

Now on the low level IP addresses are a sequences of bytes and the .s are mostly for visual purposes acting much like a comma in a sequences of numbers. If you were to use 32 bit binary the address 151.101.66.217 would come back as 10010111011001010100001011011001. Unlike domain names IP addresses are very compact and streamlined for quick network transport.

IP addresses are also bound by a numbering authority ICANN (Internet Corporation for Assigned Names and Numbers). This authority handles registration of specific IP ranges to corporations. 151.101.66.217 is part of the IP range 151.101.0.0 - 151.101.255.255 which according to ICANN's lookup belongs to the CDN (Content Distribution Network) provider Fastly. Note that there are special ranges of IPs known as private IPs. These sit behind routers and firewalls providing local network functionality.

Hosts File

Now before even touching DNS there's a quick check against what's known as the hosts file. On most systems this lies at /etc/hosts and windows it can be found at C:\Windows\System32\drivers\etc\hosts. The file looks something like this:

# localhost name resolution is handled within DNS itself.
#   127.0.0.1       localhost
#   ::1             localhost
192.168.1.91 rpi
192.168.1.93 rpi2
# End of section

This one is a mapping of my raspberry pi devices to their respective IP addresses on my local network. Instead of typing the IP address I can simply type rpi when SSH-ing in. Unlike actual domain names host file entries are more free form. Some advanced uses have domain names mapped to 0.0.0.0 providing a rudimentary domain blacklist.

DNS Cache

There's another entry point before DNS infrastructure is actually involved and that is DNS cache. Operating systems will vary in how they handle cache. Linux in most cases doesn't have DNS caching on by default due to its need to support a number of different scenarios. On Windows the cache may look something like this:

www.google-analytics.com
----------------------------------------
Record Name . . . . . : www.google-analytics.com
Record Type . . . . . : 1
Time To Live  . . . . : 9
Data Length . . . . . : 4
Section . . . . . . . : Answer
A (Host) Record . . . : 142.250.178.14

Browsers can also have their own built in DNS due to the large number of requests they typically make. Here's an example of my Firefox entry for dev.to:

From there caching works up several levels including routers, ISP/public servers, all the way up the chain.

Domain Name Authorities

Domain names have a hierarchical system of authorities starting at what are known as the root servers all the way down to the authoritative server that owns the domain name. This server is generally the registrar used to purchase the domain name.

IANA (Internet Assigned Numbers Authority) is a part of an ICANN affiliate which handles root DNS servers. These servers are the absolute authority on what are known as the top level domains. They keep a listing along with the entity who is authorized to represent the top level domain. For example, VeriSign Global Registry Service is the entity which is authorized to register domain names for the .com top level domain:

.com    generic     VeriSign Global Registry Services

The system also distinguishes between such generic top level domains and ones designated for countries:

.us     country-code    Registry Services, LLC

Most companies will go through the generic top level domain program if they themselves wish to act as an authority. There's also another process for top level domains representing countries. For those who wish to act as a domain registrar instead of a top level authority the accredited registrar program is available. Given how critical DNS infrastructure is all of these applications are strictly vetted so it's certainly a large investment.

The DNS Flow

So assuming the answer to a query of what something like dev.to is mainly starts at the locally designated DNS servers. This will most likely be your ISP but it's not uncommon to utilize public DNS servers such as Quad9, Google, and Cloud Flare. Public DNS servers were popularized after "certain ISPs" decided that showing ad littered pages for unknown domains was a good idea.

So let's say I'm looking for dev.to. Assuming it isn't cached my designated DNS server will reach out to one of the root DNS servers (h.root-servers.net for example) to get information on .to's ownership. .to is country code tld managed by the Kingdom of Tonga. It's not uncommon for country based TLDs to be used for vanity purposes such as .ai. The .to authority (ns01.trs-dns.com as an example) will then delegate the request to the authoritative nameservers which in this case are owned by Cloud Flare who would be considered to be the registrar that dev.to worked with to obtain (or transfer) the domain (josh.ns.cloudflare.com for example). This will then provide a number of responses:

;; ANSWER SECTION:
│dev.to.                 300     IN      A       151.101.194.217
│dev.to.                 300     IN      A       151.101.130.217
│dev.to.                 300     IN      A       151.101.66.217
│dev.to.                 300     IN      A       151.101.2.217

Any of these addresses will allow access to the dev.to site. Sometimes the entry comes back as a CNAME which is essentially an alias to another domain. In this case that will form a new request for the user's designated DNS server. All of these responses will be cached appropriately to ensure timely return to the client.

It's important to note that the user's DNS query to the ISP/Public DNS server is what's known as a recursive query as the server is handling the entire chain for you. The process of the ISP/Public DNS server going root server -> tld server -> authoritative server is known as incremental lookup. Note that if you attempt to query a root name server (recursive by default) it will simply let you know it doesn't support recursive calls and return the incremental version instead.

DNS Packets

DNS utilizes UDP (user datagram protocol) instead of the traditional TCP/IP used by many applications. The UDP protocol is extremely simple with fields for source port, destination port, length of packet, checksum, and data. This avoids the overhead of many of TCP's features which means packets would take longer to return. UDP is generally wrapped around one of the IP protocols to indicate the source and destination IP. DNS packet data is built around messages as defined in RFC 1035. By using the dig DNS tool we can see some of what that looks like:

$ dig dev.to
│
│; <<>> DiG 9.20.21-1~deb13u1-Debian <<>> dev.to
│;; global options: +cmd
│;; Got answer:
│;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41311
│;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
│
│;; OPT PSEUDOSECTION:
│; EDNS: version: 0, flags:; udp: 4096
│;; QUESTION SECTION:
│;dev.to.                                IN      A
│
│;; ANSWER SECTION:
│dev.to.                 261     IN      A       151.101.194.217
│dev.to.                 261     IN      A       151.101.66.217
│dev.to.                 261     IN      A       151.101.2.217
│dev.to.                 261     IN      A       151.101.130.217
│
│;; Query time: 0 msec
│;; SERVER: 192.168.1.254#53(192.168.1.254) (UDP)
│;; WHEN: Sun Apr 26 20:17:30 EDT 2026
│;; MSG SIZE  rcvd: 99

Here I'm doing a recursive query directed at my router (which is pointed to Google's DNS servers). The router has indicated it's a server that is capable of doing recursive queries. The answer section is the resulting IPs behind dev.to. Now let's compare this to another query:

$dig @ns01.trs-dns.com dev.to
│
│; <<>> DiG 9.20.21-1~deb13u1-Debian <<>> @ns01.trs-dns.com dev.to
│; (2 servers found)
│;; global options: +cmd
│;; Got answer:
│;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61237
│;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
│;; WARNING: recursion requested but not available
│
│;; OPT PSEUDOSECTION:
│; EDNS: version: 0, flags:; udp: 1232
│;; QUESTION SECTION:
│;dev.to.                                IN      A
│
│;; AUTHORITY SECTION:
│dev.to.                 900     IN      NS      josh.ns.cloudflare.com.
│dev.to.                 900     IN      NS      jill.ns.cloudflare.com.
│
│;; Query time: 91 msec
│;; SERVER: 2620:57:4001::1#53(ns01.trs-dns.com) (UDP)
│;; WHEN: Sun Apr 26 20:03:51 EDT 2026
│;; MSG SIZE  rcvd: 118

In this case dig is letting me know that the server doesn't support recursive queries and I'm given an incremental result instead. Because I'm not given the actual records for the domain in question the "AUTHORITY" section is populated instead pointing me to the authoritative nameservers. When the actual DNS records for the domain name comes back the "ANSWER" records are populated instead.

DNS Records

There are a lot of DNS record types. Which of these will be acted upon will depend on the client accessing the information. A good majority of the time the important records you'll be working with are:

A: IPv4 address backing the domain
AAA: IPv6 address backing the domain
CNAME: points to another host to do DNS lookup for
MX: Email server backing the domain's email services
TXT: Freeform field used for a number of purposes
NS: The authoritative name servers for the domain

A and AA records are the most vital in obtaining the IP address to map to a domain name in a request.

DNSSEC

Being a simple plain text protocol DNS has security issues. If a malicious actor was able to spoof a DNS response that response would be cached among the global DNS infrastructure. This is commonly known as DNS Spoofing or DNS Cache Poisoning.

In an attempt to deal with this DNSSEC was proposed. The system works off of public key cryptography which is the same technology that powers SSL certs. DNS servers use cryptographic signatures to sign their data which are validated by their parent authority (.to's owner in the case of dev.to). The exception being the root DNS servers who have no parent authority. It's why the private keys for the root servers are very well guarded.

It's important to note that DNSSEC support is not mandatory as of right now. Though it's of course recommended to utilize it whenever possible.

Internal DNS

What I've described until now is for the public facing side. Companies are also able to utilize DNS for their own internal domain name resolution. This is done by pointing company equipment at an internal DNS server (or updating network configs for VPN users). The internal server will resolve for internal hosts and generally acts as a proxy if the domain is global such as google.com. Such servers are often hosted with software such as BIND9 on *NIX based systems and the DNS components that are part of Windows Server installs.

Wrap Up

Thanks for joining me in this very long look at the workings of DNS. I hope this proves to be an enlightening experience for those looking to deepen their knowledge on how systems work. It might be useful if you need to debug DNS issues as well!

推荐订阅源

DEV Community