PTR records let you map an IP address back to a hostname, which is essential for reverse DNS lookups.
Let’s set up a PTR record for the IP address 192.0.2.10 which should resolve to mail.example.com.
First, you need access to your DNS zone file or your DNS provider’s management interface. PTR records are typically managed by the owner of the IP address block, which is often your ISP or hosting provider, not necessarily the owner of the domain name itself. This is a key point: the zone for reverse lookups is based on the IP address, not the domain name.
Here’s how it works conceptually: For a standard "A" record, you query a hostname (e.g., www.example.com) and get an IP address (e.g., 192.0.2.1). For a PTR record, you query a special domain name derived from the IP address and get the hostname back. The special domain for IPv4 addresses is in-addr.arpa. So, for 192.0.2.10, the query name becomes 10.2.0.192.in-addr.arpa.
To create the PTR record, you’ll add an entry to the reverse lookup zone file. If you manage your own DNS server (like BIND), you’d edit the zone file for 2.0.192.in-addr.arpa. The entry would look like this:
10 IN PTR mail.example.com.
The 10 here is the last octet of the IP address 192.0.2.10. The IN specifies the Internet class, and PTR indicates it’s a Pointer record. mail.example.com. is the fully qualified domain name (FQDN) of the host, and the trailing dot is crucial to signify it’s an absolute domain name.
If you’re using a hosted DNS provider (like AWS Route 53, Google Cloud DNS, or Cloudflare), the interface will be different but the concept is the same. You’ll typically find a section for "Reverse DNS" or "PTR Records." You’ll enter the IP address (or the last octet if it’s for a subnet you manage), and the hostname. For example, in Route 53, you might create a record set in the 0.2.192.in-addr.arpa hosted zone (which you’d have to create first) with the name 10 and type PTR, pointing to mail.example.com..
You’ll need to ensure that the reverse DNS zone (2.0.192.in-addr.arpa in this case) is delegated to your DNS servers. This delegation is usually set up by your IP address administrator, often your ISP. You can check delegation using dig +trace 10.2.0.192.in-addr.arpa. You should see your authoritative nameservers responding for that zone.
After making the change, you’ll need to reload your DNS server configuration or wait for your DNS provider to propagate the changes. You can test the record using dig -x 192.0.2.10 or nslookup 192.0.2.10. A successful lookup will return 10.2.0.192.in-addr.arpa. ... mail.example.com..
The most surprising thing about PTR records is that they are managed within a DNS zone that is structured based on the IP address octets in reverse order, prepended with in-addr.arpa. This means that to manage reverse DNS for 192.0.2.10, you’re actually working with the DNS zone 2.0.192.in-addr.arpa, and the specific PTR record is keyed by the 10. This structure is designed to allow for hierarchical delegation of reverse lookup zones, mirroring the IP address allocation structure.
For IPv6 addresses, the process is similar but uses the ip6.arpa domain and a much longer, hexadecimal representation of the IP address, with each nibble (4 bits) represented by a single character.
The next challenge you’ll likely face is understanding how to set up PTR records for dynamic IP addresses or for large blocks of IPs.