DNS Record Types Explained: A, AAAA, CNAME, MX, TXT, NS, PTR & SRV 2026

DNS Record Types Explained: A, AAAA, CNAME, MX, TXT, NS, PTR and SRV

The Domain Name System (DNS) does much more than translate domain names into IP addresses. Every website, email platform, cloud service, enterprise application, and network infrastructure depends on DNS resource records to publish information about how services can be reached and how domain names should be handled.

Understanding DNS record types is an essential skill for network administrators, system administrators, cloud engineers, DevOps professionals, and cybersecurity specialists.

The most familiar DNS records include A, AAAA, CNAME, MX, TXT, NS, PTR, and SRV, but they serve different purposes. Some associate hostnames with network addresses, others identify mail servers or authoritative DNS infrastructure, and others support service discovery, certificate issuance, and security validation.

Modern DNS also includes specialized records such as SOA, CAA, DNSKEY, DS, RRSIG, HTTPS, and SVCB. These records help DNS function as an infrastructure and security system rather than a simple hostname lookup service.

This guide explains the most important DNS record types, how they work, their configuration rules, and practical troubleshooting methods using dig and nslookup.

For foundational concepts, begin with our DNS Explained guide. To understand how cached answers affect DNS changes, also see DNS Caching and TTL Explained.

What Is a DNS Record?

A DNS resource record (RR) is a structured piece of information published within the Domain Name System.

DNS organizes domain names into a hierarchical namespace. Authoritative name servers maintain data for DNS zones, and recursive resolvers retrieve this information to answer client queries.

The fundamental DNS concepts are described in RFC 1034 and RFC 1035.

A resource record normally contains several fields:

• Name: The domain name or owner name associated with the record.
• TTL: Time to Live, expressed in seconds.
• Class: Usually IN for Internet DNS.
• Type: The kind of resource record, such as A, MX, or TXT.
• RDATA: The record-specific information, such as an IP address or hostname.

For example:

www.example.com. 3600 IN A 192.0.2.10

This record identifies the IPv4 address associated with www.example.com.

Its TTL is 3600 seconds, representing one hour of normal cache freshness.

A zone may contain several different record types:

example.com.         3600 IN A     192.0.2.10
www.example.com.     3600 IN CNAME example.com.
example.com.         3600 IN MX    10 mail.example.com.
example.com.         3600 IN TXT   "example-verification=value"

Each record serves a different purpose.

The A record provides an IPv4 address. The CNAME creates an alias. The MX record identifies a mail exchanger. The TXT record publishes application-defined text.

These examples use documentation-only addresses and domains; they are not intended as live production configuration.

How DNS Records Work

Suppose a user enters www.example.com into a web browser.

The browser or operating system needs suitable DNS information before it can establish the network connection.

A simplified resolution sequence looks like this:

Web Browser
     |
     v
Operating System Resolver
     |
     v
Recursive DNS Resolver
     |
     +--> Root DNS
     |
     +--> TLD DNS
     |
     +--> Authoritative DNS
     |
     v
DNS Answer
     |
     v
Client Connection

The recursive resolver may already have a cached answer. If so, it can often respond without following the full delegation path again.

The answer also depends on the record type being requested.

An A query requests IPv4 information. An AAAA query requests IPv6 information. An MX query requests mail-exchanger information.

DNS supplies naming and service information, but it does not replace IP networking. Once a client has obtained an appropriate address, packet forwarding follows the principles described in our TCP/IP Explained guide.

DNS Record Types at a Glance

The following table provides a quick comparison.

Record	Main purpose	Common use
A	Maps a name to IPv4	Websites and servers
AAAA	Maps a name to IPv6	IPv6-enabled services
CNAME	Aliases one DNS name to another	Managed hosting and services
MX	Identifies mail exchangers	Email delivery
TXT	Publishes text-based data	Verification, SPF, DKIM, DMARC
NS	Identifies authoritative name servers	DNS delegation
PTR	Maps a reverse DNS name to another name	Reverse DNS
SRV	Publishes service location and port	Service discovery
SOA	Contains zone administrative information	Zone management
CAA	Specifies authorized certificate issuers	Certificate issuance control
DNSKEY	Publishes DNSSEC public keys	DNSSEC validation
DS	Links a child zone to its parent trust chain	DNSSEC delegation
RRSIG	Contains DNSSEC signatures	DNS data authentication
HTTPS	Publishes HTTP service-binding information	Modern HTTPS connection setup
SVCB	Publishes service-binding information	Alternative service endpoints

The correct record type depends on what the application or network service needs to discover.

A Record Explained: DNS to IPv4

An A record, also called an Address record, maps a DNS name to an IPv4 address.

Example:

example.com. 3600 IN A 192.0.2.10

This tells DNS clients that example.com has the IPv4 address 192.0.2.10.

A records are commonly used for websites, application servers, API endpoints, and other IPv4-based services.

An organization might configure:

www.example.com. 300 IN A 192.0.2.10
api.example.com. 300 IN A 192.0.2.20
app.example.com. 300 IN A 192.0.2.30

Each hostname has a different destination.

Can one hostname have multiple A records?

Yes. A single name can have multiple A records:

app.example.com. 300 IN A 192.0.2.10
app.example.com. 300 IN A 192.0.2.11
app.example.com. 300 IN A 192.0.2.12

These records form an A resource-record set, or RRset.

Clients may receive several addresses and choose among them according to their resolver and application behavior.

However, publishing multiple addresses does not automatically create a complete high-availability system.

DNS does not inherently perform application health checks against every listed address. If one server fails, clients may still attempt to connect to it.

For production infrastructure, DNS-based distribution is frequently combined with dedicated Load Balancing mechanisms.

How to check an A record

Use:

dig example.com A

To display only the answer:

dig +noall +answer example.com A

A successful DNS response indicates that the record can be resolved. It does not prove that the web server or application is accepting connections.

AAAA Record Explained: DNS to IPv6

An AAAA record maps a DNS name to an IPv6 address.

Example:

example.com. 3600 IN AAAA 2001:db8::10

The relationship is straightforward:

A Record    --> IPv4 Address
AAAA Record --> IPv6 Address

A dual-stack service can publish both types:

example.com. 3600 IN A    192.0.2.10
example.com. 3600 IN AAAA 2001:db8::10

This allows clients to discover appropriate addresses according to their network capabilities.

A vs AAAA records

Feature	A record	AAAA record
Address family	IPv4	IPv6
Example	192.0.2.10	2001:db8::10
Main function	IPv4 address lookup	IPv6 address lookup
Can coexist on one name?	Yes	Yes

IPv6 support should be configured carefully.

Publishing an AAAA record when the destination is not reachable over IPv6 may cause connection failures or delays for IPv6-capable clients.

Administrators should verify the actual IPv6 network path, firewall configuration, and application listener rather than assuming that a successful DNS lookup confirms service availability.

Check an AAAA record using:

dig example.com AAAA

CNAME Record Explained: DNS Aliases

A CNAME record, or Canonical Name record, declares that one DNS name is an alias for another.

Example:

www.example.com. 3600 IN CNAME example.com.

Instead of storing an IPv4 or IPv6 address directly under www.example.com, the DNS record directs resolution toward the canonical hostname.

Another example:

app.example.com. 300 IN CNAME service.hosting.example.

The destination may then resolve to an A or AAAA record.

app.example.com
       |
       v
     CNAME
       |
       v
service.hosting.example
       |
       v
      A / AAAA
       |
       v
   IP Address

CNAME records are particularly useful when a third-party provider manages the underlying service infrastructure.

If the provider changes the target hostname’s addresses, the domain owner may not need to update the alias itself.

A record vs CNAME

An A record points to an IPv4 address.

A CNAME points to another DNS name.

For example:

web.example.com. 300 IN A 192.0.2.20

versus:

web.example.com. 300 IN CNAME hosting.example.net.

The first publishes an address directly.

The second publishes an alias requiring the canonical name to be resolved as appropriate.

Important CNAME restrictions

A CNAME normally cannot coexist with other DNS data at the same owner name.

For instance, this is not a valid conventional CNAME configuration:

www.example.com. IN CNAME example.com.
www.example.com. IN A     192.0.2.10

The DNS standards require special handling of aliases. Administrators should not combine a CNAME with unrelated resource records at the same name.

A CNAME is also generally unsuitable at a conventional DNS zone apex such as example.com, where SOA and NS records must exist.

Some providers offer features such as CNAME flattening or ALIAS-style records to produce address responses for apex hostnames.

Cloudflare documents its implementation in CNAME Flattening.

These are provider-specific capabilities and should not be confused with ordinary CNAME record behavior.

Is a CNAME an HTTP redirect?

No.

A CNAME operates within DNS.

An HTTP redirect is an application-layer response such as HTTP 301 or 302 that instructs a client to request another URL.

A CNAME does not automatically redirect a browser from one website path to another.

MX Record Explained: Email Routing

An MX record, or Mail Exchange record, identifies a mail exchanger responsible for receiving email for a domain.

Example:

example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.

Each MX record contains a preference value and a mail server hostname.

Lower numerical preference values are generally preferred.

In this example:

• mail1.example.com has preference 10.
• mail2.example.com has preference 20.

Mail delivery systems generally try lower-preference values first, while the precise behavior also depends on the applicable SMTP rules and server availability.

When multiple MX records share the same preference value, senders may distribute attempts among them.

MX records must identify usable mail destinations

The hostname specified in an MX record must resolve appropriately.

For example:

mail1.example.com. 3600 IN A 192.0.2.25

The target should not itself be a CNAME alias under the conventional DNS requirements for MX destinations.

An MX record also does not automatically authenticate the email sent from a domain.

Email authentication relies on additional mechanisms such as SPF, DKIM, and DMARC.

How to check MX records

dig example.com MX

You should verify both the MX records and the address records of their targets.

An MX response may be perfectly valid even when the referenced mail server is unreachable. DNS configuration and SMTP availability must be evaluated separately.

TXT Record Explained: Verification and Authentication

A TXT record publishes text-based data associated with a DNS name.

TXT records are widely used for domain verification, mail authentication policies, and other application-defined information.

A generic example:

example.com. 3600 IN TXT "verification=example-value"

A service may request a specific value to confirm that an administrator controls the domain’s DNS configuration.

SPF records using TXT

Sender Policy Framework (SPF) allows receiving mail systems to evaluate whether a sending host is authorized to use a domain in the relevant SMTP identity.

SPF policies are normally published in DNS TXT records.

Example:

example.com. 3600 IN TXT "v=spf1 ip4:192.0.2.10 -all"

This illustrative policy authorizes the specified IPv4 address and indicates a fail result for other sources.

Do not copy this policy into production without confirming all legitimate mail senders.

SPF is standardized in RFC 7208.

DKIM records using TXT

DomainKeys Identified Mail (DKIM) uses cryptographic signatures to help receiving mail systems verify that signed message content is associated with the responsible domain.

A DKIM public key is commonly published at a selector-specific DNS name.

Example structure:

selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_PLACEHOLDER"

The value PUBLIC_KEY_PLACEHOLDER is illustrative, not a valid production public key.

DKIM is defined in RFC 6376.

DMARC records using TXT

Domain-based Message Authentication, Reporting, and Conformance (DMARC) builds on SPF and DKIM results and their alignment with the domain visible in the message’s From header.

A DMARC policy is published at a name beginning with _dmarc.

Example:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none"

The p=none policy is commonly used during observation and monitoring.

Stronger policies such as p=quarantine or p=reject should be configured only after the legitimate mail flows and authentication alignment have been evaluated.

The foundational DMARC specification is RFC 7489.

SPF vs DKIM vs DMARC

Mechanism	Main role	Common DNS location
SPF	Authorizes SMTP sending sources	Domain TXT
DKIM	Publishes keys used to verify signatures	Selector-specific TXT
DMARC	Defines alignment-based policy and reporting	_dmarc TXT

These mechanisms complement one another but are not interchangeable.

For network administrators, DNS-based email authentication is an important component of the broader protection strategy discussed in Network Security Basics.

NS Record Explained: Authoritative Name Servers

An NS record, or Name Server record, identifies a name server associated with a DNS zone or delegation.

Example:

example.com. 86400 IN NS ns1.example.net.
example.com. 86400 IN NS ns2.example.net.

These records identify name servers responsible for DNS information.

A domain typically uses multiple authoritative name servers for redundancy and availability.

NS records and DNS delegation

DNS operates as a hierarchy.

The root zone delegates authority to top-level domains, and those domains delegate authority to registered domains.

Organizations can also delegate their own subdomains.

For example, an organization managing example.com might delegate cloud.example.com to another DNS platform.

Conceptually:

example.com
    |
    +--> www.example.com
    |
    +--> api.example.com
    |
    +--> cloud.example.com
              |
              v
      Separate DNS Zone
              |
              v
    Dedicated Name Servers

This design is common in larger companies where individual teams maintain separate infrastructure environments.

Parent delegation vs zone NS records

Administrators should distinguish between delegation information stored in the parent zone and NS records maintained within the child zone.

Mismatches can cause inconsistent or failed resolution.

When changing DNS providers, verify the parent delegation, authoritative DNS responses, glue records where relevant, and DNSSEC configuration.

To investigate delegation paths, use:

dig +trace example.com

This is particularly valuable when diagnosing nameserver migration problems.

PTR Record Explained: Reverse DNS

A PTR record, or Pointer record, is commonly used for reverse DNS.

Ordinary forward DNS resolution finds address information associated with a hostname.

For example:

server.example.com
        |
        v
    192.0.2.10

Reverse DNS starts with an IP address and looks for a hostname associated with the corresponding reverse DNS name.

For IPv4, the special in-addr.arpa namespace is used.

An illustrative record is:

10.2.0.192.in-addr.arpa. 3600 IN PTR server.example.com.

This is the reverse DNS representation of 192.0.2.10.

IPv6 reverse DNS uses the ip6.arpa namespace with the appropriate nibble-reversed address representation.

Why PTR records matter

PTR records are useful for logging, network troubleshooting, server identification, and mail infrastructure.

Some mail systems use reverse DNS as one signal when assessing sending servers.

However, a PTR record alone does not prove ownership of an address or authenticate email.

Who controls reverse DNS?

Creating an A record does not automatically give an administrator control over the corresponding PTR record.

Public IP reverse DNS is normally configured through the organization responsible for the relevant IP address allocation or through a provider offering delegated control.

For a server hosted by a cloud or hosting company, reverse DNS may need to be configured through that provider’s management interface.

How to check a PTR record

dig -x 192.0.2.10

You can also query the reverse DNS name directly:

dig 10.2.0.192.in-addr.arpa PTR

When troubleshooting mail delivery, compare the PTR response with the forward address records and the sending server’s actual configuration.

For additional system administration techniques, see Linux Server Administration.

SRV Record Explained: Service Discovery

An SRV record, or Service record, publishes information about where a particular service is available.

Unlike a basic A record, SRV can describe a service target and network port, along with priority and weight values.

Its format is defined by RFC 2782.

A typical SRV record has this structure:

_service._protocol.example.com. TTL IN SRV priority weight port target

For example:

_sip._tcp.example.com. 3600 IN SRV 10 20 5060 sip1.example.net.

This example contains:

• Service: _sip
• Protocol: _tcp
• Priority: 10
• Weight: 20
• Port: 5060
• Target: sip1.example.net

The target hostname must be resolvable through suitable address records.

SRV priority vs weight

Priority and weight perform different functions.

Priority determines the preferred group of targets. Lower numerical values are preferred.

Weight influences selection among targets with the same priority, according to the SRV selection algorithm.

Example:

_sip._tcp.example.com. 3600 IN SRV 10 70 5060 sip1.example.net.
_sip._tcp.example.com. 3600 IN SRV 10 30 5060 sip2.example.net.
_sip._tcp.example.com. 3600 IN SRV 20  0 5060 sip3.example.net.

The first two targets have the same priority but different weights.

The third has a less-preferred priority value.

These records allow suitable clients to discover service endpoints rather than relying entirely on manually configured server names and ports.

SRV is used by various protocols and enterprise services, although support depends on the application.

How to query an SRV record

dig _sip._tcp.example.com SRV

Be sure to query the appropriate service and protocol labels required by the application.

SOA Record Explained: Zone Administration

The Start of Authority (SOA) record contains administrative and operational information associated with a DNS zone.

An illustrative SOA record is:

example.com. 3600 IN SOA ns1.example.net. hostmaster.example.com. (
    2026101401
    3600
    900
    1209600
    300
)

The fields represent:

Field	Purpose
Primary name server	Server named in the SOA record
Responsible mailbox	Administrative contact in DNS name format
Serial	Zone version indicator
Refresh	Secondary-server refresh interval
Retry	Retry interval after unsuccessful refresh
Expire	Limit for continuing to use old zone data
Minimum	Used in negative caching semantics

Managed DNS providers may control the SOA automatically.

Administrators should not blindly reuse sample SOA values, because operational requirements and provider implementations differ.

SOA and negative DNS caching

SOA information is important when investigating negative responses such as NXDOMAIN.

Under the traditional negative caching rules described in RFC 2308, the applicable negative TTL involves the smaller of the SOA record TTL and the SOA MINIMUM value.

This helps explain why a resolver may temporarily continue reporting that a hostname does not exist even after an administrator creates it.

For a detailed explanation, see DNS Caching and TTL Explained.

CAA Record Explained: Certificate Authority Authorization

A CAA record allows a domain owner to specify which certificate authorities are authorized to issue certificates for the domain.

For example:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"

This authorizes Let’s Encrypt for the applicable issuance context, subject to the complete CAA processing rules.

CAA is defined by RFC 8659.

Why CAA matters

Certificate issuance affects the security of HTTPS services.

CAA helps reduce the risk of unintended certificate issuance by allowing domain owners to declare restrictions checked by participating certificate authorities.

Common properties include:

• issue: Authorization for ordinary certificate issuance.
• issuewild: Authorization rules involving wildcard certificates.
• iodef: A mechanism for providing incident-reporting contact information.

CAA does not replace certificate validation, strong private-key management, or HTTPS configuration.

It is one control within a broader certificate security strategy.

How to check CAA records

dig example.com CAA

Before adding restrictive CAA records, verify which certificate authorities your web hosting, CDN, and certificate automation systems use.

Incorrect restrictions can interfere with legitimate certificate issuance or renewal.

DNSSEC Record Types: DNSKEY, DS, RRSIG, NSEC and NSEC3

Traditional DNS does not inherently provide cryptographic authentication of every answer.

DNS Security Extensions (DNSSEC) add mechanisms that allow validating resolvers to authenticate signed DNS data and detect certain forms of tampering.

DNSSEC introduces specialized resource records.

The foundational resource-record specifications are described in RFC 4034.

DNSKEY record

A DNSKEY record publishes a DNSSEC public key associated with a signed DNS zone.

Validating resolvers can use relevant DNSKEY information to verify DNSSEC signatures.

A DNSKEY record does not contain an ordinary website IP address.

RRSIG record

An RRSIG record contains a digital signature over a DNS RRset.

It allows a validating resolver to verify that the signed data corresponds to the relevant DNSSEC key and has not been modified without detection.

RRSIG records also include signature validity information.

DS record

A Delegation Signer (DS) record helps establish the chain of trust between a parent DNS zone and a signed child zone.

For example, a registered domain using DNSSEC usually depends on corresponding DS information in its parent zone.

Incorrect or stale DS records can cause validating resolvers to reject answers from a domain even if its authoritative servers respond normally.

This is why DNSSEC changes must be coordinated carefully during nameserver migrations.

NSEC and NSEC3 records

NSEC and NSEC3 records support authenticated denial of existence.

They allow signed DNS zones to provide evidence that a requested name or record type does not exist.

These records have different operational and privacy characteristics.

For administrators, the practical lesson is that DNSSEC protects the authenticity of DNS information but does not encrypt ordinary DNS queries.

DNSSEC should not be confused with DNS over HTTPS or DNS over TLS, which address different security and privacy concerns.

How to inspect DNSSEC records

dig example.com DNSKEY +dnssec
dig example.com DS +dnssec
dig example.com A +dnssec

The +dnssec option requests DNSSEC-related data. It does not automatically mean that your dig command has independently completed DNSSEC validation.

For secure deployments, confirm the resolver’s actual validation behavior and inspect the complete DNSSEC chain of trust.

Modern DNS Records: HTTPS and SVCB

DNS continues to evolve beyond traditional address, mail, and alias records.

Two important modern resource-record types are HTTPS and SVCB.

They are defined in RFC 9460 — Service Binding and Parameter Specification via the DNS.

What is an SVCB record?

An SVCB (Service Binding) record can provide connection information about a network service, including alternative endpoints and service parameters.

Depending on its mode, it can express service aliasing or detailed service endpoint configuration.

It helps clients learn connection-relevant information through DNS.

What is an HTTPS record?

An HTTPS record is a specialization of SVCB designed for HTTP services.

It can publish information that helps compatible clients discover supported endpoints and connection parameters before establishing a connection.

For example:

www.example.com. 300 IN HTTPS 1 . alpn="h2,h3"

This illustrative HTTPS record advertises service-binding information that includes supported application-layer protocols.

Actual use depends on client support, endpoint configuration, and applicable protocol rules.

HTTPS records do not replace ordinary A or AAAA records in all situations.

Clients still need suitable addressing and transport connectivity.

HTTPS vs CNAME

A CNAME declares that one DNS name is an alias for another.

An HTTPS record can provide richer service-binding information, including connection parameters.

SVCB and HTTPS also support certain service-aliasing scenarios that conventional CNAME records cannot handle at a DNS zone apex.

These modern records are becoming relevant to advanced web infrastructure and connection optimization, but administrators should not assume every application processes them.

DNS TTL and Resource-Record Caching

Every DNS administrator should understand Time to Live (TTL).

TTL specifies how long DNS information may normally remain fresh in a resolver cache.

Consider:

app.example.com. 3600 IN A 192.0.2.10

The TTL is 3600 seconds, or one hour.

If a recursive resolver caches this RRset, it can normally reuse the answer until its freshness lifetime expires.

High TTL vs low TTL

Characteristic	Higher TTL	Lower TTL
Cache reuse	More	Less
Authoritative query frequency	Generally lower	Generally higher
Responsiveness to updates	Potentially slower	Potentially faster
Migration flexibility	Lower	Higher

A low TTL is not automatically better.

For relatively stable infrastructure, longer cache lifetimes can reduce repeated DNS traffic.

For planned migrations or systems that need more responsive DNS updates, a lower TTL may be useful.

Lower TTL before a migration

Suppose a record has a TTL of 86400 seconds.

A resolver obtains it before the administrator changes the TTL to 300 seconds.

The resolver does not automatically learn the new TTL. It may continue using its previously cached information until the old freshness period expires.

Consequently, administrators should lower the relevant TTL sufficiently in advance of a planned migration.

The complete behavior is covered in our DNS Caching and TTL Explained guide, including negative caching, CNAME chains, and Serve Stale.

DNS Records in Cloud Infrastructure

Cloud platforms use DNS to provide stable names for infrastructure that may change behind the scenes.

A traditional architecture might use:

Domain
   |
   v
A Record
   |
   v
Single Web Server

A cloud application might instead use:

Domain
   |
   v
DNS
   |
   v
Cloud Load Balancer
   |
   +--> Application Instance A
   |
   +--> Application Instance B
   |
   +--> Application Instance C

The public hostname can remain stable while the instances behind the load balancer change.

Cloud providers also use DNS aliases, service discovery, private DNS zones, and provider-specific record-management features.

For a broader explanation of elastic infrastructure, read Cloud Computing Explained and Cloud Networking Explained.

DNS and infrastructure automation

In a production environment, DNS changes may be managed through infrastructure-as-code tools and provider APIs.

This introduces several operational requirements:

• Consistent naming conventions
• Version-controlled DNS configuration
• Restricted API permissions
• Automated validation
• Reviewable change history
• Clear rollback procedures

A malformed DNS record deployed through automation can affect many services simultaneously.

DNS should therefore be treated as production infrastructure rather than an isolated domain-management setting.

DNS Records and Network Security

DNS configuration is security-sensitive.

If an attacker gains unauthorized access to a domain’s DNS control panel or registrar account, they may be able to redirect traffic, disrupt email, or interfere with services.

Consider a legitimate A record:

portal.example.com. 300 IN A 192.0.2.10

If the authoritative configuration is changed without authorization, clients may resolve the hostname to an unintended destination.

DNSSEC can help validating resolvers detect certain unauthorized data modifications, but it does not eliminate the need to secure authoritative DNS management systems.

DNS security best practices

Protect registrar and DNS provider accounts with strong authentication and multi-factor authentication.

Use least-privilege permissions for administrative accounts and API tokens.

Record and review changes to sensitive DNS records.

Protect the domain’s authoritative nameserver configuration.

Use appropriate SPF, DKIM, and DMARC policies for email services.

Evaluate DNSSEC where suitable, including the operational requirements of key management and delegation.

Review CAA policies before automating certificate issuance.

Monitor for unexpected changes to A, AAAA, MX, NS, TXT, and other sensitive records.

These controls complement the practices covered in Network Security Basics and Firewalls Explained.

Firewalls and DNS have different responsibilities: DNS provides naming and service data, while firewalls apply network traffic policies.

Common DNS Configuration Mistakes

Many DNS problems result from configuration errors rather than complete DNS outages.

1. Confusing A and CNAME records

An A record contains an IPv4 address.

A CNAME contains another DNS name.

They cannot be substituted freely in every situation.

2. Configuring an invalid CNAME at the zone apex

A conventional CNAME conflicts with the other records required at a zone apex.

Use an appropriately supported provider feature instead of assuming that normal DNS protocol restrictions disappear.

3. Pointing an MX record to an alias

Mail exchanger destinations should resolve through appropriate address records rather than being configured as CNAME targets.

4. Publishing an unreachable IPv6 address

An AAAA record may resolve correctly even when the corresponding application cannot be reached over IPv6.

5. Changing DNS without considering TTL

Remote resolvers may continue returning previously cached data.

Lower relevant TTL values in advance when planning a migration.

6. Misconfiguring SPF, DKIM or DMARC

Incorrect email authentication configuration can disrupt legitimate mail or create weaker security than expected.

Always verify the actual mail architecture.

7. Ignoring reverse DNS

Public email servers and infrastructure monitoring systems may rely on appropriate PTR configuration.

8. Forgetting delegation changes

A child zone may be correctly configured while the parent still points to old name servers.

9. Misconfiguring DNSSEC during migration

Stale DS information or mismatched signing configurations can prevent validating resolvers from obtaining usable answers.

10. Treating DNS as proof of application availability

A successful DNS lookup does not guarantee that the destination server, TLS service, firewall, or application works.

DNS diagnostics must be followed by network and application testing when appropriate.

How to Check DNS Records Using dig

The dig utility is widely used for DNS troubleshooting on Linux and other Unix-like systems.

It can query specific record types, inspect authoritative answers, and compare recursive resolver results.

Check IPv4 and IPv6 addresses

dig example.com A
dig example.com AAAA

Check CNAME records

dig www.example.com CNAME

Check mail configuration

dig example.com MX
dig example.com TXT
dig _dmarc.example.com TXT

Check authoritative DNS information

dig example.com NS
dig example.com SOA

Check reverse DNS

dig -x 192.0.2.10

Check service discovery

dig _sip._tcp.example.com SRV

Check certificate authority restrictions

dig example.com CAA

Check HTTPS service records

dig example.com HTTPS

Check DNSSEC-related data

dig example.com DNSKEY +dnssec
dig example.com DS +dnssec

Query a specific resolver

Cloudflare Public DNS:

dig @1.1.1.1 example.com A

Google Public DNS:

dig @8.8.8.8 example.com A

Different recursive resolvers can temporarily return different results because of caching or resolver policies.

To compare with authoritative information, identify the responsible nameservers and query one directly.

dig example.com NS
dig @ns1.example.net example.com A

Replace ns1.example.net with an actual authoritative server for the domain being tested.

Investigate delegation

dig +trace example.com

This helps reveal the resolution path through the DNS hierarchy.

For a broader command-line reference, see our Linux Network Tools Guide.

How to Check DNS Records Using nslookup

The nslookup utility is available on Windows and various other operating systems.

To inspect a domain:

nslookup example.com

To request MX records:

nslookup -type=MX example.com

To request NS records:

nslookup -type=NS example.com

To request TXT records:

nslookup -type=TXT example.com

To query a particular resolver:

nslookup example.com 1.1.1.1

nslookup is convenient for simple checks, while dig often provides more detailed control and output useful for advanced troubleshooting.

DNS Records vs DHCP

DNS and DHCP are both fundamental network services, but they have different responsibilities.

DNS supplies information associated with names and other DNS resource records.

DHCP provides network configuration to clients, potentially including IP addresses, subnet information, default gateways, and DNS resolver addresses.

A simplified process is:

Client joins network
        |
        v
DHCP provides configuration
        |
        v
Client obtains DNS resolver
        |
        v
DNS resolves requested name
        |
        v
Client connects to service

A DHCP server can provide the address of a recursive DNS resolver, but it does not replace that resolver.

For more information about leases, address allocation, and network configuration, see DHCP Explained.

DNS Records vs IP Routing

DNS and routing also perform different functions.

DNS can return an address:

server.example.com --> 192.0.2.10

But DNS does not determine every hop that packets will traverse to reach the destination.

Routers forward packets according to network routes, interfaces, and routing policies.

Conceptually:

Hostname
   |
   v
DNS Resolution
   |
   v
Destination IP
   |
   v
IP Routing
   |
   v
Destination Network

Understanding both systems is essential for troubleshooting connectivity.

Our Routers, Switches and Network Devices guide explains the components responsible for forwarding traffic across networks.

Practical DNS Troubleshooting Scenarios

Understanding DNS record types becomes particularly useful when diagnosing production problems.

Scenario 1: A website works over IPv4 but fails over IPv6

Start by checking both address types:

dig example.com A
dig example.com AAAA

If the AAAA record points to an unreachable IPv6 destination, IPv6-capable clients may encounter problems even though the IPv4 service works.

Next, verify the IPv6 route, firewall rules, TLS configuration, and application listener.

Scenario 2: Email stops arriving after a DNS change

Inspect the MX records:

dig example.com MX

Then check the address records for each mail-exchanger hostname.

Confirm that the mail servers are available and that the MX priorities reflect the intended design.

If the problem concerns authentication rather than routing, inspect SPF, DKIM, and DMARC separately.

Scenario 3: A new subdomain returns NXDOMAIN

Check the authoritative DNS server directly and compare its answer with one or more recursive resolvers.

If the authoritative record exists but a recursive resolver still returns NXDOMAIN, negative caching may explain the difference.

Do not repeatedly recreate the record without first identifying where the negative response originates.

Scenario 4: A domain fails after nameserver migration

Check parent delegation, child-zone NS records, and authoritative server availability.

If DNSSEC is enabled, verify that the DS record in the parent zone matches the intended child-zone DNSSEC configuration.

A nameserver change is not simply an A-record update.

Scenario 5: A website resolves correctly but remains inaccessible

Once address resolution is confirmed, check the actual service.

For example:

curl -I https://example.com/

Investigate routing, firewall restrictions, TLS, the web server, and application behavior.

Do not keep modifying DNS if the authoritative and recursive answers are already correct.

Frequently Asked Questions About DNS Record Types

What is a DNS record?

A DNS record is structured information stored in the Domain Name System. It can associate a name with an IP address, mail server, authoritative name server, text value, or other resource-specific data.

What are the most common DNS record types?

The most frequently encountered types include A, AAAA, CNAME, MX, TXT, NS, PTR, SRV, SOA, and CAA.

Additional records such as DNSKEY, DS, RRSIG, HTTPS, and SVCB support DNS security and modern service discovery.

What is the difference between A and AAAA records?

An A record contains an IPv4 address.

An AAAA record contains an IPv6 address.

A hostname can publish both when the service supports both address families.

What is the difference between an A record and a CNAME?

An A record maps a DNS name to an IPv4 address.

A CNAME makes one DNS name an alias of another.

A CNAME is not an HTTP redirect.

Can one hostname have multiple A records?

Yes. Multiple A records can form an RRset for the same name.

However, multiple addresses alone do not guarantee application health, balanced traffic, or high availability.

What DNS records are used for email?

MX records identify mail exchangers.

TXT records commonly contain SPF, DKIM, and DMARC-related information used for email authentication.

What does MX priority mean?

MX preference values influence mail-server selection.

Lower numerical values are generally preferred over higher values.

What are TXT records used for?

TXT records are used for domain verification, email authentication, and other application-specific text information.

What is a PTR record?

A PTR record is commonly used for reverse DNS. It allows an address-related reverse DNS name to point toward a hostname.

What is an SRV record?

An SRV record publishes service discovery information, including a target hostname, port, priority, and weight.

What is an SOA record?

An SOA record contains administrative and operational information about a DNS zone, including timing fields and a zone serial.

What is a CAA record?

A CAA record allows a domain owner to specify which certificate authorities are authorized to issue certificates for the domain.

What is DNSSEC?

DNSSEC adds cryptographic mechanisms that allow validating resolvers to authenticate signed DNS data.

It uses record types including DNSKEY, DS, and RRSIG.

DNSSEC does not encrypt ordinary DNS traffic.

What is an HTTPS DNS record?

An HTTPS record provides service-binding information for HTTP services.

Compatible clients can use this information to discover supported endpoints and connection parameters.

Does changing a DNS record update every client immediately?

No.

Recursive resolvers and clients may continue using cached information until applicable cache lifetimes expire or data is otherwise refreshed.

Is DNS the same as DHCP?

No. DHCP supplies network configuration to clients, while DNS provides naming and resource information.

Is DNS the same as routing?

No. DNS resolves names and retrieves other DNS information. IP routing determines how packets are forwarded toward their destination.

Conclusion

DNS resource records form the foundation of modern Internet naming, service discovery, email routing, and important security mechanisms.

A records map DNS names to IPv4 addresses, while AAAA records support IPv6.

CNAME records create hostname aliases, and MX records identify mail exchangers.

TXT records publish information used for verification and email authentication.

NS records support authoritative DNS and delegation, while PTR records are commonly used for reverse DNS.

SRV records allow service discovery with ports, priorities, and weights.

SOA records provide zone administration information, and CAA records help control certificate issuance.

Modern resource-record types such as DNSKEY, DS, RRSIG, HTTPS, and SVCB extend DNS into cryptographic authentication and richer service discovery.

The key operational lesson is that DNS records should never be managed in isolation. Their behavior depends on caching, TTL values, authoritative DNS configuration, delegation, client support, network connectivity, and application availability.

When troubleshooting a DNS problem, first identify the record type involved. Then compare authoritative and recursive answers, inspect cache behavior, and verify the actual service.

Continue your learning with DNS Explained for DNS fundamentals, DNS Caching and TTL Explained for cache behavior and propagation, and TCP/IP Explained for the network layers underneath DNS.

For hands-on troubleshooting, explore Linux Network Tools Guide and Linux Server Administration.