Blob Blame History Raw
diff --git a/dnssec.conf b/dnssec.conf
index 4d9dbfb..bf896d3 100644
--- a/dnssec.conf
+++ b/dnssec.conf
@@ -1,54 +1,115 @@
+# The options configured in this file are supported by dnssec-trigger-script
+# which is called due to various events in related services including
+# dnssec-trigger and NetworkManager. As a result, dnssec-trigger-script,
+# together with the dnssec-trigger daemon, reconfigures a running instance
+# of Unbound, your local validating resolver.
+#
+# Changes in this file are typically applied on the next network change. To
+# make them work immediately, restart the dnssec-trigger service. On many
+# systems this is achieved by the following command:
+#
+#     systemctl restart dnssec-triggerd
+#
+# To achieve a clean state of Unbound, you can just restart the unbound
+# service and dnssec-trigger gets restarted automatically. Note that some
+# other services like VPN clients may have reconfigured unbound at runtime
+# and thus may need to be restarted as well.
+#
+#     systemctl restart unbound
+#
+# In future some of the options may be interpretted by other services as well,
+# so be careful to restart all of them. One such service may be a future
+# version of NetworkManager.
+#
+#     systemctl restart NetworkManager
+#
+
 # validate_connection_provided_zones:
 # -----------------------------------
-# Setts if forward zones added into unbound by dnssec-trigger script
-# will be DNSSEC validated or NOT. Note that this setting is global
-# for all added forward zones..
-# Possible options are:
-#
-# validate_connection_provided_zones=yes - All connection provided zones
-#                                          configured as forward zones into
-#                                          unbound WILL BE DNSSEC validated
-#                                          (NOTE: If connection provided DNS
-#                                          servers are NOT DNSSEC capable, the
-#                                          resolving of provided zones will
-#                                          NOT work!)
-#
-# validate_connection_provided_zones=no - All connection provided zones
-#                                         configured as forward zones into
-#                                         unbound will NOT be DNSSEC validated
-#
-#
-# NOTICE: if you turn the validation OFF then all forward zones added by
-# dnssec-trigger script will NOT be DNSSEC validated. If you turn the
-# validation ON, only newly added forward zones will be DNSSEC validated.
-# Forward zones added before the change will still NOT be DNSSEC validated.
-# To force validation of previously added forward zone you need to restart
-# it. For VPNs this can be done by restart NetworkManager.
+# Ensures that foward zones provided by NetworkManager connections will be
+# validated by Unbound.
+#
+# Security notes:
+#
+#  - If this option is turned off, the network you're connecting to
+#    can provide you a list of spoofed domains e.g. via DHCP. Those domains
+#    are then configured as insecure forward zones in your local validating
+#    resolver, constituting a downgrade attack on DNSSEC validation.
+#
+#  - See also security notes on the `add_wifi_provided_zones` option.
+#
+# validate_connection_provided_zones=yes
+#
+#  - Connection provided zones will be configured in Unbound as secure forward
+#    zones, validated using DNSSEC.
+#
+#    If the DNS servers for such a connection are not capable of forwarding
+#    DNSSEC queries and responses or the local zone is required to be signed
+#    according to the global DNSSEC database, local resources will not be
+#    resolved correctly and will appear inaccessible.
+#
+#    Many networks use fake top level domains which fail DNSSEC validation
+#    as there is no way to validate them at all. Do not use this strict
+#    option if you want to access resources on such networks.
+#
+# validate_connection_provided_zones=no
+#
+#  - Connection provided zones will be configured in Unbound as insecure
+#    forward zones, not validated using DNSSEC. This allows you to access
+#    local resources on networks with non-compliant DNS servers as well
+#    as networks that hijack domains that are either not in the global DNS
+#    tree at all or are required to be signed.
+#
+#    Turning this option off has security implications, See the security
+#    notice above.
+#
 validate_connection_provided_zones=yes
 
 # add_wifi_provided_zones:
 # ------------------------
-# Setts if domains provided by WiFi connection are configured as forward zones
-# into unbound.
-# Possible options are:
-#
-# add_wifi_provided_zones=yes - Domains provided by ANY WiFi connection will
-#                               be configured as forward zones into unbound.
-#                               (NOTE: See the possible security implications
-#                               stated below!)
-#
-# add_wifi_provided_zones=no - Domains provided by ANY WiFi connection will
-#                              NOT be configured as forward zones into unbound.
-#                              (NOTE: Forward zones will be still configured
-#                              for any other type of connection!)
-#
-# NOTICE: Turning ON the addition of WiFi provided domains as forward zones
-# into unbound may have SECURITY implications such as:
-# - A WiFi access point can intentionally provide you a domain via DHCP for
-#   which it does not have authority and route all your DNS queries to its
-#   DNS servers.
-# - In addition to the previous point, if you have the DNSSEC validation
-#   of forward zones turned OFF, the WiFi provided DNS servers can spoof
-#   the IP address for domain names from the provided domain WITHOUT YOU
-#   KNOWING IT! 
+# Ensures that wifi provided zones are accepted by dnssec-trigger-script just
+# as any other connection provided zones. Wireless ethernet is special in
+# that you often connect to network with no authentication or authentication
+# based on a shared secret.
+#
+# Security notes:
+#
+#  - Anyone knowing such a shared secret can set up an access point for the
+#    network and provide you a spoofed domain list via DHCP. When this option
+#    is turned on, the spoofed domains are configured as forward zones in your
+#    local validating resolver.
+#
+#  - See also security notes on the `validate_connection_provided_zones` option.
+#
+# add_wifi_provided_zones=yes
+#
+#  - Domains provided by WiFi connections will be configured as forward zones
+#    in your local validating resolver. See the security notice above.
+#
+# add_wifi_provided_zones=no
+#
+#  - Domains provided by WiFi connection will be ignored.
+#
 add_wifi_provided_zones=no
+
+# set_search_domains:
+# -------------------
+# Enable or disable writing of search domains to `/etc/resolv.conf`.
+#
+# set_search_domains=yes - Search domains are written to `/etc/resolv.conf`.
+#
+# set_search_domains=no - Search domains are not written to `/etc/resolv.conf`.
+#
+set_search_domains=no
+
+# use_private_address_ranges:
+# ---------------------------
+# Enable or disable adding reverse name resolution zones derived from
+# private IP addresses as defined in RFC 1918 and RFC 4193.
+#
+# use_private_address_ranges=yes - Use standard private IP address ranges to build
+#                                  reverse name resolution zones using the global
+#                                  forwarders.
+#
+# use_private_address_ranges=no - Ignore standard IP address ranges.
+use_private_address_ranges=yes