On Thu, 10 Apr 2014, Chuck Anderson wrote:
Yesterday, a new version of dnsmasq was released [2] that adds full DNSSEC support and provides an alternative to unbound which dnssec-trigger requires. There has also been great work done to solve the NTP/DNSSEC bootstrap problem [3]. What options are currently available in e.g. NetworkManager for using a local DNS cache and what is the current status of this integration? Is it ready yet for turning on by default in all Fedora products? [2] http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q2/008416.html [3] http://comments.gmane.org/gmane.comp.embedded.cerowrt.devel/2244
In my opinion, the last remaining hurdle is roaming users and captive portals. Nothing else prevents anyone from running with dnssec enabled per default (and even on laptops, developers can run with dnssec-triggerd and unbound). If you run a server, you should already be running unbound or bind (or dnsmasq w dnssec). I do not know if dnsmasq contains the proper code for being reconfigured on the fly based on network changes, which is a requirement for adopting to DNSSEC in various situations (such as VPNs, connecting to corporate LAN/Wifi with internal-only domains, DHCP/ISP forwarder failures). But libreswan, vpnc and openvpn already have the neccessary unbound reconfiguration code to properly support VPNs (eg flushing the cache for the vpn domain when (dis)connecting the VPN, etc) What is really needed to complete the solution and make it usable for users, not developers, is the proper integration of dnssec-trigger like code natively into NM. That must include captive portal checking (which dnssec-triggerd does) and upstream DNS forwarder checker, with dynamic reconfiguration on the fly. The current dnssec-trigger does a decent job, but its problematic because it is not native to NM. Fedora already hosts the captive portal detection services for dnssec-trigger. It would also need a little anaconda support. When the user is requested to put in a DNS server (for a static server configuration, not dhcp) than anaconda should configure that server as a _forwarder_ in an unbound configuration and ensure DNSSEC is enabled and running after install. For the roaming laptop case, anaconda should install unbound with the NM integrated dnssec-trigger replacement. In a perfect world, where all network applications are NM aware, it would be awesome if NM would launch a secure container to do the probing and captive portal logon using a sandboxed browser window. None of the other applications would even know there is a network. Once the captive portal login has succeeded, the uplink becomes available to all apps and the secure container can be destroyed. This would offer the maximum protection for applications against unsafe DNS, and limit the required acceptance of "DNS lies" to the captive portal login procedure only. The main issue to make this happen has been that we don't have enough resources to convert the dnssec-trigger code into native NM code. Paul -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
