Bind forwards DNS requests even though forwarding is disabled.
Greg Choules
gregchoules+bindusers at googlemail.com
Wed Sep 3 06:46:47 UTC 2025
Hello again and thank you for the background.
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:
sudo tcpdump -v -i any -c 10000 -w <filename> port 53
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.
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.
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.
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.
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.
Hope that helps.
Cheers, Greg
On Tue, 2 Sept 2025 at 23:54, Sascha Marcel Hacker <smhrambo at googlemail.com>
wrote:
> First of all, thank you for your quick response.
>
> In this case, “forwarding” may be somewhat of a misplaced term.
>
> What I want to achieve, and what has been working for over 5 years,
> is for BIND DNS to act as the primary DNS for DNS queries relating to
> intranet name resolution (Samba AD),
> and for Adguard to act as the secondary DNS for queries outside the
> intranet, i.e. the WAN.
>
> BIND DNS should not forward the requests to Adguard,
> as this would result in the loss of client information and thus make
> it impossible to draw conclusions about requests from specific
> clients.
>
> This approach does result in a failed request at the primary DNS for
> requests outside the intranet, but I can live with that (Homelab).
>
> kea configures each client with primary and secondary DNS.
> Primary DNS ends in x.x.x.1 for each subnet and stands for Bind.
> Secondary DNS ends in x.x.x.4 for each subnet and stands for the
> Adguard container.
> I have a network with multiple subnets and a very restrictive firewall.
>
> All tests are performed on the same machine(router) on which bind and
> adguard are running.
>
> Recursion is active.
> This was due to a problem I had with Samba,
> and I was told that it had to be active.
> However, that was quite a while ago and had to do with primary and
> secondary domain controllers and migrating/sync/zoning them.
>
> Without recursion (recursion no), It works as it should.
> But there are no recursive servers / authoritative DNS servers defined.
>
> For a better understanding,
> I will describe what I understand by forwarding and recursion.
>
> For me, forwarding was a function whereby a query that cannot be
> resolved by my own zones is forwarded to another DNS server (listed in
> the forwarders list).
>
> Recursion is a function that recursively query authoritative DNS
> servers for that domain (authoritative DNS servers such as
> /usr/share/dns/root.hints) to perform name resolution on its own.
> Since I have not configured any authoritative DNS servers in the zone
> files,
> I understood that Bind gives up the name resolution and returns a
> failed response.
> At least that's how it used to work for me.
>
>
> I only have zones for localhost and the zones configured in Samba for
> the subnets.
>
> This behavior first occurred in July.
> Adguard indicates that previously, “all internet-related” requests
> were processed by Adguard.
>
> @Greg
> nslookup and netstat should show that name resolution is performed by
> Bind and is not answered by Adguard in my Docker container.
>
> I haven't worked with Wireshare/tcpdump in a long time, and all my
> attempts so far have failed.
> tcpdump -w ~/dns.pcap udp port 53 & host google.com
> is that right?
>
> Cheers, Sascha
>
> Am Di., 2. Sept. 2025 um 21:55 Uhr schrieb Greg Choules
> <gregchoules+bindusers at googlemail.com>:
> >
> > Hi Sascha.
> > I have a few questions.
> > 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.
> > 2) How do you intend to get queries from BIND to Adguard?
> > 3) What was the "nslookupo" intended to show?
> >
> > Send us a bit more information and we'll try to help.
> > Cheers, Greg
> >
> > On Tue, 2 Sept 2025 at 18:43, Sascha Marcel Hacker via bind-users <
> bind-users at lists.isc.org> wrote:
> >>
> >> Hello,
> >> I have a Bind server running for a private Samba AD.
> >> The server is used exclusively for internal name resolution,
> >> an Adguard container is used for requests to the WAN.
> >>
> >> To enable this, forwarding is disabled on the Bind DNS (primary DNS).
> >> Unfortunately, I have noticed that the Bind DNS has been forwarding for
> some time now,
> >> even though this is disabled in the configuration.
> >>
> >> BIND version: BIND 9.18.30-0ubuntu0.24.04.2-Ubuntu (Extended Support
> Version)
> >>
> >> named.conf.options:
> >> ...
> >> options {
> >> directory “/var/cache/bind”;
> >> notify no;
> >> empty-zones-enable no;
> >> auth-nxdomain yes;
> >>
> >> forward only;
> >> forwarders {
> >> # 1.1.1.1;
> >> # 1.0.0.1;
> >> # 9.9.9.9;
> >> # 149.112.112.112;
> >> # 2606:4700:4700::1111;
> >> # 2606:4700:4700::1001;
> >> # 2620:fe::fe;
> >> # 2620:fe::9;
> >> };
> >> ...
> >>
> >> named.conf.default-zones:
> >> // prime the server with knowledge of the root servers
> >> #zone "." {
> >> # type hint;
> >> # file "/usr/share/dns/root.hints";
> >> #};
> >>
> >> // be authoritative for the localhost forward and reverse zones, and for
> >> // broadcast zones as per RFC 1912
> >>
> >> zone "localhost" {
> >> type master;
> >> file "/etc/bind/db.local";
> >> };
> >>
> >> zone "127.in-addr.arpa" {
> >> type master;
> >> file "/etc/bind/db.127";
> >> };
> >>
> >> zone "0.in-addr.arpa" {
> >> type master;
> >> file "/etc/bind/db.0";
> >> };
> >>
> >> zone "255.in-addr.arpa" {
> >> type master;
> >> file "/etc/bind/db.255";
> >> };
> >>
> >> Log:
> >> Sep 02 19:03:15 routerpi systemd[1]: Starting named.service - BIND
> Domain Name Server...
> >> Sep 02 19:03:16 routerpi named[153686]: starting BIND
> 9.18.30-0ubuntu0.24.04.2-Ubuntu (Extended Support Version) <id:>
> >> 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
> >> Sep 02 19:03:16 routerpi named[153686]: built with
> '--build=aarch64-linux-gnu' '--prefix=/usr'
> '--includedir=${prefix}/include' '--mandir=${prefix}/share/ma>
> >> Sep 02 19:03:16 routerpi named[153686]: running as: named -f -u bind -n
> 1
> >> Sep 02 19:03:16 routerpi named[153686]: compiled by GCC 13.3.0
> >> Sep 02 19:03:16 routerpi named[153686]: compiled with OpenSSL version:
> OpenSSL 3.0.13 30 Jan 2024
> >> Sep 02 19:03:16 routerpi named[153686]: linked to OpenSSL version:
> OpenSSL 3.0.13 30 Jan 2024
> >> Sep 02 19:03:16 routerpi named[153686]: compiled with libuv version:
> 1.48.0
> >> Sep 02 19:03:16 routerpi named[153686]: linked to libuv version: 1.48.0
> >> Sep 02 19:03:16 routerpi named[153686]: compiled with libxml2 version:
> 2.9.14
> >> Sep 02 19:03:16 routerpi named[153686]: linked to libxml2 version: 20914
> >> Sep 02 19:03:16 routerpi named[153686]: compiled with json-c version:
> 0.17
> >> Sep 02 19:03:16 routerpi named[153686]: linked to json-c version: 0.17
> >> Sep 02 19:03:16 routerpi named[153686]: compiled with zlib version: 1.3
> >> Sep 02 19:03:16 routerpi named[153686]: linked to zlib version: 1.3
> >> Sep 02 19:03:16 routerpi named[153686]:
> ----------------------------------------------------
> >> Sep 02 19:03:16 routerpi named[153686]: BIND 9 is maintained by
> Internet Systems Consortium,
> >> Sep 02 19:03:16 routerpi named[153686]: Inc. (ISC), a non-profit
> 501(c)(3) public-benefit
> >> Sep 02 19:03:16 routerpi named[153686]: corporation. Support and
> training for BIND 9 are
> >> Sep 02 19:03:16 routerpi named[153686]: available at
> https://www.isc.org/support
> >> Sep 02 19:03:16 routerpi named[153686]:
> ----------------------------------------------------
> >> Sep 02 19:03:16 routerpi named[153686]: adjusted limit on open files
> from 524288 to 1048576
> >> Sep 02 19:03:16 routerpi named[153686]: found 4 CPUs, using 1 worker
> thread
> >> Sep 02 19:03:16 routerpi named[153686]: using 1 UDP listener per
> interface
> >> Sep 02 19:03:16 routerpi named[153686]: DNSSEC algorithms: RSASHA1
> NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519
> ED448
> >> Sep 02 19:03:16 routerpi named[153686]: DS algorithms: SHA-1 SHA-256
> SHA-384
> >> Sep 02 19:03:16 routerpi named[153686]: HMAC algorithms: HMAC-MD5
> HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
> >> Sep 02 19:03:16 routerpi named[153686]: TKEY mode 2 support
> (Diffie-Hellman): yes
> >> Sep 02 19:03:16 routerpi named[153686]: TKEY mode 3 support (GSS-API):
> yes
> >> Sep 02 19:03:16 routerpi named[153686]: the initial working directory
> is '/'
> >> Sep 02 19:03:16 routerpi named[153686]: loading configuration from
> '/etc/bind/named.conf'
> >> Sep 02 19:03:16 routerpi named[153686]: the working directory is now
> '/var/cache/bind'
> >> Sep 02 19:03:16 routerpi named[153686]: reading built-in trust anchors
> from file '/etc/bind/bind.keys'
> >> Sep 02 19:03:16 routerpi named[153686]: looking for GeoIP2 databases in
> '/usr/share/GeoIP'
> >> Sep 02 19:03:16 routerpi named[153686]: using default UDP/IPv4 port
> range: [32768, 60999]
> >> Sep 02 19:03:16 routerpi named[153686]: using default UDP/IPv6 port
> range: [32768, 60999]
> >> Sep 02 19:03:16 routerpi named[153686]: listening on IPv4 interface lo,
> 127.0.0.1#53
> >> ...
> >> Sep 02 19:03:16 routerpi named[153686]: generating session key for
> dynamic DNS
> >> Sep 02 19:03:16 routerpi named[153686]: sizing zone task pool based on
> 4 zones
> >> Sep 02 19:03:16 routerpi named[153686]: Loading 'AD DNS Zone' using
> driver dlopen
> >> Sep 02 19:03:16 routerpi named[153686]: samba_dlz: started for DN ...
> >> Sep 02 19:03:16 routerpi named[153686]: samba_dlz: starting configure
> >> ...
> >> Sep 02 19:03:16 routerpi named[153686]: none:99: 'max-cache-size 90%' -
> setting to 3405MB (out of 3784MB)
> >> Sep 02 19:03:16 routerpi named[153686]:
> /etc/bind/named.conf.options:34: no forwarders seen; disabling forwarding
> >> Sep 02 19:03:16 routerpi named[153686]: set up managed keys zone for
> view _default, file 'managed-keys.bind'
> >> Sep 02 19:03:16 routerpi named[153686]:
> /etc/bind/named.conf.options:34: no forwarders seen; disabling forwarding
> >> Sep 02 19:03:16 routerpi named[153686]: configuring command channel
> from '/etc/bind/rndc.key'
> >> Sep 02 19:03:16 routerpi named[153686]: command channel listening on
> 127.0.0.1#953
> >> Sep 02 19:03:16 routerpi named[153686]: configuring command channel
> from '/etc/bind/rndc.key'
> >> Sep 02 19:03:16 routerpi named[153686]: command channel listening on
> ::1#953
> >> Sep 02 19:03:16 routerpi systemd[1]: Started named.service - BIND
> Domain Name Server.
> >>
> >> netstat -tulpen | grep named:
> >> ...
> >> tcp 0 0 127.0.0.1:53 0.0.0.0:*
> LISTEN 114 526776 153686/named
> >> tcp 0 0 127.0.0.1:953 0.0.0.0:*
> LISTEN 114 526829 153686/named
> >> ...
> >> tcp6 0 0 ::1:953 :::*
> LISTEN 114 526830 153686/named
> >> tcp6 0 0 ::1:53 :::*
> LISTEN 114 526804 153686/named
> >> ...
> >> udp 0 0 127.0.0.1:53 0.0.0.0:*
> 114 526775 153686/named
> >> udp6 0 0 ::1:53 :::*
> 114 526803 153686/named
> >> ...
> >>
> >> nslookup google.com:
> >> Server: 127.0.0.1
> >> Address: 127.0.0.1#53
> >>
> >> Non-authoritative answer:
> >> Name: google.com
> >> Address: 142.251.36.174
> >> Name: google.com
> >> Address: 2a00:1450:4016:808::200e
> >>
> >> resolve.conf:
> >> # operation for /etc/resolv.conf.
> >>
> >> nameserver 127.0.0.1
> >> nameserver 10.13.1.4
> >> nameserver 1.1.1.1
> >> nameserver ::1
> >> nameserver fdda:9280:731e:1:0:4::1
> >> nameserver 2606:4700:4700::1111
> >>
> >> --
> >> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
> >>
> >> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
> >>
> >>
> >> bind-users mailing list
> >> bind-users at lists.isc.org
> >> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20250903/f15a08dc/attachment-0001.htm>
More information about the bind-users
mailing list