September 11, 2026
11 min read
By Kokil Thapa | Last reviewed: September 2026
Your site can run perfect code on a healthy server and still fail for every visitor if DNS is wrong. How DNS Works: A Practical Guide starts with a simple fact: humans type names, but networks need numbers. The Domain Name System translates example.com.np into an IP address through a distributed lookup chain. If you ship Laravel apps, WordPress shops, or domain and hosting setups in Nepal, DNS is not someone else's job. It is part of launch, migration, SSL, email, and SEO.
Quick answer: How DNS works: a practical guide boils down to resolvers asking authoritative nameservers for record types like A, AAAA, CNAME, MX, and TXT, caching answers by TTL, and returning the IP or target your browser needs to connect.
How Does DNS Work When Someone Opens Your Website?
DNS is a hierarchical, cached lookup system. No single server holds the entire internet directory. Instead, each query walks from your device toward the authoritative source for that zone.
When a user visits your law-firm portal or eCommerce store, the browser does not connect to the domain name directly. It asks the operating system resolver. That resolver may answer from cache or forward the query upstream.
The five actors in a normal lookup
- Stub resolver — built into your laptop or phone OS.
- Recursive resolver — often your ISP, Cloudflare 1.1.1.1, or Google 8.8.8.8.
- Root nameserver — points to the correct TLD for
.com,.np, or.org. - TLD nameserver — returns the authoritative NS set for your domain.
- Authoritative nameserver — holds your zone and returns A, AAAA, CNAME, MX, and TXT records.
The recursive server does the walking. Your browser only sees the final answer. That separation is why two engineers can get different results seconds apart. They may hit different resolvers with different cache states.
On production deployments I've handled, the first troubleshooting step is never "restart Apache." It is "what does DNS return right now?" That habit saves hours during cutovers and certificate renewals.
How DNS Works in Production: A Practical Walkthrough
Let's trace a real request for www.courtmarriageinnepal.com style hostname. The browser calls getaddrinfo(). The OS asks the configured recursive resolver for an A or AAAA record.
If the record is cached and TTL has not expired, the answer returns in milliseconds. No root walk happens. That is why TTL matters during migrations.
Step-by-step resolution with dig +trace
Install dnsutils on Ubuntu and run a trace from your server or laptop:
dig +trace www.example.com A
;; QUESTION SECTION:
;;www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 300 IN A 203.0.113.10
The +trace flag shows each hop: root, TLD, authoritative NS, final RRset. Use it when a domain resolves in one network but not another. Compare against a public resolver:
dig @1.1.1.1 www.example.com A +short
dig @8.8.8.8 www.example.com A +short
Mismatch usually means propagation, split DNS, or a stale cache. For deeper record-type detail, see the companion piece on A, AAAA, CNAME, MX, and TXT records explained.
Authoritative data lives in a zone file or a provider UI. Registrars store glue records that tell the world which nameservers are canonical. If you change hosts, you update NS at the registrar and A records at the DNS host. Missing one side is a classic post-launch outage pattern.
What DNS Record Types Does a Practical Website Stack Need?
Most business sites need a small record set. Extra records create confusion during handover. Keep the zone readable for the next developer or agency.
| Record | Purpose | Common mistake |
|---|---|---|
| A | IPv4 address for apex or host | Pointing apex and www differently without intent |
| AAAA | IPv6 address | Missing AAAA while server advertises v6 only |
| CNAME | Alias to another hostname | CNAME at zone apex (invalid on many providers) |
| MX | Mail routing priority + host | Mail still pointing to old host after migration |
| TXT | SPF, DKIM, DMARC, domain verify | Multiple SPF TXT records on one name |
| NS | Delegates zone to nameservers | Mixing registrar DNS with external NS half-updated |
Example zone snippet for a Laravel app on Ubuntu
; example.com zone (BIND-style syntax)
$TTL 3600
@ IN A 203.0.113.10
www IN A 203.0.113.10
api IN A 203.0.113.20
@ IN MX 10 mail.example.com.
@ IN TXT "v=spf1 a mx -all"
_acme-challenge IN TXT "token-from-certbot-dns-plugin"
For WordPress or WooCommerce shops, the same A record pattern applies. CDN setups often swap A records for CNAME targets like shop.example.com.cdn.cloudflare.net. Document the intended shape before you touch production.
Email is where DNS bites hardest. I've seen client portals go live while MX still routed to a parked page inbox. Always verify MX and TXT after any website migration project. SPF and DKIM affect deliverability for booking confirmations and password resets.
Self-hosted authoritative DNS on Linux is optional for most SMB sites. Managed DNS at the registrar or a CDN is simpler. If you do run BIND, follow the BIND DNS server setup guide and lock down zone transfers.
How Do TTL and DNS Caching Affect Deployments?
Every DNS answer carries a Time To Live value in seconds. Resolvers treat that as a hard cache deadline. Lower TTL before a cutover. Raise it after stability returns.
TTL is not propagation magic. It is cache expiry. A record with TTL 86400 can linger up to 24 hours on a resolver that fetched it just before your change. Plan backward from that window.
Pre-migration TTL playbook
- One week before: drop TTL from 3600 to 300 on records you will change.
- Change day: update A/AAAA/CNAME to the new origin or load balancer.
- Verify with multiple resolvers and
dig +noall +answer. - After 48 stable hours: restore TTL to 3600 or higher for cache efficiency.
API endpoints behind CDNs need special care. Cached DNS at the edge can mask origin moves. Read Cloudflare DNS cache bypass for API endpoints before routing mobile apps through orange-cloud proxies.
Negative caching also matters. If a typo creates an NXDOMAIN, resolvers cache that failure too. Fix the record, then wait for negative TTL or flush test resolvers only you control. Do not ask customers to flush DNS as a primary fix.
How Do You Debug DNS When a Site Stops Resolving?
Start at the symptom edge and walk backward. Confirm the problem is DNS, not HTTP, TLS, or application code. These checks take two minutes and prevent wrong rabbit holes.
Command checklist
# 1. What do public resolvers see?
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short
# 2. Who is authoritative?
dig example.com NS +short
dig @ns1.provider.net example.com A +noall +answer
# 3. Trace the full chain
dig +trace example.com A
# 4. Check DNSSEC if enabled
dig example.com DNSKEY +dnssec
delv example.com A
# 5. Compare HTTP only after DNS is correct
curl -I https://example.com
Paste dig output into a JSON formatter when you need to share structured results with a client or registrar ticket. For pattern checks on SPF strings, a regex tester helps validate syntax before publish.
Common failure modes I see on Linux administration engagements:
- Split horizon — office DNS returns internal IP; public users hit wrong host.
- Registrar lock on NS — A record updated at Cloudflare while NS still point to old parking DNS.
- CNAME conflict — CNAME on
wwwplus A on apex without redirect logic. - Certificate mismatch — DNS correct but TLS SAN missing new subdomain.
- Geo DNS surprise — Nepal users resolve to Singapore POP with blocked origin ACL.
Multi-cloud and failover setups add weighted routing, health checks, and geo rules. Those patterns are covered in cross-cloud DNS and traffic routing and tie into Infrastructure as Code with Terraform when zones are version-controlled.
For Nepal-focused launches, confirm .np delegation with your registrar and Mercantile or authorized reseller policies. Local billing may be in NPR (often Rs 1,500–3,000/year for common TLDs, ~USD 11–22), but DNS mechanics are identical to global TLDs. The authoritative spec remains RFC 1034 and RFC 1035, with updates in later RFCs for DNSSEC and EDNS.
How Does DNS Tie Into SSL, SEO, and Application Architecture?
DNS is the first gate for HTTPS. HTTP clients resolve the hostname before TCP and TLS. ACME HTTP-01 needs A/AAAA pointing to the server serving the challenge. DNS-01 needs a TXT record at _acme-challenge.
SEO impact is indirect but real. Wrong canonical host, mixed www and non-www, or long outage windows hurt crawl budget and trust signals. Align DNS with your technical SEO strategy: one preferred host, 301 at the edge, correct A/AAAA, valid TLS chain.
On projects like Notary Nepal and Adventure Himalaya Nepal, launch checklists always include DNS verification before search console submission. Google Search Console fetches your robots.txt from the resolved host. If DNS points to a stale parking page, you validate the wrong property.
Application teams should store DNS ownership in runbooks alongside deploy keys. Who holds the registrar login? Which API token edits Cloudflare zones? When building a new web application, define subdomain conventions early: api., staging., cdn., mail.. Late additions collide with wildcard certs and WAF rules.
Ubuntu resolver config belongs in /etc/systemd/resolved.conf or NetworkManager. See the Ubuntu DNS configuration guide for stub resolver behavior on PHP-FPM servers. A misconfigured /etc/resolv.conf breaks outbound API calls from Laravel queues even when inbound site DNS is fine.
Managed platforms like DigitalOcean expose API-driven zones. That helps small teams without a dedicated ops hire. Pair provider docs with the DigitalOcean practical guide when you automate record creation in CI.
External references worth bookmarking: the Cloudflare DNS concepts overview explains anycast resolver behavior clearly. For public resolver policy and privacy, Google's Public DNS documentation describes query logging limits and EDNS Client Subnet trade-offs.
Key Takeaways
- DNS maps names to records through recursive resolvers and authoritative nameservers; the browser only sees the final cached answer.
- Keep zones minimal: A/AAAA for hosts, MX and TXT for mail, CNAME only where aliasing is intentional.
- Lower TTL to 300 seconds before migrations; restore higher TTL after 48 hours of stable traffic.
- Debug with
dig @1.1.1.1,dig +trace, and direct queries to authoritative NS before touching application code. - Align DNS with TLS issuance, preferred canonical host, and CDN orange-cloud settings to avoid split-brain SEO and API failures.
- Document registrar, DNS host, and API token ownership in runbooks—the next engineer should not need a founder's inbox to fix an A record.
People Also Ask
What is the difference between authoritative and recursive DNS?
Recursive resolvers fetch answers on behalf of clients and cache them. Authoritative nameservers own the zone data for your domain and return the definitive RRsets. Your laptop talks to recursive; recursive talks to authoritative.
How long does DNS propagation actually take?
There is no global instant propagation. Changes appear as each resolver's cached TTL expires. With TTL 300, most users converge within five to thirty minutes. Old TTL 86400 records can take a full day.
Can I use a CNAME on my root domain?
Traditional DNS forbids CNAME at zone apex alongside other record types. Many providers offer ALIAS, ANAME, or flattened CNAME at root. Use A record at apex or provider-specific flattening—not a raw CNAME unless your host documents support.
Why does my site work on mobile data but not office Wi-Fi?
Different networks use different recursive resolvers with different cache states. Office DNS may use split-horizon internal views. Compare dig @1.1.1.1 on both networks to isolate the stale or internal answer.
Put DNS Knowledge Into Your Next Launch
How DNS Works: A Practical Guide is not academic trivia. It is the control plane for every domain you ship. Master the lookup chain, record types, TTL discipline, and dig workflow, and migrations stop being guesswork. When you want hands-on help with registrar setup, cutover planning, or post-launch monitoring, contact us for DNS and hosting support or explore ongoing maintenance services. Read more on the blog, review client feedback, or see live examples in the portfolio—including Mijar Law Associates and other production sites where DNS, SSL, and deploy pipelines were handled end to end.
Frequently Asked Questions
DNS translates human-readable domain names into IP addresses through a distributed lookup chain. Your browser asks the OS resolver, which may answer from cache or query upstream recursive servers, root and TLD nameservers, then the authoritative source for your zone. The browser only sees the final A or AAAA answer.
Recursive resolvers fetch answers on behalf of clients and cache them. Authoritative nameservers own the zone data for your domain and return the definitive record sets.
There is no global instant propagation. Changes appear as each resolver’s cached TTL expires. With TTL 300, most users converge within five to thirty minutes.
A typical lookup involves five roles: the stub resolver built into your device OS, a recursive resolver such as your ISP or Cloudflare 1.1.1.1, a root nameserver that points to the correct TLD, a TLD nameserver for .com or .np, and the authoritative nameserver holding your zone’s A, AAAA, CNAME, MX, and TXT records. The recursive server walks the chain; your browser only receives the cached final answer.
Most business sites need a small, readable zone: A for IPv4 hosts, AAAA if you serve IPv6, CNAME only for intentional aliases, MX for mail routing, TXT for SPF, DKIM, DMARC, and domain verification, and NS to delegate to your nameservers. Common mistakes include CNAME at zone apex, MX still pointing to an old host after migration, and multiple SPF TXT records on one name. Keep extras out of the zone so the next developer can hand over cleanly.
Traditional DNS forbids a CNAME at the zone apex alongside other record types on many providers. Use an A record at apex, or provider-specific ALIAS, ANAME, or flattened CNAME if your host documents support it—not a raw CNAME unless that flattening is explicitly offered.
Every DNS answer carries a Time To Live in seconds that resolvers treat as a hard cache deadline. TTL is not propagation magic; it is cache expiry. A record with TTL 86400 can linger up to 24 hours on a resolver that fetched it just before your change. One week before a cutover, drop TTL from 3600 to 300 on records you will change. After 48 stable hours post-migration, restore TTL to 3600 or higher for cache efficiency.
Plan backward from TTL windows. Lower TTL to 300 about one week before the cutover. On change day, update A, AAAA, or CNAME to the new origin, then verify with multiple resolvers using dig against 1.1.1.1 and 8.8.8.8. If you change hosts, update NS at the registrar and A records at the DNS host—missing one side is a classic post-launch outage. Document the intended record shape before touching production.
Start at the symptom edge and confirm the problem is DNS, not HTTP, TLS, or application code. Check what public resolvers see with dig @1.1.1.1 and dig @8.8.8.8, identify authoritative nameservers with dig example.com NS, query them directly, and run dig +trace for the full chain. Compare HTTP only after DNS is correct. Mismatch across resolvers usually means propagation, split DNS, or stale cache—not a reason to restart Apache first.
Different networks use different recursive resolvers with different cache states. Office DNS may use split-horizon internal views that return an internal IP while public users hit the wrong host. Compare dig @1.1.1.1 on both networks to isolate the stale or internal answer. Geo DNS can also send Nepal users to a distant POP with a blocked origin ACL, which looks like a DNS or connectivity problem at one location only.
When a typo or missing record produces NXDOMAIN, resolvers cache that failure too, not just successful answers. After you fix the record, you must wait for the negative TTL to expire or flush test resolvers you control. Do not ask customers to flush DNS as a primary fix. This is easy to overlook during rushed launches when a wrong hostname was queried before the zone was complete.
DNS is the first gate for HTTPS. HTTP clients resolve the hostname before TCP and TLS. ACME HTTP-01 needs A or AAAA pointing to the server serving the challenge. DNS-01 needs a TXT record at _acme-challenge, as used with certbot’s DNS plugin. Certificate mismatch can occur when DNS is correct but the TLS SAN is missing a new subdomain, so align DNS changes with certificate issuance during cutovers.
SEO impact is indirect but real. Wrong canonical host, mixed www and non-www, or long outage windows hurt crawl budget and trust signals. Align DNS with one preferred host, 301 at the edge, correct A and AAAA, and a valid TLS chain. Google Search Console fetches robots.txt from the resolved host—if DNS points to a stale parking page, you validate the wrong property. Launch checklists should verify DNS before search console submission.
Split horizon returns internal IPs inside the office while public users see something else. Registrar lock on NS leaves A records updated at Cloudflare while nameservers still point to old parking DNS. CNAME conflict puts CNAME on www plus A on apex without redirect logic. Email breaks when MX still routes to a parked inbox. I've seen client portals go live while mail was wrong—always verify MX and TXT after any migration, because SPF and DKIM affect booking confirmations and password resets.
Local billing for common TLDs is often Rs 1,500–3,000 per year, roughly USD 11–22, though DNS mechanics are identical to global TLDs. For .np launches, confirm delegation with your registrar and Mercantile or authorized reseller policies. Most SMB sites use managed DNS at the registrar or a CDN rather than self-hosted BIND on Linux, which keeps operational cost and handover complexity low for small teams without a dedicated ops hire.
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.
