<div dir="ltr"><div>Hello again and thank you for the background.</div><div><br></div><div>Firstly, tcpdump. I would recommend a command like this, run in a separate terminal window just before you make some test queries in another window:</div><div><br></div><div style="margin-left:40px">sudo tcpdump -v -i any -c 10000 -w <filename> port 53</div><div><br></div><div>The -c is a safety net to make sure it stops, should you lose that terminal window for some reason. I have deliberately left out "udp" as DNS can (and does) use TCP as well. I have also left out a host criterion because I don't yet know what addresses in packets (source or destination) will need to be captured, so best to get everything.</div><div><br></div><div>We will also need to know IP addresses on the server on which BIND is running and its routeing table. This is because, in your BIND config, you have not specified a query-source address, so BIND will use the address of the outgoing interface, whatever that is.</div><div><br></div><div>Regarding recursion. I see you have commented out zone ".", whish is good, but that is archaic anyway as root hints have been built into BIND for many years now. So it is quite likely that BIND is recursing, not forwarding. The pcap will confirm this.</div><div><br></div><div>Personally I would not make clients choose a DNS based on whether they get a response or not. Client behaviour across OSs (and versions) can and does vary, so I think you are treading some unstable ground here. Ideally I would send clients to just one DNS server (or at least two, preferably three instances of that function), which in your case would be Adguard. If Adguard needs to resolve local names, configure it to ask BIND, if it can, and have those local zones configured as primary in named.conf.</div><div><br></div><div>I skimmed the Adguard documentation, such as it is, but it's not clear to me exactly how Adguard gets answers or whether it is possible to configure it to use custom, local DNS for certain domains. But if it can, I think that would be the way to go. In that case, if BIND is simply acting as an authoritative server and would not be expected to go elsewhere to obtain information with which to provide answers to clients, then "recursion no;" would be correct.</div><div><br></div><div>Hope that helps.</div><div>Cheers, Greg</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 2 Sept 2025 at 23:54, Sascha Marcel Hacker <<a href="mailto:smhrambo@googlemail.com" target="_blank">smhrambo@googlemail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">First of all, thank you for your quick response.<br>
<br>
In this case, “forwarding” may be somewhat of a misplaced term.<br>
<br>
What I want to achieve, and what has been working for over 5 years,<br>
is for BIND DNS to act as the primary DNS for DNS queries relating to<br>
intranet name resolution (Samba AD),<br>
and for Adguard to act as the secondary DNS for queries outside the<br>
intranet, i.e. the WAN.<br>
<br>
BIND DNS should not forward the requests to Adguard,<br>
as this would result in the loss of client information and thus make<br>
it impossible to draw conclusions about requests from specific<br>
clients.<br>
<br>
This approach does result in a failed request at the primary DNS for<br>
requests outside the intranet, but I can live with that (Homelab).<br>
<br>
kea configures each client with primary and secondary DNS.<br>
Primary DNS ends in x.x.x.1 for each subnet and stands for Bind.<br>
Secondary DNS ends in x.x.x.4 for each subnet and stands for the<br>
Adguard container.<br>
I have a network with multiple subnets and a very restrictive firewall.<br>
<br>
All tests are performed on the same machine(router) on which bind and<br>
adguard are running.<br>
<br>
Recursion is active.<br>
This was due to a problem I had with Samba,<br>
and I was told that it had to be active.<br>
However, that was quite a while ago and had to do with primary and<br>
secondary domain controllers and migrating/sync/zoning them.<br>
<br>
Without recursion (recursion no), It works as it should.<br>
But there are no recursive servers / authoritative DNS servers defined.<br>
<br>
For a better understanding,<br>
I will describe what I understand by forwarding and recursion.<br>
<br>
For me, forwarding was a function whereby a query that cannot be<br>
resolved by my own zones is forwarded to another DNS server (listed in<br>
the forwarders list).<br>
<br>
Recursion is a function that recursively query authoritative DNS<br>
servers for that domain (authoritative DNS servers such as<br>
/usr/share/dns/root.hints) to perform name resolution on its own.<br>
Since I have not configured any authoritative DNS servers in the zone files,<br>
I understood that Bind gives up the name resolution and returns a<br>
failed response.<br>
At least that's how it used to work for me.<br>
<br>
<br>
I only have zones for localhost and the zones configured in Samba for<br>
the subnets.<br>
<br>
This behavior first occurred in July.<br>
Adguard indicates that previously, “all internet-related” requests<br>
were processed by Adguard.<br>
<br>
@Greg<br>
nslookup and netstat should show that name resolution is performed by<br>
Bind and is not answered by Adguard in my Docker container.<br>
<br>
I haven't worked with Wireshare/tcpdump in a long time, and all my<br>
attempts so far have failed.<br>
tcpdump -w ~/dns.pcap udp port 53 & host <a href="http://google.com" rel="noreferrer" target="_blank">google.com</a><br>
is that right?<br>
<br>
Cheers, Sascha<br>
<br>
Am Di., 2. Sept. 2025 um 21:55 Uhr schrieb Greg Choules<br>
<<a href="mailto:gregchoules%2Bbindusers@googlemail.com" target="_blank">gregchoules+bindusers@googlemail.com</a>>:<br>
><br>
> Hi Sascha.<br>
> I have a few questions.<br>
> 1) Are you sure BIND is forwarding? Is that the term you mean to use? Please can you take a binary packet capture (pcap, not copy/paste of terminal output) that shows what the BIND server is doing and send that, You may have disabled global forwarding but recursion is still enabled, as Ondřej points out. Let's look at what queries BIND is sending and to where.<br>
> 2) How do you intend to get queries from BIND to Adguard?<br>
> 3) What was the "nslookupo" intended to show?<br>
><br>
> Send us a bit more information and we'll try to help.<br>
> Cheers, Greg<br>
><br>
> On Tue, 2 Sept 2025 at 18:43, Sascha Marcel Hacker via bind-users <<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a>> wrote:<br>
>><br>
>> Hello,<br>
>> I have a Bind server running for a private Samba AD.<br>
>> The server is used exclusively for internal name resolution,<br>
>> an Adguard container is used for requests to the WAN.<br>
>><br>
>> To enable this, forwarding is disabled on the Bind DNS (primary DNS).<br>
>> Unfortunately, I have noticed that the Bind DNS has been forwarding for some time now,<br>
>> even though this is disabled in the configuration.<br>
>><br>
>> BIND version: BIND 9.18.30-0ubuntu0.24.04.2-Ubuntu (Extended Support Version)<br>
>><br>
>> named.conf.options:<br>
>> ...<br>
>> options {<br>
>> directory “/var/cache/bind”;<br>
>> notify no;<br>
>> empty-zones-enable no;<br>
>> auth-nxdomain yes;<br>
>><br>
>> forward only;<br>
>> forwarders {<br>
>> # 1.1.1.1;<br>
>> # 1.0.0.1;<br>
>> # 9.9.9.9;<br>
>> # 149.112.112.112;<br>
>> # 2606:4700:4700::1111;<br>
>> # 2606:4700:4700::1001;<br>
>> # 2620:fe::fe;<br>
>> # 2620:fe::9;<br>
>> };<br>
>> ...<br>
>><br>
>> named.conf.default-zones:<br>
>> // prime the server with knowledge of the root servers<br>
>> #zone "." {<br>
>> # type hint;<br>
>> # file "/usr/share/dns/root.hints";<br>
>> #};<br>
>><br>
>> // be authoritative for the localhost forward and reverse zones, and for<br>
>> // broadcast zones as per RFC 1912<br>
>><br>
>> zone "localhost" {<br>
>> type master;<br>
>> file "/etc/bind/db.local";<br>
>> };<br>
>><br>
>> zone "127.in-addr.arpa" {<br>
>> type master;<br>
>> file "/etc/bind/db.127";<br>
>> };<br>
>><br>
>> zone "0.in-addr.arpa" {<br>
>> type master;<br>
>> file "/etc/bind/db.0";<br>
>> };<br>
>><br>
>> zone "255.in-addr.arpa" {<br>
>> type master;<br>
>> file "/etc/bind/db.255";<br>
>> };<br>
>><br>
>> Log:<br>
>> Sep 02 19:03:15 routerpi systemd[1]: Starting named.service - BIND Domain Name Server...<br>
>> Sep 02 19:03:16 routerpi named[153686]: starting BIND 9.18.30-0ubuntu0.24.04.2-Ubuntu (Extended Support Version) <id:><br>
>> Sep 02 19:03:16 routerpi named[153686]: running on Linux aarch64 6.8.0-1036-raspi #40-Ubuntu SMP PREEMPT_DYNAMIC Mon Aug 18 09:50:42 UTC 2025<br>
>> Sep 02 19:03:16 routerpi named[153686]: built with '--build=aarch64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/ma><br>
>> Sep 02 19:03:16 routerpi named[153686]: running as: named -f -u bind -n 1<br>
>> Sep 02 19:03:16 routerpi named[153686]: compiled by GCC 13.3.0<br>
>> Sep 02 19:03:16 routerpi named[153686]: compiled with OpenSSL version: OpenSSL 3.0.13 30 Jan 2024<br>
>> Sep 02 19:03:16 routerpi named[153686]: linked to OpenSSL version: OpenSSL 3.0.13 30 Jan 2024<br>
>> Sep 02 19:03:16 routerpi named[153686]: compiled with libuv version: 1.48.0<br>
>> Sep 02 19:03:16 routerpi named[153686]: linked to libuv version: 1.48.0<br>
>> Sep 02 19:03:16 routerpi named[153686]: compiled with libxml2 version: 2.9.14<br>
>> Sep 02 19:03:16 routerpi named[153686]: linked to libxml2 version: 20914<br>
>> Sep 02 19:03:16 routerpi named[153686]: compiled with json-c version: 0.17<br>
>> Sep 02 19:03:16 routerpi named[153686]: linked to json-c version: 0.17<br>
>> Sep 02 19:03:16 routerpi named[153686]: compiled with zlib version: 1.3<br>
>> Sep 02 19:03:16 routerpi named[153686]: linked to zlib version: 1.3<br>
>> Sep 02 19:03:16 routerpi named[153686]: ----------------------------------------------------<br>
>> Sep 02 19:03:16 routerpi named[153686]: BIND 9 is maintained by Internet Systems Consortium,<br>
>> Sep 02 19:03:16 routerpi named[153686]: Inc. (ISC), a non-profit 501(c)(3) public-benefit<br>
>> Sep 02 19:03:16 routerpi named[153686]: corporation. Support and training for BIND 9 are<br>
>> Sep 02 19:03:16 routerpi named[153686]: available at <a href="https://www.isc.org/support" rel="noreferrer" target="_blank">https://www.isc.org/support</a><br>
>> Sep 02 19:03:16 routerpi named[153686]: ----------------------------------------------------<br>
>> Sep 02 19:03:16 routerpi named[153686]: adjusted limit on open files from 524288 to 1048576<br>
>> Sep 02 19:03:16 routerpi named[153686]: found 4 CPUs, using 1 worker thread<br>
>> Sep 02 19:03:16 routerpi named[153686]: using 1 UDP listener per interface<br>
>> Sep 02 19:03:16 routerpi named[153686]: DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448<br>
>> Sep 02 19:03:16 routerpi named[153686]: DS algorithms: SHA-1 SHA-256 SHA-384<br>
>> Sep 02 19:03:16 routerpi named[153686]: HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512<br>
>> Sep 02 19:03:16 routerpi named[153686]: TKEY mode 2 support (Diffie-Hellman): yes<br>
>> Sep 02 19:03:16 routerpi named[153686]: TKEY mode 3 support (GSS-API): yes<br>
>> Sep 02 19:03:16 routerpi named[153686]: the initial working directory is '/'<br>
>> Sep 02 19:03:16 routerpi named[153686]: loading configuration from '/etc/bind/named.conf'<br>
>> Sep 02 19:03:16 routerpi named[153686]: the working directory is now '/var/cache/bind'<br>
>> Sep 02 19:03:16 routerpi named[153686]: reading built-in trust anchors from file '/etc/bind/bind.keys'<br>
>> Sep 02 19:03:16 routerpi named[153686]: looking for GeoIP2 databases in '/usr/share/GeoIP'<br>
>> Sep 02 19:03:16 routerpi named[153686]: using default UDP/IPv4 port range: [32768, 60999]<br>
>> Sep 02 19:03:16 routerpi named[153686]: using default UDP/IPv6 port range: [32768, 60999]<br>
>> Sep 02 19:03:16 routerpi named[153686]: listening on IPv4 interface lo, 127.0.0.1#53<br>
>> ...<br>
>> Sep 02 19:03:16 routerpi named[153686]: generating session key for dynamic DNS<br>
>> Sep 02 19:03:16 routerpi named[153686]: sizing zone task pool based on 4 zones<br>
>> Sep 02 19:03:16 routerpi named[153686]: Loading 'AD DNS Zone' using driver dlopen<br>
>> Sep 02 19:03:16 routerpi named[153686]: samba_dlz: started for DN ...<br>
>> Sep 02 19:03:16 routerpi named[153686]: samba_dlz: starting configure<br>
>> ...<br>
>> Sep 02 19:03:16 routerpi named[153686]: none:99: 'max-cache-size 90%' - setting to 3405MB (out of 3784MB)<br>
>> Sep 02 19:03:16 routerpi named[153686]: /etc/bind/named.conf.options:34: no forwarders seen; disabling forwarding<br>
>> Sep 02 19:03:16 routerpi named[153686]: set up managed keys zone for view _default, file 'managed-keys.bind'<br>
>> Sep 02 19:03:16 routerpi named[153686]: /etc/bind/named.conf.options:34: no forwarders seen; disabling forwarding<br>
>> Sep 02 19:03:16 routerpi named[153686]: configuring command channel from '/etc/bind/rndc.key'<br>
>> Sep 02 19:03:16 routerpi named[153686]: command channel listening on 127.0.0.1#953<br>
>> Sep 02 19:03:16 routerpi named[153686]: configuring command channel from '/etc/bind/rndc.key'<br>
>> Sep 02 19:03:16 routerpi named[153686]: command channel listening on ::1#953<br>
>> Sep 02 19:03:16 routerpi systemd[1]: Started named.service - BIND Domain Name Server.<br>
>><br>
>> netstat -tulpen | grep named:<br>
>> ...<br>
>> tcp 0 0 <a href="http://127.0.0.1:53" rel="noreferrer" target="_blank">127.0.0.1:53</a> 0.0.0.0:* LISTEN 114 526776 153686/named<br>
>> tcp 0 0 <a href="http://127.0.0.1:953" rel="noreferrer" target="_blank">127.0.0.1:953</a> 0.0.0.0:* LISTEN 114 526829 153686/named<br>
>> ...<br>
>> tcp6 0 0 ::1:953 :::* LISTEN 114 526830 153686/named<br>
>> tcp6 0 0 ::1:53 :::* LISTEN 114 526804 153686/named<br>
>> ...<br>
>> udp 0 0 <a href="http://127.0.0.1:53" rel="noreferrer" target="_blank">127.0.0.1:53</a> 0.0.0.0:* 114 526775 153686/named<br>
>> udp6 0 0 ::1:53 :::* 114 526803 153686/named<br>
>> ...<br>
>><br>
>> nslookup <a href="http://google.com" rel="noreferrer" target="_blank">google.com</a>:<br>
>> Server: 127.0.0.1<br>
>> Address: 127.0.0.1#53<br>
>><br>
>> Non-authoritative answer:<br>
>> Name: <a href="http://google.com" rel="noreferrer" target="_blank">google.com</a><br>
>> Address: 142.251.36.174<br>
>> Name: <a href="http://google.com" rel="noreferrer" target="_blank">google.com</a><br>
>> Address: 2a00:1450:4016:808::200e<br>
>><br>
>> resolve.conf:<br>
>> # operation for /etc/resolv.conf.<br>
>><br>
>> nameserver 127.0.0.1<br>
>> nameserver 10.13.1.4<br>
>> nameserver 1.1.1.1<br>
>> nameserver ::1<br>
>> nameserver fdda:9280:731e:1:0:4::1<br>
>> nameserver 2606:4700:4700::1111<br>
>><br>
>> --<br>
>> Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
>><br>
>> ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
>><br>
>><br>
>> bind-users mailing list<br>
>> <a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
>> <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div>