Project

General

Profile

Actions

Bug #13393

closed

DNS Resolver responds with unexpected source address when the DNS over TLS server function is enabled

Added by Marcos M over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
DNS Resolver
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.01
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

When unbound responds to DNS queries, it will by default respond with a source address that is closest to the request source. The query then fails since the requestor did not expect the answer to come from a different address. For example:

dig +short @192.168.223.1 host.domain.tld
192.168.224.20
dig +short @192.168.224.1 host.domain.tld
;; reply from unexpected source: 192.168.223.1#53, expected 192.168.224.1#53
Actions #1

Updated by Jim Pingle over 1 year ago

  • Status changed from New to Not a Bug
  • Plus Target Version deleted (22.11)

That's a limitation of Unbound when binding to specific interfaces/addresses or when acting as a DNS over TLS server.

We do this when binding to all and DoT is off:

       interface-automatic: <yes or no>
              Listen  on all addresses on all (current and future) interfaces,
              detect the source interface on UDP  queries  and  copy  them  to
              replies.   This  is  a  lot like ip-transparent, but this option
              services all interfaces whilst with ip-transparent you  can  se-
              lect  which  (future)  interfaces  Unbound  provides service on.
              This feature is experimental, and needs support in your  OS  for
              particular socket options.  Default value is no.

It's not compatible with other configurations.

Actions #2

Updated by Marcos M over 1 year ago

The issue is when it's bound to all. When it's bound to specific interfaces, it's not an issue.

https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/840

Actions #3

Updated by Jim Pingle over 1 year ago

Actions #4

Updated by Marcos M over 1 year ago

Indeed it was the DoT option - what's the reason for interface-automatic being dependent on DoT being disabled? When using DoT and adding the option manually, queries work as expected (whereas otherwise they do not).

Actions #5

Updated by Jim Pingle over 1 year ago

Marcos M wrote in #note-4:

Indeed it was the DoT option - what's the reason for interface-automatic being dependent on DoT being disabled? When using DoT and adding the option manually, queries work as expected (whereas otherwise they do not).

It's possible that Unbound fixed it, but ~4 years ago when the DoT service options were added to the GUI (#8030), enabling interface-automatic broke TCP.

With more thorough testing it may be OK to remove that condition, but we'd have to ensure that it doesn't cause other failures. For example if UDP queries work but larger TCP queries fail, that's probably a side effect of this combination of options.

Clients should really be querying the local address for DNS and not addresses on other interfaces anyhow. And if they do insist on doing so, using the usual DNS redirect port forwards can also work around that.

Actions #6

Updated by Jim Pingle over 1 year ago

  • Subject changed from DNS Resolver responds with unexpected source address to DNS Resolver responds with unexpected source address when the DNS over TLS server function is enabled
  • Status changed from Not a Bug to In Progress
  • Target version set to 2.7.0
  • Plus Target Version set to 22.11

I thought I reopened this but apparently not. Based on my last comment, this needs some more testing and confirmation that the behavior has been fixed in Unbound. If it has, then we can remove the condition that prevents using DoT and interface-automatic at the same time.

Actions #7

Updated by Marcos M over 1 year ago

The changelog here indicates it's been fixed:
https://nlnetlabs.nl/projects/unbound/download/

Fix #618: enabling interface-automatic disables DNS-over-TLS. Adds the option to list interface-automatic-ports.

Currently on 22.05 with DoT enabled, this happens:

dig +tcp google.net @10.0.50.1
;; communications error to 10.0.50.1#53: end of file

;; communications error to 10.0.50.1#53: end of file

This no longer happens on 22.11. It seems to have been solved by:

Fix that TCP interface does not use TLS when TLS is also configured

There is a new issue on 22.11. interface-automatic is now needed even when specific interfaces are selected in Network Interfaces in order to query interface addresses outside of the client's subnet.

Actions #8

Updated by Marcos M over 1 year ago

  • Status changed from In Progress to Pull Request Review
Actions #9

Updated by Marcos M over 1 year ago

  • Status changed from Pull Request Review to Feedback
  • % Done changed from 0 to 100
Actions #10

Updated by Jim Pingle over 1 year ago

  • Plus Target Version changed from 22.11 to 23.01
Actions #11

Updated by Chris Linstruth over 1 year ago

When I select LAN+Localhost in Network Interfaces I get this:

unbound     unbound     74675     7     udp4     *:53     *:*
unbound     unbound     74675     8     tcp4     *:53     *:*
# Interface IP(s) to bind to
interface-automatic: yes
interface: 172.25.236.2
interface: 2001:470:e01a:7e01::2
interface: 127.0.0.1
interface: ::1

I figure that might be a by-product of multiple binds, just like listening to IPv4 and IPv6 with OpenVPN.

Further testing shows it listens on *:53 even if only one interface is selected.

Actions #12

Updated by Marcos M over 1 year ago

  • Status changed from Feedback to Ready To Test
Testing this again on 23.01 gives the following results:
  • If Network Interfaces is set to all, unbound will respond from the wrong address unless interface-automatic: yes is set.
  • If Network Interfaces is set to specific interfaces, unbound will respond from the correct address regardless of interface-automatic (tested set/unset and yes/no).
  • If interface-automatic: yes is set, unbound will listen on all (e.g. *:53) regardless of the interface (aka Network Interfaces) option.

The following patch addresses this behavior and always respects the Network Interfaces option:

diff --git a/src/etc/inc/unbound.inc b/src/etc/inc/unbound.inc
index 2da497cd12..bbaa7aa332 100644
--- a/src/etc/inc/unbound.inc
+++ b/src/etc/inc/unbound.inc
@@ -257,15 +257,14 @@ EOF;
     // Determine interfaces where unbound will bind
     $port = (is_port($unboundcfg['port'])) ? $unboundcfg['port'] : "53";
     $tlsport = is_port($unboundcfg['tlsport']) ? $unboundcfg['tlsport'] : "853";
-    $bindintcfg = "interface-automatic: yes" . PHP_EOL;
-    if (isset($unboundcfg['enablessl'])) {
-        $bindintcfg .= sprintf('interface-automatic-ports: "%1$s %2$s"%3$s', $port, $tlsport, PHP_EOL);
-    }
+    $bindintcfg = "";
     $bindints = array();
     $active_interfaces = explode(",", $unboundcfg['active_interface']);
     if (empty($unboundcfg['active_interface']) || in_array("all", $active_interfaces, true)) {
-        $bindints[] = "0.0.0.0";
-        $bindints[] = "::0";
+        $bindintcfg = "interface-automatic: yes" . PHP_EOL;
+        if (isset($unboundcfg['enablessl'])) {
+            $bindintcfg .= sprintf('interface-automatic-ports: "%1$s %2$s"%3$s', $port, $tlsport, PHP_EOL);
+        }
     } else {
         foreach ($active_interfaces as $ubif) {
             /* Do not bind to disabled/nocarrier interfaces,
@@ -533,7 +532,7 @@ aggressive-nsec: {$aggressivensec}
 {$statistics}
 # TLS Configuration
 {$tlsconfig}
-# Interface IP(s) to bind to
+# Interface IP addresses to bind to
 {$bindintcfg}
 {$outgoingints}
 # DNS Rebinding

Actions #13

Updated by Chris Linstruth over 1 year ago

This looks good now.

Actions #14

Updated by Marcos M over 1 year ago

  • Status changed from Ready To Test to Pull Request Review
Actions #15

Updated by Marcos M over 1 year ago

  • Status changed from Pull Request Review to Feedback
Actions #16

Updated by Marcos M over 1 year ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF