DNS Records

What Is a DNS Record?

A DNS record is a small piece of data that tells the Domain Name System (DNS) how to respond to a lookup for a domain. All of a domain's records are grouped in a zone file. That file is kept on the domain's name servers.

Type example.com into a browser, and DNS returns the site's IP address. Computers need that number to connect, while people find names easier to remember. One record says where the website is hosted. Another names the server that receives the domain's email, and a third lists the servers that control the domain's records.

For example, opening a company website triggers a lookup that an A record answers with the address of its web server. Emailing the same company triggers a separate lookup, answered by its MX record. DNS records are used wherever a name has to be turned into an address: websites, email, cloud services, internal applications, and directory services.

How Do DNS Records Work?

DNS records work by answering lookups that pass through four types of DNS servers before a device gets its answer:

1. Recursive resolver: receives the device's question and does the searching for it, usually run by the internet provider or the organization's IT department

2. Root server: directs the resolver to the correct top-level domain server

3. TLD server: handles a top-level domain such as .com or .org and points to the domain's name servers

4. Authoritative name server: holds the zone file and returns the requested record

The resolver then caches, or temporarily stores, the answer. Repeat lookups skip the full chain and add less latency, the delay before a connection can begin.

What Does a DNS Record Contain?

DNS records all share the same five-field format, from a simple A record to a DNSSEC key:

• Name: the domain or subdomain the record applies to, such as www.example.com

• TTL: time to live, the number of seconds a resolver may cache the answer before asking again

• Class: almost always IN, short for internet

• Type: the record type, such as A, MX, or TXT

• Data: the value returned, such as an IP address or another domain name

Here's a typical A record as it appears in a zone file: www.example.com 3600 IN A 192.0.2.10.

Reading left to right, www.example.com resolves to 192.0.2.10, and resolvers can cache that answer for 3,600 seconds (one hour). Set the TTL short, and edits reach users sooner. A long TTL reduces query load, although old values then stay in caches for longer after an edit.

What Are the Types of DNS Records?

The ten DNS record types below cover most day-to-day DNS administration.

Two of these types need a closer look. SRV records let computers in a Windows network find their domain controllers, the servers that sign users in and apply security policy. TXT records hold the three email authentication checks:

• SPF: lists the servers allowed to send mail for the domain

• DKIM: adds a digital signature proving a message was not changed in transit

• DMARC: tells receiving servers what to do with mail that fails SPF or DKIM

Less Common DNS Record Types

Less common DNS record types cover security, service discovery, and specialist systems. Many domains never need them. They're added when a specific system requires them, such as DNSSEC signing or a VoIP platform.

• DNSKEY, DS, RRSIG, and NSEC: support DNSSEC, which adds digital signatures to DNS answers so resolvers can confirm they are genuine

• DNAME: sends every name under one domain to another domain, where a CNAME handles only one name

• HTTPS and SVCB: tell browsers which protocols a service supports, such as HTTP/3, before they connect

• NAPTR: maps a name to a service address, used mainly in internet telephony

• SSHFP: publishes the fingerprint of a server's SSH key, the key used for secure remote logins, so clients can confirm they reached the right server

• LOC: records the physical location of a host as map coordinates

How Do A, AAAA, and CNAME Records Differ?

A, AAAA, and CNAME records are the three types most often confused, and the difference comes down to what each one returns:

• A record: an IPv4 address, the older 32-bit format such as 192.0.2.10

• AAAA record: an IPv6 address, the newer 128-bit format such as 2001:db8::10

• CNAME record: another domain name, which the resolver then looks up for its own A or AAAA record

Many websites publish an A record and an AAAA record side by side, so visitors can connect whether their network runs IPv4 or IPv6. CNAMEs do a different job. They point a subdomain, such as shop.example.com, at a hosted service whose IP addresses may change, and the service provider keeps those addresses current.

CNAMEs come with two limits. A name that has a CNAME can't hold any other record. The second limit concerns the zone apex, which is the bare domain example.com: a CNAME isn't allowed there, because the apex has to hold the domain's SOA and NS records.

Can DNS Records Redirect a Domain?

DNS records can route a name to another server, although the address in the visitor's browser stays exactly as typed. Some DNS providers also offer ALIAS or ANAME records for the bare domain. They work much like a CNAME, so another server handles the request and the original name remains in the address bar.

A true URL redirect, say from olddomain.com to newdomain.com/pricing, is handled over HTTP. The server replies with status code 301 for a permanent move or 302 for a temporary one. That reply can come from the web server itself or from a reverse proxy, a server placed in front of other servers to receive their traffic. DNS providers that sell a "URL redirect" record point the domain at a web server they run, and that server sends the redirect.

Which DNS Records Does a Domain Need?

Every domain needs NS and SOA records to work at all, and the registrar or DNS hosting provider normally creates both. The rest depends on what the domain is used for:

• Website: an A record, an AAAA record if IPv6 is supported, and CNAMEs for subdomains such as www

• Email: MX records plus TXT records for SPF, DKIM, and DMARC

• Certificate control: a CAA record, plus DNSSEC records if the DNS host supports signing

• Internal services: SRV records for directory and VoIP (voice over IP) lookups, and PTR records for reverse lookups

How Do You Check DNS Records?

DNS records can be checked from any workstation with a lookup command. Each command in the table requests a single record type and prints what the resolver returns.

Sometimes the authoritative server and the local resolver disagree. When that happens, the resolver is usually holding an older cached value, which it replaces once the TTL runs out. Checking both is one of the first steps in network troubleshooting if only some users can reach a site.

How Are DNS Records Attacked and Protected?

DNS records attract attackers because a single altered answer can redirect users, email, or sign-in traffic to a server the attacker controls. The common attacks are:

• Cache poisoning: forged answers planted in a resolver's cache, which send users to the wrong address until the TTL expires

• DNS hijacking: unauthorized record changes at the registrar or DNS host, usually made through a stolen account

• Subdomain takeover: a CNAME left pointing at a deleted cloud resource, which an attacker then claims and uses to serve content

Several controls reduce the risk. DNSSEC signs answers so resolvers can verify them, a registrar lock blocks unauthorized domain transfers, and multi-factor sign-in protects DNS accounts. Role-based access limits who can edit zones. Removing CNAMEs that point at retired services closes the takeover route.

Why Is DNS Record Monitoring Important?

DNS record monitoring is important because nearly every application depends on a correct answer to a lookup. A mistyped A record, a broken name server delegation, or a deleted MX record can make a working service unreachable. The failure often surfaces as an application error with no obvious link to DNS.

Monitoring DNS records means checking on a schedule that each critical record resolves, returns the expected value, and answers quickly. The most useful checks cover:

• Resolution time: slow lookups delay every connection that depends on them

• Record value: an unexpected answer can point to a faulty configuration change or a hijacked record

• Name server availability: if the authoritative servers go down, the whole domain stops resolving

• Propagation: resolvers still serving an old value after an update send users to retired servers

When DNS checks run next to server, network, and application data in one view, root cause analysis takes less time. An outage alert can be traced straight to a failed lookup, so engineers don't spend time investigating a web server that is working fine.