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'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.
You can find source and package pre-releases at:
ftp://ftp.xelerance.com/dnssec-trigger/
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".
Cheers,
Paul
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, 2011-09-17 at 14:00 -0400, Paul Wouters wrote:
You can find source and package pre-releases at:
ftp://ftp.xelerance.com/dnssec-trigger/
At least for Fedora 15:
BuildRequires: glib-devel, gtk2-devel, ldns-devel
and in %install mkdir -p %{buildroot}%{_localstatedir}/run/dnssec-triggerd
After killing off dnsmasq and starting unbound and dnssec-trigger,
Sep 17 18:19:02 laptop setroubleshoot: SELinux is preventing /usr/sbin/unbound from name_bind access on the tcp_socket port 8953. For complete SELinux messages. run sealert -l 924dfa70-fe9e-4cc0-add0- 364b8ae90ef6
grep unbound /var/log/audit/audit.log | audit2allow -M unboundpatch semodule -i unboundpatch.pp
cat /etc/resolv.conf # Generated by dnssec-trigger 0.3 nameserver 127.0.0.1
It took over dns via unbound, even though the dhcp assigned dns servers allow dnssec queries.
dnssec-trigger-control-setup setup in directory /etc dnssec_trigger_server.key exists dnssec_trigger_control.key exists create dnssec_trigger_server.pem (self signed certificate) create dnssec_trigger_control.pem (signed client certificate) Signature ok subject=/CN=dnssec-trigger-control Getting CA Private Key Setup success. Certificates created.
dnssec-trigger-control-setup -i setup in directory /etc unbound-checkconf: no errors in /etc/unbound/unbound.conf checking if unbound-control needs to be enabled checking if root trust anchor needs to be enabled fetching or updating root trust anchor: unbound-anchor [1316311135] libunbound[17598:0] error: ldns error while converting string to RR: Syntax error, could not parse the RR's rdata [1316311135] libunbound[17598:0] error: failed to load trust anchor from /etc/unbound/root.key at line 2, skipping [1316311135] libunbound[17598:0] error: ldns error while converting string to RR: Syntax error, could not parse the RR's TTL [1316311135] libunbound[17598:0] error: failed to load trust anchor from /etc/unbound/root.key at line 4, skipping [1316311135] libunbound[17598:0] error: failed to read /etc/unbound/root.key [1316311135] libunbound[17598:0] error: error reading auto-trust-anchor- file: /etc/unbound/root.key [1316311135] libunbound[17598:0] error: validator: error in trustanchors config [1316311135] libunbound[17598:0] error: validator: could not apply configuration settings. [1316311135] libunbound[17598:0] error: module init for module validator failed add to /etc/unbound/unbound.conf: auto-trust-anchor-file: "/etc/unbound/root.key" check for search path in resolv.conf and edit /etc/dnssec-trigger.conf check for domain in resolv.conf and edit /etc/dnssec-trigger.conf
Le samedi 17 septembre 2011 à 14:00 -0400, Paul Wouters a écrit :
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.
...
However, there are many networks out there that mess with DNS,
I'm sure lots of Fedora users would love to get rid of their isp's idea of 'enhancing' dns (plus sometimes the isp dns' are not only enhanced, they're flacky making the whole network access unreliable)
Could the well-integrated caching dns option be considered as well, given we live in an unperfect world ?
On Sun, 18 Sep 2011, Nicolas Mailhot wrote:
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.
However, there are many networks out there that mess with DNS,
I'm sure lots of Fedora users would love to get rid of their isp's idea of 'enhancing' dns (plus sometimes the isp dns' are not only enhanced, they're flacky making the whole network access unreliable)
Could the well-integrated caching dns option be considered as well, given we live in an unperfect world ?
DNSSEC cannot tell the difference between "enhancing DNS" and "attacking DNS". If your ISP's nameservers are returning DNSSEC data, any rewrites would get rejected as spoofed. (for domains not using DNSSEC that cannot be easilly detected and the rewrites will just work). dnssec-triggerd currently does not attempt to detect this, so in the current setup, you would just "lose" DNS access to rewritten DNS answers. An option could be added to force it into "auth mode", or a probe for some "well known" domains that get rewritten could be written.
Things are a little more complicated because some hotspots temporarilly mess with DNS to get you to the login/payment page before they "free" DNS, though luckilly most portals these days just grab the port 80/443 traffic and give the browser a redirect at the HTTP level, as that does not suffer from TTL/caching the browsers are doing. But that throws an SSL warning on 443.
But yes, that's something that can be looked at for the next version :)
Paul
Hi all,
Sorry for my previous message to this list.
It was intended as a personal message (in Dutch) to Paul, hence the "off-list" remark at the top, but I made a stupid mistake...
Cheers,
Hi Paul,
(off-list)
On Sat, Sep 17, 2011 at 02:00:04PM -0400, Paul Wouters wrote:
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.
Even een (misschien wat flauwe) opmerking: zorg dan ook voor een Xfce panel plugin, want GNOME wordt door "echte" mannen (incl. Linus Torvalds, die dat openlijk meldde) niet meer gebruikt sinds/dankzij GNOME3 ;-).
Groet,
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:
http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dns-manag...
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.
Dan
You can find source and package pre-releases at:
ftp://ftp.xelerance.com/dnssec-trigger/
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".
Cheers,
Paul
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-manag...
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
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-manag...
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
On Thu, 22 Sep 2011, Dan Williams wrote:
But I'm not really familiar with unbound. Is it a long-running service?
Yes, It's a fully dnssec validating caching resolver. You start it at boot and leave it running.
What does its config file look like? Does it re-read config data on SIGHUP?
You properly talk to it via unbound-control, which uses SSL certs between it and the daemon. No need to re-write config files or send it weirdo signals.
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?
You could, but in general one does not. Unlike dnsmasq, unbound delivers no dhcp or other services. It is just a very secure DNS resolver.
How complicated is the config file format? Does it have the ability to specific different nameservers on a per-zone basis?
Yes you can specify specific forwarders for specific zones using the forward and stub sections (not sure if you can send these via unbound-control currently) You can even assign those a DNSSEC key, so you can validate non-public zones that would normally be proven "not to exist" in the real world.
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.
Indeed.
Paul
On Thu, 2011-09-22 at 14:26 -0400, Paul Wouters wrote:
On Thu, 22 Sep 2011, Dan Williams wrote:
But I'm not really familiar with unbound. Is it a long-running service?
Yes, It's a fully dnssec validating caching resolver. You start it at boot and leave it running.
What does its config file look like? Does it re-read config data on SIGHUP?
You properly talk to it via unbound-control, which uses SSL certs between it and the daemon. No need to re-write config files or send it weirdo signals.
Ok, this part mystifies me. I assume it just has a TCP socket listening that you talk to it on? Otherwise there's no point to using SSL on a localhost where the socket would ideally be root-protected anyway. Which would be a lot simpler for programmatic control. I'm a bit concerned about fragility here, since if we require SSL certs to talk to the daemon on localhost, that means you need to have a whole bunch of other stuff set up (CA certificates, point the helper to the CA certificates, somehow generating the client/server certificates when unbound is installed, etc) before things will work, which typically shouldn't be necessary talking to a local machine with both processes running as root.
Ideally we can send all the information to unbound in *one* request (to reduce possible race conditions) and get back meaningful status/error information too. That's often the problem with running helper binaries, in that screen-scraping is a horrible, horrible way to return error information. Ideally the helper binary returns a nice fine-grained exit value and hopefully prints out well-formatted error messages to stderr?
Dan
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?
You could, but in general one does not. Unlike dnsmasq, unbound delivers no dhcp or other services. It is just a very secure DNS resolver.
How complicated is the config file format? Does it have the ability to specific different nameservers on a per-zone basis?
Yes you can specify specific forwarders for specific zones using the forward and stub sections (not sure if you can send these via unbound-control currently) You can even assign those a DNSSEC key, so you can validate non-public zones that would normally be proven "not to exist" in the real world.
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.
Indeed.
Paul _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
On Thu, 22 Sep 2011, Dan Williams wrote:
You properly talk to it via unbound-control, which uses SSL certs between it and the daemon. No need to re-write config files or send it weirdo signals.
Ok, this part mystifies me. I assume it just has a TCP socket listening that you talk to it on? Otherwise there's no point to using SSL on a localhost where the socket would ideally be root-protected anyway. Which would be a lot simpler for programmatic control. I'm a bit concerned about fragility here, since if we require SSL certs to talk to the daemon on localhost, that means you need to have a whole bunch of other stuff set up (CA certificates, point the helper to the CA certificates, somehow generating the client/server certificates when unbound is installed, etc) before things will work, which typically shouldn't be necessary talking to a local machine with both processes running as root.
On first startup, the unbound init script generates all the certs for unbound-control to talk to unbound. See:
yum install unbound service unbound start
Then you can do things like:
[paul@bofh paul]$ sudo unbound-control status version: 1.4.12 verbosity: 1 threads: 2 modules: 2 [ validator iterator ] uptime: 92870 seconds unbound (pid 2148) is running...
and:
[paul@bofh paul]$ sudo unbound-control forward off (using root hints) [paul@bofh paul]$ sudo unbound-control forward 193.110.157.136 193.110.157.2 ok [paul@bofh paul]$ sudo unbound-control forward 193.110.157.2 193.110.157.136 [paul@bofh paul]$ sudo unbound-control forward off ok
Ideally we can send all the information to unbound in *one* request (to reduce possible race conditions) and get back meaningful status/error
Let's clarify things a bit here. unbound should only be fed "known working" DNS resolvers. Currently, dnssec-triggerd is performing that check. If these DNS servers are broken, dnssec-triggerd checks if it can talk to the auth servers directly. Then it is ready to reconfigure unbound to:
1) use the resolvers (unbound-control forward 1.2.3.4 5.6.7.8) 2) use the auth servers directly (unbound-control forward off) 3) block unbound from doing any new lookups (unbound-control forward 127.0.0.127) 4) go insecure (prob implemented using 1) plus unbound-control set_option val-permissive-mode: yes)
So either the NM plugin takes over that core from dnssec-triggerd, or it outsources this ti dnssec-triggerd. If the latter, then it talks to dnssec-triggerd in a similar way as you talk to unbound. Via a dnssec-triggerd-control command, which uses certs that are also generating on first service start of dnssec-triggerd
information too. That's often the problem with running helper binaries, in that screen-scraping is a horrible, horrible way to return error information. Ideally the helper binary returns a nice fine-grained exit value and hopefully prints out well-formatted error messages to stderr?
The output is pretty terse and simple? Not sure if unbound-control or dnssec-triggerd-control use nice different exit codes for failures, and if not, if Wouter would like to implement that :)
Paul
On 09/17/2011 08:00 PM, 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'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.
Hello Paul,
this is a great idea and work. We talked (inside Red Hat) about similar approach how to secure the clients but this proposal is better, ready for use, and I like it.
The only one question for discussion is if we should "disable DNSSEC when it is proven untrusted". Previously, I tended to use similar approach but after discussion with security guys I think we shouldn't go this way.
The main problem is how to differ between misconfigured ISP's proxy/server which strips DNSSEC data (good example is bind 9.3, still widely used, and it's default "dnssec-enable no;" setting) and MITM attack which strips DNSSEC data. Due this I think we should always enforce DNSSEC, user should explicitly modify unbound or riggerd configuration to disable DNSSEC. Otherwise we can end with same situation as with X.509 certs on the Internet - when cert is bad, everyone automatically accept it and there is no security benefit.
Another argument for enforcing DNSSEC is that in future (well, I believe :) ) DNS will be used as storage for X.509 certs, SSHFP records and other stuff. If we adopt "leisure" approach (automatic disabling of DNSSEC or ability to "click" somewhere on the applet to disable DNSSEC) then we can end in the same situation as we are currently with X.509 certs. Everyone will simply click on "disable DNSSEC" button or, when MITM attack will be in progress, DNSSEC will be automatically disabled. This will degrade DNSSEC benefits.
When we enforce DNSSEC there will be definitely some users which will end with "broken" DNS but this is a great opportunity how to really secure end nodes.
Comments are welcomed.
Regards, Adam
On 09/21/2011 10:21 AM, Adam Tkac wrote:
Another argument for enforcing DNSSEC is that in future (well, I believe :) ) DNS will be used as storage for X.509 certs, SSHFP records and other stuff. If we adopt "leisure" approach (automatic disabling of DNSSEC or ability to "click" somewhere on the applet to disable DNSSEC) then we can end in the same situation as we are currently with X.509 certs. Everyone will simply click on "disable DNSSEC" button or, when MITM attack will be in progress, DNSSEC will be automatically disabled. This will degrade DNSSEC benefits.
Beside the obvious design flaws in dnssec and in the long run they only solve a part of the problem how can you even consider removing the ability for disabling dnssec when implementing and deploying and running dnssec increases the complexity times hundred and people and isp's alike cant even implement and properly run a simple dns server as it is now?
JBG
On Wed, 2011-09-21 at 12:45 +0000, "Jóhann B. Guðmundsson" wrote:
On 09/21/2011 10:21 AM, Adam Tkac wrote:
Another argument for enforcing DNSSEC is that in future (well, I believe :) ) DNS will be used as storage for X.509 certs, SSHFP records and other stuff. If we adopt "leisure" approach (automatic disabling of DNSSEC or ability to "click" somewhere on the applet to disable DNSSEC) then we can end in the same situation as we are currently with X.509 certs. Everyone will simply click on "disable DNSSEC" button or, when MITM attack will be in progress, DNSSEC will be automatically disabled. This will degrade DNSSEC benefits.
Beside the obvious design flaws in dnssec and in the long run they only solve a part of the problem how can you even consider removing the ability for disabling dnssec when implementing and deploying and running dnssec increases the complexity times hundred and people and isp's alike cant even implement and properly run a simple dns server as it is now?
You probably did not understand the meaning of "removing the ability for disabling dnssec" in the Adam's e-mail. It is not meant to disable the ability to not use of dnssec completely but that it should not be possible to simply click away any failures to verify dnssec for domains that are marked as that they should be validated by dnssec. Simply if a domain is marked as dnssec enabled in the parent record then it must have correct dnssec entries or it should not be accepted. Domains that are not marked as dnssec enabled (that should be the default for admins that are unable or unwilling to use dnssec on their domains) are not affected in any way.
On 09/21/2011 01:00 PM, Tomas Mraz wrote:
You probably did not understand the meaning of "removing the ability for disabling dnssec" in the Adam's e-mail. It is not meant to disable the ability to not use of dnssec completely but that it should not be possible to simply click away any failures to verify dnssec for domains that are marked as that they should be validated by dnssec. Simply if a domain is marked as dnssec enabled in the parent record then it must have correct dnssec entries or it should not be accepted. Domains that are not marked as dnssec enabled (that should be the default for admins that are unable or unwilling to use dnssec on their domains) are not affected in any way.
You are right I misunderstood him.
By all means remove the users availability to simply click them selves away from that.
JBG
On Wed, 21 Sep 2011, Tomas Mraz wrote:
solve a part of the problem how can you even consider removing the ability for disabling dnssec when implementing and deploying and running dnssec increases the complexity times hundred and people and isp's alike cant even implement and properly run a simple dns server as it is now?
Let's not try and turn this into a dnssec bashing thread please. Fedora has been shipping with turn on dnssec aware servers that do a pretty decent job. ISPs can simple install bind or unbound in Fedora or RHEL and dnssec just works. (especially on ISP networks that have no broken cheap consumer hardware issues)
You probably did not understand the meaning of "removing the ability for disabling dnssec" in the Adam's e-mail. It is not meant to disable the ability to not use of dnssec completely but that it should not be possible to simply click away any failures to verify dnssec for domains that are marked as that they should be validated by dnssec.
right. the big problem is not working around a broken network or a network with an attacker. The problem is false positives due to the pletora of hotspot mangling techniques out there. Ideally, NetworkManager would deal with the whole "hotspot detection" and lift any blocking done by the hotspot pre-login, and then dnssec-triggerd in some way or shape can deal with the DNS investigation and caching resolver reconfiguration.
For example, the Apple iOS hotspot detection consists of simple trying to fetch: http://www.apple.com/library/test/success.html
Once NM detects something like this, it can: 1) use dnssec-triggerd to put unbound in "readonly cache mode" to avoid insecure/bad DNS 2) fire of a webrequest that triggers the user into portal authentication 3) detect with above test the access has opened (or will never get better) 4) signal dnssec-triggerd to see if it can go to either "use ISP DNS server" or "auth mode".
Simply if a domain is marked as dnssec enabled in the parent record then it must have correct dnssec entries or it should not be accepted.
If you never contacted that domain before, you cannot always perform that check on a pre-login hotspot. Even if they do not mangle DNS but grab you at the IP layer, then you run into the DNSSEC DANE record telling you about a TLS cert that is mismatching due to the portal.
Paul
On Wed, 2011-09-21 at 11:23 -0400, Paul Wouters wrote:
On Wed, 21 Sep 2011, Tomas Mraz wrote:
solve a part of the problem how can you even consider removing the ability for disabling dnssec when implementing and deploying and running dnssec increases the complexity times hundred and people and isp's alike cant even implement and properly run a simple dns server as it is now?
Let's not try and turn this into a dnssec bashing thread please. Fedora has been shipping with turn on dnssec aware servers that do a pretty decent job. ISPs can simple install bind or unbound in Fedora or RHEL and dnssec just works. (especially on ISP networks that have no broken cheap consumer hardware issues)
You probably did not understand the meaning of "removing the ability for disabling dnssec" in the Adam's e-mail. It is not meant to disable the ability to not use of dnssec completely but that it should not be possible to simply click away any failures to verify dnssec for domains that are marked as that they should be validated by dnssec.
right. the big problem is not working around a broken network or a network with an attacker. The problem is false positives due to the pletora of hotspot mangling techniques out there. Ideally, NetworkManager would deal with the whole "hotspot detection" and lift any blocking done by the hotspot pre-login, and then dnssec-triggerd in some way or shape can deal with the DNS investigation and caching resolver reconfiguration.
For example, the Apple iOS hotspot detection consists of simple trying to fetch: http://www.apple.com/library/test/success.html
There's long notes on how to do this in the TODO file in NM git, just needs the time to implement. It's essentially what Windows does as well, they just fetch a known URL and compare the result to a known response, and if there isn't a match, you're not connected to the internet. Various other plugins could check the response for known portal junk (and we can use the various portal auto-login standards like WPAD) to handle portal auto-login if we can.
Dan
Once NM detects something like this, it can:
- use dnssec-triggerd to put unbound in "readonly cache mode" to avoid insecure/bad DNS
- fire of a webrequest that triggers the user into portal authentication
- detect with above test the access has opened (or will never get better)
- signal dnssec-triggerd to see if it can go to either "use ISP DNS server" or "auth mode".
Simply if a domain is marked as dnssec enabled in the parent record then it must have correct dnssec entries or it should not be accepted.
If you never contacted that domain before, you cannot always perform that check on a pre-login hotspot. Even if they do not mangle DNS but grab you at the IP layer, then you run into the DNSSEC DANE record telling you about a TLS cert that is mismatching due to the portal.
Paul
On Thu, Sep 22, 2011 at 11:27:41AM -0500, Dan Williams wrote:
right. the big problem is not working around a broken network or a network with an attacker. The problem is false positives due to the pletora of hotspot mangling techniques out there. Ideally, NetworkManager would deal with the whole "hotspot detection" and lift any blocking done by the hotspot pre-login, and then dnssec-triggerd in some way or shape can deal with the DNS investigation and caching resolver reconfiguration.
For example, the Apple iOS hotspot detection consists of simple trying to fetch: http://www.apple.com/library/test/success.html
There's long notes on how to do this in the TODO file in NM git, just needs the time to implement. It's essentially what Windows does as well, they just fetch a known URL and compare the result to a known response, and if there isn't a match, you're not connected to the internet. Various other plugins could check the response for known portal junk (and we can use the various portal auto-login standards like WPAD) to handle portal auto-login if we can.
ConnMan (https://lwn.net/Articles/456967/) already has code to detect and login on hotspot pages. Maybe you can just lift code from ConnMan instead of redoing it.
On Thu, 2011-09-22 at 22:29 +0200, Tomasz Torcz wrote:
On Thu, Sep 22, 2011 at 11:27:41AM -0500, Dan Williams wrote:
right. the big problem is not working around a broken network or a network with an attacker. The problem is false positives due to the pletora of hotspot mangling techniques out there. Ideally, NetworkManager would deal with the whole "hotspot detection" and lift any blocking done by the hotspot pre-login, and then dnssec-triggerd in some way or shape can deal with the DNS investigation and caching resolver reconfiguration.
For example, the Apple iOS hotspot detection consists of simple trying to fetch: http://www.apple.com/library/test/success.html
There's long notes on how to do this in the TODO file in NM git, just needs the time to implement. It's essentially what Windows does as well, they just fetch a known URL and compare the result to a known response, and if there isn't a match, you're not connected to the internet. Various other plugins could check the response for known portal junk (and we can use the various portal auto-login standards like WPAD) to handle portal auto-login if we can.
ConnMan (https://lwn.net/Articles/456967/) already has code to detect and login on hotspot pages. Maybe you can just lift code from ConnMan instead of redoing it.
Yeah, it does, but the licenses are incompatible (GPLv2 vs. GPLv2+).
Dan
On Wed, 21 Sep 2011, Adam Tkac wrote:
this is a great idea and work. We talked (inside Red Hat) about similar approach how to secure the clients but this proposal is better, ready for use, and I like it.
Great. Please test and give us feedback :)
The only one question for discussion is if we should "disable DNSSEC when it is proven untrusted". Previously, I tended to use similar approach but after discussion with security guys I think we shouldn't go this way.
The main problem is how to differ between misconfigured ISP's proxy/server which strips DNSSEC data (good example is bind 9.3, still widely used, and it's default "dnssec-enable no;" setting) and MITM attack which strips DNSSEC data. Due this I think we should always enforce DNSSEC, user should explicitly modify unbound or riggerd configuration to disable DNSSEC. Otherwise we can end with same situation as with X.509 certs on the Internet - when cert is bad, everyone automatically accept it and there is no security benefit.
Currently, a big warning comes that tells you you can either continue from your current cache (with causes new lookups to fail) or to go insecure. We're trying to gain more hotspot experiences to see how well this works. If we can do auth dns ourselves in the majority of causes, we might be better of then we think. Networks with bind 9.3 tend to not firewall port 53, so moving in such a network should be mostly transparent.
Another argument for enforcing DNSSEC is that in future (well, I believe :) ) DNS will be used as storage for X.509 certs, SSHFP records and other stuff. If we adopt "leisure" approach (automatic disabling of DNSSEC or ability to "click" somewhere on the applet to disable DNSSEC) then we can end in the same situation as we are currently with X.509 certs.
There is a difference still. Applications can still see the difference between the localhost resolver returning the AD bit or not. So going insecure will render the sshfp/dane records "uselesss", they will not be trusted. Note also that with "dnssec chains" via TLS, either as a TLS extension or as part of a certificate blob, the non-attack case will be able to work in the browser even if fetching DNS via the network is broken/misconfigured.
Everyone will simply click on "disable DNSSEC" button or, when MITM attack will be in progress, DNSSEC will be automatically disabled. This will degrade DNSSEC benefits.
When we enforce DNSSEC there will be definitely some users which will end with "broken" DNS but this is a great opportunity how to really secure end nodes.
One of the reasons we are trying this, is to gain experience in how bad DNS at the endnode really is.
So I agree, we're not yet ready to inflict it on mortals, just on developers :)
Paul
<snip>
If people are testing this it would be good if they could test the unit files for this too on F15+ hosts. Afaik I have already converted the whole xelerance.com stuff and it's just laying there in bugzilla.
Create the relevant files in there relevant paths then run...
systemctl daemon-reload and systemctl start dnssec-triggerd-keygen.service dnssec-triggerd.service
#/lib/systemd/system/dnssec-triggerd-keygen.service
[Unit] Description=DNSSEC Unbound Forwarding Key Generator Before=dnssec-triggerd.service After=syslog.target ConditionPathExists=!/etc/dnssec_trigger_control.key
[Service] Type=oneshot ExecStart=/usr/sbin/dnssec-trigger-control-setup ExecStartPost=/sbin/restorecon /etc/dnssec-triggeer_* RemainAfterExit=yes
[Install] WantedBy=multi-user.target
# /lib/systemd/system/dnssec-triggerd.service
[Unit] Description=DNSSEC Unbound Forwarding After=syslog.target network.target unbound.service dnssec-triggerd-keygen.service
[Service] Type=forking PIDFile=/run/dnssec-triggerd/dnssec-triggerd.pid EnvironmentFile=-/etc/sysconfig/dnssec-triggerd RootDirectory=/var/lib/dnssec-triggerd ExecStart=/usr/sbin/dnssec-triggerd ExecStartPost=/etc/NetworkManager/dispatcher.d/01-dnssec-trigger-hook "all" "bootup"
[Install] WantedBy=multi-user.target
#/etc/tmpfiles.d/dnssec-trigger.conf
d /run/dnssec-triggerd 0755 root root -
-
Adam Tkac -
Carl Byington -
Dan Williams -
Jos Vos -
Jóhann B. Guðmundsson -
Nicolas Mailhot -
Paul Wouters -
Tomas Mraz -
Tomasz Torcz