Before we jump into setting up your own servers with VMM or setting up our domains in the Hestia control panel, let’s go over some basic concepts about how the Internet works.
We should start by defining our terms. While some of these topics are familiar from other contexts, there are many terms used when talking about domain names and DNS that aren’t used too often in other areas of computing.
Domain Name System
The domain name system, more commonly known as “DNS” is the networking system in place that allows us to resolve human-friendly names to unique IP addresses.
A domain name is the human-friendly name that we are used to associating with an internet resource. For instance, “google.com” is a domain name. The domain name system allows us to reach the Google servers when we type “google.com” into our browsers.
An IP address is what we call a network addressable location. Each IP address must be unique within its network. When we are talking about websites, this network is the entire internet. IPv4, the most common form of addresses, are written as four sets of numbers, each set having up to three digits, with each set separated by a dot. For example, “184.108.40.206” could be a valid IPv4 IP address. With DNS, we map a domain name to that IP address so that you do not have to remember a complicated set of numbers for each place you wish to visit on a network.
A top-level domain, or TLD, is the most general part of the domain. The top-level domain is the furthest portion to the right (as separated by a dot). Common top-level domains are “com”, “net”, “org”, “gov”, and “edu”.
Reserved domain names for testing
Three Top Level domain names are reserved for testing and documentation: dot test, dot example and dot localhost.
".test" is recommended for use in testing of DNS code.
".example" is recommended for use in documentation.
".localhost" is recommended for the localhost server.
In addition, the following second level domain names are reserved.
We will therefore use server1.example.com. for our Fully Qualified Domain Name (FQDN)
Fully Qualified Domain Name
A fully qualified domain name, often called FQDN, is what we call an absolute domain name. Domains in the DNS system can be given relative to one another, and as such, can be somewhat ambiguous. A FQDN is an absolute name that specifies its location in relation to the absolute root of the domain name system. A proper FQDN ends with a dot, indicating the root of the DNS hierarchy. An example of a FQDN is “mail.google.com.”. Sometimes software that calls for FQDN does not require the ending dot, but the trailing dot is required to conform to ICANN standards.
A name server is a computer designated to translate domain names into IP addresses. These servers do most of the work in the DNS system. Since the total number of domain translations is too much for any one server, each server may redirect request to other name servers or delegate responsibility for a subset of subdomains they are responsible for. Name servers can be “authoritative”, meaning that they give answers to queries about domains under their control. Otherwise, they may point to other servers, or serve cached copies of other name servers’ data.
A zone file is a simple text file that contains the mappings between domain names and IP addresses. Zone files reside in name servers and generally define the resources available under a specific domain, or the place that one can go to get that information.
Within a zone file, records are kept. In its simplest form, a record is basically a single mapping between a resource and a name. These can map a domain name to an IP address, define the name servers for the domain, define the mail servers for the domain, etc.
DNS is, at its core, a hierarchical system. At the top of this system is what are known as “root servers”. These servers are controlled by various organizations and are delegated authority by ICANN (Internet Corporation for Assigned Names and Numbers). There are currently 13 root servers in operation. The root servers won’t actually know where the domain is hosted. They will, however, be able to direct the requester to the name servers that handle the specifically requested top-level domain. So if a request for “www.wikipedia.org” is made to the root server, it will find a record for the “org” TLD and give the requesting entity the address of the name server responsible for “org” addresses.
The requester then sends a new request to the IP address (given to it by the root server) that is responsible for the top-level domain of the request. So, to continue our example, it would send a request to the name server responsible for knowing about “org” domains to see if it knows where “www.wikipedia.org” is located - it will find a record listing the IP address of the name server responsible for “wikipedia.org”.
Domain-Level Name Servers
At this point, the requester has the IP address of the name server that is responsible for knowing the actual IP address of the resource. It sends a new request to the name server asking, once again, if it can resolve “www.wikipedia.org”. The name server checks its zone files and it finds that it has a zone file associated with “wikipedia.org”. Inside of this file, there is a record for the “www” host. This record tells the IP address where this host is located. The name server returns the final answer to the requester.
Resolving Name Server
What is the requester in this situation? In almost all cases, the requester will be what we call a “resolving name server.” A resolving name server is one configured to ask other servers questions. It is basically an intermediary for a user which caches previous query results to improve speed and knows the addresses of the root servers to be able to “resolve” requests made for things it doesn’t already know about. The resolving name servers are usually provided by an ISP or other organizations. For instance Google provides resolving "DNS servers" that you can query. These can be either configured in your computer automatically or manually.
When you type a URL in the address bar of your browser, your computer first looks to see if it can find out locally where the resource is located. It checks the “hosts” file on the computer and a few other locations. It then sends the request to the resolving name server and waits back to receive the IP address of the resource. The resolving name server then checks its cache for the answer. If it doesn’t find it, it goes through the steps outlined above.
Within the zone file, we can have many different record types. We will go over some of the more common (or mandatory types) here.
The Start of Authority, or SOA, record is a mandatory record in all zone files.
ns1.example.com defines the primary name server for this domain
admin.example.com.: This is the email address of the administrator for this zone. The “@” is replaced with a dot in the email address
12083: This is the serial number for the zone file.
Map a host to an IP address. The "A” record is used to map a host to an IPv4 IP address. The general format is this:
host IN A IPv4_address
So since our SOA record called out a primary server at “ns1.example.com”, we would have to map this to an address to an IP address since “ns1.example.com” is within the “example.com” zone that this file is defining. The record could look something like this:
ns1 IN A 220.127.116.11
Notice that we don’t have to give the full name. We can just give the host, without the FQDN and the DNS server will fill in the rest with the $ORIGIN value. However, we could just as easily use the entire FQDN if we feel like being semantic:
ns1.example.com. IN A 18.104.22.168
We should also tell where the base domain resolves to. We can do this like this:
example.com. IN A 22.214.171.124
MX records are used to define the mail exchanges that are used for the domain. This helps email messages arrive at your mail server correctly. Unlike many other record types, mail records generally don’t map a host to something, because they apply to the entire zone. As such, they usually look like this:
IN MX 10 mail.example.com.
Note that there is no host name at the beginning.
Also note that there is an extra number in there. This is the preference number that helps computers decide which server to send mail to if there are multiple mail servers defined. Lower numbers have a higher priority. The MX record should point to a host defined by an A record,
This record type defines the name servers that are used for this zone. You may be wondering, “if the zone file resides on the name server, why does it need to reference itself?”. Part of what makes DNS so successful is its multiple levels of caching. One reason for defining name servers within the zone file is that the zone file may be actually being served from a cached copy on another name server.
Like the MX records, these are zone-wide parameters, so they do not take hosts either. In general, they look like this:
IN NS ns1.domain.com.
IN NS ns2.domain.com.
You should have at least two name servers defined in each zone file in order to operate correctly if there is a problem with one server. Most DNS server software considers a zone file to be invalid if there is only a single name server. As always, include the mapping for the hosts with A or AAAA records:
IN NS ns1.example.com.
IN NS ns2.example.com.
ns1 IN A 126.96.36.199
ns2 IN A 188.8.131.52
The PTR records are used define a name associated with an IP address. PTR records are the inverse of an A record.
Here is an example of a PTR record for 111.222.333.444 would look like:
444.333.222.111.in-addr.arpa. 33692 IN PTR host.example.com.
Most email servers will look up the PTR record of an IP address it receives email from. If the source IP address does not have a PTR record, the emails being sent may be treated as spam and rejected. It is not important that the FQDN in the PTR matches the domain name of the email being sent. What is important is that there is a valid PTR record with a corresponding and matching forward A record. It is important that the FQDN in the PTR record has a corresponding and matching forward A record. Example: 111.222.333.444 has a PTR of server.example.com and server.example.com is an A record that points to 111.222.333.444. Most providers offering VPS services will give customers the ability to set a PTR record for their IP address.
CAA records are used to specify which Certificate Authorities (CAs) are allowed to issue SSL/TLS certificates for your domain. As of September 8, 2017 all CAs are required to check for these records before issuing a certificate. If no record is present, any CA may issue a certificate. Otherwise, only the specified CAs may issue certificates. CAA records can be applied to single hosts, or entire domains.
An example CAA record follows:
example.com. IN CAA 0 issue "letsencrypt.org"
The host, IN, and record type (CAA) are common DNS fields. The CAA-specific information above is the 0 issue "letsencrypt.org" portion. It is made up of three parts: flags (0), tags (issue), and values ("letsencrypt.org").
How To Choose the Right DNS Configuration
In this guide, we will talk about some of the different types of DNS server setups and what the advantages, use cases, and properties are of each.
The Path of a DNS Query
When a client program wants to access a server by its domain name, it must find out how to translate the domain name into an actual routable ip address that it can use to communicate. It needs to know this information in order to get or send information to the server.
Some applications, including most web browsers, maintain an internal cache of recent queries. This is the first place the application will check, if it has this capability, in order to find the IP address of the domain in question. If it does not find the answer to its question here, it then asks the system resolver to find out what the address of the domain name is.
The system resolver is the resolving library that your operating system uses to seek out the answer for DNS queries. In general, system resolvers are usually what we consider stub resolvers because they are not capable of much complexity beyond searching a few static files on the system (like the /etc/hosts file) and forwarding requests to another resolver.
So generally, a query goes from the client application to the system resolver, where it is then passed to a DNS server that it has the address for. This DNS server is called a recursive DNS server. Recursive servers maintain a cache. It will check this cache first to see if it already has the answer to the query. If it does not, it will see if it has the address to any of the servers that control the upper level domain components. So if the request is for example.com and it cannot find that host address in its cache, it will see if it has the address of the name servers for example.com and if necessary, com. It will then send a query to the name server of most specific domain component it can find in order to query for more information.
If it does not find the address to any of these domain components, it has to start from the very top of the hierarchy by querying the root name servers. The root servers know the addresses of all of the TLD (top level domain) name servers which control zones for .com, .net, .org, etc. It will ask the root servers if it knows the address of to example.com. The root server will refer the recursive server to the name servers for the .com TLD.
The recursive server then follows the trail of referrals to each successive name server that has been delegated responsibility for the domain components, until it can zero in on the specific name server that has the full answer. It puts this answer into its cache for later queries and then returns it to the client.
As you can see from this example, there are many different kinds of servers, and they each play a different role. Let’s go over the specifics of the different types of DNS servers.
Most servers that are involved with implementing DNS are specialized for certain functions.
Authoritative-Only DNS Servers
An authoritative-only DNS server is a server that only concerns itself with answering the queries for the zones that it is responsible for. Since it does not help resolve queries for outside zones, it is generally very fast and can handle many requests efficiently.
Will not respond to recursive queries. The very definition of an authoritative-only server is one that does not handle recursive requests. This makes it a server only and never a client in the DNS system.
Caching DNS Server
A caching DNS server is a server that handles recursive requests from clients. Almost every DNS server that the operating system’s stub resolver will contact will be a caching DNS server. Caching servers have the advantage of answering recursive requests from clients. While authoritative-only servers may be ideal for serving specific zone information, caching DNS servers are more broadly useful from a client’s perspective. They make the DNS system of the world accessible to rather dumb client interfaces. A caching DNS server maintains a cache of recently requested data. By caching the results as it collects them from other DNS servers for its client requests, a caching DNS server builds a cache for recent DNS data.
Forwarding DNS Server
A alternative take on developing a cache for client machines is through the use of a forwarding DNS server. This approach adds an additional link in the chain of DNS resolution by implementing a forwarding server that simply passes all requests to another DNS server with recursive capabilities (such as a caching DNS server).
The advantage of this system is that it can give you the advantage of a locally accessible cache while not having to do the recursive work (which can result in additional network traffic and can take up substantial resources on high traffic servers). This can also lead to some interesting flexibility in splitting your private and public traffic by forwarding to different servers.
A forwarding DNS server has the following properties:
The ability to handle recursive requests without performing recursion itself. The most fundamental property of a forwarding DNS server is that it passes requests on to another agent for resolution.
Provide a local cache at a closer network location. Particularly if you do not feel up to building, maintaining, and securing a full-fledged recursive DNS solution, a forwarding server can use public recursive DNS servers.
Increases flexibility in defining local domain space. By passing requests to different servers conditionally, a forwarding server can ensure that internal requests are served by private servers while external requests use public DNS.
While the above solutions are built with very specific purposes in mind, it is often desirable to set up your DNS server to combine the advantages of each. A DNS server may be configured to act as a recursive, caching server for a select number of local clients, while answering only iterative, authoritative requests from other clients. This is a common configuration because it allows you to answer global requests for your domain, while also allowing your local clients to utilize the server for recursive resolution.
While certain DNS software is specially designed to fulfill one specific role, applications like Bind are incredibly flexible and can be used as hybrid solutions.
Especially in the case of small infrastructure, it makes the most sense to maintain a single, all-in-one solution.
Primary and Secondary Servers
Given the importance of DNS in making services and entire networks accessible, most DNS servers that are authoritative for a zone will have built-in redundancy. There are various terms for the relationships between these servers, but generally, a server can either be a primary or a secondary in its configuration.
Both primary and secondary servers are authoritative for the zones they handle. The primary does not have any more power over the zones than the secondary. The only differentiating factor between a primary and a secondary server is where they read their zone files from. A primary server reads its zone files from files on the system’s disk. These are usually where the zone administrator adds, edits, or transfers the original zone files.
The secondary server receives the zones that it is authoritative for through a zone transfer from one of the primary servers for the zone. Once it has these zones, it places them in a cache. If it has to restart, it first checks its cache to see if the zones inside are up-to-date. If not, it requests the updated information from the primary server.
Servers are not relegated to only be a primary or a secondary for all of the zones they handle. Primary or secondary status is assigned on a zone-by-zone basis, so a server can be a primary for some zones and a secondary for others. Any zone responsible for an internet routable zone must have at least two name servers.
Public vs Private Servers
Often, organizations use DNS both externally and internally. However the information that should be made available in both of these spheres is often drastically different. An organization might maintain an externally available authoritative-only DNS server to handle public DNS queries for the domains and zones that it handles. For its internal users, the organization might use a separate DNS server that contains the authoritative information that the public DNS provides, as well as additional information about internal hosts and services. It might also provide additional features, such as recursion and caching for its internal clients.
While we mentioned the ability to have a single server handle all of these tasks in the “combination” server above, there are definite advantages to splitting the workload. In fact, maintaining completely separate servers (internal vs external) that have no knowledge of each other is often desirable. It is especially important, from a security standpoint, that the public server has no records of the private counterpart. This means not listing your private name servers with NS records in the public zone files.
There are some additional considerations to keep in mind. While it might be easier to have your public and private servers share zone data that they have in common in a traditional primary-secondary relationship, this can leak information about your private infrastructure into the wild.
Beyond just keeping your private servers out of the zone files themselves (essentially a publicly searchable entity), it is usually a good idea to also remove any reference to the private server in the public server’s configuration files. This means removing transfer, notify, and primary configuration details so that a compromise of the public server does not mean that your internal name servers are suddenly exposed.
This means maintaining separate zone files for each, which can be extra work. However, this may be necessary for absolute separation and security.
DNS forwarding is the process by which particular sets of DNS queries are handled by a designated server, rather than being handled by the initial server contacted by the client. Usually, all DNS servers that handle address resolution within the network are configured to forward requests for addresses that are outside the network to a dedicated forwarder.
When deciding how to allocate DNS resources on a network it’s important to implement some separation between external and internal Domain Name Services. Having all DNS servers configured to handle both external and internal resolution can impact the performance and security of a network.
If no DNS server is designated as the forwarder to which external queries are routed, then all DNS servers within the network will handle external requests, which means that they will query external resolvers. This is undesirable for two main reasons.
First, internal DNS information can be exposed on the open Internet. It’s far better to have a strict separation between internal and external DNS. Exposing internal domains on the open Internet creates a potential security and privacy vulnerability.
Second, without forwarding, all DNS servers will query external DNS resolvers if they don’t have the required addresses cached. This can result in excessive network traffic. By designating a DNS server as a forwarder, that server is responsible for all external DNS resolution and can build up a cache of external addresses, reducing the need to query recursive resolvers and cutting down on traffic. For smaller companies with limited available bandwidth, DNS forwarding can increase the efficiency of the network by both reducing bandwidth usage and improving the speed at which DNS requests are fulfilled.
Now that we have a better understanding of how the Internet works, in the next article, we will look at how to connect our Virtual Private Server to the Internet.