Dnsmasq+Unbound observations in 25.1.7

[Monviech (Cedrik)]

I don't know, you have to figure this one out.

[Drinyth]

4. They get the domain that is defined in /var/etc/dnsmasq-hosts, and if you leave it empty they register the one of the dhcp-range instead.

Just wanted to add that in the event that you're using that range as a static only range, you cannot add a domain to that range currently.

If a DHCP range has Mode set to "Static" and you try and specify an "End address", it will error out with "Static only accepts a starting address."

And if you try and add a domain to this "Static" range, opnsense will error with "Can only configure a domain when a full range (including end) is specified."

Hence, the only way to current add a domain to a static pool is to explicitly add the domain to every static entry manually.

[Drinyth]

What I meant to ask:  If the dhcp-range is for example 192.168.1.100 - 192.168.1.199, but I have a Host entry for a client at 192.168.1.20 (outside of the dhcp-range), this will work automatically?  Or requires a dedicated static range (and if so, how to create it)?

I'm running in a similar situation with a subnet with some static and some dynamic addresses. In your scenario, you do not need to add a dedicated static range.

From my own experience, if you setup a DHCP range and then set a static host reservation for an IP outside of that range (but still in that same subnet), then the static and dynamic DHCP addressing will work just fine. I haven't found a second, separate "static" range to be necessary for that subnet.

If you're setting up a subnet with only static addresses, then creating a DHCP range with the mode "static" will suffice for this and not require you to add a range (i.e. start and end).

Obviously, for dynamic only DHCP you can just setup the DHCP range and let dnsmasq pull IPs from that available pool.

[Monviech (Cedrik)]

I know about the issue with the domain in static mode, its on my list:

https://github.com/opnsense/core/issues/8707

[OPNenthu]

From my own experience, if you setup a DHCP range and then set a static host reservation for an IP outside of that range (but still in that same subnet), then the static and dynamic DHCP addressing will work just fine. I haven't found a second, separate "static" range to be necessary for that subnet.

Dnsmasq manual seems to be in agreement.  https://dnsmasq.org/docs/dnsmasq-man.html

Good :)

The optional <mode> keyword may be static which tells dnsmasq to enable DHCP for the network specified, but not to dynamically allocate IP addresses: only hosts which have static addresses given via --dhcp-host or from /etc/ethers will be served. A static-only subnet with address all zeros may be used as a "catch-all" address to enable replies to all Information-request packets on a subnet which is provided with stateless DHCPv6, ie --dhcp-range=::,static

[OPNenthu]

✅ External resolution seems to be working now post patch.

I tried these multiple times each
- with DNS cache flushes in between
- with and without upstream resolvers in System->Settings->General
- with and without DoT forwarders in Unbound
- also tried several other domains

No timeouts observed.

⚠️ I'm seeing some messages like "config error is REFUSED (EDE: not ready)" in Dnsmasq log, but doesn't seem to be impacting.

⚠️ Something is still using the System default resolver (1.1.1.1:53) even though Unbound is configured not to use them.  However now the hits to 1.1.1.1 are not happening at the same time as my DNS queries.  They are coming in randomly and with less frequency than before.

You cannot view this attachment.


Sample result with trailing dot ("nslookup opnsense.org."):

Reporting: Unbound DNS

Code Select Expand

2025-05-21 13:26:42    BLACKBOX.home.internal    AAAA    opnsense.org.    Pass    Recursion    NOERROR    72ms    900        
2025-05-21 13:26:41    BLACKBOX.home.internal    A    opnsense.org.h1.home.arpa.    Drop    Local    SERVFAIL    0ms    0         
2025-05-21 13:26:41    BLACKBOX.home.internal    AAAA    opnsense.org.h1.home.arpa.    Drop    Local    SERVFAIL    0ms    0         
2025-05-21 13:26:41    BLACKBOX.home.internal    A    opnsense.org.    Pass    Recursion    NOERROR    72ms    679

Unbound:

Code Select Expand

2025-05-21T13:26:42-04:00    Informational    unbound    [79869:1] reply: 192.168.30.2 opnsense.org. AAAA IN NOERROR 0.071812 0 58   
2025-05-21T13:26:42-04:00    Informational    unbound    [79869:1] query: 192.168.30.2 opnsense.org. AAAA IN   
2025-05-21T13:26:42-04:00    Informational    unbound    [79869:0] reply: 192.168.30.2 opnsense.org. A IN NOERROR 0.072046 0 46   
2025-05-21T13:26:41-04:00    Informational    unbound    [79869:0] query: 192.168.30.2 opnsense.org. A IN   
2025-05-21T13:26:41-04:00    Informational    unbound    [79869:3] reply: 192.168.30.2 opnsense.org.h1.home.arpa. AAAA IN SERVFAIL 0.000773 0 43   
2025-05-21T13:26:41-04:00    Informational    unbound    [79869:3] query: 192.168.30.2 opnsense.org.h1.home.arpa. AAAA IN   
2025-05-21T13:26:41-04:00    Informational    unbound    [79869:2] reply: 192.168.30.2 opnsense.org.h1.home.arpa. A IN SERVFAIL 0.000782 0 43   
2025-05-21T13:26:41-04:00    Informational    unbound    [79869:2] query: 192.168.30.2 opnsense.org.h1.home.arpa. A IN   
2025-05-21T13:26:41-04:00    Informational    unbound    [79869:1] reply: 192.168.30.2 1.30.168.192.in-addr.arpa. PTR IN NXDOMAIN 0.000495 0 43   
2025-05-21T13:26:41-04:00    Informational    unbound    [79869:1] query: 192.168.30.2 1.30.168.192.in-addr.arpa. PTR IN

Dnsmasq:

Code Select Expand

2025-05-21T13:26:41-04:00    Informational    dnsmasq    415 127.0.0.1/8043 query[AAAA] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    414 127.0.0.1/42028 config error is REFUSED (EDE: not ready)   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    414 127.0.0.1/42028 query[AAAA] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    413 127.0.0.1/26379 config error is REFUSED (EDE: not ready)   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    413 127.0.0.1/26379 query[AAAA] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    412 127.0.0.1/15174 config error is REFUSED (EDE: not ready)   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    412 127.0.0.1/15174 query[AAAA] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    411 127.0.0.1/9795 config error is REFUSED (EDE: not ready)   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    411 127.0.0.1/9795 query[AAAA] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    410 127.0.0.1/60288 config error is REFUSED (EDE: not ready)   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    410 127.0.0.1/60288 query[A] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    409 127.0.0.1/23829 config error is REFUSED (EDE: not ready)   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    409 127.0.0.1/23829 query[A] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    408 127.0.0.1/39599 config error is REFUSED (EDE: not ready)   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    408 127.0.0.1/39599 query[A] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    407 127.0.0.1/50627 config error is REFUSED (EDE: not ready)   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    407 127.0.0.1/50627 query[A] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    406 127.0.0.1/35830 config error is REFUSED (EDE: not ready)   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    406 127.0.0.1/35830 query[A] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    405 127.0.0.1/27077 config 192.168.30.1 is NXDOMAIN   
2025-05-21T13:26:41-04:00    Informational    dnsmasq    405 127.0.0.1/27077 query[PTR] 1.30.168.192.in-addr.arpa from 127.0.0.1


Sample result without trailing dot ("nslookup opnsense.org"):

Reporting: Unbound DNS

Code Select Expand

2025-05-21 13:40:59    BLACKBOX.home.internal    A    opnsense.org.    Pass    Recursion    NOERROR    112ms    75        
2025-05-21 13:40:59    BLACKBOX.home.internal    A    opnsense.org.h1.home.arpa.    Drop    Local    SERVFAIL    0ms    0         
2025-05-21 13:40:59    BLACKBOX.home.internal    AAAA    opnsense.org.    Pass    Recursion    NOERROR    65ms    900        
2025-05-21 13:40:59    BLACKBOX.home.internal    AAAA    opnsense.org.h1.home.arpa.    Drop    Local    SERVFAIL    0ms    0

Unbound:

Code Select Expand

2025-05-21T13:40:59-04:00    Informational    unbound    [75768:3] reply: 192.168.30.2 opnsense.org. AAAA IN NOERROR 0.064924 0 58   
2025-05-21T13:40:59-04:00    Informational    unbound    [75768:3] query: 192.168.30.2 opnsense.org. AAAA IN   
2025-05-21T13:40:59-04:00    Informational    unbound    [75768:2] reply: 192.168.30.2 opnsense.org. A IN NOERROR 0.111528 0 46   
2025-05-21T13:40:59-04:00    Informational    unbound    [75768:2] query: 192.168.30.2 opnsense.org. A IN   
2025-05-21T13:40:59-04:00    Informational    unbound    [75768:1] reply: 192.168.30.2 opnsense.org.h1.home.arpa. AAAA IN SERVFAIL 0.000854 0 43   
2025-05-21T13:40:59-04:00    Informational    unbound    [75768:1] query: 192.168.30.2 opnsense.org.h1.home.arpa. AAAA IN   
2025-05-21T13:40:59-04:00    Informational    unbound    [75768:0] reply: 192.168.30.2 opnsense.org.h1.home.arpa. A IN SERVFAIL 0.000803 0 43   
2025-05-21T13:40:59-04:00    Informational    unbound    [75768:0] query: 192.168.30.2 opnsense.org.h1.home.arpa. A IN   
2025-05-21T13:40:59-04:00    Informational    unbound    [75768:3] reply: 192.168.30.2 1.30.168.192.in-addr.arpa. PTR IN NXDOMAIN 0.000563 0 43   
2025-05-21T13:40:59-04:00    Informational    unbound    [75768:3] query: 192.168.30.2 1.30.168.192.in-addr.arpa. PTR IN

Dnsmasq:

Code Select Expand

2025-05-21T13:40:59-04:00    Informational    dnsmasq    499 127.0.0.1/18297 config error is REFUSED (EDE: not ready)   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    499 127.0.0.1/18297 query[AAAA] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    498 127.0.0.1/48481 config error is REFUSED (EDE: not ready)   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    498 127.0.0.1/48481 query[AAAA] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    497 127.0.0.1/50630 config error is REFUSED (EDE: not ready)   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    497 127.0.0.1/50630 query[AAAA] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    496 127.0.0.1/21817 config error is REFUSED (EDE: not ready)   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    496 127.0.0.1/21817 query[AAAA] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    495 127.0.0.1/40146 config error is REFUSED (EDE: not ready)   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    495 127.0.0.1/40146 query[AAAA] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    494 127.0.0.1/46551 config error is REFUSED (EDE: not ready)   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    494 127.0.0.1/46551 query[A] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    493 127.0.0.1/46189 config error is REFUSED (EDE: not ready)   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    493 127.0.0.1/46189 query[A] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    492 127.0.0.1/55548 config error is REFUSED (EDE: not ready)   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    492 127.0.0.1/55548 query[A] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    491 127.0.0.1/40791 config error is REFUSED (EDE: not ready)   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    491 127.0.0.1/40791 query[A] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    490 127.0.0.1/15519 config error is REFUSED (EDE: not ready)   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    490 127.0.0.1/15519 query[A] opnsense.org.h1.home.arpa from 127.0.0.1   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    489 127.0.0.1/13196 config 192.168.30.1 is NXDOMAIN   
2025-05-21T13:40:59-04:00    Informational    dnsmasq    489 127.0.0.1/13196 query[PTR] 1.30.168.192.in-addr.arpa from 127.0.0.1


Internal resolution tests next up....

[OPNenthu]

P.S. I'm fairly confident the hits to 1.1.1.1:53 are from the firewall itself, because I block DNS requests from clients that are not destined to the firewall.  Also, I redirect port 53 from sources other than the firewall to Unbound (except for the VPN and GUEST networks, but those are presently vacant / no clients).

[meyergru]

I just applied the patch, too. For normal operations, the unencrypted DNS requests to the configured system name servers have disappeared for the most part.

This seems to insinuate that requests where done for external names with an appended local domain first or in parallel and it was DNSmasq mostly who created that DNS leaking, because a request for "www.google.com.internal" could not be resolved and was being requested upstream.

The patch addresses this situation by keeping DNSmasq from ever asking upstream if so instructed via the GUI - as it should be in this configuration.


What I still see is this when I use it from OpnSense itself:

Code Select Expand

# nslookup www.google.com.internal
;; Got SERVFAIL reply from 127.0.0.1, trying next server
Server:         80.81.7.3
Address:        80.81.7.3#53

** server can't find www.google.com.internal: NXDOMAIN

I then see requests for 80.81.7.3:53 leaving the WAN interface. This is not the case

Obviously, 80.81.7.3 is one of my configured system nameservers and .internal is one of my internal domains like so:

Code Select Expand

# cat /etc/resolv.conf
domain internal
nameserver 127.0.0.1
nameserver 80.81.7.3
nameserver 80.81.6.17

I interpret that as: First, Unbound is asked. This in turn delegates the request to DNSmasq, which cannot resolve it. That delivers a SERVFAIL, leading to going to the next server in the list, which eventually delivers an NXDOMAIN.

So, the leak from OpnSense might be caused by SERVFAIL instead of NXDOMAIN answers by Unbound when it does not get an answer from DNSmasq.

Calling DNSmasq directly for "www.google.com.internal" gets me:

Code Select Expand

# nslookup
> set port=53053
> server 127.0.0.1
Default server: 127.0.0.1
Address: 127.0.0.1#53053
> www.google.com.internal
Server:         127.0.0.1
Address:        127.0.0.1#53053

** server can't find www.google.com.internal: REFUSED

So, apparently, DNSmasq delivers REFUSED instead of NXDOMAIN, and this makes Unbound return SERVFAIL. Strangely, it does this even on requests it can answer:

Code Select Expand

# nslookup
> set port=53053
> server 127.0.0.1
Default server: 127.0.0.1
Address: 127.0.0.1#53053
> machine1.internal
Server:         127.0.0.1
Address:        127.0.0.1#53053

Name: machine1.internal
Address: 192.168.7.7
** server can't find machine1.internal: REFUSED

But that makes Unbound just answer correctly, this time returning only the correct address.


Very confusing...


P.S.: When I re-enable upstream servers in DNSmasq, non-existent local entries are met with NXDOMAIN, as expected.

P.P.S.: Enumerating the host names including their domain part in addn=/var/etc/dnsmasq-hosts is apparently not enough to make DNSmasq think it has authority for a domain. What you need on top are directives like "local=/internal/". This stops DNSmasq from wanting to ask upstream servers for such domains, which is forbidden by "no-resolv" and thus causing REFUSED answers.
BTW: no-resolv is still needed, otherwise there could be upstream DNS traffic (aka leaks). Also, you must effectively list all local domains that you forwarded from Unbound explicitely, there is no means for a wildcard match in DNSmasq.

[OPNenthu]

Hi @Monviech, with regard to DHCP and internal DNS names, I'm only seeing a couple of issues as of now.  I think at least one of them might be already addressed by recent commits in master, but I'm not certain.

For reference here is the content of /var/etc/dnsmasq-hosts:

Code Select Expand

192.168.1.6     sw1.h1.home.arpa sw1
192.168.1.11    ap1.h1.home.arpa ap1
192.168.1.16    unifi.h1.home.arpa unifi
192.168.1.17    tinybox.h1.home.arpa tinybox
192.168.30.2    BLACKBOX.home.internal BLACKBOX
192.168.30.8    omv.home.internal omv
192.168.40.2    hp6088aa.iot.internal hp6088aa
192.168.40.3    chromecast-br.iot.internal chromecast-br
192.168.40.4    chromecast-lr.iot.internal chromecast-lr
192.168.60.2    pve.lab.internal pve

All of these IPs are outside of the configured DHCP ranges for their respective networks.  The Host overrides in the GUI all specify the MAC address in addition to the IP and domain and I do see those listed in dnsmasq.conf.

Observation 1: Clients with Host override are being offered default domain rather than the one specified in Hosts

Below is a packet capture of the DHCP offer to the "omv" client on bootup.

Option 15 (domain-name) is coming as "h1.home.arpa" which is the default domain.  I was expecting this to be set as "home.internal" as per the Host override.

Code Select Expand

ethertype IPv4 (0x0800), length 359: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 345)
    192.168.30.1.67 > 192.168.30.8.68: [udp sum ok] BOOTP/DHCP, Reply, length 317, xid 0x5ad804a4, secs 1, Flags [none] (0x0000)
      Your-IP 192.168.30.8
      Server-IP 192.168.30.1
      Client-Ethernet-Address xx:xx:xx:xx:xx:xx  (*redacted)
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message (53), length 1: Offer
        Server-ID (54), length 4: 192.168.30.1
        Lease-Time (51), length 4: 86400
        RN (58), length 4: 43200
        RB (59), length 4: 75600
        Subnet-Mask (1), length 4: 255.255.255.0
        BR (28), length 4: 192.168.30.255
        Default-Gateway (3), length 4: 192.168.30.1
        Domain-Name (15), length 12: "h1.home.arpa"
        Hostname (12), length 3: "omv"
        Domain-Name-Server (6), length 4: 192.168.30.1
        NTP (42), length 4: 192.168.30.1


Observation 2: Inconsistent results for internal lookups on plain names

To be clear, I don't expect any of these to return an IP because I am using the "DHCP fqdn" option so the plain names should not be registered.  In some cases though, it answers with an IP anyway.  In all cases there is an error, but it's inconsistent: sometimes SERVFAIL, sometimes NXDOMAIN.

The requesting host (tinybox) in these examples is a Linux box, to remove any doubt about the Windows-specific domain suffix issue discussed earlier.

tinybox itself is in the default domain: h1.home.arpa.

Code Select Expand

tinybox:~ $ nslookup blackbox
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   blackbox.h1.home.arpa
Address: 192.168.30.2
;; Got SERVFAIL reply from 192.168.1.1, trying next server
;; Got SERVFAIL reply from 2601:xx:xxxx:xxxx:xxxx:xxxx:xxxx:39a0
** server can't find blackbox.h1.home.arpa: SERVFAIL


Code Select Expand

tinybox:~ $ nslookup NUC7PJYH
;; Got SERVFAIL reply from 192.168.1.1, trying next server
;; Got SERVFAIL reply from 2601:xx:xxx:xxx:xxx:xxx:xxxx:39a0
Server:         2601:xx:xxxx:xxxx:xxxx:xxxx:xxxx:39a0
Address:        2601:xx:xxxx:xxxx:xxxx:xxxx:xxxx:39a0#53

** server can't find NUC7PJYH.h1.home.arpa: SERVFAIL

The difference here is that NUC7PJYH is taking its IP from the DHCP pool, whereas the previous client (BLACKBOX) has a Host override.

NUC7PJYH is part of the 'home.internal' network/pool and does receive the correct domain-name in DHCP offer.

Code Select Expand

tinybox:~ $ dig blackbox

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> blackbox
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33096
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;blackbox.                      IN      A

;; AUTHORITY SECTION:
.                       3600    IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2025052201 1800 900 604800 86400

;; Query time: 48 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Thu May 22 16:29:25 EDT 2025
;; MSG SIZE  rcvd: 112


Code Select Expand

tinybox:~ $ dig NUC7PJYH

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> NUC7PJYH
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15776
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;NUC7PJYH.                      IN      A

;; AUTHORITY SECTION:
.                       2625    IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2025052201 1800 900 604800 86400

;; Query time: 91 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Thu May 22 15:30:12 EDT 2025
;; MSG SIZE  rcvd: 112

'dig' returns NXDOMAIN rather than SERVFAIL for the same lookups.

This is just to highlight the difference.  I think 'NXDOMAIN' is the correct/expected response for plain names when "DHCP fqdn" is used (?)


----

In all of these cases, I do get a correct IP resolution when querying with the fully-qualified name.  It's just that 'nslookup' always gives SERVFAIL.

Code Select Expand

tinybox:~ $ nslookup pve.lab.internal
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   pve.lab.internal
Address: 192.168.60.2
;; Got SERVFAIL reply from 192.168.1.1, trying next server
;; Got SERVFAIL reply from 2601:xx:xxxx:xxxx:xxxx:xxxx:xxxx:39a0
** server can't find pve.lab.internal: SERVFAIL


Code Select Expand

tinybox:~ $ dig pve.lab.internal

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> pve.lab.internal
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43767
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;pve.lab.internal.              IN      A

;; ANSWER SECTION:
pve.lab.internal.       1       IN      A       192.168.60.2

;; Query time: 3 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Thu May 22 16:43:20 EDT 2025
;; MSG SIZE  rcvd: 61


[OPNenthu]

Querying from Windows, it's a different story.  This is from my laptop which is a DHCP client (dynamic pool IP) in the 'home.internal' range (192.168.30.100-199).

Code Select Expand

C:\>nslookup blackbox
Server:  UnKnown
Address:  192.168.30.1

Non-authoritative answer:
Name:    blackbox.home.internal
Address:  192.168.30.2


Code Select Expand

C:\>nslookup omv
Server:  UnKnown
Address:  192.168.30.1

Non-authoritative answer:
Name:    omv.home.internal
Address:  192.168.30.8


Code Select Expand

C:\>nslookup pve
Server:  UnKnown
Address:  192.168.30.1

*** UnKnown can't find pve: Server failed


Code Select Expand

C:\>nslookup pve.lab.internal
Server:  UnKnown
Address:  192.168.30.1

Non-authoritative answer:
Name:    pve.lab.internal
Address:  192.168.60.2

In this case I'm getting correct resolutions, even by plain name, without error.

The only one that fails is the lookup on "pve" which is a host with a static IP (set on the host itself), but still present in the Dnsmasq Hosts table.

I'll repeat this test once with DNS caches cleared on the laptop, just to be sure.

---

UPDATE: After clearing the Windows cache (ipconfig /flushdns), the short names failed to resolve for hosts on the other networks.  Short name resolution still works for hosts on the same network.

[Monviech (Cedrik)]

You can additionally try out:

Code Select Expand

opnsense-patch https://github.com/opnsense/core/commit/3b8e4a6ab6f74c24eca3b34d8ae0370a4ce494b8

It should prevent SERVFAIL if an entry is known by dnsmasq because it will be authoritative for the local domain.

---------

Regarding short name lookups, thats something you could only solve cleanly if you use dnsmasq as your primary resolver, because then you don't need hacky solutions like using option 119 to append multiple search domains in each dhcp-range to spam the dns server until something responds.

Right now it works from the same range as the client, because option 15 is sent which is used as single suffix.

---------

Regarding host overrides, here the expectations are wrong.

- A host overwrite will be written into the dnsmasq-hosts file.
- When you resolve it, the exact result from the dnsmasq-hosts file will be returned
- Dnsmasq will still try to register it in either the default domain, or the domain in the dhcp-range when the client gets a DHCP lease
- This makes Dnsmasq send the option 15 with either the default domain, or the dhcp-range domain

-> The domain in the dnsmasq-hosts file does not influence the DHCP domain

[meyergru]

Yes, the patch will cure most of the DNS leaks that are caused by Windows clients asking for "www.google.com.internal", which gets delegated to DNSmasq, which is then asking the configured system name servers when it does not find a local name for it.

I say "most", because it creates "local" directives for all domains from the DHCP ranges, which may or may not be sufficient or consistent with the domains search that are being appended to DNS requests.

[OPNenthu]

It should prevent SERVFAIL if an entry is known by dnsmasq because it will be authoritative for the local domain.

Yes, that patch works on my end

Regarding short name lookups, thats something you could only solve cleanly if you use dnsmasq as your primary resolver [...]

BTW if it helps, being a long-time Stubby user, I could contribute a writeup of my setup of it.

I can create a band-aid or manually configured variant, that works for me, as well, but I think normal users should have an option that is supported via the GUI.

My preferred way of solving this would be to make DNSCrypt-Proxy work by removing the validation bug. Matter-of-fact, all that is needed here is a DNS server capable of DNS forwarding and encryption. Unbound with all of its complexity should not even be needed on top of DNSmasq, as others have pointed out. If DNSmasq was capable of encryption, this was not needed at all.

I presume that putting Stubby or DNSCrypt-Proxy in front of Dnsmasq also precludes short name lookups then, so users will have to make a choice here.

I have played with DNSCrypt-Proxy a bit and I like that it supports DNSBLs, but the Unbound reporting dashboard is hard to give up.  Also, I had some issues with DNSCrypt in anonymous relay mode where the relays would silently fail with errors logged, but DNS would continue to work, leading me to believe that it was simply bypassing the relay.

- Dnsmasq will still try to register it in either the default domain, or the domain in the dhcp-range when the client gets a DHCP lease
- This makes Dnsmasq send the option 15 with either the default domain, or the dhcp-range domain

-> The domain in the dnsmasq-hosts file does not influence the DHCP domain

This is the context I was missing, but it is confusing IMO.

It would be clear if DNS and DHCP were completely separate functions in Dnsmasq, but the Host Override does both things AFAIK: it registers in DNS, and it offers the specific IP to the host via DHCP.  Why not also register the domain in DHCP, then?

If not possible, then maybe for dummies like me the UI help text for the "Domain" field in the Host Override dialogue could mention this :)

[OPNenthu]

Yes, the patch will cure most of the DNS leaks that are caused by Windows clients asking for "www.google.com.internal", which gets delegated to DNSmasq, which is then asking the configured system name servers when it does not find a local name for it.

I say "most", because it creates "local" directives for all domains from the DHCP ranges, which may or may not be sufficient or consistent with the domains search that are being appended to DNS requests.

Yes, it looks like there is still a (very) infrequent leak even with the patches.

I set up a pf live log filter with the conditions interface=wan and dst_port=53.  After a couple hours of silence, there were some hits to the system resolvers.  (I had changed it from 1.1.1.1 to the Quad9 servers.)

You cannot view this attachment.

At this time I think the only way to avoid the leak 100% is to remove all system resolvers from System->Settings->General, or put an outbound block on :53.