47

I often read that using multiple PTR records in a DNS configuration is not recommended.

However, the reasons are often vague, or not so obvious, naming:

  • "it can cause problems",
  • "can trigger bugs in programs expecting a single answer": it's the software's problem then, isn't it?!
  • "can make DNS answer packet too large": isn't this fixed with EDNS?

Are these good reasons? Do you know of any other (good) reasons? All this kinda looks like a "legacy fear" to me...

Totor
  • 3,048

3 Answers3

32

The PTR record for a reverse name (eg 7.2.0.192.in-addr.arpa) is expected to identify the canonical name that is associated with that IP address.

Both the gateway pointers at network nodes and the normal host pointers at full address nodes use the PTR RR to point back to the primary domain names of the corresponding hosts.

From: https://www.rfc-editor.org/rfc/rfc1035#section-3.5

This expectation is reflected in software that does reverse lookups; often such software specifically expects a single name back and it expects to be able to use that name as a canonical name for that host. If there are multiple names returned it's common to just take one at random because they have absolutely no way of knowing which one you would have preferred for this particular occasion.

As the general expectation is that there is one canonical name associated with an IP address and that name is what the PTR should point to, adding multiple names generally has no upside (nothing expects any random A/AAAA record to have a matching PTR) but it has a potential downside as it can cause strange results as you have no control over which of your PTR records will be used if you have added more than one.

In essence, if you have multiple PTR records you do not actually make your host appear more legitimate but rather the opposite, you run the risk of failing some validation or otherwise breaking something.

As a perhaps somewhat extreme metaphor, handing over five passports all with your photo but with different names at the airport is probably not going to be received as well as if you just hand over one.

Community
  • 1
Håkan Lindqvist
  • 36,421
19

It all comes down to unpredictable behavior since the RFC does not impose a limit or a way to handle these PTR records. Most implementations will choose round-robin and you will not achieve your desired result (perfect matching between many names to a single IP).

You can read more about this in Why you shouldn't use Multiple PTR records on a single IP.

Also, check strange behavior of getnameinfo on multiple PTR records in glibc's bug tracker. How can you guarantee this isn't happening in the infinite number of different systems around the Internet (some of them very old and unpatched) ?

To reinforce, as a rule of thumb, it's always good to avoid behavior that is unspecified and unpredictable. Unfortunately, multiple PTR records for a single IP fall into that category (as far as RFCs are concerned).

Lance U. Matthews
  • 286
5

How do you guarantee that a PTR will match a particular forward record if you have multiple PTRs?

This is especially important in mail server inter actions, where most inbound receiving SMTP servers will check if the forward matches the reverse

Pretty difficult is you have multiple PTRs and no way to guarantee which PTR is selected and that it matches the forward you gave in connecting

The easiest way to guarantee a perfect match is to have one PTR which matches a forward entry

user274768
  • 51
  • 1
  • 2