Networking/NameResolution/DNSSEC/UnboundMixedMode

Unbound mixed-mode module

Use the module at your own risk
This page describes experimental and unofficial module for unbound server!

This page describes the purpose, function and usage of experimental unbound mixed-mode module. Please that this module is highly experimental, it is not accepted nor (yet) proposed to the unbound upstream for inclusion. The module is also NOT included in the official unbound Fedora package. Purpose of this wiki is to provide a HOWTO for testers and possible developers/reviewers of the module and overall functionality/concept.

The module is targeted to be included in Fedora 23 unbound package as part of Default Local DNS Resolver, after it is accepted by the upstream. The intention of the module is to solve some particular users use-cases, that are described later on this page. The intention is to provide secure, seamless and user-friendly DNSSEC experience on the client side.

The testing build of unbound server with the mixed-mode module can be found in the COPR repo.

Bug reports
Please report any issues directly to the COPR repo owner Tomas Hozza and not to the unbound upstream NOR to the official Fedora unbound package in Bugzilla.

Motivation

In real world, a client device can connect to local network which DHCP-provided DNS resolvers don't support DNSSEC (e.g. are not able to provide all the necessary information like DNSKEY, RRSIG, etc.). When using dnssec-triggerd, it will probe DHCP-provided resolvers and realize, that these are not usable for use with DNSSEC. This means dnssec-trigger will configure Unbound to use root and authoritative servers (do full recursion) or use fall-back infrastructure listening on HTTP/HTTPS ports, in case the local network firewall blocks outbound DNS queries from client devices.

However there are cases then the user wants to use the DHCP-provided DNS resolvers even if these are NOT DNSSEC-enabled. The most common case like this is when the DHCP-provided DNS resolvers have an internal view of some domain (when using split DNS view).

The local or VPN connection may provide a search domains list, which can be used to forward only DNS Queries for specific domains to the resolvers from the local/VPN connection.

In case the connection does not provide any search domains list there is currently no way to determine which Queries should be forwarded to the local resolvers, without manual configuration.

This is the situation that the mixed-mode module intends to solve.

Function

Disclaimer
Method described below is covered by US patent application named "USING DOMAIN NAME SYSTEM SECURITY EXTENSIONS IN A MIXED-MODE ENVIRONMENT". See Red Hat, Inc. Statement of Position and Our Promise on Software Patents

The purpose of the module is to query another set of DNSSEC-not enabled DNS resolvers for domain names, for which the DNS Answer validation status is INSECURE or INDETERMINATE. The module checks the validation status set by the validator module.

1. Incoming DNS Query (from client or internally generated)
2. The Query is passed to mixed-mode module directly or by previous module
3. mixed-mode module marks the query if it is from client
4. mixed-mode module passes the query to the next module
5. work being done by next modules ...
6. A DNS Answer is passed back to mixed-mode module from the next module
   1. If it is NOT an Answer to Query from a client
      1. mixed-mode module passes the original Answer to the previous module
   2. If it IS an Answer to Query from a client
      1. If the original Answer is SECURE or BOGUS
         1. mixed-mode module passes the original Answer to the previous module
      2. If the original Answer is INSECURE or INDETERMINATE
         1. If the mixed-mode module is NOTconfigured with a set of resolvers
            1. mixed-mode module passes the original Answer to the previous module
         2. If the mixed-mode module IS configured with a set of resolvers
            1. Query preconfigured resolvers once in a row, until got some new Answer from the server
            2. if got NO new Answer
               1. mixed-mode module passes the original Answer to the previous module
            3. If got a new Answer
               1. Flush the original Answer from cache
               2. Do NOT store the new Answer in the cache
               3. Copy the security status from the original Answer
               4. mixed-mode module passes the new Answer to the previous module

Configuration

The configuration may change at any time
The configuration syntax and any configuration options related to the mixed-mode may change in the future!

To be able to use the module, one has to edit the unbound server configuration file /etc/unbound/unbound.conf.

Most importantly add the mixed-mode module into list of modules. The module has to be placed before the validator module. This is due to the fact, that mixed-mode module acts upon the final DNSSEC verification of the DNS Answer.

...
server:
    ...
    module-config: "mixed-mode validator iterator"
    ...

Static configuration

The mixed-mode module can be configured statically in the unbound configuration file /etc/unbound/unbound.conf. This can be done using the mixed-mode-fwd statement, inside the server section. The static configuration will be used after every server star/restart.

The mixed-mode-fwd statement is followed by the IPv4 or IPv6 address of DNSSEC-not-enabled resolver.

mixed-mode-fwd: <IP address>

It is possible to specify IP addresses for multiple resolvers by using multiple mixed-mode-fwd statements.

In the end, a static configuration of unbound server using the mixed-mode module can look like the following example:

...
server:
    ...
    module-config: "mixed-mode validator iterator"
    ...
    mixed-mode-fwd: 192.168.1.1
    mixed-mode-fwd: fd00:dead:beef:55::1
    ...

Dynamic configuration

The mixed-mode module can be configured during unbound runtime using the unbound-control tool. To do this, use the unbound-control with mixed_module_fwds command. The usage is also included in the tool help output:

# unbound-control -h
...
  mixed_mode_fwds [off | addr ...]	without arg show mixed-mode forwarders in use
					or off to turn off mixed-mode and delete forwardrs list
					or give list of ip addresses of forwarders to use
...

Inspecting the current configuration

To inspect the forwarders used by mixed-mode module use the mixed_module_fwds command without any arguments. In case there are some forwarders configured, the list is printed to the console:

# unbound-control mixed_mode_fwds
192.168.1.1 fd00:dead:beef:55::1

In case there are not any forwarders configured the fact is also printed to the console:

# unbound-control mixed_mode_fwds
not using any mixed-mode forwarders

Configuring new set of forwarders

To configure mixed-mode module to use new set of forwarders, use the mixed_module_fwds command followed by the IP addresses of new forwarders:

# unbound-control mixed_mode_fwds 192.168.1.22 192.168.1.33
ok

If you had not configured any forwarders before it is necessary to flush the cache, since there may be some NXDOMAIN records cached. In this situation, the module is not even called and the Query is answered directly from the cache. You can flush the whole cache using:

# unbound-control flush_zone .

Clearing the set of forwarders

To clear the list of forwarders used by the mixed-mode module (and effectively disable the module functionality), use the mixed_module_fwds command followed by the off keyword:

# unbound-control mixed_mode_fwds off
ok

Caching of responses
Currently the module does not store the results of its lookups in any kind of cache. Therefore it is not required to flush the cache after deleting the forwarders.

Usage

The mixed-mode module an be used by it's own for any purpose if the functionality described in Function section can be useful for it.

The main purpose of the mixed-mode module is to be used in conjunction with dnssec-trigger mostly on client devices. In the following section, some model use-cases are listed.

Model use-cases of Unbound + mixed-mode module + dnssec-trigger

On network configuration change the dnssec-trigger is triggered by NetworkManager using the dispatcher and dispatcher script. Now the dnssec-trigger (daemon+script) behavior and the following Unbound configuration should

TBD

FAQ

Feel free to add a question.

Does the use of mixed-mode module lowers the security of DNSSEC?

If mixed-mode is used and configured with set of resolvers, these are used only for INSECURE and INDETERMINATE DNS Answers. This means that all DNS Answers that passed the DNSSEC validation as SECURE or BOGUS will be ignored and passed along as if there was no mixed-mode module. As for the INSECURE and INDETERMINATE Answer, the validator would not be able to determine if someone tempered with the Answer anyway. The situation is the same when querying the set of insecure forwarders without doing the DNSSEC validation. Thus the mixed-mode module should not open any new possibilities to an attacker.

Are the Answers from resolvers queried by mixed-mode module stored in cache?

NO. The mixed-mode module does not store any information in the cache. Although it clears the cached original Answer to the Query, in case it queried the configured insecure forwarders and and got answer for it. Of course this happens only for INSECURE and INDETERMINATE Answers.

TBD