Hi all,
I followed the section DHCPv4 with DNS registration (https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration) in the guide as closely as I could, so that Unbound is the default resolver for clients and forwards to Dnsmasq for internal domains. For external domains Unbound forwards to Quad9 over TLS (unchanged from my previous setup with ISC).
These are the issues I am seeing so far with the latest update today. If any of this is deemed valid here I can submit scoped issue(s) in GitHub.
For all of these examples, I only have IPv4 configurations in Dnsmasq. Presently I am still using Services->Router Advertisements for IPv6 RAs.
My system default domain in System->Settings->General is "h1.home.arpa" (to distinguish from a remote site "h2.home.arpa"). I am using this domain for my LAN.
For each of the VLANs where clients connect, I defined a respective ".internal" domain in Dnsmasq per the examples in the guide.
DHCP_ranges.png
In Unbound I configured the forwarding as follows:
Unbound_forwarding.png
Unbound is configured on all interfaces ('All (recommended)' in GUI options) at port 53.
Dnsmasq is on all explicit interfaces (LAN, GUEST, etc.) at port 53053 with "Strict Interface Binding" disabled.
root@firewall:~ # sockstat -l | grep :53
unbound unbound 4479 5 udp6 *:53 *:*
unbound unbound 4479 6 tcp6 *:53 *:*
unbound unbound 4479 7 udp4 *:53 *:*
unbound unbound 4479 8 tcp4 *:53 *:*
unbound unbound 4479 9 udp6 *:53 *:*
unbound unbound 4479 10 tcp6 *:53 *:*
unbound unbound 4479 11 udp4 *:53 *:*
unbound unbound 4479 12 tcp4 *:53 *:*
unbound unbound 4479 13 udp6 *:53 *:*
unbound unbound 4479 14 tcp6 *:53 *:*
unbound unbound 4479 15 udp4 *:53 *:*
unbound unbound 4479 16 tcp4 *:53 *:*
unbound unbound 4479 17 udp6 *:53 *:*
unbound unbound 4479 18 tcp6 *:53 *:*
unbound unbound 4479 19 udp4 *:53 *:*
unbound unbound 4479 20 tcp4 *:53 *:*
nobody dnsmasq 19536 13 udp4 *:53053 *:*
nobody dnsmasq 19536 14 tcp4 *:53053 *:*
nobody dnsmasq 19536 15 udp6 *:53053 *:*
nobody dnsmasq 19536 16 tcp6 *:53053 *:*
root mdns-repea 50866 3 udp4 *:5353 *:*
root mdns-repea 50866 4 udp4 192.168.20.1:5353 *:*
root mdns-repea 50866 6 udp4 192.168.30.1:5353 *:*
root mdns-repea 50866 7 udp4 192.168.40.1:5353 *:*
I do not have any system default DNS servers in System->Settings->General and I am not allowing DNS overrides from WAN.
Observation #1: Incorrect DNS options in DHCP offerPer the guide, these DHCP options do not need to be explicitly defined and are defaulted as follows:
Quoterouter[3] -> IPv4 address of the receiving interface
dns-server[6] -> IPv4 address of the receiving interface
domain-search[119] -> Domain set in DHCP range
This is the DHCP offer as captured in Wireshark to my client on the HOME network, which has a static reservation (192.168.30.2):
Dynamic Host Configuration Protocol (Offer)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x20ab4ae0
Seconds elapsed: 0
Bootp flags: 0x8000, Broadcast flag (Broadcast)
Client IP address: 0.0.0.0
Your (client) IP address: 192.168.30.2
Next server IP address: 192.168.30.1
Relay agent IP address: 0.0.0.0
Client MAC address: ASUSTekCOMPU_xx:xx:xx (24:4b:fe:xx:xx:xx) (*redacted)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Offer)
Option: (54) DHCP Server Identifier (192.168.30.1)
Option: (51) IP Address Lease Time
Option: (58) Renewal Time Value
Option: (59) Rebinding Time Value
Option: (1) Subnet Mask (255.255.255.0)
Option: (28) Broadcast Address (192.168.30.255)
Option: (3) Router
Length: 4
Router: 192.168.30.1
Option: (15) Domain Name
Length: 12
Domain Name: h1.home.arpa
Option: (6) Domain Name Server
Length: 4
Domain Name Server: 192.168.30.1
Option: (255) End
- 'router[3]' is correct
- 'dns-server[6]' is correct
- 'domain-seearch[119]' is missing
- 'domain-name[15]' is incorrect (should be 'home.internal')
Observation #2: Frequent DNS timeouts / slow resolutionIt doesn't matter whether the internal host being resolved is static (for example, 'firewall' is in /etc/hosts) or not, the requests are experiencing a lot of timeouts and resolution takes several seconds.
C:\>nslookup firewall
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.30.1
Non-authoritative answer:
Name: firewall.h1.home.arpa
Addresses: 2601:xx:xxxx:xxxx:xxxx:xxxx:xxxx:39a0
192.168.1.1
C:\>nslookup firewall.h1.home.arpa
Server: UnKnown
Address: 192.168.30.1
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
Name: firewall.h1.home.arpa
Addresses: 2601:xx:xxxx:xxxx:xxxx:xxxx:xxxx:39a0
192.168.1.1
The same is happening for external requests, which previously had no issue:
C:\>nslookup opnsense.org
Server: UnKnown
Address: 192.168.30.1
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
Name: opnsense.org
Addresses: 2001:1af8:2050:a001:1::1
89.149.225.137
Observation #3: Intermittent resolution failuresSometimes there is no response, even for statically defined hosts in Dnsmasq:
C:\>nslookup unifi
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.30.1
DNS request timed out.
timeout was 2 seconds.
*** UnKnown can't find unifi: Server failed
Ditto for fully qualified queries:
C:\>nslookup unifi.h1.home.arpa
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.30.1
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out
Hosts.png
Observation #4: Static addresses not registeredMy Proxmox node (pve) has a static IP which I also defined as a static reservation in Dnsmasq for tracking purposes. My UniFi controller (running on Proxmox) is also static on the host and as a static reservation. Neither of these are reflected in the Dnsmasq leases table, although both are running and responding.
A Gitea instance also running on Proxmox, but with a dynamic lease, is shown in the table.
A static reservation for my desktop PC is also shown in the table.
In general, it appears that static reservations are only shown for hosts which receive their IPs from DHCP but are omitted for hosts which have static IPs set on the host itself even if a static entry is present in Dnsmasq.
For issues #2 and #3, do I need to define additional search domains explicitly in DHCP options?
In Unbound enable query request and response logging, in dnsmasq enable the same in advanced general options.
Do nslookups and check what the servers ask each other and what their responses are.
Option 15 is correct for the default fomain suffix. Option 119 is for multiple domain suffixes. So have to adjust that in the docs, I refered to the wrong option.
Here's a lookup on 'opnsense.org' from the client at 192.168.30.2.
Result:
C:\>nslookup opnsense.org
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.30.1
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
Name: opnsense.org
Addresses: 2001:1af8:2050:a001:1::1
89.149.225.137
Unbound side:
2025-05-19T13:53:48-04:00 Informational unbound [5329:3] info: 127.0.0.1 opnsense.org.h1.home.arpa. AAAA IN
2025-05-19T13:53:48-04:00 Informational unbound [5329:3] info: 127.0.0.1 opnsense.org.h1.home.arpa. AAAA IN
2025-05-19T13:53:42-04:00 Informational unbound [5329:3] info: 127.0.0.1 opnsense.org.h1.home.arpa. AAAA IN
2025-05-19T13:53:42-04:00 Informational unbound [5329:3] info: 127.0.0.1 opnsense.org.h1.home.arpa. AAAA IN
2025-05-19T13:53:42-04:00 Informational unbound [5329:0] info: 127.0.0.1 opnsense.org.h1.home.arpa. A IN
2025-05-19T13:53:42-04:00 Informational unbound [5329:0] info: 127.0.0.1 opnsense.org.h1.home.arpa. A IN
2025-05-19T13:53:40-04:00 Informational unbound [5329:2] info: 192.168.30.2 opnsense.org. AAAA IN NOERROR 0.081485 0 58
2025-05-19T13:53:40-04:00 Informational unbound [5329:2] info: 192.168.30.2 opnsense.org. AAAA IN
2025-05-19T13:53:40-04:00 Informational unbound [5329:1] info: 192.168.30.2 opnsense.org. A IN NOERROR 0.321781 0 46
2025-05-19T13:53:40-04:00 Informational unbound [5329:1] info: 192.168.30.2 opnsense.org. A IN
2025-05-19T13:53:40-04:00 Informational unbound [5329:1] info: 127.0.0.1 1.30.168.192.in-addr.arpa. PTR IN
2025-05-19T13:53:40-04:00 Informational unbound [5329:1] info: 127.0.0.1 1.30.168.192.in-addr.arpa. PTR IN
2025-05-19T13:53:39-04:00 Informational unbound [5329:0] info: 127.0.0.1 opnsense.org.h1.home.arpa. A IN
2025-05-19T13:53:39-04:00 Informational unbound [5329:0] info: 127.0.0.1 opnsense.org.h1.home.arpa. A IN
2025-05-19T13:53:38-04:00 Informational unbound [5329:3] info: 127.0.0.1 opnsense.org.h1.home.arpa. AAAA IN
2025-05-19T13:53:38-04:00 Informational unbound [5329:0] info: 192.168.30.2 opnsense.org.h1.home.arpa. AAAA IN
2025-05-19T13:53:37-04:00 Informational unbound [5329:1] info: 127.0.0.1 1.30.168.192.in-addr.arpa. PTR IN
2025-05-19T13:53:37-04:00 Informational unbound [5329:1] info: 127.0.0.1 1.30.168.192.in-addr.arpa. PTR IN
2025-05-19T13:53:36-04:00 Informational unbound [5329:0] info: 127.0.0.1 opnsense.org.h1.home.arpa. A IN
2025-05-19T13:53:36-04:00 Informational unbound [5329:3] info: 192.168.30.2 opnsense.org.h1.home.arpa. A IN
Dnsmasq side:
2025-05-19T13:53:51-04:00 Informational dnsmasq 32 127.0.0.1/17159 DHCP 192.168.40.3 is chromecast-br.h1.home.arpa
2025-05-19T13:53:51-04:00 Informational dnsmasq 32 127.0.0.1/17159 query[PTR] 3.40.168.192.in-addr.arpa from 127.0.0.1
2025-05-19T13:53:51-04:00 Informational dnsmasq 31 127.0.0.1/28211 DHCP 192.168.30.2 is blackbox.h1.home.arpa
2025-05-19T13:53:51-04:00 Informational dnsmasq 31 127.0.0.1/28211 query[PTR] 2.30.168.192.in-addr.arpa from 127.0.0.1
2025-05-19T13:53:48-04:00 Informational dnsmasq 30 127.0.0.1/46952 forwarded opnsense.org.h1.home.arpa to 127.0.0.1
2025-05-19T13:53:48-04:00 Informational dnsmasq 30 127.0.0.1/46952 query[AAAA] opnsense.org.h1.home.arpa from 127.0.0.1
2025-05-19T13:53:48-04:00 Informational dnsmasq 29 127.0.0.1/39373 forwarded opnsense.org.h1.home.arpa to 127.0.0.1
2025-05-19T13:53:48-04:00 Informational dnsmasq 29 127.0.0.1/39373 query[AAAA] opnsense.org.h1.home.arpa from 127.0.0.1
2025-05-19T13:53:42-04:00 Informational dnsmasq 28 127.0.0.1/24915 forwarded opnsense.org.h1.home.arpa to 127.0.0.1
2025-05-19T13:53:42-04:00 Informational dnsmasq 28 127.0.0.1/24915 query[AAAA] opnsense.org.h1.home.arpa from 127.0.0.1
2025-05-19T13:53:42-04:00 Informational dnsmasq 27 127.0.0.1/44700 forwarded opnsense.org.h1.home.arpa to 127.0.0.1
2025-05-19T13:53:42-04:00 Informational dnsmasq 27 127.0.0.1/44700 query[AAAA] opnsense.org.h1.home.arpa from 127.0.0.1
2025-05-19T13:53:42-04:00 Informational dnsmasq 26 127.0.0.1/61536 forwarded opnsense.org.h1.home.arpa to 127.0.0.1
2025-05-19T13:53:42-04:00 Informational dnsmasq 26 127.0.0.1/61536 query[A] opnsense.org.h1.home.arpa from 127.0.0.1
2025-05-19T13:53:42-04:00 Informational dnsmasq 25 127.0.0.1/27840 forwarded opnsense.org.h1.home.arpa to 127.0.0.1
2025-05-19T13:53:42-04:00 Informational dnsmasq 25 127.0.0.1/27840 query[A] opnsense.org.h1.home.arpa from 127.0.0.1
2025-05-19T13:53:40-04:00 Informational dnsmasq 24 127.0.0.1/12293 forwarded 1.30.168.192.in-addr.arpa to 127.0.0.1
2025-05-19T13:53:40-04:00 Informational dnsmasq 24 127.0.0.1/12293 query[PTR] 1.30.168.192.in-addr.arpa from 127.0.0.1
2025-05-19T13:53:40-04:00 Informational dnsmasq 23 127.0.0.1/48131 forwarded 1.30.168.192.in-addr.arpa to 127.0.0.1
2025-05-19T13:53:40-04:00 Informational dnsmasq 23 127.0.0.1/48131 query[PTR] 1.30.168.192.in-addr.arpa from 127.0.0.1
2025-05-19T13:53:39-04:00 Informational dnsmasq 22 127.0.0.1/37728 query[AAAA] opnsense.org.h1.home.arpa from 127.0.0.1
2025-05-19T13:53:39-04:00 Informational dnsmasq 21 127.0.0.1/45135 query[AAAA] opnsense.org.h1.home.arpa from 127.0.0.1
2025-05-19T13:53:39-04:00 Informational dnsmasq 20 127.0.0.1/26717 forwarded opnsense.org.h1.home.arpa to 127.0.0.1
2025-05-19T13:53:39-04:00 Informational dnsmasq 20 127.0.0.1/26717 query[A] opnsense.org.h1.home.arpa from 127.0.0.1
2025-05-19T13:53:39-04:00 Informational dnsmasq 19 127.0.0.1/14309 forwarded opnsense.org.h1.home.arpa to 127.0.0.1
2025-05-19T13:53:39-04:00 Informational dnsmasq 19 127.0.0.1/14309 query[A] opnsense.org.h1.home.arpa from 127.0.0.1
2025-05-19T13:53:38-04:00 Informational dnsmasq 18 127.0.0.1/29080 query[AAAA] opnsense.org.h1.home.arpa from 127.0.0.1
2025-05-19T13:53:38-04:00 Informational dnsmasq 17 127.0.0.1/12969 forwarded opnsense.org.h1.home.arpa to 127.0.0.1
2025-05-19T13:53:38-04:00 Informational dnsmasq 17 127.0.0.1/12969 query[AAAA] opnsense.org.h1.home.arpa from 127.0.0.1
2025-05-19T13:53:37-04:00 Informational dnsmasq 16 127.0.0.1/54709 query[A] opnsense.org.h1.home.arpa from 127.0.0.1
2025-05-19T13:53:37-04:00 Informational dnsmasq 15 127.0.0.1/43769 query[A] opnsense.org.h1.home.arpa from 127.0.0.1
2025-05-19T13:53:37-04:00 Informational dnsmasq 14 127.0.0.1/26508 forwarded 1.30.168.192.in-addr.arpa to 127.0.0.1
2025-05-19T13:53:37-04:00 Informational dnsmasq 14 127.0.0.1/26508 query[PTR] 1.30.168.192.in-addr.arpa from 127.0.0.1
2025-05-19T13:53:37-04:00 Informational dnsmasq 13 127.0.0.1/46047 forwarded 1.30.168.192.in-addr.arpa to 127.0.0.1
2025-05-19T13:53:37-04:00 Informational dnsmasq 13 127.0.0.1/46047 query[PTR] 1.30.168.192.in-addr.arpa from 127.0.0.1
2025-05-19T13:53:36-04:00 Informational dnsmasq 12 127.0.0.1/51277 query[A] opnsense.org.h1.home.arpa from 127.0.0.1
2025-05-19T13:53:36-04:00 Informational dnsmasq 11 127.0.0.1/16835 query[A] opnsense.org.h1.home.arpa from 127.0.0.1
2025-05-19T13:53:36-04:00 Informational dnsmasq 10 127.0.0.1/18449 query[A] opnsense.org.h1.home.arpa from 127.0.0.1
2025-05-19T13:53:36-04:00 Informational dnsmasq 9 127.0.0.1/17611 forwarded opnsense.org.h1.home.arpa to 127.0.0.1
2025-05-19T13:53:36-04:00 Informational dnsmasq 9 127.0.0.1/17611 query[A] opnsense.org.h1.home.arpa from 127.0.0.1
2025-05-19T13:53:35-04:00 Informational dnsmasq 8 127.0.0.1/55149 query[PTR] 1.30.168.192.in-addr.arpa from 127.0.0.1
2025-05-19T13:53:35-04:00 Informational dnsmasq 7 127.0.0.1/52966 query[PTR] 1.30.168.192.in-addr.arpa from 127.0.0.1
2025-05-19T13:53:34-04:00 Informational dnsmasq 6 127.0.0.1/61290 query[PTR] 1.30.168.192.in-addr.arpa from 127.0.0.1
2025-05-19T13:53:34-04:00 Informational dnsmasq 5 127.0.0.1/64544 query[PTR] 1.30.168.192.in-addr.arpa from 127.0.0.1
2025-05-19T13:53:34-04:00 Informational dnsmasq 4 127.0.0.1/4460 query[PTR] 1.30.168.192.in-addr.arpa from 127.0.0.1
2025-05-19T13:53:34-04:00 Informational dnsmasq 3 127.0.0.1/53395 forwarded 1.30.168.192.in-addr.arpa to 127.0.0.1
2025-05-19T13:53:34-04:00 Informational dnsmasq 3 127.0.0.1/53395 query[PTR] 1.30.168.192.in-addr.arpa from 127.0.0.1
2025-05-19T13:51:27-04:00 Informational dnsmasq 2 127.0.0.1/23723 reply error is SERVFAIL
2025-05-19T13:51:27-04:00 Informational dnsmasq 2 127.0.0.1/23723 forwarded omv.h1.home.arpa to 127.0.0.1
Quote from: Monviech (Cedrik) on May 19, 2025, 07:29:56 PMOption 15 is correct for the default fomain suffix. Option 119 is for multiple domain suffixes. So have to adjust that in the docs, I refered to the wrong option.
Shouldn't the default domain in that example be 'home.internal' rather than 'h1.home.arpa' as that is what I defined for the DHCP range? Or is that option referring to the system default domain, regardless of the DHCP range?
Do the subnets each need to have multiple domain suffixes in order to query each other? Or does Dnsmasq handle that?
Apologies, I'm still learning about DNS, but this is a good test case for the presumption that Dnsmasq should be simple to configure relative to ISC/Kea with Unbound :-P
I do not understand why opnsense.org is forwarded to Dnsmasq.
Somehow Unbound thinks its an internal domain first and forwards it to the query forwarding configured for h1.home.arpa. before finally noticing after multiple responses of dnsmasq that its not there and then recursively resolving it.
At first glance it looks like an Unbound issue now. It should recursively resolve fqdns that do not fall into configured query forwarding domains right away, or so is my assumption.
Although it doesn't help with the DNS resolution issue, there is something strange going on with static reservations.
My desktop PC has 2 NICs (one of them is kept disabled). Until now I was using the first NIC with a static reservation in Dnsmasq. In this case, the DNS suffix was always coming as "h1.home.arpa" even though that client is not part of that DHCP range:
Ethernet adapter Ethernet:
Connection-specific DNS Suffix . : h1.home.arpa
Description . . . . . . . . . . . : Intel(R) Ethernet Controller (2) I225-V
Physical Address. . . . . . . . . : 24-xx-xx-xx-xx-CD
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2601:xx:xxxx:xxxx:xxxx:xxxx:xxx:f69(Preferred)
IPv6 Address. . . . . . . . . . . : fdf8:fb25:3a87:1030:xxxx:xxxx:xxxx:3a21(Preferred)
Temporary IPv6 Address. . . . . . : 2601:xx:xxxx:xxxx:9cb5:6288:f91:c4c6(Preferred)
Temporary IPv6 Address. . . . . . : fdf8:fb25:3a87:1030:9cb5:6288:f91:c4c6(Preferred)
Link-local IPv6 Address . . . . . : fe80::52cc:xxxx:xxxx:c813%11(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.30.2(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Monday, May 19, 2025 3:58:47 PM
Lease Expires . . . . . . . . . . : Tuesday, May 20, 2025 3:58:44 PM
Default Gateway . . . . . . . . . : fe80::xxxx:xxxx:xxxx:39a0%11
192.168.30.1
DHCP Server . . . . . . . . . . . : 192.168.30.1
DHCPv6 IAID . . . . . . . . . . . : xxxxxxxxx
DHCPv6 Client DUID. . . . . . . . : 00-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-CD
DNS Servers . . . . . . . . . . . : 192.168.30.1
2601:xx:xxxx:xxxx:xxxx:xxxx:xxxx:39a0
NetBIOS over Tcpip. . . . . . . . : Enabled
Connection-specific DNS Suffix Search List :
h1.home.arpa
Switching over to the second NIC, this time I get a DHCP dynamic lease in the same range (192.168.30.x), but now the DNS suffix comes as "home.internal" (as configured in the pool):
Ethernet adapter Ethernet 2:
Connection-specific DNS Suffix . : home.internal
Description . . . . . . . . . . . : Realtek PCIe 2.5GbE Family Controller
Physical Address. . . . . . . . . : 78-xx-xx-xx-xx-55
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2601:xx:xxxx:xxxx:xxx:xxxx:2631:c6ff(Preferred)
IPv6 Address. . . . . . . . . . . : fdf8:fb25:3a87:1030:xxxx:xxxx:xxxx:e66b(Preferred)
Temporary IPv6 Address. . . . . . : 2601:xx:xxxx:xxxx:1de4:e57c:4ae3:f9dd(Preferred)
Temporary IPv6 Address. . . . . . : fdf8:fb25:3a87:1030:1de4:e57c:4ae3:f9dd(Preferred)
Link-local IPv6 Address . . . . . : fe80::ec8a:xxxx:xxxx:454c%8(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.30.164(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Monday, May 19, 2025 4:02:00 PM
Lease Expires . . . . . . . . . . : Tuesday, May 20, 2025 4:01:59 PM
Default Gateway . . . . . . . . . : fe80::xxxx:xxxx:xxxx:39a0%8
192.168.30.1
DHCP Server . . . . . . . . . . . : 192.168.30.1
DHCPv6 IAID . . . . . . . . . . . : xxxxxxxxx
DHCPv6 Client DUID. . . . . . . . : 00-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-CD
DNS Servers . . . . . . . . . . . : 192.168.30.1
2601:xx:xxxx:xxxx:xxxx:xxxx:xxxx:39a0
NetBIOS over Tcpip. . . . . . . . : Enabled
Connection-specific DNS Suffix Search List :
h1.home.arpa
Why should static leases not get the same DNS suffix as the DHCP range configured?
Quote from: OPNenthu on May 19, 2025, 10:19:06 PMAlthough it doesn't help with the DNS resolution issue, there is something strange going on with static reservations.
My desktop PC has 2 NICs (one of them is kept disabled). Until now I was using the first NIC with a static reservation in Dnsmasq. In this case, the DNS suffix was always coming as "h1.home.arpa" even though that client is not part of that DHCP range:
Ethernet adapter Ethernet:
Connection-specific DNS Suffix . : h1.home.arpa
Description . . . . . . . . . . . : Intel(R) Ethernet Controller (2) I225-V
Physical Address. . . . . . . . . : 24-xx-xx-xx-xx-CD
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2601:xx:xxxx:xxxx:xxxx:xxxx:xxx:f69(Preferred)
IPv6 Address. . . . . . . . . . . : fdf8:fb25:3a87:1030:xxxx:xxxx:xxxx:3a21(Preferred)
Temporary IPv6 Address. . . . . . : 2601:xx:xxxx:xxxx:9cb5:6288:f91:c4c6(Preferred)
Temporary IPv6 Address. . . . . . : fdf8:fb25:3a87:1030:9cb5:6288:f91:c4c6(Preferred)
Link-local IPv6 Address . . . . . : fe80::52cc:xxxx:xxxx:c813%11(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.30.2(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Monday, May 19, 2025 3:58:47 PM
Lease Expires . . . . . . . . . . : Tuesday, May 20, 2025 3:58:44 PM
Default Gateway . . . . . . . . . : fe80::xxxx:xxxx:xxxx:39a0%11
192.168.30.1
DHCP Server . . . . . . . . . . . : 192.168.30.1
DHCPv6 IAID . . . . . . . . . . . : xxxxxxxxx
DHCPv6 Client DUID. . . . . . . . : 00-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-CD
DNS Servers . . . . . . . . . . . : 192.168.30.1
2601:xx:xxxx:xxxx:xxxx:xxxx:xxxx:39a0
NetBIOS over Tcpip. . . . . . . . : Enabled
Connection-specific DNS Suffix Search List :
h1.home.arpa
Switching over to the second NIC, this time I get a DHCP dynamic lease in the same range (192.168.30.x), but now the DNS suffix comes as "home.internal" (as configured in the pool):
Ethernet adapter Ethernet 2:
Connection-specific DNS Suffix . : home.internal
Description . . . . . . . . . . . : Realtek PCIe 2.5GbE Family Controller
Physical Address. . . . . . . . . : 78-xx-xx-xx-xx-55
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2601:xx:xxxx:xxxx:xxx:xxxx:2631:c6ff(Preferred)
IPv6 Address. . . . . . . . . . . : fdf8:fb25:3a87:1030:xxxx:xxxx:xxxx:e66b(Preferred)
Temporary IPv6 Address. . . . . . : 2601:xx:xxxx:xxxx:1de4:e57c:4ae3:f9dd(Preferred)
Temporary IPv6 Address. . . . . . : fdf8:fb25:3a87:1030:1de4:e57c:4ae3:f9dd(Preferred)
Link-local IPv6 Address . . . . . : fe80::ec8a:xxxx:xxxx:454c%8(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.30.164(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Monday, May 19, 2025 4:02:00 PM
Lease Expires . . . . . . . . . . : Tuesday, May 20, 2025 4:01:59 PM
Default Gateway . . . . . . . . . : fe80::xxxx:xxxx:xxxx:39a0%8
192.168.30.1
DHCP Server . . . . . . . . . . . : 192.168.30.1
DHCPv6 IAID . . . . . . . . . . . : xxxxxxxxx
DHCPv6 Client DUID. . . . . . . . : 00-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-CD
DNS Servers . . . . . . . . . . . : 192.168.30.1
2601:xx:xxxx:xxxx:xxxx:xxxx:xxxx:39a0
NetBIOS over Tcpip. . . . . . . . : Enabled
Connection-specific DNS Suffix Search List :
h1.home.arpa
Why should static leases not get the same DNS suffix as the DHCP range configured?
Does the static address sit within a configured DHCP range (set as mode static) in DNSMASQ for that interface? E.g. an additional range for your reservations?
Per the Docs:
"DHCP reservations
A DHCP reservation will always assign the same IPv4 and IPv6 addresses to a client.
For an IPv4 reservation, a DHCPv4 range should exist. If this DHCPv4 range should only serve reservations, set it to static"
For issue #4, Proxmox doesn't use DHCP by default and it is not recommended (see here link (https://forum.proxmox.com/threads/set-a-dynamic-address-to-pve.119847/)). Unless you've changed it manually, it is a fixed address that is set within Proxmox. I also have a static reservation set in DNSmasq for that IP so I don't forget that it is assigned, but since Proxmox isn't using DHCP, you won't see a lease. You'd only see a lease if DHCP handed out the IP address (either a static or dynamic address).
For Unifi, I have my controller set to receive its address via a static DHCP reservation and the lease is showing up correctly.
Quote from: Taunt9930 on May 19, 2025, 10:24:57 PMDoes the static address sit within a configured DHCP range (set as mode static) in DNSMASQ for that interface? E.g. an additional range for your reservations?
Per the Docs:
"DHCP reservations
A DHCP reservation will always assign the same IPv4 and IPv6 addresses to a client.
For an IPv4 reservation, a DHCPv4 range should exist. If this DHCPv4 range should only serve reservations, set it to static"
Interesting. No, I only have the dynamic pool defined (192.168.30.100 - 192.168.30.199).
So I need to create a second pool then, 192.168.30.2 - 192.168.30.99, and set it static?
Will try it out. That's definitely one difference from ISC...
Quote from: julsssark on May 19, 2025, 10:30:08 PM[...] since Proxmox isn't using DHCP, you won't see a lease. You'd only see a lease if DHCP handed out the IP address (either a static or dynamic address).
For Unifi, I have my controller set to receive its address via a static DHCP reservation and the lease is showing up correctly.
My Proxmox management interface is static (192.168.60.2) and I added it in Dnsmasq also, for traceability.
The UniFi controller is also static within Proxmox (192.168.1.16- I'm using a VLAN trunk) and it too is added in Dnsmasq.
unifi_vlan_proxmox.png
Both of these would show up in the ISC leases, IIRC, even though they are static in Proxmox. I think this is a new behavior but I'll have to confirm.
Gitea is the only non-static service in Proxmox (it's using DHCP) and that one shows up in the leases table no problem.
It's been a while since I used ISC, but I would not expect an address to show up as a lease if the DHCP service did not hand the address out.
There's a "Lease Type" column in the ISC leases table. It would label it as "static" but the line item would still be there, along with a client status (green/connected or red/disconnected).
I did not follow all of this, but at least with static reservations, there is a new DNS problem with 25.1.7:
https://github.com/opnsense/core/issues/8694
Quote from: meyergru on May 19, 2025, 11:07:13 PMI did not follow all of this, but at least with static reservations, there is a new DNS problem with 25.1.7:
https://github.com/opnsense/core/issues/8694
This is one of the things I'm observing also, except I am not using aliases. It seems any static reservation by MAC & IP is failing to resolve.
C:\>nslookup unifi.h1.home.arpa
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.30.1
DNS request timed out.
timeout was 2 seconds.
*** UnKnown can't find unifi.h1.home.arpa: Server failed
By all accounts, this ^ should work.
However, dynamic leases resolve (eventually-- once I get past the timeouts):
C:\>nslookup OnePlus-6T.iot.internal
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 192.168.30.1
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
Name: OnePlus-6T.iot.internal
Address: 192.168.40.165
I just updated the ticket title accordingly. We have discovered that in the meantime as well:
No static reservations work unless their DHCP registrations are active. This is because of a bugfix for IPv6 reservations with dynamic prefixes, which obviously cannot work before the actual IPv6 is known. This fix breaks all static IPv6 and IPv4 reservations that expect the DNS resolution regardless of how the client obtains its address.
My preferred fix for this would be to write the reservations like before, leaving out only the affected "partial" IPv6s. However, a fix make take until 25.7. as of now.
Quote from: meyergru on May 19, 2025, 11:37:18 PMI just updated the ticket title accordingly. We have discovered that in the meantime as well:
No static reservations work unless their DHCP registrations are active. This is because of a bugfix for IPv6 reservations with dynamic prefixes, which obviously cannot work before the actual IPv6 is known. This fix breaks all static IPv6 and IPv4 reservations that expect the DNS resolution regardless of how the client obtains its address.
My preferred fix for this would be to write the reservations like before, leaving out only the affected "partial" IPv6s. However, a fix make take until 25.7. as of now.
When you say the fix may take until 25.7, does this mean all local DNS resolution is broken until then for all static leases?
I migrated to DNSMasq+Unbound over the weekend and everything was running great. I upgraded to 25.1.7 earlier today and now all local resolution of static reservations is broken. Dynamic reservations work just fine. Have confirmed I am setup like the docs suggest, the queries just never resolve at the DNSMasq level for static leases.
I put up the issue to the link here just to save you from finding out by yourself the hard way that this is broken with 25.1.7.
It is not my decision or business when it will be fixed (I just happen to be on the same boat). Look at the linked ticket. Maybe Deciso will decide to put out a hotfix or patch earlier, but the target milestone is 25.7 as of the time of my writing.
Just to put it into perspective the issue is less than 24 hours old and we already discussed some potential ways to tackle this, but finding the right fix just takes some weighting of options and discussions which takes time.
You can always go back to 25.1.6 for a while longer.
Correct. Reverting just works.
As does using "opnsense-patch e69b02c" and reapplying the DNSmasq host reservations, at least for that specific issue.
As @Monviech pointed out, there is a hotfix out already, so please use that and reapply DNSmasq configuration.
Thanks to @Monviech for solving it that fast!
Just want to say thank you to everyone involved for tracking this down and fixing it!
I had this problem when upgrading to 25.1.7 and immediately rolled back to my old KEA/Unbound configuration since that was working as intended. I applied patch e69b02c above and everything is working again.
Quote from: meyergru on May 20, 2025, 12:30:52 PMAs does using "opnsense-patch e69b02c" and reapplying the DNSmasq host reservations, at least for that specific issue.
Stupid question time. How do you apply that patch?
Just search for updates, it is already hotfixed now.
You might have to press "Apply" in dnsmasq one time after the update.
Nice work! Just updated to 25.1.7_2 and now I am able to query static reservations.
Qualified names work:
C:\>nslookup unifi.h1.home.arpa
Server: UnKnown
Address: 192.168.30.1
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
DNS request timed out.
timeout was 2 seconds.
Name: unifi.h1.home.arpa
Address: 192.168.1.16
Plain names don't work initially, but after several tries they do:
C:\>nslookup unifi
Server: UnKnown
Address: 192.168.30.1
*** UnKnown can't find unifi: Server failed
C:\>nslookup unifi
Server: UnKnown
Address: 192.168.30.1
Non-authoritative answer:
DNS request timed out.
timeout was 2 seconds.
Name: unifi.h1.home.arpa
Address: 192.168.1.16
Obviously my Unbound is still broken / having trouble with internal forwards.
I'm seeing exactly the same symptoms; DNS timeouts for internal and external addresses.
I do have a slightly different configuration though in that I use Adguard Home running on OPNsense for all DNS queries (port 53). This is then passed on to Unbound running on port 65353 as an upstream DNS server with Private Reverse DNS Server configured to point to Dnsmasq. I've followed the instructions exactly including Dnsmasq running on port 53053 and created the necessary query forwards for all internal domains and reverse lookups.
However, nslookup gives timeouts for every query - even for the same query.
One thing I have noticed though is that the timeouts only happen on Windows devices. I can run nslookup on a Macbook and on Linux and don't see any timeouts, just an instant response.
@OP
Lets go at this structured, let's first compare Unbound configurations. Here is mine where I do not have any timeouts, maybe we can find a difference. Please post yours. Do not omit anything, do not anonymize anything. If you cant post it, please PM it to me.
I do not see any slow responses with Windows (Surface Pro 5 with Windows 11), MacOS (Macbook Pro) or Linux (Debian 12)
UNBOUND:
<unboundplus version="1.0.12">
<general>
<enabled>1</enabled>
<port>53</port>
<stats/>
<active_interface/>
<dnssec>0</dnssec>
<dns64>0</dns64>
<dns64prefix/>
<noarecords>0</noarecords>
<regdhcp>0</regdhcp>
<regdhcpdomain/>
<regdhcpstatic>0</regdhcpstatic>
<noreglladdr6>0</noreglladdr6>
<noregrecords>0</noregrecords>
<txtsupport>0</txtsupport>
<cacheflush>1</cacheflush>
<local_zone_type>transparent</local_zone_type>
<outgoing_interface/>
<enable_wpad>0</enable_wpad>
</general>
<advanced>
<hideidentity>0</hideidentity>
<hideversion>0</hideversion>
<prefetch>1</prefetch>
<prefetchkey>0</prefetchkey>
<dnssecstripped>0</dnssecstripped>
<aggressivensec>1</aggressivensec>
<serveexpired>0</serveexpired>
<serveexpiredreplyttl/>
<serveexpiredttl/>
<serveexpiredttlreset>0</serveexpiredttlreset>
<serveexpiredclienttimeout/>
<qnameminstrict>0</qnameminstrict>
<extendedstatistics>0</extendedstatistics>
<logqueries>1</logqueries>
<logreplies>1</logreplies>
<logtagqueryreply>1</logtagqueryreply>
<logservfail>0</logservfail>
<loglocalactions>0</loglocalactions>
<logverbosity>1</logverbosity>
<valloglevel>0</valloglevel>
<privatedomain/>
<privateaddress>0.0.0.0/8,10.0.0.0/8,100.64.0.0/10,169.254.0.0/16,172.16.0.0/12,192.0.2.0/24,192.168.0.0/16,198.18.0.0/15,198.51.100.0/24,203.0.113.0/24,233.252.0.0/24,::1/128,2001:db8::/32,fc00::/8,fd00::/8,fe80::/10</privateaddress>
<insecuredomain/>
<msgcachesize/>
<rrsetcachesize/>
<outgoingnumtcp/>
<incomingnumtcp/>
<numqueriesperthread/>
<outgoingrange/>
<jostletimeout/>
<discardtimeout/>
<cachemaxttl/>
<cachemaxnegativettl/>
<cacheminttl/>
<infrahostttl/>
<infrakeepprobing>0</infrakeepprobing>
<infracachenumhosts/>
<unwantedreplythreshold/>
</advanced>
<acls>
<default_action>allow</default_action>
</acls>
<dnsbl>
<enabled>1</enabled>
<safesearch>0</safesearch>
<type>sb</type>
<lists/>
<whitelists/>
<blocklists/>
<wildcards/>
<address/>
<nxdomain>1</nxdomain>
</dnsbl>
<forwarding>
<enabled>0</enabled>
</forwarding>
<dots>
<dot uuid="7917a181-1ba1-4ec1-aa57-7463b4b5a325">
<enabled>1</enabled>
<type>forward</type>
<domain>ad.pischem.com</domain>
<server>127.0.0.1</server>
<port>53053</port>
<verify/>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description/>
</dot>
<dot uuid="0fc28394-2da5-470c-b9d8-9d51979878b9">
<enabled>1</enabled>
<type>forward</type>
<domain>gast.pischem.com</domain>
<server>127.0.0.1</server>
<port>53053</port>
<verify/>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description/>
</dot>
<dot uuid="2dc5bc5c-a57b-475b-98a8-84d0d10b9bb2">
<enabled>1</enabled>
<type>forward</type>
<domain>16.172.in-addr.arpa</domain>
<server>127.0.0.1</server>
<port>53053</port>
<verify/>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description/>
</dot>
</dots>
<hosts/>
<aliases/>
</unboundplus>
DNSMASQ:
<dnsmasq version="1.0.5">
<enable>1</enable>
<regdhcp>0</regdhcp>
<regdhcpstatic>0</regdhcpstatic>
<dhcpfirst>0</dhcpfirst>
<strict_order>0</strict_order>
<domain_needed>1</domain_needed>
<no_private_reverse>0</no_private_reverse>
<log_queries>1</log_queries>
<no_hosts>0</no_hosts>
<strictbind>0</strictbind>
<dnssec>0</dnssec>
<regdhcpdomain/>
<interface>opt1,opt2</interface>
<port>53053</port>
<dns_forward_max/>
<cache_size/>
<local_ttl/>
<add_mac/>
<add_subnet>0</add_subnet>
<strip_subnet>0</strip_subnet>
<dhcp>
<no_interface/>
<fqdn>1</fqdn>
<domain/>
<lease_max/>
<authoritative>1</authoritative>
<default_fw_rules>1</default_fw_rules>
<reply_delay/>
<enable_ra>1</enable_ra>
<nosync>0</nosync>
</dhcp>
<no_ident>1</no_ident>
<hosts uuid="474a0dca-beef-4e56-908a-e8ab086640fa">
<host>pc02</host>
<domain/>
<ip>172.16.0.140</ip>
<client_id/>
<hwaddr>f0:6e:0b:c1:24:4c</hwaddr>
<lease_time/>
<ignore>0</ignore>
<set_tag/>
<descr/>
<comments/>
<aliases/>
</hosts>
<dhcp_tags uuid="63db3d8f-e6a8-45ed-b4a5-832a3fcc9160">
<tag>test</tag>
</dhcp_tags>
<dhcp_ranges uuid="3e1125ad-42c6-4e87-a1f1-c3199111b878">
<interface>opt1</interface>
<set_tag/>
<start_addr>172.16.0.100</start_addr>
<end_addr>172.16.0.199</end_addr>
<constructor/>
<mode/>
<prefix_len/>
<lease_time/>
<domain>ad.pischem.com</domain>
<nosync>0</nosync>
<ra_mode/>
<ra_priority/>
<ra_mtu/>
<ra_interval/>
<ra_router_lifetime/>
<description/>
</dhcp_ranges>
<dhcp_ranges uuid="779c0310-fc06-4051-a445-5bb2cad7c9f6">
<interface>opt2</interface>
<set_tag/>
<start_addr>172.16.1.100</start_addr>
<end_addr>172.16.1.199</end_addr>
<constructor/>
<mode/>
<prefix_len/>
<lease_time/>
<domain>gast.pischem.com</domain>
<nosync>0</nosync>
<ra_mode/>
<ra_priority/>
<ra_mtu/>
<ra_interval/>
<ra_router_lifetime/>
<description/>
</dhcp_ranges>
<dhcp_ranges uuid="84184b4c-2145-4052-8991-56088a7dfaa0">
<interface>opt1</interface>
<set_tag/>
<start_addr>::100</start_addr>
<end_addr>::999</end_addr>
<constructor>opt1</constructor>
<mode/>
<prefix_len/>
<lease_time/>
<domain/>
<nosync>0</nosync>
<ra_mode>slaac,ra-names</ra_mode>
<ra_priority/>
<ra_mtu/>
<ra_interval/>
<ra_router_lifetime/>
<description/>
</dhcp_ranges>
<dhcp_ranges uuid="6c525437-5e47-473f-a226-d86d15c5960d">
<interface>opt2</interface>
<set_tag/>
<start_addr>::</start_addr>
<end_addr/>
<constructor>opt2</constructor>
<mode/>
<prefix_len/>
<lease_time/>
<domain/>
<nosync>0</nosync>
<ra_mode>ra-names,ra-stateless</ra_mode>
<ra_priority/>
<ra_mtu/>
<ra_interval/>
<ra_router_lifetime/>
<description/>
</dhcp_ranges>
<dhcp_options uuid="84858973-99b7-48e0-b969-c3cfcf1ac031">
<type>set</type>
<option/>
<option6>23</option6>
<interface>opt1</interface>
<tag/>
<set_tag/>
<value>[::]</value>
<force>0</force>
<description/>
</dhcp_options>
<dhcp_options uuid="0f7518aa-dcdd-45df-a15e-9ed010422654">
<type>set</type>
<option/>
<option6>23</option6>
<interface>opt2</interface>
<tag/>
<set_tag/>
<value>[::]</value>
<force>0</force>
<description/>
</dhcp_options>
</dnsmasq>
I am using the exact setup as described here (it was recently updated): https://docs.opnsense.org/manual/dnsmasq.html#dhcpv4-with-dns-registration
Only difference is that I own a domain and use that as my internal one.
@Monviech, thanks. The full Unbound config is pasted below. I'll PM you my Dnsmasq config because it contains MACs, but I'll also paste a redacted version here.
Unbound:
<unboundplus version="1.0.12">
<general>
<enabled>1</enabled>
<port>53</port>
<stats>1</stats>
<active_interface/>
<dnssec>1</dnssec>
<dns64>0</dns64>
<dns64prefix/>
<noarecords>0</noarecords>
<regdhcp>0</regdhcp>
<regdhcpdomain/>
<regdhcpstatic>0</regdhcpstatic>
<noreglladdr6>1</noreglladdr6>
<noregrecords>1</noregrecords>
<txtsupport>0</txtsupport>
<cacheflush>1</cacheflush>
<local_zone_type>transparent</local_zone_type>
<outgoing_interface/>
<enable_wpad>0</enable_wpad>
</general>
<advanced>
<hideidentity>1</hideidentity>
<hideversion>1</hideversion>
<prefetch>0</prefetch>
<prefetchkey>1</prefetchkey>
<dnssecstripped>0</dnssecstripped>
<aggressivensec>0</aggressivensec>
<serveexpired>0</serveexpired>
<serveexpiredreplyttl/>
<serveexpiredttl/>
<serveexpiredttlreset>0</serveexpiredttlreset>
<serveexpiredclienttimeout/>
<qnameminstrict>0</qnameminstrict>
<extendedstatistics>0</extendedstatistics>
<logqueries>1</logqueries>
<logreplies>1</logreplies>
<logtagqueryreply>0</logtagqueryreply>
<logservfail>0</logservfail>
<loglocalactions>0</loglocalactions>
<logverbosity>1</logverbosity>
<valloglevel>0</valloglevel>
<privatedomain/>
<privateaddress>0.0.0.0/8,10.0.0.0/8,100.64.0.0/10,169.254.0.0/16,172.16.0.0/12,192.0.2.0/24,192.168.0.0/16,198.18.0.0/15,198.51.100.0/24,203.0.113.0/24,233.252.0.0/24,::1/128,2001:db8::/32,fc00::/8,fd00::/8,fe80::/10</privateaddress>
<insecuredomain/>
<msgcachesize/>
<rrsetcachesize/>
<outgoingnumtcp/>
<incomingnumtcp/>
<numqueriesperthread/>
<outgoingrange/>
<jostletimeout/>
<discardtimeout/>
<cachemaxttl/>
<cachemaxnegativettl/>
<cacheminttl/>
<infrahostttl/>
<infrakeepprobing>0</infrakeepprobing>
<infracachenumhosts/>
<unwantedreplythreshold/>
</advanced>
<acls>
<default_action>allow</default_action>
</acls>
<dnsbl>
<enabled>1</enabled>
<safesearch>0</safesearch>
<type>ag,sb</type>
<lists/>
<whitelists/>
<blocklists>trace.svc.ui.com</blocklists>
<wildcards/>
<address/>
<nxdomain>1</nxdomain>
</dnsbl>
<forwarding>
<enabled/>
</forwarding>
<dots>
<dot uuid="c98be808-4cd7-473d-9cb5-bc0d40bab267">
<enabled>1</enabled>
<type>dot</type>
<domain/>
<server>9.9.9.9</server>
<port>853</port>
<verify>dns.quad9.net</verify>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description/>
</dot>
<dot uuid="b84bb19f-0d53-4ec3-989a-012284f8035e">
<enabled>1</enabled>
<type>dot</type>
<domain/>
<server>149.112.112.112</server>
<port>853</port>
<verify>dns.quad9.net</verify>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description/>
</dot>
<dot uuid="b38fc5d6-a348-4758-b6c1-81523afd1160">
<enabled>1</enabled>
<type>dot</type>
<domain/>
<server>2620:fe::fe</server>
<port>853</port>
<verify>dns.quad9.net</verify>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description/>
</dot>
<dot uuid="8d4320ea-0a34-430a-96ad-d3c93a71d6b7">
<enabled>1</enabled>
<type>dot</type>
<domain/>
<server>2620:fe::9</server>
<port>853</port>
<verify>dns.quad9.net</verify>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description/>
</dot>
<dot uuid="0fb43272-d79b-4473-9b63-b1b803eb017c">
<enabled>1</enabled>
<type>forward</type>
<domain>h1.home.arpa</domain>
<server>127.0.0.1</server>
<port>53053</port>
<verify/>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description>Dnsmasq lookup (A) for LAN</description>
</dot>
<dot uuid="9391bbdb-2135-4480-a9c7-0248a1125a0a">
<enabled>1</enabled>
<type>forward</type>
<domain>1.168.192.in-addr.arpa</domain>
<server>127.0.0.1</server>
<port>53053</port>
<verify/>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description>Dnsmasq reverse lookup (PTR) for LAN</description>
</dot>
<dot uuid="a47d7759-d555-47bf-a2ad-88a03f292e72">
<enabled>1</enabled>
<type>forward</type>
<domain>guest.internal</domain>
<server>127.0.0.1</server>
<port>53053</port>
<verify/>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description>Dnsmasq lookup (A) for GUEST</description>
</dot>
<dot uuid="a13a9eaa-78b5-41a8-a678-a1b5f6f242de">
<enabled>1</enabled>
<type>forward</type>
<domain>20.168.192.in-addr.arpa</domain>
<server>127.0.0.1</server>
<port>53053</port>
<verify/>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description>Dnsmasq reverse lookup (PTR) for GUEST</description>
</dot>
<dot uuid="cf891bd5-53cb-4e0c-a755-8e92ff03e4ec">
<enabled>1</enabled>
<type>forward</type>
<domain>home.internal</domain>
<server>127.0.0.1</server>
<port>53053</port>
<verify/>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description>Dnsmasq lookup (A) for HOME</description>
</dot>
<dot uuid="6e6834a6-2136-413e-9a25-de7f44695526">
<enabled>1</enabled>
<type>forward</type>
<domain>30.168.192.in-addr.arpa</domain>
<server>127.0.0.1</server>
<port>53053</port>
<verify/>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description>Dnsmasq reverse lookup (PTR) for HOME</description>
</dot>
<dot uuid="940a25f0-22ca-4b23-a90d-824613220185">
<enabled>1</enabled>
<type>forward</type>
<domain>iot.internal</domain>
<server>127.0.0.1</server>
<port>53053</port>
<verify/>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description>Dnsmasq lookup (A) for IOT</description>
</dot>
<dot uuid="093e0408-209c-4659-ae5b-b9ba80b6a181">
<enabled>1</enabled>
<type>forward</type>
<domain>40.168.192.in-addr.arpa</domain>
<server>127.0.0.1</server>
<port>53053</port>
<verify/>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description>Dnsmasq reverse lookup (PTR) for IOT</description>
</dot>
<dot uuid="e02893f4-5823-4f6f-aa04-3731d8f8ba1c">
<enabled>1</enabled>
<type>forward</type>
<domain>vpn.internal</domain>
<server>127.0.0.1</server>
<port>53053</port>
<verify/>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description>Dnsmasq lookup (A) for VPN</description>
</dot>
<dot uuid="a19e7326-baa1-4050-aac7-e0c27bd5700b">
<enabled>1</enabled>
<type>forward</type>
<domain>50.168.192.in-addr.arpa</domain>
<server>127.0.0.1</server>
<port>53053</port>
<verify/>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description>Dnsmasq reverse lookup (PTR) for VPN</description>
</dot>
<dot uuid="5c2aae7e-57a5-4cce-8077-832425ac4406">
<enabled>1</enabled>
<type>forward</type>
<domain>lab.internal</domain>
<server>127.0.0.1</server>
<port>53053</port>
<verify/>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description>Dnsmasq lookup (A) for LAB</description>
</dot>
<dot uuid="4700bebf-1fe0-421d-a712-23d973634adc">
<enabled>1</enabled>
<type>forward</type>
<domain>60.168.192.in-addr.arpa</domain>
<server>127.0.0.1</server>
<port>53053</port>
<verify/>
<forward_tcp_upstream>0</forward_tcp_upstream>
<forward_first>0</forward_first>
<description>Dnsmasq reverse lookup (PTR) for LAB</description>
</dot>
</dots>
<hosts>
<host uuid="772b3900-8559-4f54-9231-773362eda505">
<enabled>1</enabled>
<hostname>firewall</hostname>
<domain>h2.home.arpa</domain>
<rr>A</rr>
<mxprio/>
<mx/>
<ttl/>
<server>192.168.130.1</server>
<description>OPNsense @ h2 site</description>
</host>
<host uuid="b26a8d34-d59a-49e1-9e3b-0195ffa21e13">
<enabled>1</enabled>
<hostname>unifi</hostname>
<domain>h2.home.arpa</domain>
<rr>A</rr>
<mxprio/>
<mx/>
<ttl/>
<server>192.168.130.2</server>
<description>UniFi Network @ h2 site</description>
</host>
<host uuid="b7432305-e3f0-4500-a860-aa675935e97b">
<enabled>1</enabled>
<hostname>epirus</hostname>
<domain>h2.home.arpa</domain>
<rr>A</rr>
<mxprio/>
<mx/>
<ttl/>
<server>192.168.130.3</server>
<description>Bedroom PC @ h2 site</description>
</host>
<host uuid="9898e09f-7902-49d6-8c46-51d7224d677c">
<enabled>1</enabled>
<hostname>demati</hostname>
<domain>h2.home.arpa</domain>
<rr>A</rr>
<mxprio/>
<mx/>
<ttl/>
<server>192.168.130.4</server>
<description>Synology DS224+ @ h2 site</description>
</host>
</hosts>
<aliases/>
</unboundplus>
Dnsmasq (MACs redacted):
<dnsmasq version="1.0.5">
<enable>1</enable>
<regdhcp>0</regdhcp>
<regdhcpstatic>0</regdhcpstatic>
<dhcpfirst>0</dhcpfirst>
<strict_order>0</strict_order>
<domain_needed>0</domain_needed>
<no_private_reverse>1</no_private_reverse>
<log_queries>1</log_queries>
<no_hosts>0</no_hosts>
<strictbind>0</strictbind>
<dnssec>0</dnssec>
<regdhcpdomain/>
<interface>opt2,opt3,opt4,opt1,lan,opt5</interface>
<port>53053</port>
<dns_forward_max/>
<cache_size/>
<local_ttl/>
<add_mac/>
<add_subnet>0</add_subnet>
<strip_subnet>0</strip_subnet>
<dhcp>
<no_interface/>
<fqdn>1</fqdn>
<domain/>
<lease_max/>
<authoritative>0</authoritative>
<default_fw_rules>1</default_fw_rules>
<reply_delay/>
<enable_ra>0</enable_ra>
<nosync>0</nosync>
</dhcp>
<no_ident>1</no_ident>
<hosts uuid="47645bc7-e777-40ee-91ce-5e59f0c3def9">
<host>sw1</host>
<domain>h1.home.arpa</domain>
<ip>192.168.1.6</ip>
<client_id/>
<hwaddr>xx:xx:xx:xx:xx:xx</hwaddr>
<lease_time/>
<ignore>0</ignore>
<set_tag/>
<descr>USW-Pro-Max-16-PoE</descr>
<comments/>
<aliases/>
</hosts>
<hosts uuid="42e20b17-96ee-485c-a6f8-a294e9d805cc">
<host>ap1</host>
<domain>h1.home.arpa</domain>
<ip>192.168.1.11</ip>
<client_id/>
<hwaddr>xx:xx:xx:xx:xx:xx</hwaddr>
<lease_time/>
<ignore>0</ignore>
<set_tag/>
<descr>U7 Lite 2nd Floor</descr>
<comments/>
<aliases/>
</hosts>
<hosts uuid="9d830c51-58e5-409c-9491-337047bd23d1">
<host>unifi</host>
<domain>h1.home.arpa</domain>
<ip>192.168.1.16</ip>
<client_id/>
<hwaddr>xx:xx:xx:xx:xx:xx</hwaddr>
<lease_time/>
<ignore>0</ignore>
<set_tag/>
<descr>UniFi Network Application</descr>
<comments/>
<aliases/>
</hosts>
<hosts uuid="415529a5-6805-4a84-8300-9f46dc0ae9ae">
<host>tinybox</host>
<domain>h1.home.arpa</domain>
<ip>192.168.1.17</ip>
<client_id/>
<hwaddr>xx:xx:xx:xx:xx:xx</hwaddr>
<lease_time/>
<ignore>0</ignore>
<set_tag/>
<descr>NUT server / RPi 3B+</descr>
<comments/>
<aliases/>
</hosts>
<hosts uuid="e28acf68-839f-4ccc-a554-e4a0f140e247">
<host>BLACKBOX</host>
<domain>home.internal</domain>
<ip>192.168.30.2</ip>
<client_id/>
<hwaddr>xx:xx:xx:xx:xx:xx</hwaddr>
<lease_time/>
<ignore>0</ignore>
<set_tag/>
<descr>Desktop PC</descr>
<comments/>
<aliases/>
</hosts>
<hosts uuid="fc8e9408-1cda-44bc-b690-f9f544d09e24">
<host>omv</host>
<domain>home.internal</domain>
<ip>192.168.30.8</ip>
<client_id/>
<hwaddr>xx:xx:xx:xx:xx:xx</hwaddr>
<lease_time/>
<ignore>0</ignore>
<set_tag/>
<descr>OpenMediaVault</descr>
<comments/>
<aliases/>
</hosts>
<hosts uuid="82cdefab-0215-4324-a279-66c0712f4f90">
<host>hp6088aa</host>
<domain>iot.internal</domain>
<ip>192.168.40.2</ip>
<client_id/>
<hwaddr>xx:xx:xx:xx:xx:xx</hwaddr>
<lease_time/>
<ignore>0</ignore>
<set_tag/>
<descr>HP Photosmart 7525</descr>
<comments/>
<aliases/>
</hosts>
<hosts uuid="712bd0c6-8ba6-4615-9b6a-b36ea0e678b8">
<host>chromecast-br</host>
<domain>iot.internal</domain>
<ip>192.168.40.3</ip>
<client_id/>
<hwaddr>xx:xx:xx:xx:xx:xx</hwaddr>
<lease_time/>
<ignore>0</ignore>
<set_tag/>
<descr>Bedroom Chromecast</descr>
<comments/>
<aliases/>
</hosts>
<hosts uuid="1f966d3b-3c07-488d-b12a-6dd27e86918f">
<host>chromecast-lr</host>
<domain>iot.internal</domain>
<ip>192.168.40.4</ip>
<client_id/>
<hwaddr>xx:xx:xx:xx:xx:xx</hwaddr>
<lease_time/>
<ignore>0</ignore>
<set_tag/>
<descr>Living Room Chromecast</descr>
<comments/>
<aliases/>
</hosts>
<hosts uuid="ec1df31a-6b69-4c12-99ed-6d7c8f1e0358">
<host>pve</host>
<domain>lab.internal</domain>
<ip>192.168.60.2</ip>
<client_id/>
<hwaddr>xx:xx:xx:xx:xx:xx</hwaddr>
<lease_time/>
<ignore>0</ignore>
<set_tag/>
<descr>Proxmox VE</descr>
<comments/>
<aliases/>
</hosts>
<dhcp_ranges uuid="5c0e81f5-b10b-4cb2-836f-f7501b3be776">
<interface>lan</interface>
<set_tag/>
<start_addr>192.168.1.100</start_addr>
<end_addr>192.168.1.199</end_addr>
<constructor/>
<mode/>
<prefix_len/>
<lease_time/>
<domain>h1.home.arpa</domain>
<nosync>0</nosync>
<ra_mode/>
<ra_priority/>
<ra_mtu/>
<ra_interval/>
<ra_router_lifetime/>
<description/>
</dhcp_ranges>
<dhcp_ranges uuid="1f9156cc-3f3d-4d7b-a9f8-8cb57b959456">
<interface>opt2</interface>
<set_tag/>
<start_addr>192.168.20.100</start_addr>
<end_addr>192.168.20.199</end_addr>
<constructor/>
<mode/>
<prefix_len/>
<lease_time/>
<domain>guest.internal</domain>
<nosync>0</nosync>
<ra_mode/>
<ra_priority/>
<ra_mtu/>
<ra_interval/>
<ra_router_lifetime/>
<description/>
</dhcp_ranges>
<dhcp_ranges uuid="8026572d-7028-499d-87d3-dd839667af64">
<interface>opt3</interface>
<set_tag/>
<start_addr>192.168.30.100</start_addr>
<end_addr>192.168.30.199</end_addr>
<constructor/>
<mode/>
<prefix_len/>
<lease_time/>
<domain>home.internal</domain>
<nosync>0</nosync>
<ra_mode/>
<ra_priority/>
<ra_mtu/>
<ra_interval/>
<ra_router_lifetime/>
<description/>
</dhcp_ranges>
<dhcp_ranges uuid="690266e3-481e-41f1-a30f-bf1b68d7217f">
<interface>opt4</interface>
<set_tag/>
<start_addr>192.168.40.100</start_addr>
<end_addr>192.168.40.199</end_addr>
<constructor/>
<mode/>
<prefix_len/>
<lease_time/>
<domain>iot.internal</domain>
<nosync>0</nosync>
<ra_mode/>
<ra_priority/>
<ra_mtu/>
<ra_interval/>
<ra_router_lifetime/>
<description/>
</dhcp_ranges>
<dhcp_ranges uuid="f1e1f6a9-5b3a-4f88-a760-58d07af51897">
<interface>opt5</interface>
<set_tag/>
<start_addr>192.168.50.100</start_addr>
<end_addr>192.168.50.199</end_addr>
<constructor/>
<mode/>
<prefix_len/>
<lease_time/>
<domain>vpn.internal</domain>
<nosync>0</nosync>
<ra_mode/>
<ra_priority/>
<ra_mtu/>
<ra_interval/>
<ra_router_lifetime/>
<description/>
</dhcp_ranges>
<dhcp_ranges uuid="8035e2df-4f21-4b63-a4ea-8d72404a2993">
<interface>opt1</interface>
<set_tag/>
<start_addr>192.168.60.100</start_addr>
<end_addr>192.168.60.199</end_addr>
<constructor/>
<mode/>
<prefix_len/>
<lease_time/>
<domain>lab.internal</domain>
<nosync>0</nosync>
<ra_mode/>
<ra_priority/>
<ra_mtu/>
<ra_interval/>
<ra_router_lifetime/>
<description/>
</dhcp_ranges>
<dhcp_options uuid="1b7d3a55-7c1f-46d4-9e77-a46659ec6401">
<type>set</type>
<option>42</option>
<option6/>
<interface>lan</interface>
<tag/>
<set_tag/>
<value>192.168.1.1</value>
<force>0</force>
<description/>
</dhcp_options>
<dhcp_options uuid="e4aede3d-80de-4086-8420-b48f32574ae6">
<type>set</type>
<option>6</option>
<option6/>
<interface>opt2</interface>
<tag/>
<set_tag/>
<value>1.1.1.1,1.0.0.1</value>
<force>0</force>
<description/>
</dhcp_options>
<dhcp_options uuid="b0793cb9-63ee-4e31-8209-6650cf05996e">
<type>set</type>
<option>42</option>
<option6/>
<interface>opt2</interface>
<tag/>
<set_tag/>
<value>192.168.20.1</value>
<force>0</force>
<description/>
</dhcp_options>
<dhcp_options uuid="8937f768-6e35-4fe1-85dd-81818bcf84fe">
<type>set</type>
<option>42</option>
<option6/>
<interface>opt3</interface>
<tag/>
<set_tag/>
<value>192.168.30.1</value>
<force>0</force>
<description/>
</dhcp_options>
<dhcp_options uuid="82f23a0b-3e23-4cdf-97cf-84411ba0d769">
<type>set</type>
<option>42</option>
<option6/>
<interface>opt4</interface>
<tag/>
<set_tag/>
<value>192.168.40.1</value>
<force>0</force>
<description/>
</dhcp_options>
<dhcp_options uuid="52f318f0-ed93-49e1-b4ee-ade96582958a">
<type>set</type>
<option>42</option>
<option6/>
<interface>opt5</interface>
<tag/>
<set_tag/>
<value>192.168.50.1</value>
<force>0</force>
<description/>
</dhcp_options>
<dhcp_options uuid="f31b62fb-76b5-45a7-94d2-94617261ff4b">
<type>set</type>
<option>42</option>
<option6/>
<interface>opt1</interface>
<tag/>
<set_tag/>
<value>192.168.60.1</value>
<force>0</force>
<description/>
</dhcp_options>
<dhcp_options uuid="675d2222-af1c-4894-a9fc-3d4504a1521f">
<type>set</type>
<option>43</option>
<option6/>
<interface>lan</interface>
<tag/>
<set_tag/>
<value>01:04:c0:a8:01:10</value>
<force>0</force>
<description>UniFi controller</description>
</dhcp_options>
</dnsmasq>
Thanks I will import these tomorrow and see if I can replicate the issues.
If somebody else wants to try too, go ahead.
Quote from: RutgerDiehard on May 20, 2025, 04:50:01 PMOne thing I have noticed though is that the timeouts only happen on Windows devices. I can run nslookup on a Macbook and on Linux and don't see any timeouts, just an instant response.
I just tried from a Raspberry Pi and I'm seeing the same kind of failures, although I can't rule out configuration issues on my end yet (TBD).
What I can say though is that 'dig' fails instantly with 'NXDOMAIN' whereas 'nslookup' (on both Linux and Windows) gives several timeouts before finally returning 'SERVFAIL'.
I looked at the config, but everything I thought could cause this was harmless, like the blocklists, hide identify, hide version. I tried enabling those here and it still worked fine. The only time I saw similar timeout problems was with 25.1.7 when my static reservations were gone.
Ah, interesting, the thing with Windows - I only tried from a Linux client.
OPNsense seems to combine the Unbound 'Query Forwarding' and 'DNS over TLS' configs into one /var/unbound/etc/dot.conf file. So I fed this to ChatGPT for its opinion. It made two recommendations.
For reference here is the original file:
server:
do-not-query-localhost: no
# Forward zones
forward-zone:
name: "1.168.192.in-addr.arpa."
forward-addr: 127.0.0.1@53053
forward-zone:
name: "20.168.192.in-addr.arpa."
forward-addr: 127.0.0.1@53053
forward-zone:
name: "30.168.192.in-addr.arpa."
forward-addr: 127.0.0.1@53053
forward-zone:
name: "40.168.192.in-addr.arpa."
forward-addr: 127.0.0.1@53053
forward-zone:
name: "50.168.192.in-addr.arpa."
forward-addr: 127.0.0.1@53053
forward-zone:
name: "60.168.192.in-addr.arpa."
forward-addr: 127.0.0.1@53053
forward-zone:
name: "guest.internal."
forward-addr: 127.0.0.1@53053
forward-zone:
name: "h1.home.arpa."
forward-addr: 127.0.0.1@53053
forward-zone:
name: "home.internal."
forward-addr: 127.0.0.1@53053
forward-zone:
name: "iot.internal."
forward-addr: 127.0.0.1@53053
forward-zone:
name: "lab.internal."
forward-addr: 127.0.0.1@53053
forward-zone:
name: "vpn.internal."
forward-addr: 127.0.0.1@53053
# Forward zones over TLS
server:
tls-cert-bundle: /usr/local/etc/ssl/cert.pem
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 9.9.9.9@853#dns.quad9.net
forward-addr: 149.112.112.112@853#dns.quad9.net
forward-addr: 2620:fe::fe@853#dns.quad9.net
forward-addr: 2620:fe::9@853#dns.quad9.net
Feedback #1:
same_forward_target.png
I have yet to look into whether or not Dnsmasq has these server=/domain/ directives (not entirely clear on that), but this also gave me the idea to clean up the Forwarding in Unbound. I have condensed it to this (although it didn't help).
server:
do-not-query-localhost: no
# Forward zones
forward-zone:
name: "168.192.in-addr.arpa"
forward-addr: 127.0.0.1@53053
forward-zone:
name: "h1.home.arpa"
forward-addr: 127.0.0.1@53053
forward-zone:
name: "internal"
forward-addr: 127.0.0.1@53053
# Forward zones over TLS
server:
tls-cert-bundle: /usr/local/etc/ssl/cert.pem
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 9.9.9.9@853#dns.quad9.net
forward-addr: 149.112.112.112@853#dns.quad9.net
forward-addr: 2620:fe::fe@853#dns.quad9.net
forward-addr: 2620:fe::9@853#dns.quad9.net
----
EDIT: I looked in /usr/local/etc/dnsmasq.conf for any 'server=' directives, but found none. I only see the domains, so I'm not sure what GPT is referring to here.
Near the top of the file there is one reference to 'h1.home.arpa', the system default domain for 192.168.1.0/24. Then further down there are the ranges that I defined for the VLANs.
...
dhcp-fqdn
domain=h1.home.arpa
...
dhcp-range=tag:vlan0.1,192.168.1.100,192.168.1.199,86400
domain=h1.home.arpa,192.168.1.100,192.168.1.199
dhcp-range=tag:vlan0.20,192.168.20.100,192.168.20.199,86400
domain=guest.internal,192.168.20.100,192.168.20.199
dhcp-range=tag:vlan0.30,192.168.30.100,192.168.30.199,86400
domain=home.internal,192.168.30.100,192.168.30.199
dhcp-range=tag:vlan0.40,192.168.40.100,192.168.40.199,86400
domain=iot.internal,192.168.40.100,192.168.40.199
dhcp-range=tag:vlan0.50,192.168.50.100,192.168.50.199,86400
domain=vpn.internal,192.168.50.100,192.168.50.199
dhcp-range=tag:vlan0.60,192.168.60.100,192.168.60.199,86400
domain=lab.internal,192.168.60.100,192.168.60.199
I'm going to ignore this feedback because anyway the issue seems to be with Unbound not forwarding correctly, not with Dnsmasq.
Feedback #2:
server_blocks.png
I can't do anything about this one. I tried editing the file directly with 'vi' to combine the server blocks as suggested, however on config reload this file just gets overwritten. There's no way to persist it, so I can't test.
Is this suggestion correct, or is ChatGPT hallucinating?
----
EDIT: I think this is allowed as per the Unbound manual: https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#server-options
QuoteFile Format
There must be whitespace between keywords. Attribute keywords end with a colon ':'. An attribute is followed by a value, or its containing attributes in which case it is referred to as a clause. Clauses can be repeated throughout the file (or included files) to group attributes under the same clause.
... which makes sense, else there would be a lot of broken setups and complaints :)
It also said this, but I think this is bullsh*t. It may be required by RFC for technical correctness, but I know that Unbound handles this internally.
Others don't include a trailing dot (.) and it's working for them. I tried it anyway. No difference.
ending_dots.png
@meyergru could you quickly provide some clarity on ranges?
If we set a DHCP range as per the docs of, say, 192.168.1.10 - 192.168.1.100 for dynamic leases, and then set a reservation up for 'Host A' at address 192.168.1.200 - do we need to set up a separate range but with mode 'static' that incorporates the desired reserved addresses?
The docs suggest we need to for DHCP v4, but the OP suggests they haven't done so and addresses are being set/reserved - what are the side effects of not doing so / why do we need a range set?
Just asking as this is contrary to what people are used to with Kea etc - the direction there was to ensure any reservations were explitly OUTSIDE of any defined ranges on the DHCP server...
Thanks.
Please create separate threads for separate issues, this one is about tracking the weird dns forwarding issues of the OP.
Quote from: Monviech (Cedrik) on May 20, 2025, 09:46:43 PMPlease create separate threads for separate issues, this one is about tracking the weird dns forwarding issues of the OP.
Understood - not an issue, as such, was just seeking to understand if it might be contributing to this issue as the OP indicated that this is one area where they have deviated from the docs direction- hence asking the question in this thread. Your reply suggests it is not a factor, so noted - thanks.
@Taunt9930 - where did you see that mentioned in the docs?
I don't think the UI allows to create static ranges. You get into a circular error loop if you try (see screenshots). So the only way to create something 'static' at the moment is to omit both the ending address and the domain part- which makes it unclear.
Quote from: OPNenthu on May 20, 2025, 10:06:00 PM@Taunt9930 - where did you see that mentioned in the docs?
Second Paragraph of the DHCP Reservations section. But, as indicated above by Cedrik, not considered a contributing factor so a red herring perhaps!
Thanks- two issues I think:
1) The doc wording isn't clear. Maybe they mean to say IPv4 dynamic leases require a DHCP range defined, and the range should be set to static if it only serves reservations. (?)
2) Might be a UI bug. If this is indeed required in Dnsmasq, then there's no way to do it.
Good that you brought it up- I'd like to know the answer as well. In either case I think @Monviech was right earlier that my issue is with Unbound misforwarding things.
Quote from: Taunt9930 on May 20, 2025, 09:41:02 PMIf we set a DHCP range as per the docs of, say, 192.168.1.10 - 192.168.1.100 for dynamic leases, and then set a reservation up for 'Host A' at address 192.168.1.200 - do we need to set up a separate range but with mode 'static' that incorporates the desired reserved addresses?
The docs suggest we need to for DHCP v4, but the OP suggests they haven't done so and addresses are being set/reserved - what are the side effects of not doing so / why do we need a range set?
Just asking as this is contrary to what people are used to with Kea etc - the direction there was to ensure any reservations were explitly OUTSIDE of any defined ranges on the DHCP server...
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.
The behavior @Drinyth describes is the same as my experience. I have VLANs that are configured with all 3 scenarios (static only, dynamic only and a mix).
I think I found it, but it's not great news- DNS might be broken in 25.1.7.
There was a hint in this post: https://forum.opnsense.org/index.php?topic=47126.msg237665;topicseen#msg237665. @Monviech could you check the recent commits?
My Starting point:
- No system name servers in System->Settings->General
- TLS upstream (Quad9) in Unbound
- Observed: DNS misrouting and timeouts
Second test:
- Disable TLS upstreams in Unbound (it should become a recursive resolver)
- Observed: DNS misrouting and timeouts
Third test:
- Add a name server to System->Settings->General (I chose 1.1.1.1)
- Leave "Use System Nameservers" unchecked in Unbound
- Expected: Unbound continues to act as recursive resolver
- Observed: Unbound forwards to 1.1.1.1:53 (confirmed in pf logs)
- Observed: DNS timeouts go away, although external queries still get forwarded to internal zones first.
Fourth test:
- Leave 1.1.1.1 configured in System->Settings->General
- Re-enable the TLS upstreams in Unbound
- Expected: Unbound forwards to DoT, doesn't use 1.1.1.1
- Observed: Both DoT and system nameservers being used. Also, external queries still getting forwarded to internal zones.
pf_log.png
In conclusion, system nameservers are required to resolve the timeouts, but they are clobbering the DoT forwarding and being used when they shouldn't. Also, all external queries are first getting forwarded to the system default domain (h1.home.arpa) in all cases. None of the other internal zones are being used.
Actually, I have system nameservers defined, but I expected them not to be used when I configured DoT.
Check your pf logs @meyergru
Yes, with or without DoT configured, I can see outbound traffic on port 53 with strict DoT on. Switching "Use System Nameservers" changed nothing on that. The targets always were my system resolvers. IDK why this is, because even if DoT is disabled, I would expect Unbound to act as DNS resolver, not using any upstream servers.
And then - oh, well: https://github.com/opnsense/core/issues/7639 and: https://github.com/NLnetLabs/unbound/issues/451
Quote from: meyergru on May 21, 2025, 01:35:07 AMYes, with or without DoT configured, I can see outbound traffic on port 53 with strict DoT on. Switching "Use System Nameservers" changed nothing on that. The targets always were my system resolvers. IDK why this is, because even if DoT is disabled, I would expect Unbound to act as DNS resolver, not using any upstream servers.
And then - oh, well: https://github.com/opnsense/core/issues/7639 and: https://github.com/NLnetLabs/unbound/issues/451
Fascinating.
So the reason I never saw this until now is because my system was configured in a specific way:
- No global resolvers defined in System->Settings->General
- Only one internal domain (h1.home.arpa) for all my VLANs
I only moved to multiple domains now because of the Dnsmasq migration guide.
While the issue of external requests getting forwarded to the internal zone may have been present, I at least was not seeing any unexpected traffic to public resolvers on port 53 because... I simply didn't have any defined. I also was not seeing other internal zones not getting forwarded to because... I simply didn't have any defined.
Seems Unbound forwarding is fundamentally broken, and has been.
So I tested it this morning.
It might be a case of testing the domain resolution wrong, and might be specific to windows clients as suggested before.
When querying with nslookup:
# nslookup opnsense.org
This will append the Domain suffix to the query on the windows client itself, turning it into:
"opnsense.org.lan.internal"
This is seen in the Unbound logs and that is what causes the slow initial resolution (because Unbound tries to indeed forward "lan.internal" to dnsmasq since it has a query forwarding for it, but dnsmasq does not know that hostname so it fails).
I have verified that with Wireshark, the client will first query for domain+suffix, and then afterwards just for the domain.
In contrast, when using:
# nslookup opnsense.org.
(notice the dot after org)
This will resolve right away.
I have also tried stripping option 15 so that windows does not receive a domain suffix to use, and it had the same result.
--------
So, maybe the test is wrong and there are no issues after all?
"Wer viel misst misst Mist"?
@Monviech: Windows is a special case, as you found out. E.g., it will per default not heed a DNS search list and domain name via DHCP (the domain name that is used is the one from the Windows hostname).
I take great lengths to make sure that both requests for a plain hostname and hostname.domain work on the DNS server side because of that, inlcuding aliases for each any every name.
However, aside these Windows-specific problems, we can see now that Unbound forwarding seems fundamentally broken, which is why OPNnthu saw the problems without any upstream servers.
Behind this, there lurks another problem: If you want to use private DNS via DoT, DoH, or DNSCrypt you are stuck right now, because:
1. With Unbound, DoT is implemented using forwarding. I have verified that to (sometimes) not work at all and essentially leak all DNS requests via unencrypted channels to upstream servers. This is an unfixed upstream issue. Not configuring upstream servers lead to timeout symptoms, so it is no viable alternative.
2. Unbound actually would allow for DoH (which uses no broken forwarding), but OpnSense GUI does not offer it, so it is an alternative with manual configuration at best. Also, it is doubtful if Unbound can be used at all in combination with DNSmasq, because, still the forwarded local domains do not work correctly.
3. The most often used way to implement encrypted upstream DNS with DNSmasq is Stubby, but there is no package or plugin for OpnSense. Mimugmail has a package for Blocky, but that is manually configured and has basically no GUI.
4. There is still the DNSCrypt-Proxy plugin, which can handle DoT and DNSCrypt upstream and also working DNS forwards for local domains, but at this time, it will not work because of this unfixed GUI validation bug: https://github.com/opnsense/plugins/issues/4697, which effectively prevents using forwards for local domains to DNSmasq.
Currently, I know of no easy, working solution for a DNS server that handles encrypted upstream DNS with OpnSense.
BTW if it helps, being a long-time Stubby user, I could contribute a writeup of my setup of it. I thought I had done it in the Tutorials sections but I could be wrong. Not all my intentions make it there.
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 proposed a pull request for DNSCrypt-Proxy, but I understand that the way I think the validation should work violates Deciso's coding guidelines. On the other hand, using the pre-fabricated validation type breaks existing setups. It is up to @Franco and @Monviech on how to eventually solve it. Also, plugins normally have lower priority, that is why I wanted to highlight the implications of this Unbound defect unfolding.
P.S.: Even Kea + Unbound is not a viable solution in the light of this problem.
https://github.com/opnsense/core/issues/8708
Please no noise in that ticket if possible, its only about the specific forwarding issues that happen due to domain suffixes being appended by some clients.
Quote from: meyergru on May 21, 2025, 11:47:22 AMI 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.
For what it's worth, I'm using AGH that is listening on port 53 and forwarding queries for local and reverse domains to dnsmasq running on a different port. So similar to having unbound running on port 53 and handling everything non-local. AGH can forward to upstream providers using DoT or DoH. It is also available to configure via the GUI.
Granted, it's not part of the default opnsense offering and one has to add Mimugmail's repo to enable it.
Duly noted regarding the Windows behavior; I'll keep that in mind. On that point I'd like to offer a rebuttal, however, on two grounds:
1. My web browser surely doesn't use nslookup, but since this issue started my web pages and mobile apps have been laggy. There is a systemic DNS performance hit, but I don't have measurements to offer.
2. Adding the trailing dot (.) to nslookup only helps with external resolutions. There is still a problem getting internal names to resolve in general. Plain names don't resolve, with or without a dot.
Plain name, no ending dot:
C:\>nslookup pve
Server: UnKnown
Address: 192.168.30.1
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out
Plain name, with dot (not sure if this is valid):
C:\>nslookup pve.
Server: UnKnown
Address: 192.168.30.1
*** UnKnown can't find pve.: Non-existent domain
Qualified name, with dot:
C:\>nslookup pve.lab.internal.
Server: UnKnown
Address: 192.168.30.1
Non-authoritative answer:
DNS request timed out.
timeout was 2 seconds. <-- timeout
Name: pve.lab.internal
Address: 192.168.60.2
Qualified name, no dot:
C:\>nslookup pve.lab.internal
Server: UnKnown
Address: 192.168.30.1
DNS request timed out.
timeout was 2 seconds. <-- timeout
Non-authoritative answer:
DNS request timed out.
timeout was 2 seconds. <-- timeout
Name: pve.lab.internal
Address: 192.168.60.2
I think I mentioned this in an earlier post- Dnsmasq is offering the wrong domain to static clients (which my Windows machine is).
Because my desktop IP falls outside of the DHCP range, it is not getting the expected "home.internal" domain. Rather, it is getting the default "h1.home.arpa" domain.
I might expect this behavior if the static client were not entered into Dnsmasq at all, however it is. I have a Host entry with "home.internal". Screens attached. (Note also that 'pve.lab.internal' is in there.)
Despite this host entry, the DHCP offer contains "h1.home.arpa":
Dynamic Host Configuration Protocol (Offer)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0xfa34428a
Seconds elapsed: 0
Bootp flags: 0x8000, Broadcast flag (Broadcast)
Client IP address: 0.0.0.0
Your (client) IP address: 192.168.30.2
Next server IP address: 192.168.30.1
Relay agent IP address: 0.0.0.0
Client MAC address: ASUSTekCOMPU_xx:xx:xx (xx:xx:xx:xx:xx:xx) (*redacted)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Offer)
Option: (54) DHCP Server Identifier (192.168.30.1)
Option: (51) IP Address Lease Time
Option: (58) Renewal Time Value
Option: (59) Rebinding Time Value
Option: (1) Subnet Mask (255.255.255.0)
Option: (28) Broadcast Address (192.168.30.255)
Option: (3) Router
Option: (15) Domain Name
Length: 12
Domain Name: h1.home.arpa
Option: (6) Domain Name Server
Length: 4
Domain Name Server: 192.168.30.1
Option: (255) End
And this is backed up by ipconfig (also attached).
Anyhow, this is only one issue. I just wanted to get this one acknowledged before moving on to the others.
---
EDIT: To be clear, when I say my desktop PC is static, I dot not mean it has a static IP in Windows. It's set to DHCP. What I mean is that there is a static reservation in Dnsmasq, with an IP, MAC, and domain.
The 'pve' host is in fact static. I just added that Host entry for resolution purposes.
I can now confirm all timeouts for nslookup has now been resolved by adding a single DNS server (1.1.1.1) in System > Settings > General without Use System Nameservers checked in Unbound DNS Query Forwarding.
I can see in the firewall logs outbound 1.1.1.1:53 connections from the WAN address in addition to DoH connections that are configured in Unbound. If I create a firewall rule to block :53, the nslookup timeouts return.
I removed all Query Forwarding rules and included them in a /usr/local/etc/unbound.opnsense.d/local.conf file as per https://github.com/opnsense/core/issues/7639. This did not work; I recieved SERVFAIL errors for every query sent for internal domains so this doesn't look like a solution - for my installation anyway.
As @OPNenthu mentioned, I've only started to experience this because I moved to multiple internal domains by following the Dnsmasq migration guide.
Quote from: Monviech (Cedrik) on May 21, 2025, 12:40:55 PMhttps://github.com/opnsense/core/issues/8708
Please no noise in that ticket if possible, its only about the specific forwarding issues that happen due to domain suffixes being appended by some clients.
Thank you for logging this. I apologize for asking (I'm mentally dragging a bit today) does this address the internal resolution failures I posted about above as well?
Quote from: RutgerDiehard on May 21, 2025, 12:51:05 PMI can see in the firewall logs outbound 1.1.1.1:53 connections from the WAN address in addition to DoH connections that are configured in Unbound. If I create a firewall rule to block :53, the nslookup timeouts return.
Yes, and I want to add an observation here as well (the next issue).
Encrypted DNS is not a factor in the leakage to the system resolvers. I noticed that even when Unbound is in recursive mode with no DoT forwards enabled, the default resolver (1.1.1.1:53) will appear in the pf logs sprinkled in between the recursive hits to the authoritative name servers.
The leak does not depend on DoT being active.
I want to make sure this leak issue is also acknowledged.
Quote from: Drinyth on May 21, 2025, 12:47:47 PMQuote from: meyergru on May 21, 2025, 11:47:22 AMI 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.
For what it's worth, I'm using AGH that is listening on port 53 and forwarding queries for local and reverse domains to dnsmasq running on a different port. So similar to having unbound running on port 53 and handling everything non-local. AGH can forward to upstream providers using DoT or DoH. It is also available to configure via the GUI.
Granted, it's not part of the default opnsense offering and one has to add Mimugmail's repo to enable it.
I am also using AGH running on 53. So I thought this will be a simple enough fix to bypass Unbound and use AGH to forward local domains and rDNS queries to Dnsmasq to resolve while everything else goes out over DoT (or even DoH).
Unfortunately, even when configured correctly (I think), there is still lookup timeouts with nslookup. The only thing that stops it is to add a DNS entry (1.1.1.1) in System > Settings > General. As soon as that's added, 1.1.1.1:53 traffic starts appearing in the firewall logs.
Whilst I originally thought this was only Windows boxes that had the issue, I've seen the same on Linux (Ubuntu Server 24.04 LTS) also.
Taking another look at the configuration in System > Settings > General, there is an option to NOT use the local DNS service as the nameserver for this system. It was initially unchecked so I removed 1.1.1.1 in the DNS servers list and checking this box to not use local DNS.
With AGH configured as above, no delays were noticed on any client running nslookup and no traffic to 1.1.1.1:53 was observed in the firewall logs - as to be expected.
Is anybody able to test this when Unbound is providing DNS duties.
@OPNenthu
Can you try:
opnsense-patch https://github.com/opnsense/core/commit/220dbc7931
Afterwards in dnsmasq General Settings in DNS Forwarding select:
"Do not forward to system defined DNS servers" and apply.
With this it should not matter which nameservers are defined by the system, dnsmasq will not forward anything it does not know (if no other forwarders are defined in its own Server tab), but reply with a failure right away, increasing dns lookup times for windows clients even if they first ask wrongly with a suffix first.
@Monviech- patch applied. Will run through some scenarios and post back in some time.
A few clarifying questions from early in this thread, to make sure the results are correct:
1) In order to do proper resolution of a host name on a different Dnsmasq domain (say client A on home.internal wants to resolve client B on iot.internal), do I need to add an additional 'domain-search[119]' DHCP option to offer 'iot.internal' as a search domain to A?
2) Is it required in Dnsmasq to create a separate static range (start/end address) for hosts not taking dynamic leases but are in the same subnet?
3) Is it expected that a static Host entry with MAC+IP+domain will register with DNS and be resolved?
3a) Also for clients which are having static IPs on the host level and not taking DHCP offers?
4) Do static Host entries always get the system default domain in the DHCP offer, or should they get the domain which is listed in the Host entry?
1. No. Option 15 is sent automatically which includes the domain suffix to use. Option 119 is not needed.
2. Not always. If you have a dynamic range and specify static leases in it they will be sent out too. But the lease could be already taken and your static lease will not work then.
3. Yes, if its in /var/etc/dnsmasq-hosts
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.
Quote from: Monviech (Cedrik) on May 21, 2025, 05:11:26 PM2. Not always. If you have a dynamic range and specify static leases in it they will be sent out too. But the lease could be already taken and your static lease will not work then.
All clear, except #2 because I asked incorrectly. My fault.
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)?
Thanks
I don't know, you have to figure this one out.
Quote from: Monviech (Cedrik) on May 21, 2025, 05:11:26 PM4. 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.
Quote from: OPNenthu on May 21, 2025, 05:19:39 PMWhat 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.
I know about the issue with the domain in static mode, its on my list:
https://github.com/opnsense/core/issues/8707
Quote from: Drinyth on May 21, 2025, 05:49:17 PMFrom 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 :)
QuoteThe 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
✅ 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.
default_resolvers.png
Sample result with trailing dot ("nslookup opnsense.org."):
Reporting: Unbound DNS
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:
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:
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
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:
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:
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....
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).
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:
# 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:
# 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:
# 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:
# 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.
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:
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.
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.
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
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.
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
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.
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
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
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).
C:\>nslookup blackbox
Server: UnKnown
Address: 192.168.30.1
Non-authoritative answer:
Name: blackbox.home.internal
Address: 192.168.30.2
C:\>nslookup omv
Server: UnKnown
Address: 192.168.30.1
Non-authoritative answer:
Name: omv.home.internal
Address: 192.168.30.8
C:\>nslookup pve
Server: UnKnown
Address: 192.168.30.1
*** UnKnown can't find pve: Server failed
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.
You can additionally try out:
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
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.
Quote from: Monviech (Cedrik) on May 23, 2025, 10:35:42 AMIt 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
Quote from: Monviech (Cedrik) on May 23, 2025, 10:35:42 AMRegarding short name lookups, thats something you could only solve cleanly if you use dnsmasq as your primary resolver [...]
Quote from: cookiemonster on May 21, 2025, 10:57:09 AMBTW if it helps, being a long-time Stubby user, I could contribute a writeup of my setup of it.
Quote from: meyergru on May 21, 2025, 11:47:22 AMI 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.
Quote from: Monviech (Cedrik) on May 23, 2025, 10:35:42 AM- 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 :)
Quote from: meyergru on May 23, 2025, 12:06:39 PMYes, 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.)
dst_port_53.png
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.