The DNS Crash Course Nobody Asked For (But Everyone Needs)
I once hosted a small blog on Ghost.org that served as as a therapeutic space where I expressed personal thoughts. However, as time passed, I realized I wasn’t fully utilizing the robust features Ghost offered, and my website traffic was very limited. I decided to migrate my blog to a more cost-effective solution: deploying it on Cloudflare Workers.
What initially seemed like a straightforward migration turned into an adventure through the world of DNS. Along the way, I acquired valuable lessons that I’d love to share with you.
DNS Fundamentals
1. Nameservers
As you know the heart of the internet lies the Domain Name System (DNS). Its what transforms human-readable domain names like www.myapp.com into IP addresses like 192.0.2.1. The relationship between the domain name and the IP address is defined in DNS databases called Nameserver.
Nameservers are organized in a hierarchical structure with different types: Root Nameservers, TLD Nameservers and Authoritative Nameservers.
-
Root Nameservers
The root nameservers are at the very top of the DNS hierarchy. There are exactly 13 root nameserver clusters (labeled from a to m) worldwide, and they hold the knowledge of all Top-Level Domain (TLD) nameservers (like .com, .org). They direct DNS queries to the appropriate TLD nameservers.
a.root-servers.net - Verisign b.root-servers.net - University of Southern California c.root-servers.net - Cogent Communications d.root-servers.net - University of Maryland e.root-servers.net - NASA f.root-servers.net - Internet Systems Consortium g.root-servers.net - US Defense Information Systems Agency h.root-servers.net - US Army Research Lab i.root-servers.net - Netnod j.root-servers.net - Verisign k.root-servers.net - RIPE NCC l.root-servers.net - ICANN m.root-servers.net - WIDE Project -
TLD Nameservers
TLD (Top Level Domain) is the last segment of a domain name (like .com, .org, .net, or country codes like .fr, .uk). TLD Nameservers are responsible for directing traffic to specific domains under their control. They know all domains within their TLD.
For instance, Nameservers like Verisign manage the .com and .net TLDs.
-
Authoritative Nameservers
The Nameservers that actually hold your domain's DNS records. They can be managed by various DNS providers like Cloudflare, AWS, or a domain registrar like GoDaddy.
2. Zones
Here's where I first got confused. I thought a zone was just another name for a domain. Its more than that actually. It’s more accurate to think of a it as an administrative space under your control, including:
- The domain itself
- All subdomains (unless delegated)
- Associated DNS records
In my case, everything under myapp.com was my zone.
Zone delegation allows you to assign control over subdomains to different Nameservers.
3. DNS Resolution
When a user types a domain name into their browser, the process begins to translate that name into an IP address. This involves a component of the operating system called a DNS resolver. Here's how it works step-by-step:
- Local DNS Cache: The resolver first checks its own cache to see if it already knows the IP address for the requested domain. If the record exists and is still valid (TTL hasn't expired), it uses that cached result for immediate access.
- Root Nameservers: If nothing is found locally, the resolver turns to the root nameservers. These servers respond with the TLD nameserver responsible for the requested domain.
- TLD Nameservers: The resolver queries the identified TLD nameserver, which subsequently points the resolver to the authoritative nameserver for the specific domain.
- Authoritative Nameservers: Lastly, the resolver reaches out to the authoritative nameserver, which holds the record containing the actual IP address for the domain.
You can observe and debug this entire resolution process using the dig command, a powerful tool for investigating DNS records.
# Trace the full resolution path
dig +trace myapp.com
# See root nameservers your computer uses
dig NS .
4. Resource Records (RR)
Information on domain names is stored as Resource Records (RR) within DNS servers. Each record represents various types of data about a domain. Here's a simplified syntax of how these records are structured:
[name] [TTL] class type data_dependent_on_the_type_of_a_record
// Fields in [ ] are optional
// NAME: The domain name.
// TTL: Time to live, in seconds.
// CLASS: Typically IN (Internet).
// TYPE: The type of DNS record (A, CNAME, MX, etc.).
Here are some of the most common DNS record types you’ll encounter:
| Type | Purpose |
|---|---|
| A | Points a domain to an IPv4 address. The IP address should not have a dot at the end. |
| CNAME | Creates an alias pointing to another domain. When using CNAME, always include the full domain name with a dot at the end. If the dot is not included, the name of the domain is added. |
| NS | Defines authoritative nameservers for a domain. |
| MX | Specifies the mail server responsible for receiving incoming emails. |
| SOA | Contains administrative information regarding the domain, including the primary nameserver. |
| TXT | Holds text information, often for verification or other data purposes. |
Practice
Let’s assume I bought a domain myapp.com with a fictitious IP address 111.22.333.44. The initial DNS configuration looks like this:
// DNS Records
@ 10800 IN A 111.22.333.44
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.
@ 10800 IN MX 50 fb.mail.gandi.net.
@ 10800 IN MX 10 spool.mail.gandi.net.
@ 10800 IN TXT "v=spf1 include:_mailcust.gandi.net ?all"
// Nameservers
a.dns.gandi.net
b.dns.gandi.net
c.dns.gandi.net
1. Breaking Down Main Records
@ represents the root domain myapp.com . The entry of type A indicates that the root domain points to the IP address 111.22.333.44.
All records use a TTL of 10800 seconds (3 hours). Long enough to reduce DNS server load and short enough to allow changes within a reasonable time. Consider lowering before planned changes.
blog CNAME entry is an alias to another domain. This sets blog.myapp.com to point to Gandi's blog hosting service.
Records for email imap, pop, and smtp specify the routes for retrieving and sending emails through Gandi's mail servers.
MX records indicates two servers that handle incoming emails. 10 and 50 define priority. Lower number (10) = higher priority
2. Pointing to My Ghost Blog
To connect to my Ghost blog, the admin dashboard requested that I add the following records:
TYPE HOST VALUE
CNAME www myapp.ghost.io # For root domain
A @ 123.123.123.123 # For subdomain (Fake IP)
When pointing a domain to Ghost (or any web service), you typically need two records because of a DNS limitation. CNAMEs can only point to other domains, while A records need to directly point to an IP address.
3. Adding Cloudflare
I switched my nameservers on Gandi to Cloudflare:
a.dns.gandi.net
b.dns.gandi.net
c.dns.gandi.net
// Becomes
xxx.ns.cloudflare.com
yyy.ns.cloudflare.com
Cloudflare then scans and copies my existing records (but some need manual deletion).
But even if this the setup looked good, it was not working. After some research it I discovered I couldn't use the proxied mode with Ghost due to SSL and CDN conflicts.
Ghost already provides SSL and CDN. They explicitly recommends running in DNS-only mode with Cloudflare. Here’s a quick comparison:
| Proxied (Orange Cloud): | DNS Only (Gray Cloud): |
|---|---|
✓ Free SSL certificate | ✓ Only DNS resolution |
// Without Cloudflare:
User → Gandi DNS → Ghost's servers
// With Cloudflare (proxied) -> This setup does not work
User → Gandi NS records → Cloudflare DNS → Cloudflare PROXY → Ghost's servers
// With Cloudflare (DNS only) -> This setup works
User → Gandi DNS → Cloudflare DNS → Ghost's servers
4. Switching to the Cloudflare Worker app
At this point I had my initial blog deployed on Ghost and uses Cloudflare DNS and I had my new Worker app deployed on Cloudflare workers without any domain name.
Cloudflare offers an UI to do easily points a custom domain (already scanned in their platform) to a Worker. You have to choose the domain or subdomain and it adds the record needed automatically.
For instance, this operation creates a non standard type of records called Worker .
Worker www.myapp.com my-app-worker
The "Worker" record type in Cloudflare DNS seems to be like a higher-level abstraction over traditional DNS records, specific to Cloudflare's infrastructure. It make sense in a serverless environment, the routing have some special needs and IPs change I guess.
This config worked well for www.myapp.com but the root domain myapp.com was not reachable. I had to add a redirection to www subdomain.
First, I tried two features from Cloudfalre infra: Rules and Page Rules but without any success. The config looked good but could not figure out my it was not working.
Finally, I decided to add a straightforward CNAME record, and bingo! It worked like a charm.
CNAME myapp.com www.myapp.com
Debugging
During this journey, I discovered two effective DNS debugging tools that helped a lot.
First, WhatsMyDNS.net. This website provides a world map displaying your DNS propagation status. It's an invaluable tool for confirming whether your changes have dispersed across all nameservers.
Second, is dig command. The dig (Domain Information Groper) command is a DNS lookup utility that helps you query DNS nameservers for various DNS records. Here are some common usages:
# Basic syntax
dig [options] domain [type]
# Check current DNS settings
dig myapp.com
dig www.myapp.com
# Trace the full resolution path
dig +trace myapp.com
# Return answer only
dig +short myapp.com
# See root nameservers your computer uses
dig NS .
# Check propagation against a Nameserver
# @8.8.8.8 # Google DNS
# @1.1.1.1 # Cloudflare DNS
# @208.67.222.222 # OpenDNS (Cisco)
dig @8.8.8.8 myapp.com
dig @1.1.1.1 myapp.com
Conclution
What began as a cost-saving migratio transformed into an exponential learning experience about the inner workings of DNS.
Not only did I save money by transitioning to Cloudflare Workers, but I also gained a profound understanding of DNS operations.
Now I feel significantly more confident when deploying new projects or troubleshooting issues.
I hope this article provides you with a clearer insight into how the DNS functions.