Re: Looking for dnssec-triggerd alpha testers!

[Adam Tkac <atkac redhat com>]

On 09/17/2011 08:00 PM, Paul Wouters wrote:
> Hi developers of NM and Fedora,
>
> We are trying to get DNSSEC validation on the end nodes. One way of doing
> that is to run a caching resolver on every host, but that strains the
> DNS infrastructure because all DNS caches would be circumvented. Since
> DNSSEC data is signed, you can obtain it via "insecure channels" and then
> validate it. So we want to try and use the DHCP obtained DNS caches as much
> as possible.
>
> However, there are many networks out there that mess with DNS, and sometimes
> we have to accept fake DNS to get past hotspot/login pages. Sometimes the
> DNS proxies are broken for DNSSEC and we would prefer to run the queries
> ourselves to the authoritative nameservers without using the broken caching
> middle layer.
>
> This is where "dnssec-trigger" comes in. Users run a local validating
> resolver with DNSSEC support (unbound) that can be dynamically reconfigured
> to use different forwarders. dnssec-triggerd checks the DNS path by sending
> a query to a root name server (via the caching resolver or directly) and
> determines if the DHCP obtained DNS servers can be used, or if unbound should
> attempt it directly. Or in the worst case, if DNS should be disabled completely
> because it is proven untrusted.
>
> dnssec-trigger consists of NetworkManager hooks, a daemon that rewrites
> resolv.conf and signals unbound, and a gnome applet to show the user the
> DNSSEC status and to warn the user if the network is (too?) unsafe to use.
>
> We'd love to hear from Fedora people how well this integrates and works in
> various hotspot scenarios. We'd love to hear from NM developers to see if
> the hooking have all been done in proper ways.
>
Hello Paul,

this is a great idea and work. We talked (inside Red Hat) about similar
approach how to secure the clients but this proposal is better, ready
for use, and I like it.

The only one question for discussion is if we should "disable DNSSEC
when it is proven untrusted". Previously, I tended to use similar
approach but after discussion with security guys I think we shouldn't go
this way.

The main problem is how to differ between misconfigured ISP's
proxy/server which strips DNSSEC data (good example is bind 9.3, still
widely used, and it's default "dnssec-enable no;" setting) and MITM
attack which strips DNSSEC data. Due this I think we should always
enforce DNSSEC, user should explicitly modify unbound or riggerd
configuration to disable DNSSEC. Otherwise we can end with same
situation as with X.509 certs on the Internet - when cert is bad,
everyone automatically accept it and there is no security benefit.

Another argument for enforcing DNSSEC is that in future (well, I believe
:) ) DNS will be used as storage for X.509 certs, SSHFP records and
other stuff. If we adopt "leisure" approach (automatic disabling of
DNSSEC or ability to "click" somewhere on the applet to disable DNSSEC)
then we can end in the same situation as we are currently with X.509
certs. Everyone will simply click on "disable DNSSEC" button or, when
MITM attack will be in progress, DNSSEC will be automatically disabled.
This will degrade DNSSEC benefits.

When we enforce DNSSEC there will be definitely some users which will
end with "broken" DNS but this is a great opportunity how to really
secure end nodes.

Comments are welcomed.

Regards, Adam