Unbound mixed-mode module
.png){kind=small}
This page describes experimental and unofficial module for unbound server!
This page describes the purpose, function and usage of unbound mixed-mode module. Please note 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 unbound package once it is merged upstream. The module is a prerequisite for Default Local DNS Resolver. The intention of the module is to solve specific real world use-cases (broken local networks, hijacked TLDs, ...), 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 the real world, client devices can connect to networks which DHCP-provided DNS resolvers don't support DNSSEC (e.g. are not able to provide all the necessary information like DNSKEY, RRSIG, etc.) or are doing nasty things like hijacking some non-existing domain. While hijacking non-existing domains is incorrect, it is commonly done (e.g. in Germany with fritz.box ISP, or in companies using corp. TLD).
When using dnssec-trigger, it will probe DHCP-provided resolvers and realize, that these are not usable for DNSSEC validation. 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). Another possible situation is that the DHCP-provided DNS resolver will be usable for DNSSEC, but they are hijacking a non-existing TLD and this would cause the DNSSEC validation to fail.
Although the DHCP-provided DNS resolvers may not support DNSSEC, these may have an internal view of part of DNS domain tree and the user must use them to get to the internal resources. Another use-case with the hijacked domains is e.g. on airports, where one can access some useful information about flights using this hijacked domain.
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.
These are the situations that the mixed-mode module intends to solve.
Function
The purpose of the module is, for queries that fit the criteria, to forward them to another set of DNS resolvers (possibly without DNSSEC support). The criteria for queries to be processed by mixed-mode module may be one of the following (based on the configuration):
- [DONE] DNS Queries, for which the DNS Answer validation status is INSECURE or INDETERMINATE. The module checks the validation status set by the validator module.
- [TO BE DONE] DNS Queries for which the DNS Answer says that the TLD does NOT exist.
- [TO BE DONE] DNS Queries for explicitly white-listed domains (e.g. fritz.box, ...) (NOTE: this is what forward_zones in Unbound already do, so this may not be needed)
The algorithm works in the following fashion (text form):
- Incoming DNS Query (from client or internally generated)
- The Query is passed to mixed-mode module directly or by previous module
- mixed-mode module marks the query if it is from client
- mixed-mode module passes the query to the next module
- work being done by next modules ...
- A DNS Answer is passed back to mixed-mode module from the next module
- If the mixed-mode module is NOTconfigured with a set of resolvers
- mixed-mode module passes the original Answer to the previous module
- If it is NOT an Answer to Query from a client
- mixed-mode module passes the original Answer to the previous module
- If it IS an Answer to Query from a client and the mixed-mode module IS configured with a set of resolvers
- If the original Answer is SECURE or BOGUS or INDETERMINATE
- mixed-mode module passes the original Answer to the previous module
- So the original Answer is INSECURE
- Query preconfigured resolvers once in a row, until got some new Answer from the server
- if got NO new Answer
- mixed-mode module passes the original Answer to the previous module
- If got a new Answer
- Flush the original Answer from cache
- Do NOT store the new Answer in the cache
- Copy the security status from the original Answer
- mixed-mode module passes the new Answer to the previous module
- If the original Answer is SECURE or BOGUS or INDETERMINATE
- If the mixed-mode module is NOTconfigured with a set of resolvers
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
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. In the following charter, the usual use-cases are described in more detail:
NOTE by pwouters: This asusmes VPN's are split tunnel VPNs. For VPN's that cover all traffic, DNS should also use the VPN DNS resolvers)
| NO VPN | VPN resolvers with NO DNSSEC | VPN resolvers WITH DNSSEC | |
|---|---|---|---|
| CONNECTION resolvers WITH DNSSEC |
|
|
|
| CONNECTION resolvers with NO DNSSEC |
|
|
|
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