The Domain Name System (DNS) is the distributed naming system that translates readable domain names, such as example.com, into the IP addresses computers use to reach websites, applications, email and APIs. Almost every connection starts with a DNS lookup, so when DNS is slow, misconfigured or unavailable, everything that depends on it appears to be down. For a business, DNS is also a control point for email delivery, traffic steering, failover and security.
At a glance
- DNS is hierarchical: the root points to top-level domains such as .com, which point to the authoritative servers for each domain.
- Recursive resolvers look up and cache answers for users; authoritative servers hold the official records for a domain.
- Records such as A, AAAA, CNAME, MX and TXT route web traffic, email and domain verification.
- Caching, controlled by each record’s TTL, makes DNS fast but means changes take time to spread.
- Outages, hijacked registrar accounts and DDoS attacks on DNS can take every service on a domain offline.
What problem it solves
People and applications use names; networks route on numbers. DNS bridges the two, so you can move a website to a new server, switch email providers or add a cloud region by changing a record instead of telling every user a new address.
It has grown well beyond simple lookup. Teams use DNS to point users to a content delivery network (CDN), split traffic between clouds, route around a failed data center and prove domain ownership to SaaS providers. Email authentication records (SPF, DKIM and DMARC) live in DNS and affect whether your mail is delivered. Because so much depends on it, DNS is worth designing, monitoring and change-controlling rather than treating it as a one-time “set the record and forget it” task.
How it works
Lookup. A device asks a recursive resolver, typically run by the ISP, the company or a public DNS service, for a name such as www.example.com. If the resolver has no cached answer, it asks a root server, then the server for the top-level domain, then the authoritative server for example.com, which returns the record.
Caching. The resolver caches the answer for the record’s time to live (TTL). Short TTLs, often a few minutes, make changes and failover take effect faster; long TTLs reduce query volume. Failed lookups are cached too, so a mistake can linger after it is fixed.
Records. A and AAAA records map a name to an IPv4 or IPv6 address. CNAME points one name at another. MX directs email. TXT holds verification tokens and email authentication policies. NS records delegate a zone, SRV records help find services such as SIP, and CAA records state which certificate authorities may issue certificates for the domain.
Hosting and registration. You register a domain through a domain registrar, which tells the top-level domain which authoritative servers to use. Those servers may be run in-house or by a managed DNS provider, many of which use anycast to answer from many locations at once. Some offer health-checked or geographic answers, the basis of DNS-based global server load balancing (GSLB).
Security. DNSSEC adds signatures so validating resolvers can detect forged answers; it authenticates answers but does not encrypt them. DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt queries between a device and its resolver. Inside the company, DNS filtering blocks lookups of known malicious domains. Internally, split-horizon DNS can return private addresses to staff and public addresses to everyone else.
When it matters for buyers
- Choosing a DNS host. Look for an anycast network, an API for automation, DNSSEC support and a published uptime commitment. A secondary provider can protect against one provider’s outage.
- Protecting the registrar account. Domain hijacks often start with a compromised registrar login. Use multi-factor authentication, registrar and registry locks where available, and make sure the company, not an individual or former vendor, owns the account.
- Planning migrations and failover. Lower TTLs before a move, and test failover records before you need them.
- Email deliverability. Changes to email services require matching SPF, DKIM and DMARC updates.
- DDoS exposure. Attacks can target your authoritative DNS as well as your applications; see distributed denial of service (DDoS).
DNS sits in front of most public services; our cloud content delivery network overview covers how CDNs build on it.
Questions to ask vendors
- Is your authoritative DNS served over anycast, from how many locations, and what uptime do you commit to in the SLA?
- Do you support DNSSEC, and who manages key rollover?
- Can we run you alongside a secondary provider, and do you support zone transfers to keep them in sync?
- What health checks, geographic routing or weighted answers are available, and how are they priced?
- Is there an API or infrastructure-as-code support, and is there an audit log of record changes?
- How do you protect against DDoS attacks on the DNS service itself?
- Who on our side can change records, and can changes require approval?
How it differs from managed DNS
DNS is the naming system itself, the protocol and global hierarchy that internet-connected devices use. Managed DNS is a service in which a provider hosts and operates the authoritative DNS for your domains on its own network, usually adding anycast distribution, traffic steering, DDoS protection and an SLA. Every organization with a domain uses DNS; managed DNS is one way to host it. DNS is also distinct from a domain registrar, which records who owns a domain and where its authoritative servers are, but does not necessarily host the records itself.
Problems this helps with
- Our website or email went down because of a DNS change
- Single DNS provider is a single point of failure
- Not sure who controls our domain records or registrar account
- Need faster failover between sites or clouds
