Two Reverse DNS entries?
21 Replies
@Piki:
I'm currently hosting two sites on my Linode, each with it's own domain. The problem is that as far as I can tell, only one reverse DNS can be used, which means one domain can be entered as the reverse DNS. That leaves the other site open to look like a spam site, and can open both sites to complaint. Is there a way to tell the reverse DNS that my Linode's IP belong to two domains?
While more than one PTR record is possible and allowed by RFC, it's ambiguous and Linode (and many others, I suppose) only let you have one. Consider using a third, neutral domain for that (and as the base for your system hostname), or stick with the default .members.linode.com.
I'm currently using the second site as the reverse DNS since my site isn't quite ready, would just be nice if I could do it without attaching an extra IP to my Linode and reconfiguring everything.
@Piki:
Another domain wouldn't work. The second site "officially" isn't mine, I'm just a volunteer who offered up my Linode to get away from the old donated one (our leader can't afford a "real" host), and the default would still make it look like potential spam.
I'm currently using the second site as the reverse DNS since my site isn't quite ready, would just be nice if I could do it without attaching an extra IP to my Linode and reconfiguring everything.
Think about what you're asking for a little more. How exactly are you expecting the DNS servers to know which domain the requester "wants" to see when querying the IP?
@Piki:
I'm currently hosting two sites on my Linode, each with it's own domain. The problem is that as far as I can tell, only one reverse DNS can be used, which means one domain can be entered as the reverse DNS. That leaves the other site open to look like a spam site, and can open both sites to complaint. Is there a way to tell the reverse DNS that my Linode's IP belong to two domains?
Anyone who things that this configuration would be "spam" is badly misunderstanding the nature of DNS.
It's normal for mail to come from a host that doesn't have the originating name in the rDNS. As long as the rDNS has a valid forward record that matches (eg IP 1.2.3.4 -> foo.example.com, and foo.example.com -> 1.2.3.4) then it's good.
@glg:
Think about what you're asking for a little more. How exactly are you expecting the DNS servers to know which domain the requester "wants" to see when querying the IP?
I never said I expected that. It would be impossible. A psychic computer is just as implausible (if not more) as the cat bumping my arm and my shirt spontaneously combusting. There's nothing to think about here with what I'm asking: someone queries the IP, it shows both domains. The requester decides for himself which he wants to look at out of the two entries shown.
@sweh:
Anyone who things that this configuration would be "spam" is badly misunderstanding the nature of DNS.
It's normal for mail to come from a host that doesn't have the originating name in the rDNS. As long as the rDNS has a valid forward record that matches (eg IP 1.2.3.4 -> foo.example.com, and foo.example.com -> 1.2.3.4) then it's good.
It's not spam, but it looks like spam, which is what I'm after here. People might think that someone is using one domain as a relay for mail coming from the other, and there are actually mail servers that are setup to check that as a part of their spam filters.
@Piki:
@sweh:Anyone who things that this configuration would be "spam" is badly misunderstanding the nature of DNS.
It's normal for mail to come from a host that doesn't have the originating name in the rDNS. As long as the rDNS has a valid forward record that matches (eg IP 1.2.3.4 -> foo.example.com, and foo.example.com -> 1.2.3.4) then it's good.
It's not spam, but it looks like spam, which is what I'm after here. People might think that someone is using one domain as a relay for mail coming from the other, and there are actually mail servers that are setup to check that as a part of their spam filters.
No, it doesn't look like spam. It's normal. Anyone who thinks that mail from example.com must come from a mail server with "example.com" in the rDNS is wrong, and their "anti-spam" will block many many legitimate messages.
No one with half a clue would implement such a test in their mail server.
Ever used Google Apps? Google sends all of those e-mails from IP addresses whose reverse DNS point to something.google.com, not your own hosted domain. But nobody thinks they're spamming. The only thing that anybody ever checks is whether or not the reverse DNS matches the forward DNS.
Why? Because this simple check (along with other DNS-based checks such as SPF and DKIM) eliminates 99% of spam originating from virus-infected home PCs. If any spam gets through nowadays, it was probably sent from a compromised account at one of the free e-mail service providers (e.g. "I got stranded in Europe" frauds), or from a machine that actually has its DNS entries set up properly.
@hybinet:
@sweh is right. There is absolutely no need for your reverse DNS to match the domain(s) you're hosting.
Ever used Google Apps? Google sends all of those e-mails from IP addresses whose reverse DNS point to something.google.com, not your own hosted domain. But nobody thinks they're spamming. The only thing that anybody ever checks is whether or not the reverse DNS matches the forward DNS.
That seems a bit contradictory to me. I don't need to have the reverse and forward DNS entries match, but people check this for spam? Then why wouldn't I need to have them matching?
If I do use Google Apps, the reverse DNS won't match my forward DNS, and it will look like I'm using Google to relay all my spam so that they aren't tracked back to me. Google, however, will be able to detect this and I will get in trouble anyway (provided I'm not using Google Apps).
Of course, if I see email being sent from the other domain on my Linode, I'll know it's legit. The problem is that if the reverse DNS matches my domain and not theirs and we send out an email to someone who's smart enough to check but not smart enough to check to see they're both on the same machine, they will get suspicious – "The email was sent from arklinux.org but I traced it back to pikiisconfused.com! What gives?!" The same goes for if my reverse DNS points to the other domain and I send an email from mine.
Forward DNS is a mapping from "name" to IP address.
Reverse DNS is a mapping from IP address to name.
When your SMTP server connects to a remote machine, the remote machine only knows your IP address. Let's say it's 1.2.3.4. So then it does a reverse lookup and gets a name; "foo.example.com". Now that name could be spoofed, so a good program will then do a forward lookup for that name; it will look up "foo.example.com". If the result is the original IP address (1.2.3.4) then the remote machine can be confident that the name is correct. If the result doesn't match then there's a problem; this might be a spoofing attempt, so refuse the mail.
Note that none of this refers to the actual content of the email; it's just doing sanity checking on the IP<->DNS lookups.
NOTE: this is also different to "MX" records; nothing says that your incoming mail gateway has to be the same as your outgoing mail gateway.
No program should care that mail from arklinux is sent from a pikiisconfused domain name. UNLESS you have an SPF record that says otherwise. By default no one has that SPF record, and by default no one should care. Anyone who does care is just wrong.
Talking of SPF, you could create an SPF record that explicity says that mail for arklinux is sent from pikiisconfused, and any client could use this to be even more confident the mail isn't forged.
@sweh:
You seem to misunderstand what "forward" and "reverse" DNS means.
Forward DNS is a mapping from "name" to IP address.
Reverse DNS is a mapping from IP address to name.
Already understood.
> When your SMTP server connects to a remote machine, the remote machine only knows your IP address. Let's say it's 1.2.3.4. So then it does a reverse lookup and gets a name; "foo.example.com". Now that name could be spoofed, so a good program will then do a forward lookup for that name; it will look up "foo.example.com". If the result is the original IP address (1.2.3.4) then the remote machine can be confident that the name is correct. If the result doesn't match then there's a problem; this might be a spoofing attempt, so refuse the mail.
Note that none of this refers to the actual content of the email; it's just doing sanity checking on the IP<->DNS lookups.
Both my domain and the other domain point to the same IP, but the IP only points to one domain. So the other domain fails the sanity check, correct? Then it gets rejected.
> NOTE: this is also different to "MX" records; nothing says that your incoming mail gateway has to be the same as your outgoing mail gateway.
Most mail servers, to my understanding, prepend either mail or mail2 to their domain for sending and receiving mail, so hopefully the servers would be smart enough to pick up on that.
> No program should care that mail from arklinux is sent from a pikiisconfused domain name. UNLESS you have an SPF record that says otherwise. By default no one has that SPF record, and by default no one should care. Anyone who does care is just wrong.
Talking of SPF, you could create an SPF record that explicity says that mail for arklinux is sent from pikiisconfused, and any client could use this to be even more confident the mail isn't forged.
That starts into a new topic I have yet to explore. I'm still confused about the initial issue, though.
@Piki:
Both my domain and the other domain point to the same IP, but the IP only points to one domain. So the other domain fails the sanity check, correct? Then it gets rejected.
No. Because the client only sees the IP address, gets the pikiisconfused name and only looks that up. It never cares about the forward DNS entry for the other domain.
"IP -> rDNS -> pikiisconfused -> IP" is the process.
> Most mail servers, to my understanding, prepend either mail or mail2 to their domain for sending and receiving mail, so hopefully the servers would be smart enough to pick up on that.
No. Not even no, but "hell no". That's not even touching reality.
I was getting confused at:
> When your SMTP server connects to a remote machine, the remote machine only knows your IP address. Let's say it's 1.2.3.4. So then it does a reverse lookup and gets a name; "foo.example.com". Now that name could be spoofed, so a good program will then do a forward lookup for that name; it will look up "foo.example.com". If the result is the original IP address (1.2.3.4) then the remote machine can be confident that the name is correct. If the result doesn't match then there's a problem; this might be a spoofing attempt, so refuse the mail.
Note that none of this refers to the actual content of the email; it's just doing sanity checking on the IP<->DNS lookups.
For some reason, my mind was switching "domain" and "IP" at the start of the paragraph.
@sweh:
No. Because the client only sees the IP address, gets the pikiisconfused name and only looks that up. It never cares about the forward DNS entry for the other domain.
"IP -> rDNS -> pikiisconfused -> IP" is the process.
I was reading your post wrong.
>
> Most mail servers, to my understanding, prepend either mail or mail2 to their domain for sending and receiving mail, so hopefully the servers would be smart enough to pick up on that.
No. Not even no, but "hell no". That's not even touching reality.
I remember reading that in a couple places (I think I saw that on this forum somewhere, will have to dig out the post).
@Piki:
>> Most mail servers, to my understanding, prepend either mail or mail2 to their domain for sending and receiving mail, so hopefully the servers would be smart enough to pick up on that.No. Not even no, but "hell no". That's not even touching reality.
I remember reading that in a couple places (I think I saw that on this forum somewhere, will have to dig out the post).
Don't waste your time. It's just wrong. There is zero requirement and zero expectation mail servers are called "mail" or "mail2" or anything.
But since I now know which order mail servers will check in, I'm not too worried about it.
Your server's IP address is 1.2.3.4.
Your server's reverse DNS is li12-34.members.linode.com.
Your mail server software thinks that its hostname is li12-34.members.linode.com.
You have a domain, foo.com, on the server. You might also have other domains on the same server, but this is irrelevant.
Let's say you have a script that sends an email from
1. Your server contacts Gmail's server, and says "Hi, I'm li12-34.members.linode.com."
2. Gmail's server sees that somebody from 1.2.3.4 is claiming to be li12-34.members.linode.com. So it checks the reverse DNS for 1.2.3.4, and it is indeed li12-34.members.linode.com. Just to be sure, it also checks the A record (a.k.a. forward DNS) for li12-34.members.linode.com, and it is indeed 1.2.3.4. Gmail now has a good reason to think that your server is who it says it is. So it tells your server to continue.
3. Your server then says: "I have a message from
4. Gmail's server might check the SPF record for foo.com at this point, to make sure that li12-34.members.linode.com is permitted to send mail on behalf of foo.com, or at least that it is not prohibited from doing so. If you have a valid SPF record that confirms this, Gmail now has even more reason to think that your e-mail is legit. (The importance of SPF records is questionable these days, but it's a good idea to have them anyway.)
5. Provided that
6. Now it's time for Gmail to scan the content of your e-mail to see if it looks like spam. Nobody knows exactly what happens at this stage, but it probably has very little to do with DNS anymore.
So, there are three things that REALLY matter:
li12-34.members.linode.com should point to 1.2.3.4.
1.2.3.4 should have the reverse DNS, li12-34.members.linode.com.
Your server should identify itself correctly as li12-34.members.linode.com.
These three things have nothing to do with what kinds of domains you have on your server. The three things only need to be consistent with one another. Your domain isn't even mentioned. These checks take place at the HELO stage, even before your server has said who the sender is.
Most spammers don't even care to make these three things consistent with one another, which is why such a rudimentary check is so effective in fighting spam. According to one badass e-mail forwarding service
There's a fourth thing that may or may not matter:
- The SPF record for foo.com should allow li12-34.members.linode.com to send mail on behalf of foo.com.
But this is completely unreated to reverse DNS. As long as you are in control of the SPF record, it does not even matter if the actual website is hosted thousands of miles away.
@hybinet:
So, there are three things that REALLY matter:
li12-34.members.linode.com should point to 1.2.3.4.
1.2.3.4 should have the reverse DNS, li12-34.members.linode.com.
Your server should identify itself correctly as li12-34.members.linode.com.
Actually that third entry isn't necessary either; the machine needs to identify itself as a valid DNS name, but not necessarily as a name that matches the originating IP address.
This becomes important for multi-homed machines or machines with multiple IP addresses each of which may be used for originating traffic. Heck, maybe even IP4 and IP6 with different DNS names for each address. In these instances the sending machine can not always guarantee that the HELO (or EHLO) value matches the originating IP address.
Any receiving machine that requires the HELO name matches the IP address is broken. The receiving machine may validate that the DNS name provide is valid (many home machines just use their local hostname, and so they get rejected; drop a lot of spam that way!) but it should not attempt to match that to the IP address.
Now you might say "the sending machine can send a HELO value that matches the IP address" but:
1) this doesn't happen in real life. sendmail,postfix etc use the same value no matter what IP address you talk on
2) this value is used for simple "loopback" detection. If I'm called "foo.bar" and I connect to a machine that identifies itself as "foo.bar" then I can immediately abort; I'm talking to myself!
HELO is required and logged, but it is not checked for legitimacy (false positive rate too high).
Envelope sender must have a valid FQDN which must exist
Envelope recipient must have a valid FQDN which must exist and must be a local destination
The sending server must not be in an internal DNSBL or a handful of external *BLs[1], and a DNS query for its IP address must return a hostname which, when queried, returns the IP address. A handful of exceptions exist.
[1] These include one which blocks all domains registered within the past 5 days.
A couple important takeaways from this:
I cannot reject based on bad HELO without rejecting a lot of valid mail.
I cannot reject outright on forward/reverse DNS failure: I must defer due to the possibility of transient errors, and even with that, I have exceptions for notifications from $bank, my cellphone carrier's SMS-to-email gateways, the Department of Education, etc.
Obviously, others may have more restrictive policies and/or use scoring to divert messages to a spambucket that I would otherwise accept (indeed, so do I), but this is as good as I can do without losing legitimate mail.
So, don't sweat the actual hostname used (I send out as framboise.hoopycat.com), nor the contents of HELO (the Linode threshold alert e-mail I just got was sent from mail.linode.com, which HELO'd as "
It probably won't
smtpd_helo_required = yes
#smtpd_helo_restrictions = permit_mynetworks, check_client_access hash:/etc/postfix/heloaccess, reject_invalid_hostname, reject_non_fqdn_hostname
smtpd_sender_restrictions = reject_non_fqdn_sender, reject_unknown_sender_domain, permit_mynetworks
smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks,reject_unauth_destination, permit
smtpd_client_restrictions = check_client_access cidr:/etc/postfix/access,
permit_mynetworks,
reject_rbl_client <redacted>,
warn_if_reject reject_rbl_client bafrica_asia_south-america.<redacted>.geobl.spameatingmonkey.net,
reject_rbl_client bl.spameatingmonkey.net,
reject_rbl_client zen.spamhaus.org,
reject_rhsbl_sender urired.spameatingmonkey.net,
reject_rhsbl_client urired.spameatingmonkey.net,
reject_rhsbl_sender fresh.spameatingmonkey.net,
reject_rhsbl_client fresh.spameatingmonkey.net,
reject_rbl_client bl.ipv6.spameatingmonkey.net,
defer_if_reject reject_unknown_client_hostname,
permit</redacted></redacted>
Currently my rules are:
smtpd_restriction_classes =
sweh_restrictions
smtpd_recipient_restrictions =
reject_unknown_sender_domain,
check_recipient_access hash:/etc/postfix/recipient,
permit_mynetworks,
reject_unauth_destination
sweh_restrictions =
reject_unauth_pipelining,
check_sender_access hash:/etc/postfix/sweh/sender,
reject_rbl_client zen.spamhaus.org,
reject_non_fqdn_sender,
reject_non_fqdn_hostname,
permit
The "recipient" hash just has "mydomain swehrestrictions" so that mail sent my domain runs the extra checks; mail not sent to my domain will skip them and fail the unauth_destination check.
The "sender" hash is a white/black list so I can short-circuit deny morons, or whitelist people that would otherwise fail.
eg a blacklist and a whitelist entry
fortunoff@news.fortunoff.com 554 Fuck off spammers - see if I spend money with you again!
list.theregister.co.uk reject_unauth_destination,permit
@sweh:
I used to have complex rules, but got bored of maintaining whitelists 'cos various companies (eg Banks!) can't run an infrastructure properly. sigh
This suggests a rule of thumb: Make your e-mail appear less dodgy and suspicious than e-mails from a legitimate bank, and you should be alright.
Also, be sure to add