Request for testers of dnssec-trigger (now in rawhide)

Paul Wouters pwouters at
Tue Feb 7 05:01:46 UTC 2012


In our efforts to push DNSSEC to the enduser, we have packaged our
initial DNSSEC reconfiguration utility.

Basically, this makes it possible to use DNSSEC on your laptop, while
moving between networks of which some are "friendly" man in the middle
attacks on DNS via hotspots and sign-ons. Some steps are still awaiting
further network-manager integration. We hope to be able to hide almost
everything from the user, but the network manager integration is not yet
complete. But we would really like get more feedback on how well it
works in various alien and broken networks out there (especially wifi
and 3G/LTE)

First, to get some feedback on whether or not you are using DNSSEC and a
site is protected by DNSSEC, you should install the Firefox
plugin that show DNSSEC information in the address bar:

Next, install dnssec-trigger (currently only in rawhide) but you can
grab a source rpm from here:

Either reboot or start some services manually:

sudo systemctl start unbound-keygen.service
sudo systemctl start unbound.service
sudo systemctl start dnssec-triggerd-keygen.service
sudo systemctl start dnssec-triggerd.service

Then start the dnssec-trigger-applet from the Applications menu. A
(trust) anchor applet icon will now appear.

Now reconnect to your network so that NetworkManager receives DNS
servers via DHCP.

Browse to  with firefox

If everything went well, you should see the green lock on the left
meaning that DNSSEC was used and proved that the DNS lookup for was DNSSEC signed and used. There are other domains
you can use to test, perhaps most importantly at this point,
You can also run a manual test (dig +dnssec and test
if the "ad" flag was set in the dig output.

If your icon is orange, it means your DHCP supplied DNS servers did not
perform DNSSEC. This should never happen in this setup, but would happen
if you only installed the firefox plugin and did not install and start
the unbound/dnssec-triggerd services.

When joining a new network,  right-click the anchor and select
"re-probe". After a few seconds you can get some debug output by
right-clicking and selecting "show results".

What this does:

1) Perform various probes to see if the DHCP supplied DNS servers and
the network are DNSSEC capable. If so, reconfigure the system to use
these. We do not want applications to query these directly, as we do not
trust oursourcing DNSSEC validation to anyone but our own locally
running DNS server (unbound) as the connection between you and the ISP
DNS servers is not trusted, and attackers could rewrite DNS answers
unless your laptop itself confirms this with validation (it comes with
the DNS ROOT key preinstalled)

2) If these servers are broken, it will attempt to query authoritative
servers directly, bypassing the caching DNS servers from the ISP. We do
not do this per default because we do not want to destroy the internet's
DNS caching hierarchy.

3) If using authoritative servers directly fails (eg there is a bad
transparent port 53 proxy or firewall rule forcing use of the DHCP
offered (broken) DNS servers, there is an option to attempt DNS over TLS
and raw DNS over port 80. This is a method of last resort and works
surprisingly well (though slow). This is currently not yet enabled but
you can enable it manually in /etc/dnssec-trigger.conf. Once the nice
people of Fedora Hosted have added a few of these servers, we will
enable this fallback option via a package update.

4) if all of this fails, the user is prompted with a choice. Either go
into "cache only mode" where you cannot do any insecure lookups and are
only using the cached DNS answers you already had before you joined this
network, or you can go "insecure" in which case the local DNS server is
pulled aside (so it does not get poisoned with unvalidated results) and
you're all on your own in your very hostile network without DNSSEC (kind
of what you are likely using right now :)  Exponential back-off attempts
run in the background to see if we can go back to a secure mode.

The Hot spot issue

Sometimes, you need to accept some "fake DNS" to get past the hotspot
portal. For this, the anchor also has an option. It will go into
"insecure" mode, and you can authenticate, pay or click "I acecpt your
terms". When you are done, you select "re-probe". (We cannot do this
automatically without risking to break your spoofed login portal page).
We are working on giving networkmanager a way to detect hotspots for you.

VPN and split DNS

If you connect to a VPN and you need a special DNS server to resolve
internal domains, you need to add an exception to
/etc/unbound/unbound.conf for now. The syntax is:

    name: ""


Planned for the near future:
- Less user interaction, more network manager integration
- automatic hot spot detection
- network manager vpn plugin support for DNS forward-zone
- phasing out the applet in favour of native network-manager support
- validate TLS certificates via DNSSEC (IETF DANE support)

That's it, go break your DNS and let us know how it went!


More information about the devel mailing list