On Wed, Feb 26, 2014 at 12:54:37AM +0100, li...@rhsoft.net wrote:
> > The local resolver can have the resolvers on the LAN configured as
> > forwarders, but you need the local stub resolver. No reason not to have
> > one, really, especially on a busy mail server
>
> yes, you normally have a local resolver on the mailserver
> but you hardly trust that one alone and in case it crashs
> you typically have another one on the LAN
1. In a decade of running BIND caching resolvers of various
antiquities on Morgan Stanley MTAs handling ~2 million
messages a day, I've never seen a local resolver crash.
2. If yours do, arrange for automated re-start and send an alert.
The postmaste master(8) daemon might be killed, which also stops
mail flow. How is that different? The requirement for a local
caching resolver is not a real impediment.
With a caching local resolver, all the DNSSEC validation code is
where it should be, in a DNSSEC application.
If you know how to configure TSIG DNS transport security, you can
use remote resolvers with which you've configured a trusted channel.
If the LAN housing the MTAs and multiple caching nameservers is
physically secure and well firewalled, you could potentially rely
on that physical security and firewall anti-spoofing rules.
All of the above are much more complex than a local validating stub
resolver.
--
Viktor.
