41

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"...

Community
  • 1
Totor
  • 2,876
  • 3
  • 22
  • 31
  • 4
    Why do you want to have multiple PTR records for a single IP address? I can't think of a reason that would make sense to do. – Per von Zweigbergk Aug 07 '14 at 12:40
  • 3
    @PervonZweigbergk This is not what I asked, but for example, because I have several names pointing to the same IP, and want the reverse to match all of them. – Totor Aug 07 '14 at 12:44
  • 11
    @PervonZweigbergk Imagine a mail server that handles mail for multiple domains. You may want to use a name within the domain you are sending mail for in the `EHLO` command. Certain receivers require that you have a `PTR` record matching the domain in your `EHLO` command, otherwise they won't accept mail from you. But if you have multiple `PTR` records, they may just pick one of them at random, and if that one does not match the `EHLO` command, it rejects the mail. – kasperd Aug 07 '14 at 12:44
  • 3
    I know it's not what you asked, which is why I asked this via a comment, not as an answer. :-) You never mentioned what application you're talking about. You'd do well to be more explicit that you're talking about the context of outgoing e-mail, which is what @kasperd is speculating. – Per von Zweigbergk Aug 07 '14 at 13:26
  • 2
    @kasperd I suppose someone may want to do that but doing so is unconventional and needlessly causes the problematic situation that the question is about. A mail server is only expected to use a single name in its `EHLO` commands, regardless how many domains it handles mail for. The name in `HELO`/`EHLO` is expected to identify the mail server itself, not relate to the `MAIL FROM` or `From` mail addresses. – Håkan Lindqvist Aug 07 '14 at 16:37
  • 1
    @HåkanLindqvist I wasn't suggesting it was a good idea, quite the contrary. I was answering why somebody might think it was a good idea based on partial understanding of the problem they were trying to solve. – kasperd Aug 07 '14 at 16:42
  • 1
    When you have a moment, can you select one of the answers below so that this question doesn't show up as unanswered? (and if you need more info, please let us know) – Andrew B Dec 11 '14 at 00:10
  • @PervonZweigbergk How would you comply with the requirement to have PTR for each A/AAAA records on a HTTP virtual host with many names but one IP address? And no, you can't use CNAMEs for everything. – Pavel Šimerda Nov 02 '15 at 09:24

3 Answers3

26

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
  • 33,741
  • 5
  • 65
  • 90
  • Elaborating on "one canonical name": in cases where the IP address could be associated with more than one entity, the most specific is preferred. In the case of a webserver with multiple name based virtual hosts, the name of the webserver itself is most appropriate. This is one of those cases where trying to follow the advice of the Informational RFCs (`PTR` always agreeing with the `A` record) is completely bunk. – Andrew B Aug 07 '14 at 22:14
  • "The PTR record *is expected* to identify" : by who? It looks like a *de facto* rule, as software developers started to consider that only one PTR was the norm. Am I right? – Totor Aug 11 '14 at 10:16
  • @Totor Added a quote and link for a source. – Håkan Lindqvist Aug 11 '14 at 10:32
  • As an anecdote, it was recently noted that Apple has a few PTR records that are over 9k bytes worth of answers. Doubtless they aren't the only ones. This is a rather extreme example of what you can end up with when mandatory PTR record policies don't take the details of this answer into consideration. – Andrew B Jun 13 '16 at 22:43
18

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 here: https://supernoc.rogerstelecom.net/pdfs/multiple-ptrs.pdf

Also, check this bug from the Glibc's getnameinfo function (https://sourceware.org/bugzilla/show_bug.cgi?id=5790). 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).

Giovanni Tirloni
  • 5,693
  • 3
  • 24
  • 49
  • 2
    How can you guarantee that a *any problem* isn't happening in the "infinite" number of different systems around the Internet? Your answer is nice but this argument is of no value. Moreover, client bugs are irrelevant IMHO, except if a "significant" number of them are impacted. – Totor Sep 24 '14 at 15:53
  • Regrettably the link to the Rogers Telecom paper doesn't seem to work anymore. Is it still available under a different address? – Tilman Schmidt Jan 07 '22 at 17:35
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