DNS Resolution Process

When you type example.com in your browser, the DNS resolution process works like this:

1. Local Cache Check: Your browser and operating system check their local DNS caches for recent lookups.

2. Recursive Resolution: If the address is not found in the local cache, your system contacts a recursive DNS resolver (typically provided by your ISP). The recursive resolver performs the following steps:

   • Root Nameserver Query: The resolver first contacts one of the 13 root nameservers (labeled A through M), asking, “Who knows about .com domains?”

   • TLD Nameserver Query: The root nameserver responds with the address of the Top-Level Domain (TLD) nameservers for .com domains. The resolver then queries these TLD nameservers, asking, “Who knows about example.com?”

   • Authoritative Nameserver Query: The TLD nameserver responds with the address of the authoritative nameservers for example.com. The resolver then queries these authoritative servers, asking, “What is the IP address for example.com?”

   • Answer Delivery: The authoritative nameserver responds with the requested DNS record (e.g., the A record containing the IP address).

3. Response Caching: The recursive resolver caches this response for future use, according to the Time-to-Live (TTL) value.

4. Final Delivery: The IP address is returned to your browser, which then establishes a connection to the server hosting example.com.

Essential DNS Record Types

A Record

The fundamental record that maps a hostname to an IPv4 address. Tells your computer the IPv4 address of the server hosting your website or application.

example.com.     IN   A     93.184.216.34

This record indicates that example.com is hosted at the IPv4 address 93.184.216.34

AAAA Record

Similar to the A record, but maps a hostname to an IPv6 address. Provides the IPv6 address for your website or application. Adopting IPv6 is becoming increasingly important

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

This record maps example.com to the IPv6 address 2606:2800:220:1:248:1893:25c8:1946

CNAME Record

It creates an alias for another domain name. It redirects one domain or subdomain to another. Common use cases include pointing www.example.com to example.com or creating specific subdomains for different services.

www.example.com.    IN   CNAME example.com.

This records makes www.example.com an alias of example.com

Why is this useful? Imagine you have multiple subdomains pointing to the same server. If the server's IP address changes, you only need to update the A record for the original domain. All CNAME records pointing to that domain will automatically inherit the new IP address, simplifying maintenance.

MX Record

Specifies the mail servers responsible for accepting email messages on behalf of a domain. Essential for setting up email services for your domain

example.com.        IN   MX    10 mail.example.com.

This record routes email for example.com to mail.example.com with priority 10. Lower numbers indicate higher priority. If you have multiple MX records, the mail server will try the lowest priority number server first

NS Record

Specifies the authoritative name servers for a domain. Delegates the authority for a domain or subdomain to specific name servers. Typically, you'll have multiple NS records for redundancy

example.com.        IN   NS    ns1.exampledns.com.
example.com.        IN   NS    ns2.exampledns.com.

This record specifies the authoritative nameservers for example.com.

TXT Record

Contains arbitrary text-based information associated with a domain. Used for a variety of purposes, including domain ownership verification, SPF (Sender Policy Framework) records for email authentication, and storing arbitrary metadata

example.com.        IN   TXT   "v=spf1 include:_spf.google.com ~all"

Provides text info, often used for SPF, domain verification, or other metadata.

PTR Record

Performs a reverse DNS lookup, mapping an IP address back to a domain name. Used for verifying the legitimacy of a server. Often used in email authentication.

34.216.184.93.in-addr.arpa.  IN   PTR   example.com.

This maps an IP address back to a domain name (used for reverse DNS)

SOA Record

Defines the primary authoritative server for a domain and provides essential administrative information like the contact email, serial number, and zone refresh settings. It is the first record in a DNS zone file and is required for proper zone operation and replication.

ns.icann.org. noc.dns.icann.org. 2025011602 7200 3600 1209600 3600

This record provides the following information:

• Primary nameserver: ns.icann.org – the main server for DNS information.

• Admin contact: noc@dns.icann.org – contact email for DNS issues (written with a dot instead of @).

• Serial number: 2025011602 – version number of the zone file; changes when the zone is updated.

• Refresh interval: 7200 seconds (2 hours) – how often secondary servers check for updates.

• Retry interval: 3600 seconds (1 hour) – how long to wait before retrying after a failed update check.

• Expire time: 1209600 seconds (14 days) – how long a secondary server keeps using data if it can’t reach the primary.

• Minimum TTL: 3600 seconds (1 hour) – default time DNS records are cached by other servers.

SRV Record

Specifies the location (hostname and port number) of servers for specific services. Used to locate services like SIP, XMPP, and other network protocols. Useful for applications (VoIP or messaging systems) that rely on service discovery.

_ldap._tcp.example.com.  IN   SRV   10  5  389  ldap-server.example.com.

Specifies that the LDAP service (over TCP) for example.com is handled by ldap-server.example.com, with priority 10, weight 5, and port 389

@ Symbol in DNS Records

The @ symbol in DNS records is shorthand for the domain itself, simplifying zone files. Instead of repeating the domain name, @ acts as a placeholder. For example, @ IN A 93.184.216.34 maps example.com to the IP address 93.184.216.34. Similarly, @ IN MX 10 mail.example.com designates mail.example.com as the mail server for the main domain, making DNS records more concise and easier to manage. Use @ for records applying to the entire domain, but not for subdomains.

DNS TTL (Time To Live)

It defines how long a DNS record is cached by resolvers before it must be refreshed. Measured in seconds, a higher TTL improves speed and reduces server load but delays DNS updates, while a lower TTL allows faster changes at the cost of increased traffic and potentially slower performance. Choosing the right TTL depends on how often you expect to update your DNS records

DNS Records vs Zone Files

A DNS record is a single entry within a DNS database that maps a domain name or subdomain to a specific value, like an IP address or another domain. Think of it as a single row in a spreadsheet, defining a specific piece of DNS information.

A zone file, on the other hand, is a text file that contains a collection of DNS records for a particular domain. It represents the complete authoritative source of DNS information for that domain, encompassing all its records (A, MX, CNAME, etc.). The zone file is what the authoritative DNS server reads to respond to DNS queries for that domain. So, a zone file is the container holding multiple DNS records

Digging into DNS with the dig Command

The dig command (Domain Information Groper) is a powerful command-line tool for querying DNS name servers. It's an essential tool for any developer who needs to troubleshoot DNS issues, verify configurations, or simply understand how DNS resolution work

Getting the A record for a domain

dig example.com A

Finding the MX records for a domain

dig example.com MX

Querying a specific DNS server

dig @8.8.8.8 example.com A  # Query Google's Public DNS

Getting a concise output

dig example.com A +short

Tracing the DNS resolution path

dig example.com A +trace

Check domain name for an IP Address

dig -x 172.217.168.206

View list of top level name servers

dig com +short NS

Check when cache will expire (use https://ttl-calc.com/ to calculate in hours and minutes)

dig example.com +noall +answer

Understanding DNS records is fundamental for software developers deploying and maintaining online services. By understanding the different record types and their purposes, you can ensure your applications are reachable, resilient, and performant.

Why Do Console Logs Disappear on Redirect?

When a browser like Chrome performs a redirect, it unloads the current page and loads a new one. This means:

• The JavaScript execution context is lost.

• The Developer Tools console is refreshed, clearing previous logs.

• Any debug information logged before the redirect is no longer accessible.

The Simple Trick to Debug Before Redirect

After some research, I found a simple yet effective trick to pause execution right before the redirect:

window.addEventListener("beforeunload", function() { debugger; }, false);

Run the above code snippet in the Developer Tools console. This listens for the beforeunload event, which fires just before the page is unloaded (e.g., during navigation or refresh). Inside the event listener, debugger; triggers a breakpoint in the browser’s Developer Tools, pausing execution and allowing you to inspect console logs before they disappear.

For more details about beforeunload, check out MDN documentation on beforeunload.