On Tue, Feb 26, 2013 at 08:57:51PM -0500, b...@bitrate.net wrote:
> > When Postfix support for DANE (RFC 6698) is introduced, there will
> > be a requirement to operate a local nameserver that is DNSSEC aware
> > on any machine that wants to take advantage of peer certificate details
> > published via DNSSEC to scalably deliver verified TLS email to many
> > sites without the overhead of local per-site configuration.
>
> Why must the nameserver be local?
Very easy. If the server is *not* local, you should not trust the
AD-bit in its responses without authenticating the nameserver via
something like TSIG.
I am not going to bloat Postfix with TSIG support, this would be
really silly, when a local cache can take care of that. A fortiori
I am not going to bloat Postfix with its own RRSIG-validing DNSSEC
support. Therefore, Postfix support for DANE will be sensibly
predicated on a *local* DNSSEC verifying cache.
Unless we add code to check that the resolv.conf in fact only
contains local servers (I am disinclined to do that also), you will
be able to "break the warranty" and trust the AD-bit from non-local
nameservers by telling Postfix to enable DANE even with a resolv.conf
that points to remote servers. If you do that, you only have yourself
to blame when lack of TSIG, ... makes it possible to MITM your
server's ostensibly "secure" email deliveries.
All, I can say (and will say in the documentation) is that you've
been warned. Since the fields of "_res" other than "_res.options"
are not generally documented, there is no reasonable way to perform
a run-time check that the configured nameservers consist of just
127.0.0.1 and/or ::1. So the plan is to document the warning clearly
in all the relevant documents, and leave the rest to the administrator's
ability to restrain himself from folly.
Perhaps "postfix check" could generate a warning if DANE is enabled
and non-local nameservers are found in /etc/resolv.conf (or and/or
its chroot-jail version).
--
Viktor.
