1

I am aware that apex records (records at the zone "root") can have PTR records, but frequently I see that zone root records do not have a matching PTR, or they are pointing to a different place than the associated host record.

Example:

dig umich.edu @8.8.8.8; dig -x 141.211.243.251

(truncated for brevity)

;; ANSWER SECTION:
umich.edu.              709     IN      A       141.211.243.251

(truncated for brevity)

;; ANSWER SECTION:
251.243.211.141.in-addr.arpa. 1800 IN   PTR     www.umich.edu.

(truncated for brevity)

Reasons not to have a PTR:

  1. A reason not to put in a PTR is if you are not authoritative for the address zones anyway. E.g. I am making an A record point to a cloud provider, and I cannot use a CNAME because it is a zone root.
  2. Another reason I could understand is if you are using anycast for your DNS services, and may not get the same answer (geographic) place-to-place. Google.com seems to do this.

But is there a reason one should "never" or "always" do this aside from an exception like the above? I would think there should always be a correct PTR by default.

galoget
  • 235
Watki02
  • 637

1 Answers1

1

I see Michael's point as I think he's referring to the domains in the namespace for handling reverse mapping: in-addr.arpa and ip6.arpa. That said, I understand what you're getting at.

The reverse DNS (rDNS) lookup of a domain doesn't have to match the forward lookup. I have a domain on shared hosting. I get the same IP address from a forward lookup of my domain name and www. An RDNS lookup of this IP address returns the shared server:

23.168.192.in-addr.arpa. 14400 IN PTR foo.bar.example.com.

Since you're looking for best practices, take a look at the IETF's draft Considerations for the use of DNS Reverse Mapping. It's worth reading the whole document. Here's a particularly important point:

Applications should not rely on reverse mapping for proper operation, although functions that depend on reverse mapping will obviously not
work in its absence. Operators and users are reminded that the use
of the reverse tree, sometimes in conjunction with a lookup of the
name resulting from the PTR record, provides no real security, can
lead to erroneous results and generally just increases load on DNS
servers. Further, in cases where address block holders fail to
properly configure reverse mapping, users of those blocks are
penalized.

And this:

By recommending applications avoid using reverse mapping as a
security mechanism this document points out that this practice,
despite its use by many applications, is an ineffective form of
security. Applications should use better mechanisms of
authentication.

I hope this helps.