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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct