Discussion:
Looking for dnssec-triggerd alpha testers!
(too old to reply)
Paul Wouters
2011-09-17 18:00:04 UTC
Permalink
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
Carl Byington
2011-09-18 02:07:19 UTC
Permalink
Post by Paul Wouters
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
Nicolas Mailhot
2011-09-18 16:45:24 UTC
Permalink
Post by Paul Wouters
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.
...
Post by Paul Wouters
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 ?
--
Nicolas Mailhot
Paul Wouters
2011-09-18 17:41:56 UTC
Permalink
Post by Nicolas Mailhot
Post by Paul Wouters
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
Jos Vos
2011-09-18 19:19:40 UTC
Permalink
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,
--
-- Jos Vos <jos at xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
Jos Vos
2011-09-18 19:14:59 UTC
Permalink
Hi Paul,

(off-list)
Post by Paul Wouters
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,
--
-- Jos Vos <jos at xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
Dan Williams
2011-09-20 15:19:15 UTC
Permalink
Post by Paul Wouters
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.
Post by Paul Wouters
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

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
Post by Paul Wouters
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
Adam Tkac
2011-09-21 10:37:45 UTC
Permalink
Post by Dan Williams
Post by Paul Wouters
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.
Post by Dan Williams
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.
Post by Dan Williams
Post by Paul Wouters
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
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
Dan Williams
2011-09-22 16:46:58 UTC
Permalink
Post by Adam Tkac
Post by Dan Williams
Post by Paul Wouters
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?
Post by Adam Tkac
By default, both bind and unbound are installed as DNSSEC-validating
local resolvers so NM can only spawn unbound/bind.
Post by Dan Williams
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
Post by Adam Tkac
Post by Dan Williams
Post by Paul Wouters
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
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
Paul Wouters
2011-09-22 18:26:13 UTC
Permalink
Post by Dan Williams
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.
Post by Dan Williams
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.
Post by Dan Williams
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.
Post by Dan Williams
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.
Post by Dan Williams
Post by Adam Tkac
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
Dan Williams
2011-09-22 19:46:42 UTC
Permalink
Post by Paul Wouters
Post by Dan Williams
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.
Post by Dan Williams
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
Post by Paul Wouters
Post by Dan Williams
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.
Post by Dan Williams
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.
Post by Dan Williams
Post by Adam Tkac
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 at gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Paul Wouters
2011-09-22 20:56:28 UTC
Permalink
Post by Dan Williams
Post by Paul Wouters
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 at 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 at bofh paul]$ sudo unbound-control forward
off (using root hints)
[paul at bofh paul]$ sudo unbound-control forward 193.110.157.136 193.110.157.2
ok
[paul at bofh paul]$ sudo unbound-control forward
193.110.157.2 193.110.157.136
[paul at bofh paul]$ sudo unbound-control forward off
ok
Post by Dan Williams
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
Post by Dan Williams
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
Adam Tkac
2011-09-21 10:21:14 UTC
Permalink
Post by Paul Wouters
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
&quot;Jóhann B. Guðmundsson&quot;
2011-09-21 12:45:11 UTC
Permalink
Post by Adam Tkac
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
Tomas Mraz
2011-09-21 13:00:30 UTC
Permalink
Post by &quot;Jóhann B. Guðmundsson&quot;
Post by Adam Tkac
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.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
&quot;Jóhann B. Guðmundsson&quot;
2011-09-21 13:20:57 UTC
Permalink
Post by Tomas Mraz
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
Paul Wouters
2011-09-21 15:23:20 UTC
Permalink
Post by Tomas Mraz
Post by &quot;Jóhann B. Guðmundsson&quot;
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)
Post by Tomas Mraz
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".
Post by Tomas Mraz
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
Dan Williams
2011-09-22 16:27:41 UTC
Permalink
Post by Paul Wouters
Post by Tomas Mraz
Post by &quot;Jóhann B. Guðmundsson&quot;
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)
Post by Tomas Mraz
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.
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
Post by Paul Wouters
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".
Post by Tomas Mraz
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
Tomasz Torcz
2011-09-22 20:29:57 UTC
Permalink
Post by Dan Williams
Post by Paul Wouters
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.
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.
--
Tomasz Torcz Only gods can safely risk perfection,
xmpp: zdzichubg at chrome.pl it's a dangerous thing for a man. -- Alia
Dan Williams
2011-09-22 22:42:29 UTC
Permalink
Post by Tomasz Torcz
Post by Dan Williams
Post by Paul Wouters
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.
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

Paul Wouters
2011-09-21 14:23:45 UTC
Permalink
Post by Adam Tkac
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 :)
Post by Adam Tkac
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.
Post by Adam Tkac
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.
Post by Adam Tkac
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
&quot;Jóhann B. Guðmundsson&quot;
2011-09-22 19:03:22 UTC
Permalink
<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 -
Loading...