On Wed, Feb 26, 2014 at 10:42:29AM +0100, li...@rhsoft.net wrote:
> > 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
Postfix does not know what is in your /etc/resolv.conf file.
If you use an insecure nameserver (whose replies are subject
to potential spoofing) you get insecure results.
You've been warned. If you think a local resolver is "overkill"
(I disagree) that's your call. Context switching to a process in
the same VM is certainly much cheaper than context switching to a
different VM for exmaple. With a local resolver, the MTA administrator
knows whether it in fact performs DNSSEC validation, and can check
or adjust the trust anchor settings (e.g. to include some non-root
trust-anchors).
> > 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
Without an anti-spoofing firewall, remote name servers may be able
to forge DNS replies that appear to come from your LAN. It is not
always obvious whether such protection is in place and is robust.
--
Viktor.
