Recently for an active project I wanted to link the main domain sprakit.com to one hoster and a subdomain beta.sprakit.com to another hoster. Technically, this is not a big deal, but it’s simpler with a basic understanding of the DNS record and its entries.

DNS lookup process

Whenever you want to visit a domain, your operating system has to find out the corresponding IP. This is of course a simple lookup table problem, but having all domain names around the world in a local table would be a bit too much and a many entries would change each day. Thus, your local computer will never have all hostnames resolvable. In fact, depending on the operating system and setup you are using, you might not even use a cache at all. Standard linux operating systems without additional software do not use a cache.

Whether your operating system does use a DNS cache or not, it will always start up the local resolver on a DNS request. This tries to resolve the hostname to an IP locally, e.g. by looking through the DNS cache and checking a local hosts file (/etc/hosts on linux).

Whenever your operating system cannot resolve a hostname, it will query the configured nameservers. Some people set this to the own router, other people set it to remote servers (famous 8.8.8.8 at Google) and for standard users it’s usually a nameserver at the own ISP.

If this station does have the requested information in its cache, it will respond immediately, otherwise it will start an iterative query. For sake of simplicity, let’s imagine we want to access beta.sprakit.com. During the iterative query it would start at the root nameservers and query for information about the TLD com.

We will look into more detail of the meanings of these outputs later, for now just concentrate onto the first and last column.

[eliteinformatiker@eliteinformatiker-netbook ~]$ drill -T com
com.    172800    IN    NS    a.gtld-servers.net.
com.    172800    IN    NS    b.gtld-servers.net.
[...]

It gets a response for nameservers which are responsible for the com domain. It can send the next request for sprakit.com to any of these nameservers.

eliteinformatiker@eliteinformatiker-netbook ~]$ drill -T sprakit.com
com.    172800    IN    NS    a.gtld-servers.net.
[...]
sprakit.com.    172800    IN    NS    ns.inwx.de.
sprakit.com.    172800    IN    NS    ns2.inwx.de.
[...]
sprakit.com.    3600      IN    A     85.13.141.123

The last line is the IP address for the domain sprakit.com, but this is not the domain of interest. So the iterative query once again has to go on and query for beta.sprakit.com.

[eliteinformatiker@eliteinformatiker-netbook ~]$ drill -T beta.sprakit.com
[...]
beta.sprakit.com.     3600    IN    A     138.201.246.140

And finally the nameserver got the result. With this result, it can update its own cache (in case more requests for this domain will occur) and send the result back to the requesting computer.

DNS records

So let’s have a closer look at the DNS records. These are the configuration entries for your domain and subdomains. They are summarized into a so called zone file.

The most frequent DNS record in this blog post up to now is the NS record. This record determines one or multiple nameservers for a domain. This tells the DNS resolver which server to query for more information on the given domain.

We also saw the A record above. This tells us the IPv4 address for a domain, so this is the information you are often interested in. If you use IPv6, then the relevant record is AAAA.

When you send an email, the MX record is important. This tells the resolver which server is responsible for processing emails. Usually, this is different from the domain you use in the mail address. Imagine you send a mail to me via [something]@sprakit.com. This will not necessarily be handled by the same server that handles the normal requests to sprakit.com. Instead, a DNS query of sprakit.com for MX records will return:

[eliteinformatiker@eliteinformatiker-netbook ~]$ drill sprakit.com MX
[...]
sprakit.com.    3599    IN   MX    10 mail.sprakit.com.
[...]

So, a mail transport agent will know that it should send mails targeted to [something]@sprakit.com to the server under mail.sprakit.com, for which in turn it will have to query the IP address. The MX record should point to a host name, and not directly to an IP address.

Another important DNS record which I currently do not use is CNAME. This sets an alias from one domain to another, the real domain. E.g. you could set www.sprakit.com as an alias to sprakit.com. It’s also possible to set something like ftp.sprakit.com to sprakit.com if they both use the same server (and thus the same A record).

Routing domain and subdomain to different servers

If you still remember the task from the beginning: We wanted to set different servers for the main domain and the subdomain. So sprakit.com should be handled by another server than beta.sprakit.com. Knowing about A records and how DNS is resolved, this is a simple task.

We need of course the standard nameserver entries for NS. And then we set the IP of server 1 for the A record of sprakit.com, while set the IP address of server 2 for the A record for beta.sprakit.com.

I do not maintain a comments section. If you have any questions or comments regarding my posts, please do not hesitate to send me an e-mail to blog@stefan-koch.name.