Symptom:

A PTR record is the reverse of an A record. That is, it maps an IP address to a hostname, rather than vice versa. Given an IP address of the form a.b.c.d, the usual form for a PTR record is this:

d.c.b.a.in-addr.arpa.    PTR    host.name.

Note that, in certain special cases (classless subnet reverse zones), the name of the record may be different.

Because the naming rule of PTR records, they are almost always organized into separate zones, called reverse zones. For example, a typical reverse zone for a class C subnet would be named “c.b.a.in-addr.arpa.”, where again, the letters at the beginning stand for the octets of the subnet address a.b.c.0/24.

A reverse zone typically corresponds to a subnet, not a domain name, and a PTR record corresponds to a particular IP address, not an A record. These distinctions are important to understand.

Solution

Conventional Usage

There’s no technical requirement (as far as proper DNS function is concerned) for PTR records. They were designed as a matter of convenience and completeness. However, they have become required by some security schemes.

As a result, the following conventions are often applied to PTR records:

• There should be exactly one PTR record per IP address/name pair. Each IP address should have a PTR record. Note that this isn’t one PTR record per computer, necessarily; a computer with multiple IP addresses would have multiple PTR records, one per address. If one address has multiple names (real A-Records, not CNAME alias), there will be one PTR record per name/address pair.
• For any given MX record, the mailhost name used in the MX record must have an A record - this is the rule, not a convention. The convention is, that name’s IP address must have a PTR record that resolves back to the name used in the MX record.
• There should be an A record for every PTR record (but not necessarily vice versa). In other words, one should be able to take an IP address, look up its PTR record (yielding a hostname), and then look up the A record for that hostname and get back the IP address. The hostname should have exactly one A record (not a CNAME record).

Note that these guidelines are by no means universally followed, and there is some disagreement between DNS professionals over these conventions. Some disagree with the first item, in particular - they say that most IP addresses don’t need any PTR record at all.

Delegation

The hardest part to understand about PTR records for inexperienced DNS administrators is delegation. For forward zones (i.e. domains), the domain is registered using a domain registrar, and the registrar is told to “point” the domain to a particular server. This is delegation.

In the case of reverse zones, the situation is similar, except that instead of a registrar delegating the zone, it’s usually the ISP that creates the delegation. Or doesn’t, in many cases, leaving the operator of the subnet unable to effectively create PTR records. In such cases, the operator of the subnet must rely on the controller of the reverse zone (usually an ISP) to manage the PTR records properly.

The key point is that having control over a domain and a subnet doesn’t give control over the reverse zone for that subnet. It’s up to whoever assigns the subnet to also assign control of the reverse zone, or decide not to do so. In the case of subnets smaller than a class C (a 24-bit subnet), RFC 2317 provides a method of delegating control of the PTR records.

Note that, for private subnets (e.g. 192.168.0/24 or 10.1.1.0/24), there is no delegation of the reverse zone. In such cases, the DNS server that the client machines (and internal servers such as mail servers) use for DNS lookups usually must either host the reverse zone or know where to find it (what other servers to query).