DNS Records Explained — Part 2: PTR, SRV, CAA, DNSSEC, HTTPS/SVCB and Advanced Troubleshooting

Introduction

In Part 1, we covered seven essential DNS record types:

• A
• AAAA
• CNAME
• MX
• TXT
• NS
• SOA

These records help applications locate servers, route email, maintain DNS aliases and manage authoritative DNS zones.

However, modern DNS provides additional capabilities.

For example, DNS can associate an IP address with a hostname through reverse DNS.

It can identify the hostname and port for a service such as SIP.

It can restrict which Certificate Authorities are authorized to issue publicly trusted certificates.

DNS also supports cryptographic signatures, modern HTTPS service discovery and email authentication policies.

These capabilities are important for enterprise networks, cybersecurity, email administration and cloud infrastructure.

What You Will Learn

• PTR records and reverse DNS
• SRV records for service discovery
• CAA records for certificate issuance policy
• SPF, DKIM and DMARC TXT records
• DNSSEC records
• HTTPS and SVCB records
• Other specialized DNS records
• DNS caching and record changes
• How to query and verify DNS records
• Common DNS configuration problems
• DNS record security best practices

Prerequisites: DNS Records Explained — Part 1, DNS Fundamentals and Basic Networking

Series: DNS Records Explained — Part 2 of 2

1. PTR Record — Pointer Record

A PTR record is commonly used for reverse DNS.

It associates a DNS name in a reverse lookup namespace with another DNS name.

What Is Reverse DNS?

Forward DNS commonly retrieves an IP address associated with a hostname.

Reverse DNS retrieves a PTR record associated with an IP address.

Example

IP address:

192.0.2.80

Reverse DNS name:

80.2.0.192.in-addr.arpa.

PTR Syntax

80.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com.

Explanation

Why Is the IPv4 Address Reversed?

IPv4 reverse DNS uses the in-addr.arpa hierarchy.

The relevant address components appear in reverse order.

What About IPv6?

IPv6 reverse DNS uses the ip6.arpa namespace and a nibble-reversed representation.

Common Uses

• Mail server identity checks
• Network diagnostics
• Log enrichment
• Asset identification
• Operational troubleshooting

Does Every IP Address Have a PTR Record?

No.

PTR records must be configured within the appropriate reverse DNS authority.

Does PTR Prove Host Identity?

No.

Reverse DNS information alone is not sufficient authentication.

Some applications additionally verify that forward DNS is consistent with the reverse result.

Query Reverse DNS

dig -x 192.0.2.80

The documentation address does not necessarily have a meaningful publicly published PTR record.

2. SRV Record — Service Location Record

An SRV record identifies information needed to locate a network service.

This can include:

• Service name
• Transport protocol
• Priority
• Weight
• Port
• Target hostname

Syntax

_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com.

Explanation

What Is SRV Priority?

Lower numeric priority values are preferred.

What Is SRV Weight?

Weight influences relative target selection among records with the same priority.

A larger weight generally increases selection probability under the SRV selection algorithm.

Can SRV Support Redundancy?

Yes.

Applications supporting SRV can discover multiple eligible service endpoints.

However, the clients must implement the relevant service-discovery behavior.

Important Limitation

A typical browser opening an ordinary HTTPS website does not simply use an arbitrary SRV record to discover its web server.

Service-specific protocol support is required.

Does SRV Guarantee Application Availability?

No.

The target must actually provide the service at the specified port.

Query an SRV Record

dig _sip._tcp.example.com SRV

3. CAA Record — Certification Authority Authorization

A CAA record allows a domain holder to publish restrictions on which Certificate Authorities may issue certificates for the domain.

CAA stands for Certification Authority Authorization.

Purpose

CAA helps reduce the risk of unintended publicly trusted certificate issuance.

General Syntax

example.com. 3600 IN CAA 0 issue "ca.example.net"

The CA domain in this example is illustrative. It is not a production configuration for an actual certificate issuer.

Understanding the Fields

Important CAA Properties

issue

Controls the Certificate Authorities authorized to issue applicable non-wildcard certificates.

issuewild

Provides a separate authorization policy for wildcard certificate issuance.

iodef

Specifies a mechanism for reporting selected certificate issuance policy violations.

Additional Restrictions

CAA supports extensible parameters and issuer-specific policy mechanisms.

The exact supported options depend on the applicable standards and the Certificate Authority.

How Do CAs Evaluate CAA?

RFC 8659 defines relevant CAA record discovery and processing.

Certificate Authorities must evaluate applicable CAA authorization before certificate issuance, subject to the standard’s defined rules and exceptions.

Does CAA Create a Certificate?

No.

CAA expresses an issuance policy. It does not issue, sign, install or renew a certificate.

Does CAA Protect Existing Private Keys?

No.

CAA does not prevent an already compromised certificate private key from being misused.

Query CAA Records

dig example.com CAA

4. SPF, DKIM and DMARC — Email Authentication Using DNS

DNS plays an important role in email authentication.

Three commonly used mechanisms are:

• SPF
• DKIM
• DMARC

They are not equivalent to MX records.

MX identifies incoming mail exchangers, while SPF, DKIM and DMARC support sender authentication and policy processing.

SPF — Sender Policy Framework

SPF allows a domain to publish information used to determine whether a mail sender is authorized under SPF’s rules.

Example

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

The address is illustrative.

DKIM — DomainKeys Identified Mail

DKIM uses cryptographic signatures applied to email messages.

Public-key information is commonly published using a selector under _domainkey.

DKIM Record Location

selector1._domainkey.example.com

Illustrative Structure

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

BASE64_PUBLIC_KEY is a placeholder, not a usable production key.

DMARC — Domain-Based Message Authentication, Reporting and Conformance

DMARC connects SPF and DKIM authentication results to domain alignment and a published handling policy.

Example

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

The p=none policy requests monitoring rather than quarantine or rejection under the DMARC policy mechanism.

A production deployment requires an appropriate email authentication and reporting strategy.

Comparison

Important Point

SPF, DKIM and DMARC are separate email authentication protocols using DNS data.

They are not simply three new DNS record types equivalent to A or MX.

5. DNSSEC Records — DNSKEY, RRSIG, DS and NSEC

DNSSEC (Domain Name System Security Extensions) provides cryptographic mechanisms for authenticating DNS information.

DNSSEC introduces additional DNS resource records.

Important DNSSEC Record Types

DNSKEY

A DNSKEY record contains information used to verify relevant DNSSEC signatures.

RRSIG

An RRSIG record contains a digital signature for a covered resource record set.

DS

A DS record helps establish the DNSSEC chain of trust between a child zone and its parent.

NSEC and NSEC3

These records support authenticated responses showing that certain DNS names or record types do not exist.

What Does DNSSEC Protect?

• DNS data origin authenticity
• Integrity of signed DNS information
• Authenticated denial of existence

Does DNSSEC Encrypt DNS Traffic?

No.

DNSSEC does not provide query confidentiality.

DNS-over-TLS and DNS-over-HTTPS address different transport security requirements.

What Happens If DNSSEC Validation Fails?

A validating resolver may return SERVFAIL when the relevant DNSSEC data is bogus.

Query DNSSEC Records

dig example.com DNSKEY +dnssec

Important Diagnostic Limitation

The +dnssec option requests DNSSEC-related response information.

It does not by itself prove that the returned DNS information has been cryptographically validated.

6. HTTPS and SVCB Records — Modern DNS Service Discovery

Modern DNS also supports the HTTPS and SVCB resource record types.

These are defined by RFC 9460.

HTTPS Record

An HTTPS record can provide information used by supported clients to discover HTTPS service endpoints and relevant connection parameters.

Illustrative Syntax

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

Explanation

In this example, h2 and h3 are HTTP/2 and HTTP/3 ALPN identifiers.

The service must actually support the advertised protocols.

SVCB Record

SVCB stands for Service Binding.

It provides a general-purpose DNS mechanism for advertising service endpoints and associated parameters.

General SVCB Syntax

_ServiceName. TTL IN SVCB Priority TargetName Parameters

The precise queried name and applicable parameters depend on the service’s mapping specification.

What Can These Records Support?

Depending on client and service capabilities:

• Alternative service endpoints
• Application protocol information
• Service port information
• Address hints
• Other extensible connection parameters

Do HTTPS Records Replace A and AAAA?

No.

Address records and service binding records can be used together.

Can HTTPS/SVCB Replace Every CNAME?

No.

They provide useful service-binding capabilities, including certain apex-domain aliasing use cases for supported protocols, but they do not universally replace traditional DNS aliases.

Security Consideration

A client must still perform appropriate service authentication.

Publishing HTTPS or SVCB data does not make an endpoint automatically trustworthy.

7. Other Specialized DNS Records

The DNS record ecosystem contains additional types.

Examples include:

Why Are There So Many Record Types?

DNS supports many different applications.

Some records were introduced to address specific operational, authentication or service-discovery requirements.

Should Every Domain Publish Every Type?

No.

Use the record types required by the applications, protocols and security services actually deployed.

Current Reference

The IANA DNS Parameters Registry is the authoritative registry for DNS resource record type assignments.

As of October 31, 2026, the registry reflects updates published through October 16, 2026.

8. DNS TTL, Record Changes and Caching

DNS changes can take time to become visible through recursive resolvers and application caches.

What Is TTL?

Time to Live (TTL) defines the normal lifetime for caching applicable DNS information.

Example

www.example.com. 3600 IN A 192.0.2.80

The record has a TTL of 3,600 seconds.

What Happens After a DNS Change?

The authoritative server may begin serving the updated record, while resolvers may temporarily retain previously cached answers.

Does DNS Propagation Always Take 24 to 48 Hours?

No.

There is no universal fixed propagation time.

Actual behavior depends on:

• Previous record TTLs
• Cache lifetimes
• Delegation caching
• DNS provider updates
• Client and application caching
• Resolver policies

What About Negative Caching?

Resolvers can cache certain responses indicating that DNS names or requested record types do not exist.

What About Serve-Stale?

Some resolvers can return previously cached expired information under controlled failure conditions.

Recommended Practice

Plan DNS changes using the actual previous TTLs and provider-specific procedures.

Verify authoritative data and recursive responses separately.

9. Practical Lab — Verify DNS Records Using dig

The dig utility can query DNS resource records and display response information.

These commands are read-only DNS checks.

Step 1 — Query A and AAAA

dig example.com A

dig example.com AAAA

Step 2 — Query MX and TXT

dig example.com MX

dig example.com TXT

Step 3 — Query NS and SOA

dig example.com NS

dig example.com SOA

Step 4 — Query Reverse DNS

dig -x 192.0.2.80

Step 5 — Query SRV

dig _sip._tcp.example.com SRV

Step 6 — Query CAA

dig example.com CAA

Step 7 — Query SPF and DMARC TXT

dig example.com TXT

dig _dmarc.example.com TXT

Step 8 — Query DNSSEC Key Information

dig example.com DNSKEY +dnssec

Step 9 — Query HTTPS and SVCB

dig example.com HTTPS

dig example.com SVCB

A query returning no record is not necessarily a problem.

The domain may not publish that record type.

Step 10 — Inspect the DNS Delegation Path

dig +trace example.com

Step 11 — Query an Authoritative DNS Server

dig @a.iana-servers.net example.com SOA +norecurse

What Should You Inspect?

10. Common DNS Record Problems and Troubleshooting

Troubleshooting Workflow

1. Identify the affected application.
2. Determine which DNS record types it requires.
3. Query the appropriate authoritative servers.
4. Compare recursive responses.
5. Check TTL and cache behavior.
6. Validate targets, priorities and syntax.
7. Check DNSSEC and security policies if relevant.
8. Verify the actual destination service.
9. Correct the authoritative configuration.
10. Retest from the affected client environment.

11. DNS Record Security Best Practices

Maintain Accurate Records

Remove obsolete addresses, names and application targets.

Protect DNS Management Accounts

Use appropriate access controls and multifactor authentication where available.

Validate Changes

Check record syntax and relevant application requirements before publishing.

Apply DNSSEC When Appropriate

Protect DNS data authenticity through correctly managed signing and validation.

Review Email Policies

Maintain consistent SPF, DKIM and DMARC configurations.

Apply CAA Carefully

Authorize the intended certificate issuers without unintentionally blocking renewal.

Monitor DNS Changes

Detect unexpected changes to nameservers, mail records and other critical infrastructure records.

Review TTL Values

Select values appropriate for service reliability, caching and planned migrations.

Confirm Redundancy

Verify that advertised nameservers and mail exchangers are actually operational.

Use Current DNS Standards

Consult the latest IANA registry, applicable RFCs and supported DNS provider documentation.

Current NIST Guidance

NIST published SP 800-81 Revision 3 — Secure Domain Name System (DNS) Deployment Guide in March 2026.

It provides security recommendations for DNS data integrity, authoritative DNS, recursive DNS and DNS privacy.

12. Advantages and Limitations of DNS Records

Advantages

Scalability

DNS distributes naming information across authoritative servers and resolvers.

Flexibility

Different resource record types support a wide variety of services.

Redundancy

Multiple suitable records and DNS servers can help improve availability.

Service Discovery

Records such as SRV, HTTPS and SVCB support discovery of selected services and connection parameters.

Security Policies

CAA, DNSSEC and TXT-based email authentication policies support important security functions.

Limitations

Configuration Complexity

Different record types have distinct syntax and restrictions.

Caching Delays

Previously cached information may remain visible after an authoritative update.

Misconfiguration Risks

Incorrect records can interrupt websites, email and other services.

Security Dependencies

DNS provider security, zone administration and application validation matter.

No Automatic Service Health Verification

Publishing a DNS record does not establish that the advertised endpoint is functioning.

13. Frequently Asked Questions

Q1. What is a DNS Resource Record?

A structured DNS entry associated with a name, class and record type.

Q2. What is the difference between A and AAAA?

A records contain IPv4 addresses. AAAA records contain IPv6 addresses.

Q3. Does a CNAME redirect a website?

No. CNAME provides a DNS alias. HTTP redirection is a separate mechanism.

Q4. What does the MX preference number mean?

Lower numeric values are normally preferred for mail exchange routing.

Q5. Are SPF, DKIM and DMARC DNS record types?

They are email authentication mechanisms commonly publishing information through DNS TXT records.

Q6. What is the difference between PTR and SRV?

PTR is commonly used for reverse DNS. SRV publishes service-location information.

Q7. Does CAA guarantee certificate security?

No. It restricts applicable certificate issuance, but private-key protection and certificate validation remain necessary.

Q8. Do DNSSEC records encrypt queries?

No. DNSSEC authenticates DNS data. Encrypted DNS transport is a separate mechanism.

Q9. What are HTTPS and SVCB records?

Modern DNS resource record types that support service binding and connection parameters for participating clients and protocols.

Q10. Why do DNS changes take time?

Recursive resolvers and applications may retain previously cached data according to applicable TTLs and policies.

14. Key Takeaways

• PTR records support reverse DNS.
• SRV records contain service target, port, priority and weight information.
• CAA records restrict applicable certificate issuance.
• SPF, DKIM and DMARC commonly use TXT records.
• DNSSEC adds cryptographic DNS data authentication.
• DNSKEY, RRSIG and DS support DNSSEC validation.
• HTTPS and SVCB provide modern service binding.
• Specialized DNS records should be used only when the relevant application requires them.
• DNSSEC does not encrypt DNS traffic.
• DNS records must satisfy both syntax and application-specific requirements.
• DNS caching affects the visibility of record changes.
• dig is useful for querying and diagnosing individual resource record types.
• Accurate DNS configuration requires verification of both DNS answers and the actual services.

Conclusion

DNS records provide much more than hostname-to-IP address mappings.

Advanced records support reverse DNS, service discovery, certificate issuance restrictions, DNS authentication and modern application connection parameters.

PTR records help associate IP addresses with DNS names.

SRV records help supported applications discover service endpoints.

CAA records allow domain holders to restrict eligible certificate issuers.

TXT records support important email authentication mechanisms, including SPF, DKIM and DMARC.

DNSSEC provides cryptographic authentication for DNS information.

HTTPS and SVCB extend DNS with modern service-binding capabilities.

However, every record type has specific requirements and limitations.

A record may be syntactically valid while still being unsuitable for the application.

Administrators must therefore verify DNS record contents, caching behavior, application compatibility and relevant security policies.

Together, Parts 1 and 2 provide a practical reference to essential and advanced DNS records for reliable DNS administration and troubleshooting.

Recommended Further Reading

• What Is DNS? Domain Name System Explained
• What Is a Recursive DNS Server?
• What Is an Authoritative DNS Server?
• What Is BIND DNS Server?
• DNSSEC Explained
• DNS Troubleshooting Using dig and nslookup

Useful Links and References

SanchitGurukul Resources

Official DNS Standards and Documentation