Unbound mixed-mode module
.png){kind=small}
This page describes HIGHLY 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.
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
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
TBD
Configuration
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
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
TBD
FAQ
TBD
Feel free to add a question.