On Wed, 2011-09-21 at 12:37 +0200, Adam Tkac wrote: > 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. This typically doesn't work well, as we've found for dnsmasq. Given that resolv.conf/DNS data can change often (DHCP lease renewal, IPv6 RDNSS changes, you bring up a VPN, take down a VPN, connect to new networks) something needs to prioritize the DNS servers that the networks give you, and something needs to push the updated DNS information to the resolver. With dnsmasq, the problem is that people use it for many different things, and we also run different instances of it on a per-interface basis for things like connection sharing and virt. So users modifying the global config file /etc/dnsmasq.conf themselves almost certainly aren't setting the right options and invariably end up breaking either connection sharing or local caching DNS. But I'm not really familiar with unbound. Is it a long-running service? What does its config file look like? Does it re-read config data on SIGHUP? Is there any case you'd run more than one instance at a time, like we do with dnsmasq when you have virtual machines that use dnsmasq as the forwarding nameserver between the NAT-ed VM and the host? How complicated is the config file format? Does it have the ability to specific different nameservers on a per-zone basis? > 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. Understood. Dan > >> 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
