DNS (Domain Name System): The Internet's Address Book Explained

DNS, short for Domain Name System, is the infrastructure that translates human-readable domain names into the numerical IP addresses computers use to locate servers on the internet. When a visitor types your company's domain into a browser, DNS resolves that name to an address and routes the request to the correct server, in milliseconds.

The common analogy holds: a domain name is like a name in a contact book, DNS is the system that looks up the corresponding number. A registered domain without configured DNS records is a name that leads nowhere.

The Four Record Types You Will Encounter

A DNS zone contains multiple record types, each handling a different routing function:

• A record: Maps a domain name directly to an IPv4 address. Updating this record is the primary step when pointing your domain to a new web server.
• CNAME record: Creates a hostname alias that resolves to another hostname rather than to an IP address directly. It is used for subdomains such as www, but cannot be placed at the apex domain (example.com itself) because the DNS specification prohibits a CNAME from coexisting with other required records at the zone root.
• MX record: Directs incoming email to the mail server responsible for your domain. Changing your web host has no effect on email delivery, provided MX records remain untouched.
• TXT record: Stores plain-text data. Common uses include domain ownership verification and publishing email authentication policies such as SPF and DKIM.

DNS vs Domain Name vs Web Hosting

Three terms that regularly blend together in planning discussions:

A domain name (such as example.com) is the address your audience types into a browser. It is a string registered through a domain registrar. On its own, it is just a name.

DNS is what makes that name functional. DNS records specify where requests arriving at your domain should be routed: to which web server, which mail provider, which verification authority. A domain without properly configured DNS records delivers nothing.

Web hosting is a separate layer. It is where your website's actual files live. DNS points traffic to the host; it does not store or serve those files. Confusing the two leads to trouble during migrations: moving to a new host requires updating DNS, but updating DNS does not move or copy your site's files.

Example: Migrating a Website to Webflow

Example: A company moves its website from a traditional hosting provider to Webflow. The development team finishes the new site and publishes it to a Webflow subdomain. The domain itself still points to the old host.

To complete the switchover, two DNS records need updating at the domain registrar:

1. The A record for the apex domain (example.com) is changed to Webflow's designated server IP address.
2. The CNAME record for the www subdomain is pointed to Webflow's proxy hostname.

The MX records stay unchanged, since email delivery runs independently of the web host. TXT records for domain ownership verification with Webflow are added separately as a new entry, rather than replacing existing records.

This pattern applies to any platform migration: update A and CNAME records to point to the new host, preserve MX records to protect email continuity, and add any TXT records the new platform requires for verification. For a full picture of what a Webflow website for companies involves from DNS setup through to launch, the technical and contractual steps are covered in detail there.

DNS Propagation: Why Changes Take Time

When you update a DNS record, the change does not take effect globally at once. Resolvers across the internet cache records for a duration set by the TTL (Time to Live) field on each record. Until a resolver's cached copy expires, it serves the old value rather than the updated one.

This is why DNS changes appear inconsistent during a migration: a visitor using one resolver may reach the new site while another visitor, querying a different resolver, still lands on the old host. Lowering the TTL well before a planned migration, so that caches expire quickly once the change is published, reduces this overlap window and speeds up the global update.

The practical implication: treating a DNS update as a last-minute action at cutover rarely produces the quick result teams expect. Planning the change in advance, and reducing the TTL before the migration date, is the reliable approach.

Why DNS Matters for Your Relaunch

DNS underpins every layer of a website launch: whether the site loads at all, whether email continues without interruption, whether SSL certificates can be issued, and how quickly the new site becomes visible worldwide. A relaunch that skips DNS planning produces avoidable downtime, not because the new site is broken, but because records were updated in the wrong order or at the wrong time.

Understanding the four core record types and the role of TTL turns DNS from a source of last-minute confusion into a manageable pre-launch checklist item.

Teams comparing platforms before committing to a migration will find the Framer vs. Webflow comparison useful for decision-relevant technical differences, including how each platform handles custom domain configuration.