DNSSEC-TRIGGER

How does it work

DNSSEC-Trigger uses unbound which is running on localhost (127.0.0.1) as a validating (caching) local resolver. Often unbound is pointed at another cache, and forwards all queries there (but performs DNSSEC validation itself). There is a dnssec-triggerd daemon running that catches changes in the network, DHCP events, and probes what unbound should do to get DNSSEC.

Probe sequence

The probe sequence uses normal DNSSEC queries, and checks if the answer contains RRSIGs and proper DNSSEC information. The probe:

  1. Check the DHCP provided DNS caches. If they work they have a hot cache, and lessen load on infrastructure, and provide fast answers.
  2. Check authority servers directly. If that works, full resolver mode is used to get DNSSEC.
  3. Check open resolver on TCP port 80(www port). If that works, unbound is told to use (plain) DNS over TCP to port 80 to an open (DNSSEC capable) resolver.
  4. Check open resolver over SSL port 443(https port). If that works, unbound is told to use SSL encapsulated DNS over port 443 to an open (DNSSEC capable) resolver.

The list is tried in order to lessen network load on servers down the list. If no servers work then the user is informed, and can select to disconnect (DNS is blackholed) or connect insecurely (the DHCP provided DNS servers are used). In this case, timer-based reprobes are attempted.

The last SSL-port-443 attempt is because, if https is going to work then traffic over port-443 works on this internet-hotspot. And then SSL encapsulated DNS over SSL-port-443 also works. If something bad happens to that traffic then neither DNSSEC nor https can work.

The dnssec-trigger.conf config file is shipped by default with an open resolver at NLnet Labs that serves port 80 and 443 (it runs unbound). You can disable it or add others if you want.

Hotspot detection

During the probe sequence, also a potential active hotspot is detected. These are those devices that require a user to interact with some webpage before you can enter the network. They are detected by trying to download a known, fixed webpage, and checking if the result is correct. If the result is correct, then the connection to the internet is open and nothing needs to be done. If the result is not correct, a hotspot is likely needed, and the user is prompted if this is the case, a webbrowser is opened to a random web page (this page) which should then show the hotspot-page. Meanwhile, every 10 seconds it retries to enable DNSSEC.

It picks a random server from a number of configured servers, and for IPv4 and IPv6 attempts to access the page. Only one needs to work. It cycles through addresses provided, that it looks up via the cache-DNS (because that may be intercepted by the hotspot).

Commandline test

It is possible to test the software from the commandline. The dnssec-trigger-control utility can be used to test and connect to the daemon.

With dnssec-trigger-control status you can see the probe results from the commandline.

With dnssec-trigger-control reprobe trigger a reprobe (just like the item from the tray icon menu).

With dnssec-trigger-control hotspot_signon go to insecure, forced. Use reprobe when signed on to resume dnssec protection efforts.

With dnssec-trigger-control submit 192.0.2.1 you can pretend that DHCP gave the 192.0.2.1 DNS server IPs (IP4 and IP6 separated by spaces).

With dnssec-trigger-control skip_http you can skip the http hotspot test, it'll assume the network is accessible and continue to set up DNSSEC for you.

With dnssec-trigger-control unsafe you can pretend that DNSSEC does not work. It takes a couple seconds while it probes useless 127.0.0.x IPs. Note that if you press insecure on the dialog an automated reprobe after 10 seconds in the background is likely to enable DNSSEC again and stop the insecure test. You have to be fast to see resolv.conf change to the insecure DNS servers (or the fake ones used in this test).

With dnssec-trigger-control test_tcp you can pretend that DHCP cache and authority direct does not work, and it attempts to use TCP-port-80/443. This requires unbound 1.4.13 or later. The test_ssl command is similar.

With dnssec-trigger-control test_http you can pretend that the http probe fails to fetch the correct contents (as if there is a hotspot).