I'm quoting Timothy Mayo from his March 2 message titled "Re: DNS &
/etc/hosts"
>No, qmail does NOT use the resolver. Yes it makes direct DNS requests.
...
>qmail NEVER uses /etc/hosts, period. It only uses DNS, regardless of how
>you have set up your resolver. The only way to override the use of DNS is
>by using /var/qmail/control/smtproutes.
How does Qmail act as an outbound relay for a host who is not listed in
DNS?
I'm setting up a network which has two Qmail mail relays on the DMZ, and
the mail server (mail store) on the internal network. The firewall allows
the mail store to talk to the mail relays (and vice versa), and the mail
relays to talk to the Internet (and vice versa).
The mail relays are in DNS with MX values of 10 and 20.
The mail store is not listed in Internet-accessible DNS, a standard
security precaution. The mail relays use our ISP's DNS servers for all
their resolution. Our ISP hosts our primary and secondary DNS servers as
far as the Internet is concerned; our internal network has its own "primary"
and "secondary" which provide DNS for internal hosts and which slave to the
ISP's DNS servers for all else (as allowed by the firewall).
When the internal host tried to send out via the relay (Yes, I've got
RELAYCLIENT set via tcpserver), the relay complained that it couldn't find
the mail store in DNS and therefore wouldn't accept the mail (I don't have a
copy of the exact error message, but can get it if that makes a difference).
Adding the internal mail store machine to /etc/hosts didn't help (as
Timothy's message above would indicate).
So what's the solution for this?
1) Add the mail store to Internet-available DNS? Security guidelines
say not to do this, in order to deny information to attackers, but that's
always seemed a pretty weak argument to me (once someone is in a position to
use the information, they're in a position to gather the information pretty
easily).
2) Set the firewall to allow the mail relays to query the INTERNAL DNS
servers, which will know about this host and will forward other requests
back out the firewall to the ISP's DNS server? Seems inefficient, and
presumably is as bad or worse than #1 security wise (cracker need only break
DMZ to get all DNS info, as opposed to breaking onto the internal network).
3) Set up a forwarding DNS server on the DMZ which knows about the
internal mail store, but doesn't pass that info on to the Internet?
4) Entering an [dotted quad] into smtproutes fixes this on the inbound
relay case. Is there a similar fax for the outbound relay case?
5) Everything else I haven't thought of ;>
Surely I can't be the only one who's tried this. How do the rest of you
handle this?
Any help you can give is appreciated. I've got two weeks or more before
this system needs to go live, so I can take the time to do the "right"
solution rather than the expedient solution.
--
gowen -- Greg Owen -- [EMAIL PROTECTED] -- [EMAIL PROTECTED]
Please note my new [EMAIL PROTECTED] address which will
become my default address in March, and which works now.
