Front-end/Internet

DNS(Domain Name System)

metamong 2023. 3. 22.

1. What is DNS?

๐Ÿค  The Domain Name System (DNS) is the phonebook of the Internet. Humans access information online through domain names, like nytimes.com or espn.com. Web browsers interact through Internet Protocol (IP) addresses. DNS translates domain names to IP addresses so browsers can load Internet resources.
(When you enter a domain name into your web browser, your computer sends a DNS query to a DNS server, which returns the corresponding IP address. Your computer then uses that IP address to connect to the website or other resource you've requested.)

 

Each device connected to the Internet has a unique IP address which other machines use to find the device. DNS servers eliminate the need for humans to memorize IP addresses such as 192.168.1.1 (in IPv4), or more complex newer alphanumeric IP addresses such as 2400:cb00:2048:1::c629:d7a2 (in IPv6).

 

๐Ÿค  what if you don't know the IP address of the computer you want to connect to? What if you need to access a web server referred to as www.anothercomputer.com? How does your web browser know where on the Internet this computer lives? The answer to all these questions is the Domain Name Service or DNS. The DNS is a distributed database which keeps track of computer's names and their corresponding IP addresses on the Internet. 

2. How does DNS work?

๐Ÿค  The process of DNS resolution involves converting a hostname (such as www.example.com) into a computer-friendly IP address (such as 192.168.1.1). An IP address is given to each device on the Internet, and that address is necessary to find the appropriate Internet device - like a street address is used to find a particular home. When a user wants to load a webpage, a translation must occur between what a user types into their web browser (example.com) and the machine-friendly address necessary to locate the example.com webpage.

 

In order to understand the process behind the DNS resolution, it’s important to learn about the different hardware components a DNS query must pass between. For the web browser, the DNS lookup occurs "behind the scenes" and requires no interaction from the user’s computer apart from the initial request.

 

DNS server

 

๐Ÿค  Many computers connected to the Internet host part of the DNS database and the software that allows others to access it. These computers are known as DNS servers. No DNS server contains the entire database; they only contain a subset of it. If a DNS server does not contain the domain name requested by another computer, the DNS server re-directs the requesting computer to another DNS server.

The Domain Name Service is structured as a hierarchy similar to the IP routing hierarchy. The computer requesting a name resolution will be re-directed 'up' the hierarchy until a DNS server is found that can resolve the domain name in the request. Figure 6 illustrates a portion of the hierarchy. At the top of the tree are the domain roots. Some of the older, more common domains are seen near the top. What is not shown are the multitude of DNS servers around the world which form the rest of the hierarchy.

When an Internet connection is setup (e.g. for a LAN or Dial-Up Networking in Windows), one primary and one or more secondary DNS servers are usually specified as part of the installation. This way, any Internet applications that need domain name resolution will be able to function correctly. For example, when you enter a web address into your web browser, the browser first connects to your primary DNS server. After obtaining the IP address for the domain name you entered, the browser then connects to the target computer and requests the web page you wanted.

DNS was created to be an open public communication protocol, because of its openness, DNS is susceptible to cyber attacks - ex) DNS spoofing - hacks and changes it to a wrong IP address - using a fake website problem

3. 4 DNS servers

โ‘  DNS recursor: The recursor can be thought of as a librarian who is asked to go find a particular book somewhere in a library. The DNS recursor is a server designed to receive queries from client machines through applications such as web browsers. Typically the recursor is then responsible for making additional requests in order to satisfy the client’s DNS query.

 

โ‘ก Root namesever: The root server is the first step in translating (resolving) human readable host names into IP addresses. It can be thought of like an index in a library that points to different racks of books - typically it serves as a reference to other more specific locations.

 

โ‘ข TLD nameserver: The top level domain server (TLD) can be thought of as a specific rack of books in a library. This nameserver is the next step in the search for a specific IP address, and it hosts the last portion of a hostname (In example.com, the TLD server is “com”).

 

โ‘ฃ Authoritative nameserver(domain's nameserver): This final nameserver can be thought of as a dictionary on a rack of books, in which a specific name can be translated into its definition. The authoritative nameserver is the last stop in the nameserver query. If the authoritative name server has access to the requested record, it will return the IP address for the requested hostname back to the DNS Recursor (the librarian) that made the initial request.

 

โ‘  Authoritative DNS server

 

Put simply, an authoritative DNS server is a server that actually holds, and is responsible for, DNS resource records. This is the server at the bottom of the DNS lookup chain that will respond with the queried resource record, ultimately allowing the web browser making the request to reach the IP address needed to access a website or other web resources. An authoritative nameserver can satisfy queries from its own data without needing to query another source, as it is the final source of truth for certain DNS records.

+ if) It’s worth mentioning that in instances where the query is for a subdomain such as foo.example.com or blog.cloudflare.com, an additional nameserver will be added to the sequence after the authoritative nameserver, which is responsible for storing the subdomain’s CNAME record.

There is a key difference between many DNS services and the one that Cloudflare provides. Different DNS recursive resolvers such as Google DNS, OpenDNS, and providers like Comcast all maintain data center installations of DNS recursive resolvers. These resolvers allow for quick and easy queries through optimized clusters of DNS-optimized computer systems, but they are fundamentally different than the nameservers hosted by Cloudflare.

 

Cloudflare maintains infrastructure-level nameservers that are integral to the functioning of the Internet. One key example is the f-root server network which Cloudflare is partially responsible for hosting. The F-root is one of the root level DNS nameserver infrastructure components responsible for the billions of Internet requests per day. Our Anycast network puts us in a unique position to handle large volumes of DNS traffic without service interruption.

Steps in DNS lookup

For most situations, DNS is concerned with a domain name being translated into the appropriate IP address. To learn how this process works, it helps to follow the path of a DNS lookup as it travels from a web browser, through the DNS lookup process, and back again. Let's take a look at the steps.

 

Note: Often DNS lookup information will be cached either locally inside the querying computer or remotely in the DNS infrastructure. There are typically 8 steps in a DNS lookup. When DNS information is cached, steps are skipped from the DNS lookup process which makes it quicker. The example below outlines all 8 steps when nothing is cached.

 

โ‘  A user types ‘example.com’ into a web browser and the query travels into the Internet and is received by a DNS recursive resolver.

โ‘ก The resolver then queries a DNS root nameserver (.).

โ‘ข The root server then responds to the resolver with the address of a Top Level Domain (TLD) DNS server (such as .com or .net), which stores the information for its domains. When searching for example.com, our request is pointed toward the .com TLD.

โ‘ฃ The resolver then makes a request to the .com TLD.

โ‘ค The TLD server then responds with the IP address of the domain’s nameserver, example.com.

โ‘ฅ Lastly, the recursive resolver sends a query to the domain’s nameserver.

โ‘ฆ The IP address for example.com is then returned to the resolver from the nameserver.

โ‘ง The DNS resolver then responds to the web browser with the IP address of the domain requested initially.

 

Once the 8 steps of the DNS lookup have returned the IP address for example.com, the browser is able to make the request for the web page:

 

โ‘จ The browser makes a HTTP request to the IP address.

โ‘ฉ The server at that IP returns the webpage to be rendered in the browser (step 10).

DNS Resolver

The DNS resolver is the first stop in the DNS lookup, and it is responsible for dealing with the client that made the initial request. The resolver starts the sequence of queries that ultimately leads to a URL being translated into the necessary IP address.

(the resolver server is usually your ISP)

 

Note: A typical uncached DNS lookup will involve both recursive and iterative queries.

 

It's important to differentiate between a recursive DNS query and a recursive DNS resolver. The query refers to the request made to a DNS resolver requiring the resolution of the query. A DNS recursive resolver is the computer that accepts a recursive query and processes the response by making the necessary requests.

3 typs of DNS queries

In a typical DNS lookup three types of queries occur. By using a combination of these queries, an optimized process for DNS resolution can result in a reduction of distance traveled. In an ideal situation cached record data will be available, allowing a DNS name server to return a non-recursive query.

 

โ‘  Recursive query - In a recursive query, a DNS client requires that a DNS server (typically a DNS recursive resolver) will respond to the client with either the requested resource record or an error message if the resolver can't find the record.

 

โ‘ก Iterative query - in this situation the DNS client will allow a DNS server to return the best answer it can. If the queried DNS server does not have a match for the query name, it will return a referral to a DNS server authoritative for a lower level of the domain namespace. The DNS client will then make a query to the referral address. This process continues with additional DNS servers down the query chain until either an error or timeout occurs.

 

โ‘ข Non-recursive query - typically this will occur when a DNS resolver client queries a DNS server for a record that it has access to either because it's authoritative for the record or the record exists inside of its cache. Typically, a DNS server will cache DNS records to prevent additional bandwidth consumption and load on upstream servers.

DNS caching

The purpose of caching is to temporarily stored data in a location that results in improvements in performance and reliability for data requests. DNS caching involves storing data closer to the requesting client so that the DNS query can be resolved earlier and additional queries further down the DNS lookup chain can be avoided, thereby improving load times and reducing bandwidth/CPU consumption. DNS data can be cached in a variety of locations, each of which will store DNS records for a set amount of time determined by a time-to-live (TTL).

(1) Browser DNS caching

Modern web browsers are designed by default to cache DNS records for a set amount of time. The purpose here is obvious; the closer the DNS caching occurs to the web browser, the fewer processing steps must be taken in order to check the cache and make the correct requests to an IP address. When a request is made for a DNS record, the browser cache is the first location checked for the requested record.

 

In Chrome, you can see the status of your DNS cache by going to chrome://net-internals/#dns.

(2) Operating System(OS) level DNS caching

The operating system level DNS resolver is the second and last local stop before a DNS query leaves your machine. The process inside your operating system that is designed to handle this query is commonly called a “stub resolver” or DNS client. When a stub resolver gets a request from an application, it first checks its own cache to see if it has the record. If it does not, it then sends a DNS query (with a recursive flag set), outside the local network to a DNS recursive resolver inside the Internet service provider (ISP).

 

When the recursive resolver inside the ISP receives a DNS query, like all previous steps, it will also check to see if the requested host-to-IP-address translation is already stored inside its local persistence layer.

(โ€ป browser cache → DNS cache → Hosts File)

 

The recursive resolver also has additional functionality depending on the types of records it has in its cache:

 

โ‘  If the resolver does not have the A records, but does have the NS records for the authoritative nameservers, it will query those name servers directly, bypassing several steps in the DNS query. This shortcut prevents lookups from the root and .com nameservers (in our search for example.com) and helps the resolution of the DNS query occur more quickly.

 

โ‘ก If the resolver does not have the NS records, it will send a query to the TLD servers (.com in our case), skipping the root server.

 

โ‘ข In the unlikely event that the resolver does not have records pointing to the TLD servers, it will then query the root servers. This event typically occurs after a DNS cache has been purged.

DNS in One Picture

DNS or Domain Name System is one of the fundamental blocks of the internet. As a developer, you should have at-least the basic understanding of how it works. This article is a brief introduction to what is DNS and how it works.

 

DNS at its simplest is like a phonebook on your mobile phone. Whenever you have to call one of your contacts, you can either dial their number from your memory or use their name which will then be used by your mobile phone to search their number in your phone book to call them. Every time you make a new friend, or your existing friend gets a mobile phone, you have to memorize their phone number or save it in your phonebook to be able to call them later on. DNS or Domain Name System, in a similar fashion, is a mechanism that allows you to browse websites on the internet. Just like your mobile phone does not know how to call without knowing the phone number, your browser does not know how to open a website just by the domain name; it needs to know the IP Address for the website to open. You can either type the IP Address to open, or provide the domain name and press enter which will then be used by your browser to find the IP address by going through several hoops. The picture below is the illustration of how your browser finds a website on the internet.

DNS Records

→ the information that is stored in 'Authoritative Name Server' is DNS Records or Zone Files

 

A record / AAAA record / CNAME record / MX record / TXT record / NS record

 

TTL(Time To Live): a field on DNS records that controls how long each record is valid - how long it takes for record updates to reach your end users (longer TTLs speed up DNS lookups by increasing the chance of cached results, but a longer TTL also means that updates to your records take longer to go into effect)

Type Domain Name Value(IP address) TTL(Time To Live)
A(stands for "address") @ 185.199.108.153 14400
A app 185.199.108.153 14400
A @ 185.199.109.155 14400
A app 195.199.109.156 14400
CNAME blog sh-avid-learner.tistory.com 14400
MX @ 10 mail.example.com 14400
MX @ 20 mail-2.example.com 14400
TXT @ some dummy text. 14400
NS @ dns1.p01.authoritativeserver.net 14400
NS @ dns2.p02.authoritativeserver.net 14400

โ‘  A record

 

"Address Record. Indicates the IP address of the domain"

โ‘  Type: A

โ‘ก Domain Name: if '@', which means a blank record, points to your root main domain to a server. if 'app'(in this case http://app.~), will now point to different IP address.

โ‘ข Value: IP address(IPv4) (A record simply points a domain to an IPv4 address). Multiple records for the domain are pointing to different servers

 

โ‘ก AAAA record

 

→ AAAA record, just like A record, point to the IP address for a domain. However, this DNS record type is different in the sense that it points to IPV6 addresses. IPV6 is an upgrade over IPV4 as it offers more IP addresses. As a result, IPV6 solves the issue of running out of unique IP addresses. An IPV6 address looks something like the following:

3001:0db7:3c5d:0024:0000:0000:1a2f:3c1b

A colon separates each field in an IPV6 address.

 

โ‘ข CNAME record - alias

 

"Canonical name. Points a domain or subdomain to another domain"

a DNS record that points a domain name (an alias) to another domain. In a CNAME record, the alias doesn't point to an IP address. And the domain name that the alias points to is the canonical name. For example, the subdomain ng.example.com can point to example.com using CNAME. Here example.com points to the actual IP address using an A record.

 

Use of CNAME record

 

A practical example for the use of CNAME records is running multiple subdomains for different purposes on the same server. For example, we can use ftp.example.com for file transfer protocol (FTP) and serve webpages via www.example.com. We can then use a CNAME record to point both subdomains to example.com. The main domain example.com then points to the server's IP address using an A record.

It's also possible to point a CNAME to another CNAME. However, doing so is inefficient and can lead to slow load speed and poor user experience.

 

โ‘ฃ MX record

 

"Mail exchanger. Helps route the emails to the relevant server"

 

A mail exchange (MX) record, is a DNS record type that shows where emails for a domain should be routed to. In other words, an MX record makes it possible to direct emails to a mail server.

 

You can have multiple MX records for a single domain name. And what this means is that you can have backup email servers. Above table shows an example of a domain with multiple MX records:

 

From the above table, the MX record with priority 10 will be the primary mail server, while the secondary server will only be used when the primary server is unavailable (or fails to send emails). The lower the priority value, the higher the actual priority.

 

(Table) any emails which are sent to naked domain(@; i.e. metamong@tistory.com) will be sent to mail.example.com

 

โ‘ค TXT record

 

"text record. allows us to add arbitrary text to domain name."

 

text record is mostly used by third-party services which want to verify the ownership of domain name

 

TXT Records allow you to contain any textual information on a domain or subdomain. Applications can use this to check information about a service you are running, commonly SPF records, DomainKeys, and DKIM (two other email verification processes). Usage with SPF can be read about above in the SPF Records section. TXT Records may contain any information up to 255 characters.

 

TXT stands for "text," and this record type lets the owner of a domain store text values in the DNS. Several services use this record to verify ownership of a domain.

 

โ‘ฅ NS record

 

"name server record. indicates the authoritative servers."

 

gives you the location of the authoritative server

 

A nameserver (NS) record specifies the authoritative DNS server for a domain. In other words, the NS record helps point to where internet applications like a web browser can find the IP address for a domain name. Usually, multiple nameservers are specified for a domain. For example, these could look like ns1.examplehostingprovider.com and ns2.examplehostingprovider.com.

 

Use of NS record

 

If you've purchased a web hosting service or set up a simple website, you probably received an email with nameserver details. Those nameservers, in simple terms, connect your domain name to the actual server your site is hosted on. The nameserver contains other DNS records for the domain like an A record and MX record.

inspecting DNS records

โ˜† inspecting DNS Records with host

host -t a https://sh-avid-learner.tistory.com/

glue record

Q. Suppose you're looking up maps.google.com using DNS. root name server → .com name server → google.com name server

google.com name server knows the IP address you're looking for.

 

โ€ป Problem arises when a root name server refers to a different one, it does so with an NS record. That NS record doesn't contain the server's IP address. 

 

ex) if a root server sent us below example NS record

Name Value Type Time to live
com. a.gtld-servers.net NS record 2 days

→ Now we know a.gtld-servers.net is a name server for the .com zone

→ next we could do a DNS lookup for a.gtld-servers.net

 

→ when DNS lookup(for a.gtld-servers.net), they'll point us towards the .net name servers(which are also located within gtld-servers.net)

Name Value Type Time to live
net. a.gtld-servers.net NS record 2 days

A. root name sever can use DNS additional info to include extra A record & AAAA records for the name servers it previously mentioned

→ introducing glue record (A, AAAA record)

Name Value Type Time to live
a.gtld-servers.net 192.5.6.30 A record 2 days
a.gtld-servers.net 2001:503:a83e::2:30 AAAA record 2 days

→ thus, in one DNS message, the root name server can tell us that

โ‘  a.gtld-servers.net can help you find things in the .com zone

โ‘ก the name server(a.gtld-servers.net) is located at this IPv4 address (based on the glue records) & as well as the IPv6 address (also)

so figured out where to reach the .com name server

 

→ as of google.com, .com name server can have an additional A record below (telling us the IP address of ns1.google.com)

Name Value Type
google.com ns1.google.com NS record
ns1.google.com 216.239.32.10 A record

→ downside) but, when using glue records, have to update your DNS every time that name server's IP address changes (may cause an unnecessary downtime)

→ since the name server is hosted on someone else's domain, a glue record isn't necessary (so just the NS record do)

 

use a glue record if your name servers are hosted within your domain


* source 1) https://www.cloudflare.com/en-gb/learning/dns/what-is-dns/

* source 2) https://howdns.works/

* source 3) https://www.youtube.com/watch?v=Wj0od2ag5sk 

* source 4) https://youtu.be/7lxgpKh_fRY

* source 5) https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/

* source 6) https://www.youtube.com/watch?v=e48AyJOA9W8 

* source 7) https://ns1.com/resources/dns-records-explained

'Front-end > Internet' ์นดํ…Œ๊ณ ๋ฆฌ์˜ ๋‹ค๋ฅธ ๊ธ€

Web Hosting  (0) 2023.03.27
Domain Name  (0) 2023.03.27
HTTP(์ˆ˜์ •์ค‘)  (0) 2023.03.20
Packets & Protocols  (0) 2023.03.14
The Internet Explained  (0) 2023.03.14

๋Œ“๊ธ€