The Domain Name System, or DNS, lets software look up information associated with names such as example.com. Website addresses are one use: DNS can supply an IP address that a browser uses when connecting to a server. It also supports email routing and other services.

For a domain owner, the useful distinction is between registration, DNS and hosting. Registration gives you control of the name under the registrar’s agreement. DNS publishes service information. Hosting supplies the website or application visitors reach.

How a DNS lookup reaches an answer

Your device usually asks a recursive resolver for the requested record. The resolver may already have a valid cached answer. If not, it can follow referrals through the DNS hierarchy until it reaches an authoritative server for the relevant zone.

Root servers help identify the appropriate top-level-domain servers, such as those serving .com. Those servers can refer the resolver to the domain’s authoritative nameservers. The authoritative server supplies the relevant record or a response explaining that the requested information is absent.

This is a simplified account of the model described in RFC 1034. The resolver does not necessarily contact the root on every request: cached records and referrals reduce repeated work. Aliases or additional delegations can require further lookups.

Know which records control each service

A DNS zone contains records identified by name and type. The record types below serve different purposes, so changing one does not automatically change the others.

TypePurpose
AAssociates a name with an IPv4 address.
AAAAAssociates a name with an IPv6 address.
CNAMEMakes one DNS name an alias of another.
MXIdentifies mail-exchange hosts and their preferences.
TXTStores text used by services such as domain verification and email authentication.
NSIdentifies nameservers authoritative for a zone.

RFC 1035 defines core record formats, while Cloudflare’s record reference explains common uses. A CNAME is a DNS alias, not an HTTP redirect telling a browser to visit a different URL.

Find the place where records are actually served

The registrar and DNS provider can be separate companies. Check which nameservers are delegated before editing records. A record added in an inactive registrar DNS panel may not affect public answers.

For a newly acquired domain, establish which provider should serve its zone. Then obtain the required website and email settings from those service providers. Avoid preserving unexplained records from a former use merely because they were already present.

Our expired-domain registration guide covers the acquisition stage. DNS configuration comes after control of the registration is confirmed.

Understand caching before making changes

A record’s time to live, or TTL, controls how long a resolver can cache it. Cloudflare’s DNS documentation describes this field. A hypothetical TTL of 300 seconds permits five minutes of caching, rather than promising that every visitor sees a change exactly five minutes later.

Plan changes with the existing values in mind. Lowering a TTL after a resolver has cached an older record does not rewrite that cached copy. Provider processing, delegation caches and local caches can also affect what you observe.

Test the service as well as the DNS answer

After editing, inspect the relevant public record and test the website or email service. A correct address record does not prove that hosting, certificates or the application are configured correctly. Likewise, a missing website response does not prove that a domain is available to register.

Keep a dated record of intended settings and verify them after a nameserver change. Our portfolio management guide helps organise those records, while the domain cost guide separates registration charges from service expenses.

When troubleshooting, record the exact name and record type you queried. A successful answer for the main domain does not establish that a separate mail host or subdomain has the intended configuration.

Categorized in: