Am 26.02.2014 07:33, schrieb Viktor Dukhovni: > 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.
that is not the point, having on every VM running postfix a local resolver is overkill - that is the point and redundancy is always a good idea > 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. it is overkill > With a caching local resolver, all the DNSSEC validation code is > where it should be, in a DNSSEC application. which are the two dedicated nameservers in the LAN http://www.avolio.com/columns/e-mailServerSecurity.html "Turn off all services except for those required and limit these" having two *dedicated* nameservers doing nothing else than DNS and SSH for administartion in the LAN has to be enough > 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. that is the point: if i do not trust my dedicated nameservers in my own network i can also not trust the one running on the MTA and asking the both as forwarders so the only relevant question: is "127.0.0.1 (or ::1)" a hard requirement or something recommended > All of the above are much more complex than a local > validating stub resolver no - the two dns servers are already in the LAN and working they are trusted and if i do not trust my own LAN i also can not trust a forwarder running on 127.0.0.1 asking them
