DNS, Domain Name System, is the internet’s naming infrastructure. It is the system that translates human-readable domain names like example.com into the numerical IP addresses that computers use to identify and communicate with each other. Without DNS, visiting a website would require knowing and typing a string of numbers, 93.184.216.34, instead of a domain name. DNS makes the web navigable by humans.

The analogy most commonly used is a phone book. A phone book maps names to phone numbers. DNS maps domain names to IP addresses. When you want to call someone you look up their name and find their number. When your browser wants to visit example.com it looks up the domain name and finds the IP address of the server hosting it. The connection is then made to that IP address and the web page is retrieved.

DNS is foundational to how the web works, and foundational to how URL redirects, domain connections, and SSL certificates are implemented. Understanding DNS is essential for anyone managing domains, configuring redirects, or troubleshooting why a domain is not working as expected.

How DNS works

When you type example.com into a browser and press enter, a sequence of lookups happens behind the scenes to translate that domain name into an IP address. This sequence is called DNS resolution.

The browser cache: the browser first checks its own DNS cache. If it has looked up example.com recently and the cached result has not expired, it uses the cached IP address immediately without any network requests. This is the fastest possible resolution; no lookups needed.

The operating system cache: if the browser cache misses, the browser asks the operating system. The OS has its own DNS cache and checks it for a recent result. If found, the cached IP address is returned immediately.

The DNS resolver: if neither cache has the answer, the OS sends a query to a DNS resolver, typically provided by the internet service provider or a public resolver like Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1. The resolver is the primary lookup engine. It knows how to navigate the DNS hierarchy to find the answer.

The root nameservers: if the resolver does not have the answer cached, it queries one of the internet’s root nameservers. There are 13 sets of root nameservers distributed globally. The root nameserver does not know the IP address of example.com but it knows which nameserver is responsible for .com domains and directs the resolver there.

The TLD nameservers: the resolver queries the nameserver responsible for the TLD, .com, .net, .org, or any other extension. The TLD nameserver knows which nameserver is the authoritative nameserver for example.com and directs the resolver there.

The authoritative nameserver: the resolver queries the authoritative nameserver for example.com. This is the nameserver configured by whoever manages example.com, typically the domain registrar or a dedicated DNS provider. The authoritative nameserver holds the actual DNS records for the domain, including the A record that maps example.com to its IP address. It returns the IP address to the resolver.

Return to the browser: the resolver returns the IP address to the OS, which returns it to the browser. The browser connects to the IP address and requests the web page. The result is cached at each level, browser, OS, resolver, for the duration of the DNS TTL so future lookups can skip the full resolution process.

This entire process, from browser to root nameserver to TLD nameserver to authoritative nameserver and back, typically completes in milliseconds.

DNS records

DNS works through a system of records stored on authoritative nameservers. Each record type stores different information about a domain and serves a different purpose. Understanding the key record types is essential for configuring domains and redirects correctly.

A record: maps a domain or subdomain to an IPv4 address. The most fundamental DNS record. example.com → 93.184.216.34. Every domain that resolves to a web server needs an A record.

AAAA record: maps a domain or subdomain to an IPv6 address. The IPv6 equivalent of an A record. example.com → 2606:2800:220:1:248:1893:25c8:1946.

CNAME record: maps a domain or subdomain to another domain name rather than directly to an IP address. Used to alias one domain to another. www.example.com → example.com or shop.example.com → stores.shopify.com. When the browser looks up a CNAME, it follows the alias and looks up the target domain. CNAMEs are central to how many redirect management and hosting services connect domains; users point their domain to the service’s infrastructure via a CNAME record.

MX record: specifies the mail servers responsible for receiving email for a domain. Email routing uses MX records rather than A records. example.com → mail.example.com with a priority value.

TXT record: stores arbitrary text data associated with a domain. Used for domain verification, SPF records for email authentication, DKIM keys, and many other purposes. When connecting a domain to a redirect management service, a TXT record is often required for domain ownership verification.

NS record: specifies the authoritative nameservers for a domain. NS records delegate DNS authority for a domain to specific nameservers. example.com → ns1.registrar.com, ns2.registrar.com. Changing nameservers moves DNS authority from one provider to another.

CAA record: specifies which certificate authorities are authorised to issue SSL certificates for a domain. A security measure that prevents unauthorised certificate issuance.

SOA record: Start of Authority record. Contains administrative information about the DNS zone including the primary nameserver, email of the zone administrator, and timing parameters.

DNS and redirects

DNS and HTTP redirects operate at different layers of the internet stack and serve different but related purposes. Understanding the relationship between them is important for configuring redirect management correctly.

DNS routes requests to servers. HTTP redirects route requests to URLs. DNS determines which server receives a request for a domain. HTTP redirects, configured on that server or on redirect management infrastructure, determine where the request goes from there.

When a user connects a domain to a redirect management service like Redirect Supply, the process involves both DNS and HTTP redirects working together.

The DNS layer, changing a CNAME record or A record to point the domain to the redirect management infrastructure — ensures that requests for the domain are routed to the redirect management service’s servers rather than to any previous hosting.

The HTTP redirect layer, the redirect rules configured in the redirect management service, determines what Location header is returned for each incoming request and where visitors are sent.

Neither layer alone is sufficient. DNS without redirect rules means requests reach the redirect service’s infrastructure but there is no rule telling them where to go. Redirect rules without correct DNS means requests never reach the redirect service’s infrastructure in the first place.

DNS cannot perform HTTP redirects: this is a common misconception. DNS resolves domain names to IP addresses. It cannot issue 3xx status codes, cannot set Location headers, and cannot implement the kind of URL-level routing that HTTP redirects provide. Some registrar interfaces make “URL forwarding” look like a DNS feature, but the forwarding itself always requires HTTP redirect infrastructure; the registrar is running servers that handle the HTTP redirect; the DNS change just routes requests to those servers.

DNS propagation

DNS propagation is the process by which DNS record changes spread across the global network of DNS resolvers and caches. When a DNS record is updated, changing an A record to point to a new IP address, or updating a CNAME to point to new infrastructure, that change does not take effect everywhere instantly.

The change is made on the authoritative nameserver. Resolvers worldwide have cached the previous record and will continue serving the old answer until their cached copy expires. The expiry time is determined by the DNS TTL, Time To Live, a value set on each DNS record that specifies how many seconds resolvers should cache it.

A TTL of 3600 means resolvers cache the record for one hour. After one hour they discard the cached copy and query the authoritative nameserver again, at which point they receive the new record value. A TTL of 86400 means records are cached for 24 hours before resolvers recheck.

This means DNS changes can take from minutes to 48 hours to propagate fully across all resolvers worldwide, depending on:

• The TTL of the record being changed, lower TTL means faster propagation after a change

• How recently the old record was cached by a given resolver, a resolver that cached the record seconds before the change will hold the old value for the full TTL

• The resolver being used by a specific visitor, different resolvers update at different rates

For redirect management, this propagation delay matters when connecting a new domain. After updating DNS records to point to redirect management infrastructure, there is a window during which some visitors, those using resolvers with cached old records, still reach the old server rather than the redirect management infrastructure. During this window the redirect rules are not in effect for those visitors.

DNS TTL and redirect management

DNS TTL, Time To Live, is one of the most practically important DNS concepts for anyone managing domain redirects and migrations.

TTL is measured in seconds and set individually on each DNS record. A record with TTL 3600 is cached for one hour. A record with TTL 300 is cached for five minutes. A record with TTL 86400 is cached for 24 hours.

The practical implications for redirect management are significant.

Before a domain migration: lower the TTL on DNS records for the domain being migrated well in advance of the migration date. Changing TTL from 86400 to 300 means that once the migration DNS changes are made they propagate within five minutes rather than potentially 24 hours. The TTL change itself takes up to the current TTL duration to propagate; lower it at least 24-48 hours before the planned migration.

During a migration: with a low TTL in place, DNS changes for the migration propagate quickly. The window during which different visitors reach different infrastructure is minimised.

After a migration: once the migration is stable and there is no plan to change DNS records again, increase the TTL back to a normal value, 3600 or higher. Lower TTLs mean more frequent DNS queries from resolvers, which adds load to authoritative nameservers.

For redirect services: when connecting a domain to a redirect management service via CNAME, the CNAME record’s TTL determines how quickly the connection takes effect and how quickly it can be reversed if needed. A low TTL during initial setup allows rapid iteration. A higher TTL once the configuration is stable reduces DNS query overhead.

DNS and SSL certificates

SSL certificates and DNS are closely connected in the process of securing domains with HTTPS. Provisioning an SSL certificate for a domain typically requires proving domain ownership through DNS, adding a specific TXT record or CNAME record that the certificate authority checks to confirm control of the domain.

For redirect management specifically, Let’s Encrypt and other certificate authorities use DNS validation to provision SSL certificates for domains connected to redirect infrastructure. The domain owner adds a TXT record specified by the certificate authority, the authority verifies the record exists and is correct, and the certificate is issued for the domain.

This DNS-based certificate validation is why SSL provisioning for redirect management requires both DNS access, to add the verification records, and a correctly configured connection between the domain and the redirect infrastructure. Platforms that automate SSL provisioning handle the DNS validation process automatically, reducing the manual steps required from domain owners.

Common DNS terms in redirect management

Several DNS concepts appear regularly in redirect management contexts and are worth understanding together.

DNS propagation: the time it takes for DNS record changes to take effect across all resolvers worldwide.

DNS TTL: the duration DNS records are cached by resolvers before being refreshed from the authoritative nameserver.

Nameserver: the server that holds and serves DNS records for a domain.

CNAME: the record type most commonly used to connect domains to redirect management and hosting services.

A record: the record type that maps a domain directly to an IPv4 address, used when a CNAME is not appropriate such as for apex domains.

DNS zone: the collection of DNS records managed by an authoritative nameserver for a specific domain.

DNS flush: clearing the local DNS cache on a computer to force fresh DNS lookups rather than using cached results. Useful when testing DNS changes and wanting to see the updated records rather than the cached old ones.