From Fedora Project Wiki
No edit summary
 
(6 intermediate revisions by 2 users not shown)
Line 2: Line 2:
{{admon/caution|Use the module at your own risk|This page describes '''experimental''' and unofficial module for unbound server!}}
{{admon/caution|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.
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 23 unbound package as part of [[Changes/Default_Local_DNS_Resolver|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 module is targeted to be included in Fedora unbound package once it is merged upstream. The module is a prerequisite for [[Changes/Default_Local_DNS_Resolver|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.  




Line 11: Line 11:


== Motivation ==
== 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.
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).


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).
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.


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.
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.


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.
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.
These are the situations that the '''mixed-mode module''' intends to solve.


== Function ==
== Function ==
{{admon/note|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. [http://www.redhat.com/legal/patent_policy.html Statement of Position and Our Promise on Software Patents]}}
<!--'''There are some basic assumptions for the solution to work:'''
<!--'''There are some basic assumptions for the solution to work:'''
* If the machine is connected to multiple networks, the network management software always determines only single one as the default connection.
* If the machine is connected to multiple networks, the network management software always determines only single one as the default connection.
Line 31: Line 29:
** There is existing external (to the local network) public infrastructure of DNS resolvers running on HTTP/HTTPS ports-->
** There is existing external (to the local network) public infrastructure of DNS resolvers running on HTTP/HTTPS ports-->


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.
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)
# Incoming DNS Query (from client or internally generated)
# The Query is passed to '''mixed-mode''' module directly or by ''previous module''
# The Query is passed to '''mixed-mode''' module directly or by ''previous module''
Line 39: Line 42:
# work being done by ''next modules'' ...
# work being done by ''next modules'' ...
# A DNS Answer is passed back to '''mixed-mode''' module from the ''next module''
# A DNS Answer is passed back to '''mixed-mode''' module from the ''next module''
## If the '''mixed-mode''' module is '''NOT'''configured 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
## If it is '''NOT''' an Answer to Query from a client
### '''mixed-mode''' module passes the ''original Answer'' to the ''previous module''
### '''mixed-mode''' module passes the ''original Answer'' to the ''previous module''
## If it '''IS''' an Answer to Query from a client
## 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
### If the ''original Answer'' is SECURE or BOGUS or INDETERMINATE
#### '''mixed-mode''' module passes the ''original Answer'' to the ''previous module''
#### '''mixed-mode''' module passes the ''original Answer'' to the ''previous module''
### If the ''original Answer'' is INSECURE or INDETERMINATE
### So the ''original Answer'' is INSECURE
#### If the '''mixed-mode''' module is '''NOT'''configured with a set of resolvers
#### 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''
##### '''mixed-mode''' module passes the ''original Answer'' to the ''previous module''
#### If the '''mixed-mode''' module '''IS''' configured with a set of resolvers
#### If got a ''new Answer''
##### Query preconfigured resolvers once in a row, until got some ''new Answer'' from the server
##### Flush the ''original Answer from cache''
##### if got '''NO''' ''new Answer''
##### '''Do NOT store the ''new Answer'' in the cache'''
###### '''mixed-mode''' module passes the ''original Answer'' to the ''previous module''
##### Copy the security status from the ''original Answer''
##### If got a ''new Answer''
##### '''mixed-mode''' module passes the '''''new Answer''''' to the ''previous module''
###### Flush the ''original Answer from cache''
 
###### '''Do NOT store the ''new Answer'' in the cache'''
[[File:Mixed-mode-flowchart.png|900px]]
###### Copy the security status from the ''original Answer''
###### '''mixed-mode''' module passes the '''''new Answer''''' to the ''previous module''


== Configuration ==
== Configuration ==
Line 148: Line 152:
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:
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)


{|
{|

Latest revision as of 09:34, 11 February 2016

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 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.

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 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):

  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 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 it is NOT an Answer to Query from a client
      1. mixed-mode module passes the original Answer to the previous module
    3. If it IS an Answer to Query from a client and the mixed-mode module IS configured with a set of resolvers
      1. If the original Answer is SECURE or BOGUS or INDETERMINATE
        1. mixed-mode module passes the original Answer to the previous module
      2. So the original Answer is INSECURE
        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. 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
  • Default forwarders
  1. Use CONNECTION provided DNS resolvers
  • Forward zones
  1. NO forward zones configured
  • mixed-mode module configuration
  1. Turned off
  • Default forwarders
  1. Use CONNECTION provided DNS resolvers
  • Forward zones
  1. Do testing of VPN provided domains
  2. Configure INsecure forward zones for VPN provided search domains
  • mixed-mode module configuration
  1. Use VPN provided DNS resolvers
  • Default forwarders
  1. Use VPN provided DNS resolvers
  • Forward zones
  1. Configure SECURE forward zones for CONNECTION and VPN provided search domains
  2. In case of conflict, VPN provided domain is preferred
  • mixed-mode module configuration
  1. Turned off
CONNECTION resolvers with NO DNSSEC
  • Default forwarders
  1. Use fallback DNS resolvers infrastructure or do full recursion
  • Forward zones
  1. Do testing of CONNECTION provided search domains to determine if they are INSECURE
  2. Configure INsecure forward zones for CONNECTION provided (INSECURE) domains
  • mixed-mode module configuration
  1. Use CONNECTION provided DNS resolvers
  • Default forwarders
  1. Use fallback DNS resolvers infrastructure or do full recursion
  • Forward zones
  1. Do testing of CONNECTION and VPN provided search domains to determine if they are INSECURE
  2. Configure INsecure forward zones for CONNECTION and VPN provided search domains
  3. In case of conflict, VPN provided domain WINS
  • mixed-mode module configuration
  1. Use VPN + CONNECTION provided DNS resolvers in this order
  • Default forwarders
  1. Use VPN provided DNS resolvers
  • Forward zones
  1. Do testing of CONNECTION provided search domains to determine if they are INSECURE
  2. Configure INsecure forward zones for CONNECTION provided search domains
  3. In case of conflict, VPN provided domain WINS
  • mixed-mode module configuration
  1. Turned off

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

Retrieved from "https://fedoraproject.org/w/index.php?title=Networking/NameResolution/DNSSEC/UnboundMixedMode&oldid=433967"