On 09/20/2011 05:19 PM, Dan Williams wrote: > 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. Another way is to use unbound/bind default configuration files and don't pass NM-generated configs. This way you (and other NM developers) doesn't have to know unbound/bind configuration details. Next advantage is that enthusiastic users and admins can modify unbound/bind configuration without touching NM. By default, both bind and unbound are installed as DNSSEC-validating local resolvers so NM can only spawn unbound/bind. > > 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. With "DHCP obtained DNS caches" Paul probably meant the nameservers which you got via DHCP (aka ISP's nameservers). Those servers perform caching so local unbound/bind will use them and there won't be increased DNS traffic over the Internet due bypassing those caches. >> 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: > > http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dns-manager I just checked the NetworkManager/src/dns-manager/nm-dns-bind.c and this plugin already does nearly everything what we need (it spawns named and catches important info from DHCP). With little hacking I'm sure we can modify it to serve us as we need. Regards, Adam -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
