What Is DNS & How It Works With Examples

You type google.com into your browser and press Enter. A moment later, the website loads.

But here's something interesting: computers don't communicate using names like google.com. They communicate using IP addresses.

So how does your browser know which server to contact?

That's where DNS comes in.

DNS (Domain Name System) is one of the fundamental technologies that makes the internet usable. Developers rely on it every day, whether they're deploying applications, configuring servers, setting up email, or troubleshooting production issues.

If you've ever pointed a domain to a server and wondered why it sometimes takes hours to work, understanding DNS will make a lot more sense of what's happening.

Let's break it down, including a practical example of connecting a custom domain to an application deployed on PieApp.

1. What Is DNS?

DNS stands for Domain Name System. Think of it as the internet's phonebook.

Every server connected to the internet has an IP address. For example:

142.250.183.14

That's an address a computer can use to reach a server. But remembering IP addresses for every website would be impractical.

Instead, we use domain names:

• google.com
• github.com
• piehost.com

DNS translates domain names into the information computers need to find the right destination.

Here's a simple way to understand it:

Component	Example
Domain name	example.com
IP address	93.184.216.34
DNS	Resolves the domain to its destination

Without DNS, you'd have to remember IP addresses instead of website names.

2. How Does DNS Actually Work?

Let's say you type example.com into your browser.

What happens between pressing Enter and seeing the website?

Quite a few things happen behind the scenes.

Step 1: Browser checks its cache

Your browser first checks whether it already has a valid DNS result for the domain.

If it does, it can reuse that information instead of performing another lookup.

Step 2: Operating system checks its cache

If the browser doesn't have the answer, the operating system may have it cached.

Your computer maintains its own DNS cache to avoid repeatedly looking up the same domains.

Step 3: The recursive DNS resolver

If the answer isn't available locally, your computer sends a DNS query to a recursive DNS resolver.

This resolver is usually provided by your internet service provider, but you can also configure public DNS providers.

Some popular options:

• Google DNS: 8.8.8.8
• Cloudflare DNS: 1.1.1.1
• Quad9: 9.9.9.9

The resolver's job is to find the answer for you.

Step 4: The resolver queries the DNS hierarchy

If the resolver doesn't already have a cached answer, it follows the DNS hierarchy.

There are three important components here.

Root DNS servers

These sit at the top of the DNS hierarchy. They don't normally provide the IP address of your website. Instead, they direct the resolver toward the appropriate top-level domain servers.

TLD name servers

TLD stands for Top-Level Domain.

These servers handle domain extensions such as:

• .com
• .org
• .net
• .in

For example, a .com TLD server can direct the resolver to the authoritative name servers responsible for example.com.

Authoritative DNS servers

These servers provide the actual DNS records for a domain.

They know the configured records, such as the domain's IP address, mail servers, and other DNS information.

The resolver queries the authoritative server and gets the answer.

Step 5: Your browser connects to the server

The resolver returns the DNS answer to your computer.

Your browser can now establish a connection to the destination server, negotiate HTTPS if required, and request the webpage.

And that's how a simple domain name gets translated into an actual network connection.

3. Understanding Different DNS Records

DNS does more than map domain names to IP addresses.

It supports several record types, each serving a different purpose.

Here are the records every developer should understand.

A Record

An A record maps a domain name to an IPv4 address.

Example:

example.com    A    93.184.216.34

If you're pointing your domain directly to a server with a public IPv4 address, you'll generally use an A record.

AAAA Record

An AAAA record does the same thing, but for IPv6 addresses.

Example:

example.com    AAAA    2606:2800:220:1:248:1893:25c8:1946

As IPv6 adoption grows, these records are becoming increasingly important.

CNAME Record

A CNAME record makes one domain name an alias of another domain name.

Example:

www.example.com    CNAME    example.com

Instead of pointing directly to an IP address, it points to another hostname.

This is particularly useful when working with hosting platforms, CDNs, and managed deployment services.

One important restriction: a traditional CNAME cannot coexist with other record types at the same DNS name.

MX Record

MX stands for Mail Exchange.

It tells other mail servers where to deliver emails for your domain.

For example, when you configure Google Workspace or another email provider, you'll need to add MX records.

MX records also have priorities. A mail server with a lower priority number is preferred over one with a higher number.

TXT Record

TXT records store text information associated with a domain.

They're commonly used for:

• Domain ownership verification.
• SPF email authentication.
• DKIM configuration.
• DMARC policies.

If you've configured email for your domain, you've probably worked with TXT records.

NS Record

NS stands for Name Server.

NS records identify the authoritative name servers responsible for a domain or delegated subdomain.

For example, if you move your DNS management to Cloudflare, your domain registrar needs to point to Cloudflare's assigned name servers.

CAA Record

CAA records specify which certificate authorities are permitted to issue SSL/TLS certificates for your domain.

This gives domain owners additional control over certificate issuance.

4. What Is DNS Propagation?

Here's a situation most developers have experienced.

You update a DNS record, save the changes, and immediately open your website.

Nothing happens.

You wait a few minutes and try again. Still nothing.

Then, after some time, the website suddenly starts working.

What's going on?

The answer is DNS caching and TTL.

TTL stands for Time To Live. It determines how long a DNS resolver can cache a particular DNS response.

For example:

example.com    A    93.184.216.34    TTL: 3600

A TTL of 3600 seconds means the resolver can cache that answer for up to one hour.

Now imagine you change the IP address to a new server.

Resolvers that still have the old answer cached may continue returning it until their cached entries expire.

This is commonly called DNS propagation.

One important distinction: DNS changes don't physically travel across the internet from one server to another. Different resolvers refresh their cached answers at different times.

That's why one user might reach your new server while another still reaches the old one.

Developer tip: If you're planning a server migration, lower the TTL well before making the DNS change. This can reduce how long resolvers retain the old answer. Lowering TTL immediately before a change won't invalidate answers that are already cached.

5. How DNS Works When Deploying an Application on PieApp

Let's take a practical example.

Imagine you've built a Node.js application or a Laravel API. Everything works locally, and now you want to deploy it to production.

You deploy your application using PieApp, PieHost's managed application deployment platform.

Once the deployment is successful, your application gets a default subdomain:

myapp.pie.host

You can immediately access your application through this address, without purchasing or configuring a separate domain.

But let's say you already own:

api.mycompany.com

You want users to access your application through your own domain instead.

How does DNS fit into this?

Step 1: Deploy your application

Create a PieApp application and connect your Git repository.

PieApp handles the build process, containerization, and deployment.

Once the deployment succeeds, your application becomes accessible through its assigned .pie.host subdomain.

For example:

https://myapp.pie.host

Step 2: Add your custom domain

Open your application settings and configure your custom domain:

api.mycompany.com

PieApp supports custom domains with SSL, so you don't need to manually set up an SSL certificate on your application server.

Step 3: Configure your DNS records

Now you need to tell DNS where your application is hosted.

Open the DNS management panel of your domain provider.

This could be Cloudflare, Namecheap, GoDaddy, or another provider.

Add the DNS record using the target and record type provided by PieApp.

For example, if your hosting platform instructs you to use a CNAME:

Type	Name	Target
CNAME	api	Target provided by PieApp

The exact target depends on your application's domain configuration. Always use the value shown in your hosting dashboard rather than guessing it.

Step 4: Wait for DNS resolution

Once you've saved the record, DNS resolvers need to pick up the new configuration.

You can check whether the domain resolves correctly using:

dig api.mycompany.com

Or query a public resolver:

dig @1.1.1.1 api.mycompany.com

If the record is configured correctly, you'll see the DNS answer returned by the resolver.

Step 5: Enable HTTPS

Your domain should now resolve to the configured hosting destination.

PieApp supports automatic SSL for custom domains. Once domain verification and certificate provisioning are complete, you can access your application securely:

https://api.mycompany.com

That's it.

You've deployed an application, connected your own domain, and enabled HTTPS without manually configuring a web server or managing certificates.

This is a good example of how DNS, application hosting, and SSL certificates work together in a real deployment.

6. How Can Developers Debug DNS Issues?

Understanding DNS is useful. Knowing how to troubleshoot it is even more useful.

Here are a few commands worth keeping in your terminal toolkit.

Using nslookup

Check which IP address a domain resolves to:

nslookup example.com

You can also query a specific DNS resolver:

nslookup example.com 1.1.1.1

Using dig

dig is one of the most useful DNS debugging tools available on Linux and macOS.

Check an A record:

dig example.com A

Check MX records:

dig example.com MX

Check TXT records:

dig example.com TXT

Query Cloudflare DNS directly:

dig @1.1.1.1 example.com

Trace the DNS resolution path

Want to see how a DNS lookup progresses through the hierarchy?

Try:

dig +trace example.com

This is particularly useful when investigating DNS delegation problems.

Check authoritative name servers

You can also inspect which name servers are responsible for a domain:

dig example.com NS

This helps when troubleshooting incorrect nameserver configurations.

Flush your local DNS cache

Sometimes your computer continues using an old DNS result even after you've changed the records.

On macOS:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

On Ubuntu using systemd-resolved:

sudo resolvectl flush-caches

Flushing your local cache doesn't clear caches maintained by public DNS resolvers or ISPs, but it can help eliminate local caching as the cause of a problem.

7. DNS vs. IP Address: What's the Difference?

These two terms are related, but they aren't the same.

An IP address identifies a network endpoint used for communication.

A domain name is a human-readable name that DNS can resolve into an IP address or other DNS information.

Also, remember:

• One domain can resolve to multiple IP addresses.
• Multiple domains can point to the same IP address.
• A domain can use different DNS records for different services.
• DNS doesn't guarantee that the destination server is online.

For example, your website, email service, and API can all use different DNS records and point to different infrastructure.

8. A Few DNS Concepts Worth Knowing

Once you're comfortable with the basics, there are a few more concepts you'll encounter when working with production infrastructure.

Recursive vs. iterative queries

A recursive query asks a DNS resolver to find the final answer on your behalf.

An iterative query allows a DNS server to return a referral to another server that might know more about the requested domain.

DNSSEC

DNS Security Extensions add cryptographic signatures to DNS data, helping resolvers verify that DNS responses haven't been tampered with.

Anycast DNS

With anycast, multiple DNS servers can advertise the same IP address from different geographical locations. Network routing directs users toward an appropriate instance, often improving availability and response times.

Round-robin DNS

A DNS server can return multiple IP addresses for a domain, sometimes rotating their order between responses.

This can distribute traffic across servers, although it isn't a replacement for a proper load balancer.

Final Thoughts

DNS is one of those technologies that's easy to ignore until something breaks.

A misconfigured A record can make your website unreachable. An incorrect MX record can stop emails from arriving. A stale DNS cache can make a server migration look like it's only partially complete.

For developers, understanding DNS isn't just theoretical knowledge. It's a practical skill that comes in handy when deploying applications, managing infrastructure, and debugging production problems.

The next time your application refuses to load, don't immediately start checking your application code or restarting your server.

Start with:

dig yourdomain.com

You might discover that the problem isn't your application at all. It's DNS.

And that's a much easier problem to fix once you understand how it works.