The best method is via the response policy zone in Bind 9.8.1 or newer. It allows you to override single records in arbitrary zones (and there's no need to create a whole subdomain for that, only the single record you want to change), it allows you to override CNAMEs, etc. Other solutions such as Unbound cannot override CNAMEs.
https://www.redpill-linpro.com/sysadvent/2015/12/08/dns-rpz.html
EDIT: Let's do this properly then. I will document what I've done based on the tutorial linked above.
My OS is Raspbian 4.4 for Raspberry Pi, but the technique should work without any changes on Debian and Ubuntu, or with minimal changes on other platforms.
Go to where your Bind config files are kept on your system - here it's in /etc/bind
. Create in there a file called db.rpz
with the following contents:
$TTL 60
@ IN SOA localhost. root.localhost. (
2015112501 ; serial
1h ; refresh
30m ; retry
1w ; expiry
30m) ; minimum
IN NS localhost.
localhost A 127.0.0.1
www.some-website.com A 127.0.0.1
www.other-website.com CNAME fake-hostname.com.
What does it do?
- it overrides the IP address for
www.some-website.com
with the fake address 127.0.0.1
, effectively sending all traffic for that site to the loopback address
- it sends traffic for
www.other-website.com
to another site called fake-hostname.com
Anything that could go in a Bind zone file you can use here.
To activate these changes there are a few more steps:
Edit named.conf.local
and add this section:
zone "rpz" {
type master;
file "/etc/bind/db.rpz";
};
The tutorial linked above tells you to add more stuff to zone "rpz" { }
but that's not necessary in simple setups - what I've shown here is the minimum to make it work on your local resolver.
Edit named.conf.options
and somewhere in the options { }
section add the response-policy
option:
options {
// bunch
// of
// stuff
// please
// ignore
response-policy { zone "rpz"; };
}
Now restart Bind:
service bind9 restart
That's it. The nameserver should begin overriding those records now.
If you need to make changes, just edit db.rpz
, then restart Bind again.
Bonus: if you want to log DNS queries to syslog, so you can keep an eye on the proceedings, edit named.conf.local
and make sure there's a logging
section that includes these statements:
logging {
// stuff
// already
// there
channel my_syslog {
syslog daemon;
severity info;
};
category queries { my_syslog; };
};
Restart Bind again and that's it.
Test it on the machine running Bind:
dig @127.0.0.1 www.other-website.com. any
If you run dig on a different machine just use @the-ip-address-of-Bind-server instead of @127.0.0.1
I've used this technique with great success to override the CNAME for a website I was working on, sending it to a new AWS load balancer that I was just testing. A Raspberry Pi was used to run Bind, and the RPi was also configured to function as a WiFi router - so by connecting devices to the SSID running on the RPi I would get the DNS overrides I needed for testing.
I think you are confusing incoming and outgoing mail exchangers. I'll try to answer your question by treating both separately:
Incoming mail
When another MTA has a message for $localpart@$yourdomain
it does a DNS query (type MX
, data $yourdomain
). The answer is get is mail.$yourdomain
(and probably also it's IP). It uses this to connect to your machine on port 25 and try to deliver the mail. Since the other machine is sending (not accepting), it will not to anti-spam checks based on your machine.
Outgoing mail
You want to send an e-mail from $localpart@$yourdomain
to somebody else. Your machine (this does not have to be the same as the MX record) connects to the remote mail server and tries to deliver the mail. Now the remote machine will do anti-spam checks. It has two pieces of information from your machine: The 'HELO/EHLO name' and the IP address.
Nowadays most servers demand that the 'HELO name' is a fully qualified domain name and that it resolves to your IP address. Some demand that your IP address has reverse DNS that does not look dynamic (like dyn-127-0-0-1.example.com
). I have encountered some servers that applied rate-limiting or greylisting when the 'HELO name' did not match the reverse DNS, but never full rejection.
My recommendations
- Keep your MX record as
mail.$yourdomain
.
- If you also use this machine for outgoing mail, set the 'HELO name' to
mail.$yourdomain
.
A shared machine for outgoing mail is far from ideal, abuse from other users can easily get you on DNS-bases blacklists.
Best Answer
Generally what they care about is that the rDNS result resolves back to the original IP. So a typical setup would look like this:
www.example.com
andwww.yourdomain.example
both resolve to 192.0.2.1.myhost1.yourdomain.example
.myhost1.yourdomain.example
resolves to 192.0.2.1.I believe most spam filters consider that to be an appropriate rDNS configuration.
If, however, you have separate IP addresses for each website and mail server running on your box so that email from
example.com
andyourdomain.example
appear to come from different IP addresses (and that would be a really bizarre email setup), then the forward and reverse DNS for that domain/IP combination should just point back to each other:example.com
email comes from 192.0.2.2example.com
.example.com
resolves to 192.0.2.2