Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am in the process of setting up a new server for my web application (the site will be moved, it is not for load balancing or the like), which has a different IP address from my existing server. My current server has a reverse DNS PTR record set up pointing its IP to Is it bad to set up a reverse DNS PTR record for the new IP pointing to as well? Or should I wait until I do my migration to set up the record?

Update: I forgot to mention, the A record for the points to the old server's IP address, not the new one, if it matters.

share|improve this question
It isn't clear to me what particular service your system is running. You say domain, are you talking about a web server? The PTR record is barely used at all for HTTP, so it probably doesn't matter at all. OTOH incorrect PTR config can seriously break email. – Zoredache Apr 21 '10 at 17:12
Both servers are webservers that also send and receive email (which is why I asked) – Daniel Vandersluis Apr 21 '10 at 17:43
Out going mail from the new server will attract spam points. E.g. SpamAssasin will tag mail with the "RDNS_NONE" (Delivered to internal network by a host with no rDNS). It even does this if the new server, which is sending a mail, DOES have the correct reverse dns. The reason for this is because the url doesn't map to this ip. – Robino Jan 4 at 10:51
FYI the score you get for this is -1.274, so if your mail is not spammy in any other way then you probably won't even notice. – Robino Jan 4 at 10:52
up vote 8 down vote accepted

If it is convenient for you as a temporary solution, it should be perfectly acceptable. I cannot think of many scenarios where having multiple PTR records with the same hostname will introduce any technical issues.

One potential scenario would be mail delivery on the new server. At least, if the forward lookup resolves to the old server. Fickle mail servers will bounce mail without hostnames/IPs being able to resolve both ways and match.

Outside of that, and I'm really trying, I can't think of any. If there's more, it's likely to be of limited scope like above.

share|improve this answer
What if you have 100 mail servers (so it is failsafe), wouldn't you want all the servers to respond as having the proper PTR? – Alexis Wilke May 27 at 1:13

As long as you keep your A record pointing to one specific IP address (no round robin) this should not cause any problems.

Of course, the best practice is to always have 1 <-> 1 resolution to close the circle.

There's some thorough explanation at The point is, it's RFC design goal, but the practical approach is - at times you don't even have access to some reverse entries (f.e. former ISP having stale records), and it shouldn't be a problem (assuming you only use 1 "live" address).

So in brief:

  • If you want your reverse DNS entry to "wait" for you when you migrate - it seems absolutely OK.
  • If you're using both servers at the same time for production - I'm not sure. Theoretically it's bad practice (see RFC 1912), but I don't think anything but mail would complain about it.
share|improve this answer

If you have two IPs resolving to the same domain name, then you cannot have Forward Confirmed Reverse DNS (FCrDNS) for both, which is the check that many authentication schemes use (such as email servers when deciding whether to deliver your mail).

In order to get forward confirmed reverse DNS, an IP address must resolve to a hostname that resolves back that that IP address and only that IP address.

You could, however, have one IP resolving to and another resolving to and still have FCrDNS for both.

share|improve this answer
Hmm, but this means that you cannot load balance these services? I wonder if this could pass the TLS verification on HTTPS or LDAPS. – sorin Jan 30 '15 at 16:42
This shouldn't affect any services you have, that is it should not not affect your ability to do HTTPS or LDAPS or to load balance with many servers. The FCrDNS check does not have to use the same hostname as the hostname you are using to access the server. It can use any hostname; usually an internal hostname not necessarily seen by end users unless they did a PTR check. All that is required is that each unique IP visible to the world uses something for a unique hostname that resolves back to that IP. – thomasrutter Jan 31 '15 at 2:34
For example I just looked up and the IP I got was The reverse record for that is I looked up that and got the same IP: So that Google server passes FCrDNS check, even though the name it used for that purpose,, had nothing to do with the name I access that server by (which is or names used for things like SSL. – thomasrutter Jan 31 '15 at 2:37

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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