DNS Basics Every Developer Should Know

Jan 26, 2026 · 4 min read

You’ve deployed your app, but users report it’s unreachable. Your first instinct might be to check the server, but the real culprit is often DNS. Understanding DNS basics isn’t optional—it’s essential for debugging production issues and reasoning about how your web applications actually reach users.

This article covers the DNS resolution flow, common record types, caching behavior, and modern DNS developments that affect performance and security.

Key Takeaways

DNS resolution involves three layers: stub resolvers, recursive resolvers, and authoritative nameservers—failures can occur at any point
TTL values determine propagation time; lower them before migrations, not during
HTTPS records (SVCB) provide connection hints for faster, more secure browser connections
DNSSEC authenticates records while DoH/DoT/DoQ encrypts queries—they solve different problems
Use dig or nslookup to debug DNS issues by querying different resolvers

How DNS Resolution Works

When a browser needs to connect to api.example.com, it doesn’t magically know the IP address. The resolution process involves three layers:

Stub resolver: Your operating system’s built-in DNS client. It doesn’t resolve names itself—it forwards queries to a configured recursive resolver and caches responses locally.

Recursive resolver: Typically operated by your ISP or a public service like Cloudflare (1.1.1.1) or Google (8.8.8.8). This server does the heavy lifting, querying other servers on your behalf.

Authoritative nameservers: The source of truth for a domain’s DNS records. The recursive resolver walks the DNS hierarchy—root servers, then TLD servers (.com, .io), then the domain’s authoritative servers—to find the answer.

For developers, the key insight is that DNS failures can occur at any layer. A misconfigured stub resolver, an unreachable recursive resolver, or stale authoritative records can all break your application.

Common DNS Record Types

You’ll encounter these records regularly:

A / AAAA: Map a hostname to an IPv4 or IPv6 address
CNAME: Alias one hostname to another (cannot be used at the zone apex—example.com itself requires an A or AAAA record)
MX: Specifies mail servers for the domain
TXT: Stores arbitrary text, commonly used for domain verification and email authentication (SPF, DKIM)
NS: Delegates a zone to specific nameservers

Understanding these helps when configuring CDNs, email services, or debugging why a subdomain isn’t resolving.

DNS Caching and TTL

DNS caching and TTL (Time To Live) directly impact your deployment strategy. Every DNS record includes a TTL value in seconds. Once a resolver caches a record, it won’t query again until the TTL expires.

Practical implications:

A 3600-second (1-hour) TTL means DNS changes take up to an hour to propagate
Before migrations, lower TTLs in advance—not during the change
Browsers and operating systems maintain their own caches, adding another layer

The myth that “DNS propagation takes 24-48 hours” is misleading. Propagation time depends on the previous TTL value. If your old TTL was 86400 seconds (24 hours), that’s your worst-case wait time.

Modern DNS: HTTPS Records and Encrypted Transport

DNS has evolved significantly in recent years. Two developments matter most for web developers.

The HTTPS DNS Record (SVCB)

The HTTPS record (a specific type of SVCB record) provides connection hints before the browser even contacts your server. It can advertise:

HTTP/3 and QUIC support
Alternative ports
Encrypted Client Hello (ECH) keys

This enables browsers to establish faster, more secure connections. However, HTTPS record support isn’t universal yet—not all DNS providers support it, and some resolvers don’t query for it.

Note: HTTPS records offer limited apex-aliasing capabilities, but they’re not a complete CNAME-at-apex solution.

DNS over HTTPS (DoH) and Encrypted DNS

Traditional DNS queries travel in plaintext over UDP port 53. DNS over HTTPS (DoH), DNS over TLS (DoT), and DNS over QUIC (DoQ) encrypt these queries, preventing eavesdropping and manipulation.

Encrypted DNS is now widely deployed—Firefox and Chrome use DoH by default in many configurations—but it’s not universal. Corporate networks and some ISPs still intercept or block encrypted DNS.

DNSSEC vs Encryption: Know the Difference

A common confusion: DNSSEC is not encryption.

DNSSEC provides authentication. It cryptographically signs DNS records so resolvers can verify responses haven’t been tampered with. It doesn’t hide your queries.

Encrypted DNS (DoH/DoT/DoQ) provides privacy. It encrypts the transport layer so observers can’t see which domains you’re querying.

They solve different problems and can be used together.

How DNS Failures Surface in Your Apps

When DNS fails, you’ll typically see:

NXDOMAIN errors (domain doesn’t exist)
Connection timeouts (resolver unreachable)
SERVFAIL responses (upstream server issues)

In browsers, these appear as “DNS_PROBE_FINISHED_NXDOMAIN” or similar errors. In Node.js or other runtimes, you’ll get ENOTFOUND or equivalent exceptions.

Use dig or nslookup to debug. Query different resolvers to isolate whether the problem is local caching, your resolver, or the authoritative servers.

Conclusion

DNS sits between your users and your servers. Understanding the resolution flow, TTL behavior, and modern protocols like HTTPS records and DoH helps you deploy more reliably and debug faster. When something breaks, DNS should be one of your first suspects—not your last.

FAQs

Use the dig command in your terminal, such as dig example.com A to check A records or dig example.com ANY to see all records. You can also specify a resolver like dig @8.8.8.8 example.com to query Google's DNS directly. On Windows, use nslookup example.com instead.

DNS changes appear delayed because resolvers cache records based on their TTL value. If your previous TTL was 3600 seconds, resolvers won't check for updates until that hour passes. To speed up future changes, lower your TTL well before making updates, then restore it afterward.

An A record maps a hostname directly to an IP address. A CNAME creates an alias pointing one hostname to another, which then resolves to an IP. CNAMEs are useful for subdomains pointing to external services, but cannot be used at the zone apex where your root domain requires an A or AAAA record.

DoH encrypts DNS queries, preventing network observers from seeing which domains you resolve. For end-user privacy, it's beneficial. However, for server applications, traditional DNS is often sufficient since your infrastructure is already known. Consider DoH when privacy from network intermediaries matters to your use case.

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.