DNS Quick Start

Summary

A quick but technical overview of DNS.
How to go from domain registration to a functioning website.
Uses my website as an example, which is hosted on AWS using S3, CloudFront, and Route 53.

DNS Overview

DNS stands for Domain Name System. Its purpose is to determine the IP address for a given domain name, which is the first part of a URL (Universal Resource Locator). The IP address is what is actually used to connect to a server. Any time a system attempts to connect to a server (for the first time), a request is made to the DNS server configured for that system, which returns the IP address.

The first part of the URL is the domain name. That is, the part between the protocol (e.g. "http://") and the first slash ("/"), such as "example.com"

DNS is hierarchical. Each level has servers. The servers at any given level have records that point to the servers at the level below it.

Using "example.com" as an example, the root domain servers contain a record for the "com". The "com" servers (also called the Top Level Domain (TLD) Name Servers) contain a record for "example". "example.com" has three levels of DNS servers, the root, the TLD (com), and the "example". (Though, there is nothing that says several levels can't share a server. "blog.example.com" might well be served on the same server as "example.com".

Of note, there is an implicit period at the end of the domain name. So, "example.com." is equivalent to "example.com".

DNS Resolution

DNS is resolved by a "recursive resolver", which is also known as the "DNS server" in system configuration prompts. This server makes a series of requests, starting with the root domain server, until it finds the ip of the requested domain name. Then it sends the answer back to the requester.

A DNS server gets configured on each system to make domain name resolution work. For example, in windows, you specify a DNS server in this dialog box (Network and Sharing Center → Change Adaptor Settings → right click adaptor (e.g. wifi) → properties → select "Internet Protocol Version 4" → properties (button) )

In this screenshot, note that the DNS server is set automatically, which means it is configured by DHCP. It is possible to see the IP of the server that is actually used with the following command:

$ ipconfig /all

Windows IP Configuration

(abridged)

DNS Servers . . . . . . . . . . . : 192.168.1.1
  

On my home network, this is my wireless router. (The same address is likely used for your wireless router.) In a corporate environment, this would probably be a dedicated DNS server provided by the IT department.

The DNS server has the option of caching results so that it does not have to do the same lookup repeatedly. (The local system also has this option.)

Let's look at the end-result of DNS resolution. That is, the information that is returned by resolving a domain name:

$ dig reusabit.com

; <<>> DiG 9.11.9 <<>> reusabit.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14105
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;reusabit.com. IN A

;; ANSWER SECTION:
reusabit.com. 60 IN A 13.225.146.16
reusabit.com. 60 IN A 13.225.146.104
reusabit.com. 60 IN A 13.225.146.34
reusabit.com. 60 IN A 13.225.146.64

;; Query time: 97 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Mon Oct 05 11:23:53 MDT 2020
;; MSG SIZE rcvd: 105
  

(Note: This is a Linux command. It is available on Windows by using Cygwin.)

The key here is the answer section. This example shows the four IP addresses that host our webpage. (There are four because it is hosted on CloudFront, which is AWS's Content Delivery Network (CDN).) A client is supposed to pick one of the four at random.

Domain Name Registration

Now we will look at this from the other direction, beginning with registering a domain name. Keep in mind as we look at these specific examples, that different registrars vary as to their interface, but should have similar capabilities.

We will first look at a domain which we own, but haven't used, robpulsipher.com. We registered the domain, but haven't changed any configuration, so this looks as if I had registered it today. If you go to the URL, you will just see a little page hosted by the registrar:

We use gandi.net as a domain name registrar. In this case, our registrar is providing three distinct functions. First, it registers our domain name with the TLD name servers. Second, it provides the domain name servers that host DNS records for our zone (domain name). Third, it is hosting the little webpage that you see.

The registrar has a configuration page that allows configuration of "Nameservers". In other words, this is where we configure the records that the registrar submits to the TLD name servers on our behalf. In this case, the records point to the registrar's own DNS servers.

The registrar has another configuration page that allows configuration of the "DNS Records". These records are hosted by the registrar's domain servers for our domain. The A (address) record has the IP4 address of the webserver (also owned by the registrar) hosting the parking page. (If using IP6, an AAAA record would hold the IP6 address.) The MX records configure email (which, in this case, is also hosted by the registrar). If we wanted to continue using the registrar's domain servers, we could simply change the A record here to the address of our web server. Instead, we will switch domain name service over to Route 53 (AWS's domain name service).

Data from the screen shot above:

@ 10800 IN SOA ns1.gandi.net. hostmaster.gandi.net. 1553226344 10800 3600 604800 10800
@ 10800 IN A 217.70.184.38
@ 10800 IN MX 10 spool.mail.gandi.net.
@ 10800 IN MX 50 fb.mail.gandi.net.
@ 10800 IN TXT "v=spf1 include:_mailcust.gandi.net ?all"
blog 10800 IN CNAME blogs.vip.gandi.net.
imap 10800 IN CNAME access.mail.gandi.net.
pop 10800 IN CNAME access.mail.gandi.net.
smtp 10800 IN CNAME relay.mail.gandi.net.
webmail 10800 IN CNAME webmail.gandi.net.
www 10800 IN CNAME webredir.vip.gandi.net.
  

Configuring DNS for a Website on AWS

For this example, we will switch to our active website (reusabit.com). We use AWS for hosting. Our website content is stored in an S3 bucket. The content is hosted with CloudFront. Route 53 is the dns service. As the intent of this tutorial is to discuss DNS, we will focus on the integration points with AWS. While this example covers AWS, performing these actions for another platform would be similar.

To get to this point, you could create your content in S3, create a CloudFront distribution, and then create a Hosted Zone in Route 53.

In order to use Route 53 for DNS, we need the TLD name servers to have records for our domain that point to the appropriate Route 53 servers. Our registrar does this on our behalf, based on configuration on the registrar's site. We log in, and edit the configuration in the "Nameservers" tab. We get the values to enter here from Route 53. (AWS Console → Route 53 → Hosted Zones → select domain → click the expansion arror next to "Hosted zone details" ) We simply copy this list of nameservers into the configuration on the registrar's site. (But it can take some time for these changes to propagate.)

The DNS records (scrolling down on the same AWS page) are partially reproduced in the table below. To configure the website, we configured an "alias" record in Route 53. This "alias" concept is an AWS extension of the DNS standard. (The same term (alias) is used by at least one other DNS vendor.) But be aware that it is not a standard part of DNS. It functions essentially as an A record, but gets autoconfigured for CloudFront.

Types of DNS Records

You've met the A (and AAAA) records. These are the records that provide the IP address. However, there are several other types of records.

SOA Records

The SOA (Start of Authority) record is required for each zone. When using a DNS service, it is typically provided by the service provider. The format is beyond the scope of this tutorial.

CNAME Records

A CNAME (canonical name) record sets up essentially an alias (not to be confused with the alias mechanism described above). For example, if there is a CNAME record for "www.example.com" that points to "example.com", you can access the same site using either address. They both return the same IP address upon resolution.

(Note, however, that this is not the typical approach to handling "www" sites. Instead, use an HTTP redirect response for the www site that redirects to the non-www address. This way links/bookmarks/etc. are consistent.)

MX Records

MX (mail exchange) records are used to configure the mail server for your domain. An email address has the format address@domain. There is a crucial piece of missing information in an email address. Specifically, what server should the message get sent to? When you send an email, this information gets looked up via DNS. The MX record allows you to configure this.

You might notice that we copied the MX records from our domain registrar when we switched over to Route 53 for DNS. We copied these records because we still use the email service provided by our domain registrar (another separate service). To make this work after we stopped using registrar's DNS servers, we needed to import this record into the new DNS service.

This is also how you would set up any third party email solution (e.g., Microsoft 365). (This would work the same way if you left your DNS service with your registrar.)

TXT Records

TXT records are used for a variety of things. The content of the TXT record can determine what it is for.

One common type of TXT record is an SPF (Sender Policy Framework) record. This TXT record is where the content begins with "spf". The purpose of this record is to specify servers that are allowed to send mail from your domain, so as to prevent spoofing (emails that someone sent that look like they came from you). The format of this record is beyond the scope of this tutorial.

Additional Resources

There is an excellent course covering DNS on LinkedIn Learning at https://www.linkedin.com/learning/managing-dns-essential-training.

Contact

I can be contacted by email at rob@reusabit.com. Feel free to reach out if you have questions, comments, or suggestions about this article.