Everyone knows what DNS is, but as I dug into the actual DNS journey in detail, I found a lot of interesting information, so I put together a quick summary.
- Overview
As everyone knows, DNS stands for Domain Name System, and it refers to the system that converts domain names (usually websites) into IP addresses. The lookup order for resolving a domain name is usually known as follows.
1. Domains registered in /etc/hosts
2. Local DNS cache
3. Request to the configured DNS server
It varies by operating system, but it is usually referred to as the hosts file. The mappings defined here are checked first and returned with the highest priority. In this file, you can add entries in the form of IP and domain pairs like the example below. In practice, the hosts file is sometimes modified when doing integration tests on an internal network. (For example, so authentication or payment traffic goes to a test server.)
// /etc/hosts
132.203.40.88 auth.frogred8.io
132.203.40.89 pay.frogred8.io
- DNS request order
In fact, however, you can change the lookup order for DNS requests, and that setting is in the /etc/nsswitch.conf file. The nsswitch system stands for Name Service Switch, and it provides a configuration file that lists the items to look up sequentially for each service, not just DNS.
// /etc/nsswitch.conf
passwd: files systemd
group: files systemd
hosts: files dns
networks: files
...
If I want to ignore the /etc/hosts settings and always request the DNS server, I can leave only dns in the hosts entry. Then, as intended, it will skip the hosts file and request the DNS server first. The locally stored DNS cache is usually set based on the expiration time in the DNS result, but in some cases it may be set to the DNS cache system's default value. (ex. 3600 seconds)
- DNS server settings
You can check the DNS servers used for external requests in the /etc/resolv.conf file.
// /etc/resolv.conf
...
# This file is automatically generated.
nameserver 168.126.63.1
nameserver 168.126.63.2
Usually, even if you have not configured anything on a personal computer, DNS servers are set like this. The reason is that when the computer connects to the Internet, it receives a dynamic IP address through DHCP (Dynamic Host Configuration Protocol) from the ISP (Internet Service Provider), and at that time it also receives the DNS server addresses specified by that ISP. The resolv.conf file is then automatically generated using those values.
If resolv.conf contains a message saying it was automatically generated, try modifying this file and then reconnecting to the Internet. You will see that your changes disappear and the file is generated again with the same values as before. My Internet connection uses KT's network, so the DNS servers start with 168, but SK or LG may show different addresses.
- Domestic vs. Google DNS speed test
There used to be a lot of talk that changing the DNS server setting to 8.8.8.8 would make the Internet faster, but in reality it is more likely to be slower. Since Google DNS is an overseas DNS server, requests will likely go out through an international network rather than a domestic one, which would give it relatively higher latency.
I tested whether theory matched reality. First, KT uses a 168.~ address, and Google uses an 8.~ address.
❯ ping -c 2 168.126.63.1
64 bytes from 168.126.63.1: icmp_seq=0 ttl=58 time=14.721 ms
64 bytes from 168.126.63.1: icmp_seq=1 ttl=58 time=13.302 ms
❯ ping -c 2 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=0 ttl=57 time=44.794 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=46.336 ms
// ping test result
kt: 14ms
google: 45ms
Ping is just a response to an ICMP request and does not represent the DNS server itself, so I tested once more with dig to make the request go through the DNS server.
❯ dig www.google.com
;; Query time: 17 msec
;; Query time: 19 msec
❯ dig www.google.com
;; Query time: 44 msec
;; Query time: 41 msec
// dig test
kt: 11ms
google: 43ms
These are average values from multiple tests after changing only the DNS server, without using a local DNS cache or anything like that. As expected, domestic DNS was faster than Google DNS. Going one step further, I wondered whether the DNS server from the currently connected ISP would be even faster (for example, KT DNS being fastest on a KT network, SK DNS being fastest on an SK network, and so on), but when I tested KT and SK DNS alternately on a KT network, there was no meaningful difference, so I could not prove it.
Personally, I had only been guessing that the reason Google DNS was rumored to be faster in the early 2000s was that a certain router on the domestic network was poor, or that domestic DNS servers themselves were too slow. Then, by chance, I saw an article saying that the Korea Internet & Security Agency was operating an F-root server mirror.
Looking into this in detail, the government requested a new root server assignment in 2003, but the request was rejected because the 512-byte DNS packet limit meant root servers could not be increased beyond the current 13.
So, as an alternative, they received approval to operate an F-root server mirror, introduced it in 2004, and it seems they have been operating it ever since.
Now other root server groups are also operating in Korea, so I think it is fair to say that Internet stability has improved. It made me think this may also have been one reason domestic DNS was slow in the early 2000s, and it feels interesting to look back on a time when even queries to root servers were slow.
- DNS traversal
The DNS server we usually configure is actually a server called a recursive resolver (RR from here on, since it will come up often below). It sends the requested domain to a root server, then uses the information received there to query a TLD server, and then an authoritative DNS server in sequence, finally returning the result.
User -> RR -> root server -> RR -> TLD server -> RR -> authoritative DNS server -> RR -> user
A single DNS request that we send so easily actually causes the RR to wait for several requests and responses. Of course, it does not do this every time. Since the RR first checks information it previously cached, it is usually very fast on average, but for a domain that is not in the cache, the response may be slower than usual.
Now let's look in detail at the sequential behavior that happens in the RR and the characteristics of each server.
- Root server
The RR first needs to get the list of root servers, and this list is usually updated through the RR configuration file. The root server list looks like this.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS b.root-servers.net.
a.root-servers.net. 518400 IN A 198.41.0.4
a.root-servers.net. 518400 IN AAAA 2001:503:ba3e:0:0:0:2:30
b.root-servers.net. 518400 IN A 170.247.170.2
b.root-servers.net. 518400 IN AAAA 2801:1b8:10:0:0:0:0:b
...
A total of 13 root servers, from A through M, are registered, listing information such as NS (Name Server), A records (IPv4), and AAAA records (IPv6). These 13 root servers have identical information, so even if one server goes down, the others compensate for it. In reality, that will almost never happen. Even a single server group is replicated across dozens of locations around the world, so the probability of all of them going down at the same time is close to nonexistent.
The expiration time for root servers is 518400 seconds (=6 days), and most TLD servers were set to 172800 seconds (=2 days).
If you look at the root server map in the link below, you can find which server groups exist in IDCs in specific regions. It is quite well made, so it is interesting to go take a look.
https://root-servers.org
- TLD (Top-Level Domain) server
If you request the current domain from these root servers, you can receive a list of TLD servers for that domain. There are two types of TLD servers you receive this way: gTLD (generic Top-Level Domain) and ccTLD (country code Top-Level Domain).
gTLD: General-purpose top-level domains (.com, net, org...)
ccTLD: Country-code top-level domains (.kr, jp, uk...)
The reason these types are separated is that gTLDs are operated by IANA (Internet Assigned Numbers Authority), while ccTLDs are operated by individual countries. Of course, IANA does handle overall TLD management/supervision and approval of ccTLD management organizations.
Subdomains under ccTLDs are managed separately by each country. Taking Korea as an example, the ccTLD in use is kr, and subdomains include co.kr and pe.kr, which used to be commonly used for personal homepages. It does not seem especially preferred these days, though..
I also briefly looked through recent news from the Korea Internet & Security Agency. Legislation adding subdomains such as ai.kr and io.kr has passed, and it seems registration will be available after March 2025. One more funny thing I noticed while reading: the sejong.kr subdomain dedicated to Sejong City, which had been approved in the 55th meeting, was canceled in the 56th meeting. The reason was that the sejong.kr domain had already been registered, so they could not create it as a subdomain. The person who submitted the agenda without searching first probably got scolded lol
In any case, the codes registered as ccTLDs use two-letter alphabetic country codes. But there are countries where it is ambiguous whether to consider them a country, right? For example, when a government is split in half by a coup, and so on. So rather than judging this independently, ccTLDs use the country codes defined in the ISO-3166 standard. North Korea's country code was there too, and since it is Korea (the Democratic People's Republic of), it uses kp.
As an aside, if a country code is easy to remember or can be given meaning, it can unexpectedly become a source of revenue. With the AI boom, the price of domains for the country with the .ai country code (Anguilla, population 16,000) rose, and reportedly it earned 10% of its GDP from domain revenue.
https://n.news.naver.com/article/025/0003349403
Looking at .io as well, it is not a gTLD, but one of the ccTLDs representing the British Indian Ocean Territory.
Aside from these, there is also something called an IDN ccTLD (Internationalized country code TLD), although it is rarely used. It is a way of managing domain names written in characters other than English, but writing something like https://후이즈검색.한국 feels a bit awkward, doesn't it? The domain prices set in Korea were roughly like this.
https://krnic.or.kr/jsp/popup/agencyFeePop.jsp
- Authoritative DNS Server
When you request a domain from a TLD server, it returns a list of DNS servers that contain the actual IP mapping information for the domain you are looking for. Those servers are called authoritative DNS servers, and you can think of them as the servers responsible for domain registration and updates. They are also called registrars (pronounced registrar).
Most domains purchased from domain providers such as GoDaddy, Cloudflare, Gabia, and Whois are connected here, while companies tend to connect them to AWS or to separately built servers.
// Personal domain
❯ dig NS lordz.io
lordz.io. 861 IN NS linda.ns.cloudflare.com.
lordz.io. 861 IN NS clark.ns.cloudflare.com.
clark.ns.cloudflare.com. 85051 IN A 108.162.193.87
clark.ns.cloudflare.com. 85051 IN A 172.64.33.87
...
// Corporate domain
❯ dig NS google.com
google.com. 114424 IN NS ns3.google.com.
google.com. 114424 IN NS ns2.google.com.
...
ns1.google.com. 116338 IN A 216.239.32.10
ns2.google.com. 137282 IN A 216.239.34.10
❯ dig NS naver.com
naver.com. 43372 IN NS ns2.naver.com.
naver.com. 43372 IN NS ns1.naver.com.
...
ns1.naver.com. 12796 IN A 125.209.248.6
ns2.naver.com. 12850 IN A 125.209.249.6
- The end of the DNS query journey
Through this long process, the RR (recursive resolver, the DNS server we configured) obtains the address of the authoritative DNS server, then queries the IP there and finally gets the IP connected to the domain. When the RR returns this IP to the requesting user, the user finally receives the response to the DNS query.
I wrote this once above, but if you have followed this far, this flow should now make sense.
User -> RR -> root server -> RR -> TLD server -> RR -> authoritative DNS server -> RR -> user
- Propagation of DNS changes
To add one more aside, the IP connected to a domain can be changed at any time, but not all DNS servers change immediately, and it usually takes several hours for the change to propagate properly.
That is because DNS servers were originally built based on a distributed database system, and among the CAP properties of databases (consistency, availability, partition tolerance), DNS satisfies AP by giving up consistency.
So even if there is a change to a DNS value, DNS does not guarantee in the first place that the data on every DNS server will be updated all at once and immediately. Because of that, most DNS servers use caching.
They will fetch the new value only after that cache time expires, so DNS changes tend to take time to apply. This characteristic also forms the basis for actively using DNS caches locally or on servers.
- Conclusion
1) The DNS lookup order can be changed in the nsswitch.conf file.
2) A DNS query passes through root, TLD, and authoritative servers to return the domain's IP.
3) There are two types of TLDs, gTLDs (.com) and ccTLDs (.kr), and their managing bodies are split between IANA and individual countries.
4) Good country codes (.ai, .io) can unexpectedly become a source of revenue.
Previous post: https://frogred8.github.io/
#frogred8 #network #dns
