DNS Record Types: A, AAAA, MX, TXT, PTR, SRV and SOA

DNS resource records have different purposes and data formats. Before changing one, identify the authoritative provider, preserve the existing value and confirm whether its editor expects a relative label or a complete name. The examples below use reserved documentation addresses, not deployable customer settings.

Common record types

Type	Purpose and important constraints
SOA	Zone authority metadata: primary server name, contact, serial, refresh, retry, expiry and negative-caching parameter. It is not just a hostname/address pair.
NS	Authoritative nameserver hostname. NS records have no preference field identifying primary versus secondary; either server may answer. Registrar delegation and zone NS data must be coordinated.
A	IPv4 address for an owner name, such as 192.0.2.10.
AAAA	IPv6 address, such as 2001:db8::10. Do not publish an address unless that service actually works over IPv6.
CNAME	Alias to another hostname, not an IP address. A CNAME generally cannot coexist with other data at the same owner; the zone apex already needs SOA and NS records.
MX	Mail-exchanger hostname with a numeric preference; lower numbers are preferred. The target must resolve appropriately and must not be a CNAME or a literal IP address.
TXT	Application-specific text, including ownership verification and email authentication. Separate applications use different owner names and syntax; unrelated TXT values are not interchangeable.
PTR	Reverse-DNS mapping from an address’s reverse name to a hostname. Adding a forward record in your domain does not change reverse DNS.
SRV	Service location with priority, weight, port and target. Only clients implementing discovery for that service use it; publishing an SRV record does not automatically redirect normal browser HTTP traffic.

Forward-zone format and complete example

In BIND syntax the owner, optional TTL and class precede the type and data. Use a trailing dot for an absolute hostname. Our zone-file guide contains a complete illustrative zone with SOA, NS, A, AAAA, CNAME, MX and TXT records. A zone may contain multi-line records; a panel may expose these fields differently.

A wildcard owner such as *.example.com. has DNS wildcard semantics, not an unrestricted match for every possible name or delegated child zone. Do not add wildcard addresses to conceal missing service-specific records.

SRV example

These two records are a fragment within an example.com. forward zone. The service label identifies SIP over TCP; priority 10 is considered before larger priorities, weight 20 influences selection among equal-priority targets, and 5060 is the service port. Weight is not a guarantee of exact traffic distribution.

_sip._tcp IN SRV 10 20 5060 sip.example.com.
sip IN A 192.0.2.30

PTR example in a reverse zone

This complete lab-only reverse zone illustrates a /24 boundary. The owner 20 below represents 192.0.2.20, not the hostname’s forward owner. Real reverse delegation may use a different boundary or classless arrangement; request the appropriate change from whoever controls the address space.

$ORIGIN 2.0.192.in-addr.arpa.
$TTL 300
@ IN SOA ns1.example.com. hostmaster.example.com. (
  2026101501 3600 600 1209600 300 )
@ IN NS ns1.example.com.
20 IN PTR mail.example.com.

Check publication and service behavior separately

ALIAS/ANAME/flattening are provider features, not a standard record that can be copied unchanged between every DNS platform. Verify provider support before using them at the apex. Check authoritative answers, delegation and the affected service after saving any record. A successful DNS answer does not itself prove a website certificate, mailbox or application is configured correctly.

References: BIND zone examples and SRV specification.

Reviewed October 15, 2026. Synthetic forward, SRV and reverse records were checked in an isolated BIND lab; no production DNS or service-discovery deployment was performed.