2.4. DNS

Table of Contents

Why DNS Exists

When you open a website, you type a name like example.com, not an IP address like 93.184.216.34. Computers on the internet, however, use IP addresses to talk to each other.

DNS, which stands for Domain Name System, is the system that translates human friendly domain names into machine friendly IP addresses. It is often called the "phonebook of the internet."

Without DNS, you would have to remember and type IP addresses for every site:

Instead of google.com, you would type something like 142.250.185.78.
Instead of wikipedia.org, you would type something like 208.80.154.224.

For backend development, understanding DNS matters because it affects how your API is reached, how you point domains to your servers, and how production issues can be caused by misconfigured DNS records.

DNS exists to map names to IP addresses, so clients can reach servers using readable domain names.

Basic DNS Concepts

DNS is a distributed database spread across many servers worldwide. No single server knows everything, but together they provide the complete mapping of domain names to records.

Some key concepts:

Domain: A name like example.com that you can register and configure.

Subdomain: A name that is a part of a domain, like api.example.com or blog.example.com.

Hostname: Often used to mean a specific name that points to a server, typically a domain or subdomain like www.example.com or api.example.com.

Zone: A portion of the DNS namespace managed by a particular authority. When you manage DNS for example.com at a DNS provider, that DNS configuration is the example.com zone.

Record: An entry within a zone that maps a name to some data. For example, api.example.com to an IP address.

Most backend developers work directly with records, not the deeper implementation details of DNS servers.

How DNS Resolves a Domain

When you type https://api.example.com in your browser, the browser must translate api.example.com to an IP address before it can connect.

Here is a simplified sequence of what happens:

Your application or browser checks its own cache. If it recently looked up api.example.com, it might already know the IP and skip the rest.
If not cached locally, the request goes to a DNS resolver, usually operated by your ISP or a public DNS provider like Google DNS (8.8.8.8) or Cloudflare (1.1.1.1).
The resolver checks its own cache. If not present, it performs a recursive lookup by asking other servers:

A root DNS server, which tells it where to find the TLD (Top Level Domain) servers for .com.
A .com TLD server, which tells it which nameservers are authoritative for example.com.
The authoritative nameserver for example.com, which returns the final answer, for example the IP address of api.example.com.

The resolver returns the IP to your browser, and usually caches it for a certain time.
Your browser connects to that IP address on the appropriate port, typically port 80 or 443 for web traffic.

From a backend developer’s perspective, the important parts are:

There is caching at multiple layers, so DNS changes are not instant.
A failure at the DNS resolver or authoritative server can make your service unreachable, even if your server is healthy.

Root, TLD, and Authoritative Servers

The DNS system is hierarchical.

At the top are root servers. They do not know every domain, but they know where to find the servers for top level domains such as .com, .org, .net, .io.

Below that are TLD servers. A .com TLD server knows which authoritative nameservers are responsible for domains like example.com, github.com, google.com.

Authoritative nameservers hold the final records for a domain. If you use a DNS provider such as Cloudflare, AWS Route 53, or your domain registrar’s DNS, their servers act as authoritative nameservers for your domain.

Example of the path for resolving api.example.com:

Root server: "I do not know api.example.com, but here are the nameservers for .com."
.com TLD server: "I do not know api.example.com, but example.com is managed by these authoritative nameservers: ns1.dns-provider.net, ns2.dns-provider.net."
Authoritative server: "For api.example.com, the IP address is 203.0.113.10."

Once that answer is obtained, it can be cached for some time.

DNS Records You Must Know

DNS records are typed entries in the DNS zone for a domain. Each type has a specific purpose. As a backend developer, you will regularly deal with at least A, AAAA, CNAME, and TXT records.

The most common DNS record types are:

Record type	Purpose	Example use
A	Maps a name to an IPv4 address	`api.example.com` → `203.0.113.10`
AAAA	Maps a name to an IPv6 address	`api.example.com` → `2001:db8::1`
CNAME	Creates an alias from one name to another	`www.example.com` → `example.com`
MX	Specifies mail servers for a domain	For email delivery to `user@example.com`
TXT	Stores arbitrary text data	SPF records, domain verification, etc.
NS	Specifies authoritative nameservers for zone	`example.com` uses `ns1.provider.com`, `ns2...`
SRV	Specifies service discovery records	Some services use for locating specific ports
CAA	Restricts which CAs can issue certificates	Used for TLS certificate security

The records you are most likely to configure when exposing a backend API are A, AAAA, CNAME, and sometimes TXT.

A and AAAA Records

An A record maps a name to an IPv4 address. For instance, suppose your API server is at IPv4 address 203.0.113.10. You might set up:

Name	Type	Value
`api.example.com`	A	`203.0.113.10`

Now a DNS lookup for api.example.com will return that IPv4 address, and clients can connect.

An AAAA record is similar, but for IPv6 addresses. For example:

Name	Type	Value
`api.example.com`	AAAA	`2001:db8:abcd::10`

You can have both A and AAAA records for the same hostname. Clients that support IPv6 might use the AAAA record, while others use the A record.

As a backend developer deploying APIs, you often receive a server IP address from your hosting provider or cloud platform, and then you create A and possibly AAAA records to point your domain to that IP.

An A record maps a hostname to an IPv4 address, and an AAAA record maps a hostname to an IPv6 address.

CNAME Records

A CNAME record creates an alias from one name to another canonical name. For example, suppose your main domain points to your server:

Name	Type	Value
`example.com`	A	`203.0.113.10`

You can then create:

Name	Type	Value
`www.example.com`	CNAME	`example.com`

Now both example.com and www.example.com will end up at the same IP address, because www.example.com resolves to example.com, and example.com resolves to 203.0.113.10.

Common use cases for CNAME records for backend work:

Making api.example.com an alias to a host provided by a cloud load balancer such as lb1234.somecloud.com.
Mapping multiple subdomains to a single canonical name, so you only change one place if the destination changes.

Example:

Name	Type	Value
`api.example.com`	CNAME	`backend-1.hosting.com`
`auth.example.com`	CNAME	`backend-1.hosting.com`

If the hosting provider changes the IP of backend-1.hosting.com, you do not need to modify your CNAME records. They continue to point to that name, which is updated by the provider.

There are practical rules:

The canonical name in a CNAME must be another domain name, not an IP address.
A name that has a CNAME record must not have other record types at the same name in the same zone, except for special cases. For example, you should not have both CNAME and A records for exactly the same name.

MX, TXT, and Other Records

While focusing on backend APIs, you still often encounter MX and TXT records, especially when you implement email verification or password reset features that rely on your domain’s email setup.

MX records:

Indicate which mail servers receive email for your domain.
For example, example.com may have MX records pointing to provider mail servers like mx1.mailprovider.com and mx2.mailprovider.com.

TXT records:

Store arbitrary text. They are heavily used for:

SPF records that specify which servers may send email for your domain.
DKIM and DMARC records for email security.
Domain verification for third party services, for example to prove ownership of example.com to an email sending service or cloud provider.

A TXT record might look like this:

Name: _acme-challenge.example.com
Type: TXT
Value: some-verification-token

As a backend engineer, when integrating with mail providers or cloud services, you will often be instructed to add specific TXT records to your DNS.

SRV and CAA records:

SRV records specify service locations, including host and port for particular protocols. Some systems use them for auto discovery, but they are less common in basic web and API hosting.
CAA records restrict which certificate authorities are allowed to issue TLS certificates for your domain. They are useful for improving security of HTTPS, which is covered elsewhere.

DNS Lookup Examples

You can inspect DNS records from the command line. This is very useful when debugging backend issues.

On Linux or macOS, you might use dig or nslookup. For example:

Using dig to resolve an A record:

bash

dig api.example.com A

You might see a result that includes:

text

;; ANSWER SECTION:
api.example.com.   300   IN   A   203.0.113.10

This shows that api.example.com has an A record pointing to 203.0.113.10 with a TTL of 300 seconds.

To see all records, you can use:

bash

dig api.example.com ANY

or for a specific type:

bash

dig example.com MX
dig example.com TXT

On Windows, you can use:

powershell

nslookup api.example.com

For a TXT record:

powershell

nslookup -type=TXT example.com

Learning to check DNS from the command line helps you understand if a problem is:

Due to your DNS configuration.
Due to caching and propagation delay.
Or due to something else like server downtime or a firewall issue.

TTL and Caching

DNS responses are cached to reduce the load on DNS servers and speed up lookups. Each DNS record has a Time To Live, usually abbreviated as TTL, measured in seconds. The TTL tells resolvers how long they can cache the record before they must ask again.

For example:

Name	Type	TTL	Value
`api.example.com`	A	300	`203.0.113.10`

This means that once a resolver looks up api.example.com, it can store the result for 300 seconds, which is 5 minutes. During that time, it will reuse the cached IP and will not ask the authoritative server again.

TTL controls how long DNS answers are cached. Lower TTL means faster updates but more DNS traffic. Higher TTL means slower updates but fewer DNS queries.

If you change a DNS record, users might still see the old IP until the cached TTL expires. That delay is often called DNS propagation.

Example strategy when you plan to move your API to a new server:

A day before the migration, reduce the TTL of api.example.com from something like 3600 seconds to 300 seconds.
Wait for at least the original TTL so caches holding the old long TTL expire.
Perform the migration. Change the A record to the new IP.
Because the TTL is now 300 seconds, most clients will see the new IP within a few minutes.
After migration, you may increase the TTL again if you want fewer DNS queries.

DNS and Backend Deployments

When you deploy your backend in production, you almost always interact with DNS.

Typical flow when launching api.example.com:

You register a domain, for example example.com, at a domain registrar.
You choose or configure DNS hosting for that domain. This may be the registrar itself, or another provider such as Cloudflare or AWS Route 53.
At your DNS provider, you create records:

An A record for example.com to point to your main web server.
An A record or CNAME record for api.example.com to point to your API server or load balancer.

You configure your backend application server or reverse proxy to respond to api.example.com. Browsers and clients can now reach your API at https://api.example.com.

If you migrate to a different provider, you usually:

Keep the same domain api.example.com.
Update the DNS record to point to the new provider’s IP address or hostname.
Wait for DNS propagation to take effect.

If something goes wrong and you see error messages like "Server not found" or "DNS_PROBE_FINISHED_NXDOMAIN", this can indicate:

The domain name has no DNS record configured.
The DNS record for that subdomain is misconfigured or missing.
The nameservers for the domain are not set correctly at the registrar.

Knowing how DNS records are structured lets you diagnose these issues quickly.

DNS Tools for Developers

Backend developers typically use both command line tools and online tools to inspect DNS.

Command line tools:

dig for detailed queries and debugging.
nslookup for simple queries and quick checks.
host for basic lookups.

Online tools:

Web based DNS checkers that show A, AAAA, CNAME, MX, TXT, and NS records.
Global propagation checkers that show what different resolvers around the world see, which is useful to see if a change has propagated.

Example: If you add an A record for api.example.com and it seems not to work for some users, a propagation checker can show if some regions still see the old IP or no record at all.

As you build and deploy backends, it is important to practice:

Creating and editing DNS records for test domains.
Using dig or nslookup to verify that the DNS changes match what you intended.
Checking TTLs and understanding how long changes might take to reach users.

Over time, DNS becomes a routine part of your deployment and maintenance workflow.

2.4. DNS

Why DNS Exists

Basic DNS Concepts

How DNS Resolves a Domain

Root, TLD, and Authoritative Servers

DNS Records You Must Know

A and AAAA Records

CNAME Records

MX, TXT, and Other Records

DNS Lookup Examples

TTL and Caching

DNS and Backend Deployments

DNS Tools for Developers

Comments

Where to Move