DNS records are typed instructions published under domain names. The type tells a resolver or application how to interpret the data: an A record supplies an IPv4 address, AAAA supplies IPv6 address data, CNAME names another DNS name, MX identifies mail exchangers, NS identifies authoritative name servers, TXT carries convention-defined text, and SRV describes a service endpoint with selection and port fields. Understanding that distinction prevents common mistakes such as putting a mail destination in an address record or expecting a CNAME to contain an IP address.
What a DNS record contains
A resource record has five conceptual parts: an owner name, a type, a class, a time to live (TTL), and type-specific data called RDATA. The owner is the name at which the record is published, such as www.example.com. The type determines how the RDATA must be parsed. The class identifies the namespace (the Internet class is the one normally encountered on public websites), and the TTL tells caches how long they may reuse the answer.
As an Amazon Associate I earn from qualifying purchases.
Two records can therefore contain completely different kinds of data even when they share the same owner name. An address record contains an address; an MX record contains a preference and another domain name; an SRV record contains several numeric fields plus a target. The label alone is not enough to know what a value means.
Free tools Windows power users keep installed
One-click scans. No signup required.
A and AAAA: address records for two IP versions
What is an A record?
An A record associates a DNS name with an IPv4 host address. IPv4 addresses use the familiar dotted-decimal form, for example 192.0.2.25 (an address reserved for documentation). RFC 1035 assigns A the type code 1. When a resolver receives an A answer, the result is IPv4 address data that software can use when opening an IPv4 connection.
#1 Best Overall
An A record is not a web-only setting. Any application that asks for IPv4 address data can use it, while the actual service still has to be running and reachable at that address. Publishing an A record does not prove that a web server, API, or other process is listening.
What is an AAAA record?
An AAAA record stores an IPv6 address. IPv6 address data is 128 bits, and RFC 3596 defines AAAA as type code 28. A name can publish multiple AAAA records when it has more than one IPv6 address; clients and operating systems can then select among the returned addresses according to their connection logic.
An AAAA lookup asks for IPv6 address data, but the DNS query itself does not require the resolver or the client to use IPv6 transport. A network that reaches its DNS resolver over IPv4 can still receive an AAAA answer. Connectivity to the returned IPv6 address is a separate matter.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
A versus AAAA at a glance
| Record | Data returned | Typical question | Specification detail |
|---|---|---|---|
| A | One IPv4 address per record | “Which IPv4 address should I try for this name?” | Type code 1 in RFC 1035 |
| AAAA | One 128-bit IPv6 address per record | “Which IPv6 address should I try for this name?” | Type code 28 in RFC 3596 |
Many dual-stack services publish both types. A client that supports both can use the address family and connection strategy appropriate to its network. If only one type is published, clients relying on the other family may not connect, even though the DNS name itself exists.
CNAME: an alias to another DNS name
A CNAME record says that the owner name is an alias for a canonical target name. Its RDATA is another domain name, not an IPv4 or IPv6 address. For example, docs.example.com CNAME help.example.net directs DNS resolution toward help.example.net; the target’s A or AAAA records provide any addresses ultimately used by a client.
This distinction matters when reading a zone file or troubleshooting. A CNAME does not tell you the target’s current IP address, whether the target has IPv4 or IPv6 data, or whether a service is reachable. Follow the target name and inspect its address records, then verify the application and network path separately.
When a tool displays a CNAME followed by address records, it is showing a chain of answers: the alias first, then data for the canonical target. Treating the first value as an IP address is a type error, not merely a formatting issue.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesMX: where a domain’s mail should be delivered
An MX record identifies a mail exchanger for a domain. The RDATA includes a preference value and the exchanger’s host name. Sending mail systems use the preference values to rank available exchangers, then resolve those host names to address records before making a connection.
MX is therefore a mail-routing instruction, not the address record for a website. A domain can send web traffic to one set of hosts while its MX records point to entirely different hosts. If mail delivery fails, inspect the MX names and their subsequent A or AAAA records rather than changing the site’s A record.
Multiple MX records provide alternatives. The preference field supplies the ordering information; it does not itself contain a port, an IP address, or a mailbox. The receiving host must still be configured to accept mail for the domain, and transport, policy, and filtering systems can reject mail even when the MX data is syntactically valid.
NS: which servers are authoritative
An NS record names a host that is expected to be authoritative for a domain or zone. NS records are part of delegation: they tell the DNS hierarchy which name servers hold the authoritative data for the relevant zone.
Recommended Free Tools
NS data identifies server names, not their IP addresses. To contact an authoritative server, a resolver may also need A or AAAA records for those names (or address information supplied by delegation mechanisms). An NS answer consequently does not by itself demonstrate that the server is online, reachable, or serving the expected zone contents.
Rank #3
- Used Book in Good Condition
Do not confuse an NS record with the resolver configured on your laptop or router. An authoritative name server publishes the source data for a zone; a recursive resolver asks authoritative servers questions, caches the responses, and answers clients from that cache when permitted.
TXT: text whose meaning comes from a convention
A TXT record stores one or more text strings. DNS defines the TXT container, but the meaning of the text comes from the protocol or service that reads it. A domain-verification token, an email-authentication policy, and an application-specific setting can all be carried in TXT records while following different conventions.
Because TXT is general-purpose, seeing a string does not tell you which system should consume it. Read the prefix and syntax defined by the relevant protocol, and preserve the exact punctuation, quoting, and character sequence required by that protocol. A TXT record can be present and correctly encoded yet have no effect if the consuming service is not configured to look for it.
TXT is not an alias and not a replacement for an address, MX, or SRV record. It is also not automatically proof that a claim in the text is true; an application must validate and act on the value.
SRV: structured service location
An SRV record publishes where a named service is available. Its structured data contains priority, weight, port, and a target host name. RFC 2782 assigns SRV type code 33.
- Priority lets a client prefer one group of targets over another.
- Weight distributes selection among targets at the same priority when the client supports the specified algorithm.
- Port identifies the transport port for the service.
- Target names the host to which the client should connect; that name must then be resolved to an address.
SRV is more expressive than a simple alias. A CNAME answers “what other name represents this name?” An SRV record answers “which host, on which port, should this service use, and how should multiple hosts be selected?” The application must know the service name and protocol labels used in the SRV owner name; a generic DNS client cannot infer a service merely from an arbitrary SRV record.
One table for the common record types
| Type | Core purpose | What its RDATA contains | Consumer’s question |
|---|---|---|---|
| A | IPv4 address | IPv4 address | Where is this name on IPv4? |
| AAAA | IPv6 address | 128-bit IPv6 address | Where is this name on IPv6? |
| CNAME | Alias | Canonical DNS name | Which other name is canonical? |
| MX | Mail routing | Preference and exchanger name | Which hosts should receive this domain’s mail? |
| TXT | Application-defined text | Text strings | What protocol-specific text is published here? |
| NS | Zone authority and delegation | Authoritative name-server name | Which servers publish this zone? |
| SRV | Service discovery | Priority, weight, port, and target name | Where is this service listening? |
TTL and why DNS changes are not instant
TTL is a cache lifetime. RFC 1035 describes it as the interval for which a resource record may be cached before the source should be consulted again. In the original wording, the field is described as a signed 32-bit integer; RFC 2181 later clarifies TTL handling, so that historical signedness description should not be treated as current implementation guidance.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWhen a recursive resolver stores an answer, it can continue returning that cached data until the TTL expires. Different resolvers may have obtained the record at different times, so users can observe old and new answers during a transition. Lowering a TTL immediately before a change cannot retract copies that were already cached under the earlier, longer TTL.
When changing a record, record the old value, the intended new value, and the time of the change. Query more than one recursive resolver and, when appropriate, query the authoritative server directly. A mismatch between authoritative data and a recursive answer can simply indicate an unexpired cache rather than a failed edit.
Authoritative name servers and recursive resolvers
These roles are related but not interchangeable. An authoritative name server is responsible for the source data of a zone. A recursive resolver performs lookups on behalf of clients, follows referrals, caches responses, and returns the result. Both may be casually called “DNS servers,” which is why role-specific wording helps during an outage.
If an authoritative query shows the new A record but a user’s resolver shows the old one, investigate TTL and cache age first. If authoritative servers disagree with one another, the problem is in zone publication, delegation, or synchronization and requires a different fix.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →How to interpret an unfamiliar DNS response
- Identify the owner name. Confirm whether the answer is for the exact hostname you intended, such as
api.example.com, rather than the parent domain. - Read the type before the value. An address, another name, text, and service fields require different interpretations.
- Parse the RDATA according to that type. For MX, note the preference and exchanger; for SRV, note all four fields; for NS and CNAME, follow the returned name.
- Check the TTL. Decide whether a resolver could still be serving an older cached answer.
- Resolve the next name when necessary. MX, NS, CNAME, and SRV commonly point to another DNS name whose A or AAAA records must be inspected.
- Separate DNS from service health. Test the application, port, firewall, certificate, and server configuration independently; valid DNS data does not guarantee reachability.
Practical scenarios
A website moved to a new IPv4 host
Change the relevant A record to the new IPv4 address, keep any needed AAAA record in mind, and account for the existing TTL. Visitors using different recursive resolvers may switch at different times. If the hostname is a CNAME, change the target’s address record or update the alias according to the intended design rather than placing an address in the CNAME field.
Mail is going to the wrong provider
Inspect the domain’s MX records and their preference values. Resolve each exchanger name to A and AAAA data, then verify that the receiving systems accept mail for the domain. Changing a website’s A record will not redirect mail when MX records point elsewhere.
A service-discovery client cannot connect
Check that the client is querying the correct SRV service and protocol name, then verify priority, weight, port, and target. Resolve the target host and test the advertised port. An SRV record can be perfectly formed while the process is stopped, the port is blocked, or the target address is wrong.
A verification token is not recognized
Read the TXT record exactly as the verifying protocol specifies. Confirm the token is published at the required owner name, not merely at a visually similar subdomain, and allow for resolver caching before concluding that the value is absent.
Common mistakes and their fixes
- Putting an IP address in a CNAME: replace it with a DNS name and publish the address on that target.
- Using an A record for mail routing: publish MX data for the mail domain, then provide address records for each exchanger.
- Assuming NS contains server addresses: resolve the NS host names separately and verify delegation.
- Treating TXT as self-explanatory: identify the protocol or application that defines the string’s syntax.
- Calling SRV a simple alias: account for priority, weight, port, and target as separate fields.
- Expecting every resolver to update immediately: check TTL and cache age, and compare recursive answers with authoritative data.
- Equating a DNS answer with a working service: test the actual endpoint and its network and application configuration.
What DNS records can—and cannot—tell you
Records tell software how to locate names, mail systems, authorities, text policies, and discoverable services. They do not, by themselves, establish that an address is reachable, that a port is open, that a certificate matches, that a mail server accepts a message, or that text published in TXT has passed an application’s validation. Those outcomes depend on systems beyond the DNS data.
Once you read the type first, DNS responses become much less ambiguous: A and AAAA answer address-family questions; CNAME maps an alias to a name; MX maps a domain to mail exchangers; NS identifies authority; TXT carries protocol-defined text; and SRV supplies structured service location. TTL and the split between authoritative and recursive servers explain why the same name can temporarily produce different observations.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
