[Dnssec-trigger] Looking for dnssec-triggerd alpha testers! (fwd)
paul at xelerance.com
Tue Sep 20 15:26:29 UTC 2011
---------- Forwarded message ----------
Date: Tue, 20 Sep 2011 10:19:15 -0500
From: Dan Williams <dcbw at redhat.com>
Cc: networkmanager-list at gnome.org, W.C.A. Wijngaards <wouter at NLnetLabs.nl>
To: Development discussions related to Fedora <devel at lists.fedoraproject.org>
Subject: Re: Looking for dnssec-triggerd alpha testers!
On Sat, 2011-09-17 at 14:00 -0400, 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 can do a much better job of NM integration here. We've already got a
DNS local-caching plugin for dnsmasq, but that doesn't do IPv6 as well.
We can easily create one for unbound. I tried to do one for bind, but
bind's config format is arcane enough that I gave up trying to get it to
do what I needed (local caching nameserver). NM handles rewriting
resolv.conf too, so that would no longer be required here.
Also, I saw mention of "DHCP obtained DNS caches" at the top of the
mail; can somebody provide a pointer to how that works? It's something
we should also expose via NM. NM already lets clients access all the
DHCP-provided options via the D-Bus interface, but if this requires the
DHCP client to request specific options from the server, that's
something NM would want to know as well.
> 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.
Yeah, a DNS plugin would be the best way to go here. I've already
implemented a local caching DNS plugin for dnsmasq, including reverse
resolution for IPv4 addresses so that stuff like VPN IP lookups work
correctly when they are in-use. I can provide pointers on how to set up
a new DNS plugin, but the existing ones are here:
Each plugin is a subclass of NMDnsPlugin and it should be pretty
self-explanatory. NM calls the plugin's update() method with a list of
the IPv4 and IPv6 configs of all active interaces in priority order.
The plugin then takes these and creates whatever configuration it needs
for its DNS program (dnsmasq, bind, unbound, etc) and then spawns that
program. You could also simply rewrite the program's config file and
send SIGHUP or something too if it supports that.
> You can find source and package pre-releases at:
> Install dnssec-trigger, which should drag in the unbound DNS server. Enable
> the unbound and dnssec-triggerd services to start. the panel can be manually
> started with "dnssec-trigger-panel".
networkmanager-list mailing list
networkmanager-list at gnome.org
More information about the dnssec-trigger