31 octobre 2023
DNS: Comprendre Les Bases Du Système De Noms De Domaine (article en anglais)
Are you tired of trying to look for an introduction to DNS, and finding only blogs that skim over too quickly, and others that dig too greedily into details? This post explains the basics of DNS, starting with what problems it was developed to solve, then going more and more into detail. The information is brought forth at a slow pace, one concept at a time, so that at the end of the post, everything fits together into a big picture. From this, you can get a strong grasp of the basics.
History of DNS
This section provides some historical highlights about what led to DNS in its current form.
The idea of wide area networks slowly became possible in the mid-1960s. The ARPA succeeded at the turn of the decade in connecting three universities (UCLA, UCSB, and Utah) and a research center (SRI-ARC), which gave birth to the ARPANET. Users who wanted to connect to a remote server would use a terminal.
Even though the network addresses at the time were only 8 bits long, numeric addresses are cumbersome to remember and type. Because of this, terminals provided from the beginning a way for users to specify a hostname, which was mapped by the system to a network address, similar to a “phone book” mapping names to telephone numbers. For example, RFC 208 lists the network addresses of 1971 with associated site and host names.
Early on, the hostname-to-address mapping was configured manually by a network’s system administrator (sysadmin for short). Larger networks used various configuration files, but one in particular eventually became dominant, the hosts file. A sysadmin was in charge of keeping this file updated on all terminals, by reading various channels, including RFCs, eg. RFC 590.
Not only was the hosts file’s format different on each operating system, it was outdated more often than not, and the hostnames themselves were arbitrary. This led to some efforts which resulted in an official list of hostnames (RFC 289, RFC 384) in 1972, and a standardized
HOSTS.TXT file format (RFC 606, RFC 608) with a designated maintainer (RFC 627) in 1974.
The NIC, an organisation based in the SRI-ARC, was thus in charge of maintaining the centralized
HOSTS.TXT, which would be FTP’d automatically at night (or manually by sysadmins) to keep their network updated. Someone who wanted to add a host from their network to the ARPANET had to call the NIC by phone during business hours.
This system could work in the 1970s, because then it was still possible to publish bi-weekly host status, monthly traffic statistics, and map the network. There were but 45 hosts in 1972, but the popularity of the ARPANET, and its exponential growth, pushed it to around 600 10 years later, reaching 10,000 before the 1980s were over.
Because of this popularity, official updates were slow. All of this was, of course, problematic for a manually-updated centrally-managed directory. There is even a story about a young sysadmin automating his
HOSTS.TXT file, which might have become more popular than the official NIC file.
In the early 1980s, work towards a solution was already underway, which led to some tentative solutions. Some of them are shown in the next sections, to show the ideas that led to DNS, and what system we could have ended up with. Nevertheless, the hosts file is still in use today by most systems as the first step towards hostname resolution and has been standardized in RFC 952 and RFC 953.
IEN 116, IEN 117
IEN 116, published in 1979, proposed a way to retrieve a host’s IP address by communicating with a centralized Internet Name Server.
The hostname is prefixed with the network name or number (IEN 117) surrounded by exclamation points, eg.
!ARPA!#65. The network is optional and, if empty, indicates the local network, eg.
EXAMPLE, which makes it backward-compatible.
RFC 799, published in 1981, acknowledged that a hierarchical name-space partitioning can be easy to find, but difficult to make backward-compatible with existing mail systems. It proposes a new way to write email addresses so that the domain can be specified.
The domain would replace the hostname, which would be moved to the left of the
@, with the user name. For example,
User@EXAMPLE could become
User.EXAMPLE@ARPA. The receiving mail server would then have to parse the address to figure out which host it should forward the email to.
RFC 819, RFC 830
Each terminal would have an Application Interface Process (AIP) and a Domain Name Server (DNS) installed. The AIP makes requests to its DNS, and since each domain would also have its own configured DNS, the DNSes would communicate with each other to sequentially retrieve the resulting network address. The source AIP would then negotiate with the target AIP for resource availability and compatibility, including transport and application services, eg. TCP, TELNET, and SMTP mail. In other words, the application not only finds an IP Address but also the protocol and port numbers.
User@EXAMPLE might now be
User@EXAMPLE.ARPA. The process would query its local AIP, which would query its DNS. This DNS would resolve
ARPA’s DNS’s network address, and would query that DNS for the IP address that belongs to
EXAMPLE. This proposal also allows nameless domains, eg.
User@A.#1.B with a host number, and
User@A.[22.214.171.124].B with an IP address.
RFC 882, RFC 883
RFC 882 and RFC 883, published in 1983, were the final iteration, and resulted in the Domain Name System, or DNS. These RFCs solve the main issues related to the
HOSTS.TXT file, centralized at the NIC, that had become a bottleneck.
Instead of having a single source of truth controlled by a central authority, DNS is distributed, meaning that there are no single organizations in charge of keeping all hostname data up-to-date. Instead, each organisation designates one or more servers that control its database.
Now that the hostnames’ information is distributed in multiple databases, a user needs a way to find the server that can access the database they want.
Instead of having a flat structure where all hostnames are equal, DNS is split into a hierarchy where hostnames have a parent and any number of children. This allows a server to start at the root and recursively find any hostname database.
Although DNS is often said to find a hostname’s IP address, this is not entirely correct. It offers a standardized way not only to map hostnames to IP addresses on the Internet, but also to other types of information, and on other types of networks. It is essentially a global key-value store.
The system is heavily built upon servers caching responses. It takes eventual consistency to the extreme, in the sense that updates to a database are not even replicated to other servers. This skips the hard part of caching, cache invalidation, in favor of each piece of data having a configured time-to-live (TTL), after which a copy is simply discarded.
On the other hand, this also means that a query might receive a deprecated answer, but the DNS databases are not typically updated often.
The current base RFCs for DNS are RFC 1034 (concepts) and RFC 1035 (specs), as well as RFC 1032 and RFC 1033 for domain administrators. These RFCs, along with their numerous updates, should be used as primary reference.
This section explains the concepts and high-level details of DNS.
The DNS is made of zones of authority, each managed by an organisation or entity. A zone represents a portion of the hierarchy, which starts at the root zone and splits off to children zones through delegation to other organisations.
In the context of DNS, a hostname is called a domain name, and is a string composed of labels separated by dot characters, eg.
www.example.com. Each label is case-insensitive and composed of letters and digits, as well as hyphens
- anywhere except the first and last characters. These labels are in a specific order, starting with the least significant and ending with the root zone.
The root zone is not the
com label from the example, though, but is displayed as an empty label. Since all domain names on the Internet are somewhere under this root zone, they all technically end with a dot character, eg.
www.example.com.. This notation is called fully-qualified and indicates that the domain name is absolute. Relative domain names are out of scope for this post, so unless otherwise specified, all domain names can be assumed to be fully qualified, whether they end with
. or not. Even though virtually all domain names that we encounter on the Internet do not end with
., it is the “correct” way to write them.
So, the domain name
www.example.com. is made up of four labels:
"" (the root zone). A sample of the Internet tree hierarchy (with some other domain names added) can be displayed as a tree:
│ ├─ example.com.
│ │ └─ www.example.com.
│ └─ kumojin.com.
│ └─ example.net.
Labels in a domain name roughly correspond to zones. The difference between them can be subtle: servers and authority are related to zones, while domain names are more of an abstract concept and related to the data. In the example tree above,
example.com. are distinct zones, but
www.example.com. is not and is actually part of the zone
example.com.. Why and how is explained later.
The Domain Name Space is all the zones and domain names that can be reached from the root zone. It would look like the DNS tree previously drawn but with billions of branches.
Top-level domains, or TLDs, are the zones that are directly under the root zone. When the DNS was implemented in 1983, it established the familiar generic TLDs (gTLD)
net (a couple of months later), and
int (a couple of years later). It also reserved a TLD for each countries (ccTLD) represented by the country’s two-letter ISO 3166-1 code, for example
ca for Canada and
de for Germany. This structure is explained in RFC 1591.
The same RFC has the following:
It is extremely unlikely that any other TLDs will be created.
Contrary to their initial expectations, more were created over the years, and the list grew to over a thousand TLDs. These TLDs are generally not available for registration - they are expensive and there are regulations and rules to follow.
A zone can split off one of its branches into a separate, distinct child zone, effectively transferring its ownership to another organisation. Traversal of the tree from the root zone through the new zone is delegated to another set of servers. In the example tree above,
example.com. could technically delegate
www.example.com. into a new zone to be managed separately.
For example, Verisign owns the
com. zone, and has delegated control of the child zone
digitalocean.com. to DigitalOcean. Everything in this child zone is not under Verisign’s jurisdiction anymore. In fact, except for pointers to
digitalocean.com.'s servers, Verisign doesn’t know anything about DigitalOcean’s zone.
The different kinds of data that can be queried about a domain name are called resource records, often just “record”, or
RR (in RFCs). A resource record is a typed value associated with a specific domain name. An example of a resource record would be the IPv4 address of
Zones can have any number of resource records. If zones are like directories in the DNS tree, the resource records are like files.
Name servers are servers that can respond to DNS requests. They are also called resolvers.
Normally, the client sends the DNS query to the configured router or ISP to be processed. The OS can instead be configured to send the queries elsewhere, such as a public name server, for example Cloudflare, Google, Quad9, or Cisco’s OpenDNS, just to name a few. Some other name servers are private (and paid), like NextDNS, and allow the user to customize their experience.
There are two modes of operation for a name server: by iteration, and by recursion. As per RFC 1034, name servers must implement iteration, but do not need to handle recursion. If a client desires recursion out of a name server that doesn’t handle it, an iterative answer will simply be returned.
Authoritative Name Servers
Authoritative name servers are the source of truth for a specific zone. Their only job is to iteratively answer with the zone’s resource records.
For redundancy, each zone is managed by some of these name servers - one primary, and one or more secondaries. If one of these goes down or is attacked, the other name servers are still running. If all of these go down, this will only affect the zone and its children, and the whole system won’t break. Even the root zone is not a single point of failure, as it is managed by 13 root name servers.
In iterative mode, a resolver answers with information about servers that are closer to the requested data, with which the client can continue its query.
For example, a client asking a root zone’s name server (eg.
www.example.com.'s IP address will be referred to
com.'s authoritative name servers. It is like the server is saying that it doesn’t know the IP address, but that these name servers are closer to
example.com. and are better suited to answer. The client can then ask one of these servers (eg.
a.gtld-servers.net.) and receive information about
example.com.'s authoritative name servers.
Iterative mode is easy to implement on the server side but forces the client to find its answer manually. The client is of course free to cache the responses if they might be useful in the future.
If the name server has no idea about the requested record, eg. asking
com.'s authoritative name server about
example.org. records, it will refer the client to the common denominator server (the root zone in this case), or simply return an error.
In recursive mode, a resolver searches for the answer by asking other name servers. It very likely has a cache to help with further requests.
These recursive resolvers make queries to other name servers to find the answer. Typically, the first step would be to find an authoritative name server in the cache, starting at the requested domain name, and traversing the tree towards the root zone. From that name server, iteratively ask for the requested record until an answer is found.
For a quick example, a recursive name server might receive a request for
www.example.com.'s IP address:
- The resolver doesn’t have that information in its cache, nor does it know the authoritative name servers for
com.. It knows what the root zone’s authoritative name servers are (eg.
a.root-servers.net.), along with their IP addresses (eg.
- It asks
www.example.com.'s IP address, is answered with
com.'s authoritative name servers (eg.
a.gtld-servers.net.), and is also provided with
a.gtld-servers.net.'s IP address with the value
- It asks
www.example.com.'s IP address, is answered with
example.com.'s authoritative name servers, (eg.
- It doesn’t know how to reach
a.iana-servers.net., so must find its IP address, recursively traversing again towards the root zone, and back towards
a.iana-servers.net., and ends up with the value
- It asks
www.example.com.'s IP address, is answered with
In the first step, the resolver knew about
a.root-servers.net. because all resolvers are configured with initial data that contains the root zone’s authoritative name servers and their IP addresses.
This may look a bit confusing and chaotic, especially the fourth step, but a resolver would cache the answers it finds, so if it later receives a query for, say,
digitalocean.com.'s IP Address, it already knows
com.'s authoritative name servers and their IP addresses, so the resolution will be quicker.
Forwarding Name Servers
Forwarding name servers, also called forwarders, are not really resolvers but are very simple name servers that receive DNS requests and merely forward them to another name server. This is often seen in routers, when the resolution is delegated elsewhere, eg. the ISP.
Stub Name Servers
Stub resolvers, defined in RFC 1123, are services or library functions (such as
getaddrinfo) built in the operating system for applications that need to map a hostname to an IP address. They build the DNS request and send it to the configured name server (eg.
/etc/nsswitch.conf in Linux).
This section explains at a lower level what DNS queries and answers are composed of, and how they work. Traditionally, these are UDP packets that go through the Internet towards the name server, but DNS is versatile and can use TCP as well.
The most important piece of information is the resource record. The DNS functions like a key-value store, with the key being a domain name, record type, and network class, and the value being some data and for how long it is still valid. Keys are not unique, so there can be multiple values associated with the same key, in which case there are no intrinsic orders.
The domain name is the hostname to which a resource record applies. For example,
www.example.com. are domain names.
The record type defines what the record represents. There are many record types, from IP addresses and domain names to free text. Some of the important ones are shown in the following table:
|Authoritative name server
|Start of authority
The record types will be explained in a bit more detail in the next section.
The class specifies the name space, or technically, how some of the record types were encoded. There was a time in early 1980’s when multiple concurrent networks were interconnected. On paper, DNS can serve data about multiple network classes at the same time, but this is virtually always
The time-to-live, or TTL, represents how long, in seconds, the resource record can be cached. Past this TTL, the data should be discarded and retrieved anew.
The data simply contains the piece of information that the record is about. What it means (eg. an IPv4 address, a domain name, …) depends on the record type.
For example, a resource record might be written as the following:
example.com. NS IN 86400 a.iana-servers.net.
This would mean that
a.iana-servers.net. is an authoritative name server of
example.com. on the Internet, to be cached for one day (86,400 seconds). More commonly, the
IN is implied and not displayed.
A domain name can also start with a wildcard label
*, which matches any one or more nonexistent domain names. For example, given the following records in a database:
*.example.com. TXT "Wildcard"
alpha.example.com. TXT "alpha"
beta.example.com. A 126.96.36.199
test.example.com. TXT or
one.two.example.com. TXT would both result in
"Wildcard", while querying for
alpha.example.com. TXT, or
beta.example.com. TXT would not match the wildcard.
Resource Record Types
Before moving on to DNS messages, this section explains in a bit more detail how some of the important record types work.
The record types
AAAA are IPv4 and IPv6 addresses, respectively.
CNAME, or canonical domain name, records define the record’s domain name as an alias. Processing will continue with the specified domain name. For instance, the record
www.example.com. CNAME example.com. configures
example.com. as the canonical name of
www.example.com.. Querying for
www.example.com. A would return
www.example.com. CNAME example.com. and
A domain name that is used for email has one or more
MX records to configure mail servers, each with a preference value. The lowest value is preferred and tried first when delivering the email. Multiple mail servers with the same preference value are typically load-balanced.
NS record type defines the domain name of an authoritative name server.
PTR records are similar to
CNAME records, with the exception that the processing does not continue with the specified domain name. Using the same example, querying
www.example.com. A would not return the
SOA, or start of authority, records are primarily used for zone administration. The data is composed of seven fields. At the time of writing,
SOA record looks like
ns.icann.org. noc.dns.icann.org. 2022091339 7200 3600 1209600 3600. The first field is the domain name of the primary authoritative name server, the second is the email address of the zone administrator (encoded as a domain name, with the first label being the part that comes before the
email@example.com), and the third is a serial number that, if increased, indicates that some records in the zone were modified. The last four are related to zone transfers and negative caching, and are out of scope for this post.
SOA record indicates that the domain name is the beginning of a zone. Domain names that do not have
SOA records are in the zone of the closest parent that does. For example,
www.example.com. does not have an
SOA record, so it isn’t a zone. On the other hand, its parent
example.com. has one, meaning that
www.example.com. is in the zone
A DNS message is the envelope for both DNS queries and answers, and is split into five sections: the header, question records, answer records, authority records, and additional records.
A message’s header contains its ID, some options, and the number of resource records that is contained in each of the next sections.
The ID doesn’t do much by itself but is used if a client needs to match its queries to the answers it receives.
The query-response flag, or
QR, indicates whether the message is a query or a response. This is important because of inverse queries, and because responses also contain the initial question.
The opcode, or
OPCODE, specifies the kind of query:
|Server status request
Virtually all DNS queries are of the standard kind, also called forward lookups.
IQUERYs are obsolete in favor of reverse lookups, and
STATUSes do not have any specified behavior. Some other opcodes were added over the years, but they are administrative actions more than anything else.
The authoritative answer flag, or
AA, indicates whether a response is authoritative, meaning that it was provided directly by an authoritative name server.
The truncation flag, or
TC, indicates whether the message was truncated because of its length. Truncated messages have missing resource records, and must not be cached.
The recursion desired flag, or
RD, indicates that the client is asking the name server to use recursion to find the answer. If unset, or if the name server does not support recursion, the response will be iterative.
The recursion available flag, or
RA, indicates whether the name server supports recursion. If both
RA are set in an answer, it means the name server used recursion.
The response code, or
RCODE, indicates whether the query was successful or not.
|The query was successful
|The query could not be parsed
|The query could not be processed
|The domain name does not exist
|The opcode is not supported
|The name server refuses to answer
More errors were added over the years, but the initial ones give a very good idea of how they work.
The question section contains the keys to a resource record (name, type, and class) that the client wants answers to. It usually has a single question record, but technically, it can have any number of them, including none.
The answer section contains any number of resource records. They directly answer the question records.
The authority section sometimes has resource records to add authoritative information related to the query, for example other
Querying for a domain name that doesn’t exist, eg.
invalid.example.com., may get back
SOA record in the authority section.
Because they do not support recursion, querying a root zone’s authoritative name server for
example.com. A would instead receive 13
com. NS records in the authority section.
The additional section gives more information about the current query or can help with subsequent ones.
As stated before, when querying a root zone’s authoritative name server for records about
example.com., the root server answers by providing
NS records in the authority section. Instead of letting clients do the obvious next step of finding one of these servers’ IP address, which might easily lead to an infinite loop, this information is instead included in the additional records section, in the form of
AAAA records that are called glue records.
How DNS Works
This section explains the two main types of query in more detail.
The main reason DNS is used is to query for a domain name’s resource records. This is called forward lookup (or simply lookup). With all the information that has been given in the previous sections, lookups should be easy to understand.
A DNS message can be constructed with question records. Depending on the type of name server and the options specified in the header, the response would contain the initial question record, and some answer, authority, and additional records.
For example, a client wanting to lookup
example.com.'s IPv4 addresses (its
A records), would build a message containing a single question record with name
IN, and type
A. The name server, assuming a recursive resolver, would respond with the same question record, and an answer record with name
A, a certain TTL value, and the IPv4 address
188.8.131.52 as the record’s data.
DNS Reverse Lookup
Is it possible for a client who knows an IPv4 address, eg.
184.108.40.206, to find out which domain name it belongs to?
The idea with inverse queries (the
IQUERY opcode) was that a DNS message would provide an answer and ask for the question. For example, a message would be sent containing an answer record with a class
A, and value
220.127.116.11, but with an empty name. A name server receiving such a message would look in its database for matching records, then provide the desired name in the response’s question record, eg.
example.com. A. This may have been too unintuitive, hacky, fragile, or computationally expensive, but the
IQUERY functionality was most of the time either disabled in name servers or simply unimplemented in software, and so it was deprecated with RFC 3425.
Meanwhile, the reverse lookup functionality, sometimes called rDNS and described alongside
IQUERY in RFC 1035, had continued to gain in popularity. This service is offered under the domain name
in-addr.arpa., using forward lookups and
PTR records. Contrary to inverse queries which can query for any record type, reverse lookups can only query IP addresses.
For example, to find the hostname that belongs to the IPv4 address
18.104.22.168, a DNS message is sent to query
PTR records. The IPv4 address is written in reverse to follow a domain name’s structure, starting from the least significant octet. This would result in a
PTR value of
news.ycombinator.com., the Hacker News website.
Reverse DNS is normally used for network troubleshooting and anti-spam. It may have been more useful in the past, but with how popular cloud providers have become over the last 10 years, the database has slowly become filled with generic domain names. For example, at the time of writing, reverse lookup’ing
22.214.171.124 would result in the AWS EC2 instance
ec2-44-235-246-155.us-west-2.compute.amazonaws.com. instead of
mozilla.org. Even though it was recommended that each host have a hostname, this is not enforced, and a lot of IP addresses are not mapped, for example
126.96.36.199 which both result in an
NXDOMAIN error instead of
When IPv6 was added to DNS in RFC 3596, the zone
ip6.arpa was assigned for reverse lookups of IPv6 addresses. Like IPv4 addresses, IPv6 addresses are encoded backwards, each hexadecimal digit in a separate label. Reverse lookup’ing
2606:2800:220:1:248:1893:25c8:1946 would query
Normally, a client does not need to build its own DNS queries. Instead, the operating system takes care of them.
Other times, DNS queries are performed manually, either for troubleshooting a problem, or simply for curiosity. This section shows how to use some common DNS tools in a terminal.
dig is the typical way to perform a DNS query. In its simplest form, it queries the specified domain name for its
$ dig example.com.
; <<>> DiG 9.16.42-Debian <<>> example.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 291
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 0123456789abcdef (echoed)
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 4502 IN A 188.8.131.52
;; Query time: 160 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Aug 11 19:00:00 UTC 2023
;; MSG SIZE rcvd: 79
From this output, we can see the header and all sections. We can also see that
dig has added an
OPT pseudo-record to raise the maximum message length to 4,096 octets and set a cookie ID.
From the line
;; SERVER: 192.168.1.1#53(192.168.1.1), I know that the request was sent to my router, which is the default name server that is configured in
dig’s output is by default rather verbose. The
+short flag can be added to only show the data from the answer section:
$ dig +short example.com.
The type of record can be specified at the end:
$ dig +short example.com. NS
-x parameter can be used to do a reverse lookup:
$ dig +short 240.230.216.209.in-addr.arpa. PTR
$ dig +short -x 184.108.40.206
Finally, if the system’s default name server is not desired, another can be specified with the
@ character followed by a domain name or IP address:
$ dig +short @220.127.116.11 example.com.
There are many other parameters, like
+norecurse to force an iterative mode, that are listed with
dig -h or
nslookup is another tool that can perform DNS queries. The following queries for
$ nslookup example.com.
Options are specified before the domain name, and an optional name server can be specified at the end:
$ nslookup -type=TXT example.com. a.iana-servers.net.
example.com text = "v=spf1 -all"
example.com text = "wgyf8z8cgvm2qmxpnbnldrcltvk4xqfn"
nslookup also has an interactive mode, in which commands affect the subsequent queries:
> server 18.104.22.168
Default server: 22.214.171.124
> set type=NS
example.com nameserver = a.iana-servers.net.
example.com nameserver = b.iana-servers.net.
Authoritative answers can be found from:
nslookup will also automatically detect IP addresses, so
nslookup 126.96.36.199 will perform a reverse lookup.
More information can be found with
host is used to retrieve the IP addresses of a domain name:
$ host example.com.
example.com has address 188.8.131.52
example.com has IPv6 address 2606:2800:220:1:248:1893:25c8:1946
example.com mail is handled by 0 .
nslookup, options can be specified before the domain name, and the name server specified at the end:
$ host -t NS example.com. dns.opendns.com
Using domain server:
example.com name server a.iana-servers.net.
example.com name server b.iana-servers.net.
Again similarly to
host will automatically detect IP addresses, and
host 184.108.40.206 will perform a reverse lookup.
More information can be found with
dog is a modern rewrite of
$ dog example.com A AAAA NS TXT
A example.com. 23h42m40s 220.127.116.11
AAAA example.com. 23h42m40s 2606:2800:220:1:248:1893:25c8:1946
NS example.com. 23h43m41s "b.iana-servers.net."
NS example.com. 23h43m41s "a.iana-servers.net."
TXT example.com. 1d0h00m00s "v=spf1 -all"
TXT example.com. 1d0h00m00s "wgyf8z8cgvm2qmxpnbnldrcltvk4xqfn"
Of interest is its ability to output the response in JSON. More information can be found in the
It’s crazy to think that DNS is 40 years old, mostly still in its initial state. It has become a strong and important pillar of the Internet, not because it is perfect (far from it), but because it is good enough. We can imagine how it might have been simpler but less flexible, making it useless over time as technology evolved around it. The people who thought and built this system did an incredible job of thinking ahead.
The basics shown in this post are straightforward and “easy” to understand, but once one digs deeper, it quickly gets more complicated (eg. DNSSEC). There are a lot of flaws and ways to abuse the system, but it doesn’t detract from its strengths. DNS has solidified its place for the foreseeable future.