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.

  • A PTR record for 141.211.243.251 is not going to be in the umich.edu. zone. It will be in the 211.141.in-addr.arpa. zone. So the question really doesn't make a lot of sense as-is. – Michael Hampton Feb 2 '18 at 18:41
  • Very few applications use PTR (SMTP does sometimes), for good reasons. It is often difficult to set up correctly anyway, because the records are in a different zone, often in a different administrative domain, so not under the same control. – Patrick Mevzek Feb 4 '18 at 18:57
  • @MichaelHampton, what makes you think that I said a PTR record for 141.211.243.251 is going to be in the umich.edu zone? – Watki02 Feb 13 '18 at 13:11
  • Your first sentence, your example... – Michael Hampton Feb 13 '18 at 19:00
  • Did I say "in the umich.edu zone"? Do you know what "dig -x" does? Do you know what an "ANSWER SECTION" is? Do you know how DNS works? If you answered 'yes' to all but the first question, I don't see how you came to that conclusion. Can you please be more specific? The umich.edu part is to show you an example FORWARD apex record, for which the following example, associated PTR record does not match. – Watki02 Feb 14 '18 at 20:21
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.