October 31, 2023

Domain Name System: Understand The Basics

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.

Hosts file

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!EXAMPLE, !10!EXAMPLE, !ARPA!#65. The network is optional and, if empty, indicates the local network, eg. EXAMPLE, which makes it backward-compatible.

RFC 799

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

RFC 819 and RFC 830, published in 1982, proposed a distributed System for Internet Name Service, or SINS. The host would now be a hierarchical list of names separated by dot characters.

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.

For example, 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.[].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.

Domain Names

In the context of DNS, a hostname is called a domain name, and is a string composed of labels separated by dot characters, eg. 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. 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 is made up of four labels: "www", "example", "com", and "" (the root zone). A sample of the Internet tree hierarchy (with some other domain names added) can be displayed as a tree:

├─ com.
│   ├─
│   │   └─
│   └─
├─ net.
│   └─
└─ org.

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, ., com. and are distinct zones, but is not and is actually part of the zone 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

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) gov, edu, com, mil, org, 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, could technically delegate into a new zone to be managed separately.

For example, Verisign owns the com. zone, and has delegated control of the child zone to DigitalOcean. Everything in this child zone is not under Verisign’s jurisdiction anymore. In fact, except for pointers to's servers, Verisign doesn’t know anything about DigitalOcean’s zone.

Resource Records

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

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.

Iterative Mode

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. for'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 and are better suited to answer. The client can then ask one of these servers (eg. and receive information about's authoritative name servers.

Iterative Resolver

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 records, it will refer the client to the common denominator server (the root zone in this case), or simply return an error.

Recursive Mode

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's IP address:

  1. The resolver doesn’t have that information in its cache, nor does it know the authoritative name servers for, and com.. It knows what the root zone’s authoritative name servers are (eg., along with their IP addresses (eg.;
  2. It asks about's IP address, is answered with com.'s authoritative name servers (eg., and is also provided with's IP address with the value;
  3. It asks about's IP address, is answered with's authoritative name servers, (eg.;
  4. It doesn’t know how to reach, so must find its IP address, recursively traversing again towards the root zone, and back towards, and ends up with the value;
  5. It asks about's IP address, is answered with

Recursive Resolver

In the first step, the resolver knew about 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,'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.

Resource Record

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, and 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:

Type Description
A IPv4 address
AAAA IPv6 address
CNAME Canonical name
MX Mail server
NS Authoritative name server
PTR Pointer
SOA Start of authority
TXT Text

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 IN:

Type Description
IN Internet
HS Hesiod

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: NS IN 86400

This would mean that is an authoritative name server of 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:

*     TXT "Wildcard" TXT "alpha"  A

Querying for TXT or TXT would both result in "Wildcard", while querying for TXT, TXT, or 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 A and 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 CNAME configures as the canonical name of Querying for A would return CNAME and's A records.

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.

The 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 A would not return the PTR record.

SOA, or start of authority, records are primarily used for zone administration. The data is composed of seven fields. At the time of writing,'s SOA record looks like 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 @, ie., 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.

Furthermore, an 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, does not have an SOA record, so it isn’t a zone. On the other hand, its parent has one, meaning that is in the zone

The TXT record type is for arbitrary text. It is used when no record types are available for a given data. DKIM and domain ownership verification are examples of what TXT records are used for.

Finally, the OPT record type (EDNS, RFC 2671) is a pseudo-record. It is used to specify a greater size and extend the possible flags and options for queries and answers.


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:

Code Description
QUERY Standard query
IQUERY Inverse query
STATUS 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 RD and 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.

Code Error Description
NOERROR No Error The query was successful
FORMERR Format error The query could not be parsed
SERVFAIL Server failure The query could not be processed
NXDOMAIN Non-Existent Domain The domain name does not exist
NOTIMP Not Implemented The opcode is not supported
REFUSED Query Refused 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.

Question Records

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.

Answer Records

The answer section contains any number of resource records. They directly answer the question records.

Authority Records

The authority section sometimes has resource records to add authoritative information related to the query, for example other NS or SOA records.

Querying for a domain name that doesn’t exist, eg., may get back's SOA record in the authority section.

Because they do not support recursion, querying a root zone’s authoritative name server for A would instead receive 13 com. NS records in the authority section.

Additional Records

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, the root server answers by providing com.‘s 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 A and AAAA records that are called glue records.

How DNS Works

This section explains the two main types of query in more detail.

DNS Lookup

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's IPv4 addresses (its A records), would build a message containing a single question record with name, class IN, and type A. The name server, assuming a recursive resolver, would respond with the same question record, and an answer record with name, class IN, type A, a certain TTL value, and the IPv4 address as the record’s data.

DNS Reverse Lookup

Is it possible for a client who knows an IPv4 address, eg., 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 IN, type A, and value, 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. 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, 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, a DNS message is sent to query's 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, 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 would result in the AWS EC2 instance instead of 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 and which both result in an NXDOMAIN error instead of and, respectively.

When IPv6 was added to DNS in RFC 3596, the zone 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's PTR records.


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.


The command dig is the typical way to perform a DNS query. In its simplest form, it queries the specified domain name for its A records:

$ dig

; <<>> DiG 9.16.42-Debian <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 291
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 0123456789abcdef (echoed)
;                   IN      A

;; ANSWER SECTION:             4502   IN      A

;; Query time: 160 msec
;; 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:, I know that the request was sent to my router, which is the default name server that is configured in /etc/resolv.conf.

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

The type of record can be specified at the end:

$ dig +short NS

The -x parameter can be used to do a reverse lookup:

$ dig +short PTR
$ dig +short -x

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 @

There are many other parameters, like +norecurse to force an iterative mode, that are listed with dig -h or man dig.


nslookup is another tool that can perform DNS queries. The following queries for's A and AAAA records:

$ nslookup

Non-authoritative answer:
Address: 2606:2800:220:1:248:1893:25c8:1946

Options are specified before the domain name, and an optional name server can be specified at the end:

$ nslookup -type=TXT
Address: text = "v=spf1 -all" text = "wgyf8z8cgvm2qmxpnbnldrcltvk4xqfn"

nslookup also has an interactive mode, in which commands affect the subsequent queries:

$ nslookup

Non-authoritative answer:
Address: 2606:2800:220:1:248:1893:25c8:1946
> server
Default server:
> set type=NS

Non-authoritative answer: nameserver = nameserver =

Authoritative answers can be found from:
> exit

nslookup will also automatically detect IP addresses, so nslookup will perform a reverse lookup.

More information can be found with man nslookup.


host is used to retrieve the IP addresses of a domain name:

$ host has address has IPv6 address 2606:2800:220:1:248:1893:25c8:1946 mail is handled by 0 .

Similarly to nslookup, options can be specified before the domain name, and the name server specified at the end:

$ host -t NS
Using domain server:
Aliases: name server name server

Again similarly to nslookup, host will automatically detect IP addresses, and host will perform a reverse lookup.

More information can be found with man host.


dog is a modern rewrite of dig:

   A 23h42m40s
AAAA 23h42m40s   2606:2800:220:1:248:1893:25c8:1946
  NS 23h43m41s   ""
  NS 23h43m41s   ""
 TXT 1d0h00m00s  "v=spf1 -all"
 TXT 1d0h00m00s  "wgyf8z8cgvm2qmxpnbnldrcltvk4xqfn"

Of interest is its ability to output the response in JSON. More information can be found in the official website.


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.

In addition to the various RFCs mentioned in this post,’s excellent Learning Center has a lot more information to dig deeper into how DNS works.

Simon Bernier

Simon Bernier