PTR records are most commonly used for reverse DNS or mapping an IP address to a domain name. This article focuses on reverse DNS.
PTR records are also called "Pointer Records," and are defined in RFC 1035.
DNS Check can monitor your reverse DNS records, and notify you if they become unresolvable, or start resolving to the wrong domain name. If you're using some other type of PTR record, then DNS Check supports monitoring it as well.
Reverse DNS vs. Forward DNS
A and AAAA records are referred to as "forward DNS" records because they map domain names to IP addresses. Reverse DNS (PTR) records, on the other hand, map IP addresses to domain names.
Here's an example of an IPv4 address that has matching forward and reverse DNS:
- The 220.127.116.11.in-addr.arpa PTR record points the 18.104.22.168 IP address to nyc1.dnscheck.co.
- The nyc1.dnscheck.co A record maps to 22.214.171.124.
Here's an example of an IPv6 address that has matching forward and reverse DNS:
- The 1.0.0.b.1.a.126.96.36.199.0.0.0.0.0.0.0.1.0.0.0.0.188.8.131.52.8.a.184.108.40.206.ip6.arpa PTR record points the 2604:a880:800:10::7a1:b001 IP address to nyc1.dnscheck.co.
- The nyc1.dnscheck.co A record maps to 2604:a880:800:10::7a1:b001.
Importance of Reverse DNS
Reverse DNS has a special significance when it comes to sending email. This comes from two primary areas:
- It's common for spam filters to check whether the IP address of a server that's attempting to deliver mail has matching forward and reverse DNS records. Servers whose IP addresses lack matching forward and reverse DNS are subject to having their mail deferred, rejected, or sent to the spam folder.
- Matching forward and reverse DNS is a prerequisite for registering for most email feedback loops. Email feedback loops, which are also sometimes called "complaint feedback loops" are a mechanism that ISPs use to share information about spam complaints with email senders. These provide a useful metric of how "spammy" email is and are used to identify abuse issues.
Reverse DNS Shorthand
As you can probably see from the earlier sections, PTR record names, especially in the IPv6 space, can be unwieldy.
When adding reverse DNS records into DNS Check, you can bypass this complexity by entering the IP address in place of the PTR name. Here's an example:
Alternatively, if you're using the DNS zone file importer, you can use a shorthand to specify matching sets of A and PTR or AAAA and PTR records using this format:
ip-address <=> domain
For example, to import a reverse DNS record for 220.127.116.11 that maps to nyc1.dnscheck.co., and a corresponding A record, enter:
18.104.22.168 <=> nyc1.dnscheck.co.
To import a reverse DNS record for 2604:a880:800:10::7a1:b001 that maps to nyc1.dnscheck.co., and a corresponding AAAA record, enter:
2604:a880:800:10::7a1:b001 <=> nyc1.dnscheck.co.
Here are the fields that make up a PTR record:
|Name||A fully qualified domain name (FQDN).||22.214.171.124.in-addr.arpa.|
|Type||The DNS record type. Always set to PTR.||PTR|
|Value||The fully qualified domain name (FQDN) that the PTR record points (resolves) to.||nyc1.dnscheck.co.|
DNS Zone File Examples
IPv4 and IPv6 PTR records go in separate zone files.
Here's an example of how an IPv4 PTR record looks in a zone file:
$ORIGIN 72.131.104.in-addr.arpa. ; Name Type Value 189 PTR guy.ns.cloudflare.com.
Here's an example of how an IPv6 PTR record looks in a zone file:
$ORIGIN 1.a.126.96.36.199.0.0.0.0.0.0.0.1.0.0.0.0.188.8.131.52.8.a.184.108.40.206.ip6.arpa. ; Name Type Value b.0.0.1 PTR guy.ns.cloudflare.com.
- RFC 1035 - this RFC defines PTR records. See section 3.5 - "IN-ADDR.ARPA domain" in particular.