From: Bennett Todd (no email)
Date: Wed Aug 07 2002 - 10:44:51 EDT
Postfix is a Mail Transport Agent, an MTA.
As such, it wants some host data that lies outside the scope of
/etc/hosts --- and outside the functionality of the normal stub
resolver libraries in libc.a, the ones that are controlled by
/etc/nsswitch.conf.
Specifically, it wants to do MX lookups. Plus other games come up in
the name of anti-UCE. These MTA requirements commonly result in MTAs
having their own DNS resolver library implementations; Postfix is no
exception.
It is possible, in some cases, to hardwire complete knowlege of the
relay environment into a Postfix so that it requires no DNS at all.
There's disable_dns_lookups, and you can specify hosts for relaying
and whatnot with [host.name] to disable the MX lookup.
But unless you've got an unusual and very static environment, I
wouldn't recommend doing that; Postfix's provisions for doing this
aren't designed to be a maintainable alternative to DNS.
Instead, get control of your DNS environment. On your mail server,
or (if you're really pressed flat against the wall for performance)
on a neighboring server dedicated to it, run a private DNS service
that presents the view you want.
If I wanted to provide a non-standard hostname/address view to a
Postfix I was running, I'd set up two local nameservers on the local
machine. I'd take them from djbdns[1]; that'd prevent me from having
to worry about performance.
I'd run a dnscache on 127.0.0.1, and list 127.0.0.1 in
/etc/resolv.conf. NB for very large servers dnscache requires a
little tuning, the default cache size is suited to small installs,
you'll want to give the cache more RAM for a high-volume server.
I'd run a tinydns on 127.0.0.2 --- you can have multiple aliases for
the loopback, a great trick when you've got multiple servers you
want to run that want the same port --- and I'd populate it with the
authoritative data for the domains I want to override.
Then for every domain I wished to override, I'd add an entry to
dnscache's servers/domain.name pointing to 127.0.0.2. In the extreme
case where I really want to perform no external DNS lookups
whatsoever, I'd still take this route; I'd put complete
authoritative data from the root down in the tinydns zone data, then
I'd list the tinydns server as the root nameserver for dnscache.
This same job could be done with BIND. Which nameserver is better is
at some point a matter of taste. I find djbdns much simpler to use
and manage, and I like its security record and its performance. I do
find daemontools --- notably the djb's whole svc init replacement
--- very distasteful; I run my dnscache and tinydns directly from
simple init scripts of my own[2].
-Bennett
[1] <URL:http://www.djbdns.org/>
[2] <URL:http://bent.latency.net/djbdns-initscripts/>
-
To unsubscribe, send mail to with content
(not subject): unsubscribe postfix-users
|
|
|