Hi, 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 nic.cz Firefox plugin that show DNSSEC information in the address bar: http://www.dnssec-validator.cz/ Next, install dnssec-trigger (currently only in rawhide) but you can grab a source rpm from here: http://koji.fedoraproject.org/koji/taskinfo?taskID=3767834 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 http://fedoraproject.org/ 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 fedopraproject.org was DNSSEC signed and used. There are other domains you can use to test, perhaps most importantly at this point, paypal.com. You can also run a manual test (dig +dnssec fedoraproject.org) 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: forward-zone: name: "example.com" forward-addr: 10.1.2.3 Future 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! Paul -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
