Re: My Introduction and current issues -

[bind9]

On 2025-05-10 02:03, Greg Choules wrote:

@Danilo you are correct, the contents of /etc/resolv.conf are not set 
by BIND and BIND itself does not use them. But all applications running 
on that machine (including dig, unless you specify @) that 
want some kind of name resolution will make OS system calls and then 
the OS *will* use what's in resolv.conf to determine where to send DNS 
queries on behalf of the application.


Therefore, I will change resolv.conf to replace the current IP with the 
IP of the server machine itself and, perhaps, Localhost itself 
(127.0.0.1). I never created resolv.conf and have no idea how it got 
created. It's weird because "/etc/resolv.conf" is actally a symlink to 
/run/systemd/resolve/stub-resolv.conf"... the file I need to change.


In the very first mail, bind9 said that the BIND config contains this:

listen-on port 53 { 123.123.123.10; 127.0.0.1; };  Correct
At startup, the named process will tell the OS to send it packets that 
have those destination addresses AND destination port 53. All fine so 
far.


However, bind9 also said this:

The resolv.conf file contains:

nameserver 127.0.0.53 Confining things to the Ubuntu box for now, this 
tells the OS to make DNS queries to 127.0.0.53 - the 53 is *not* the 
port number, it is the 4th octet of the IPV4 address.
So the OS sends queries to 127.0.0.53 and named is listening on 
127.0.0.1. I think you can see that this isn't going to work.


I will change that immediately. I will make that entry the same IP as 
my server machine itself. Do I need a "search" entry for the name 
server as well? And if yes, should it be just the domain name or the 
FQDN of the server machine?


I don't know why resolv.conf contains that nameserver address (and it 
is an address, not a name - read the man page for resolv.conf), but the 
easiest solution would be to add that address to the set that named is 
listening on. i.e.


listen-on port 53 { 123.123.123.10; 127.0.0.1; 127.0.0.53;};

The 127.0.0.53 addr is invalid for any form of listening. I will 
eliminate any reference to it. I will use only the server machine's IP 
and the loopback.


You will need to stop/edit/start named for this change to take effect.

I usually do "systemctl restart named".

This should fix your issues with apt and other applications running on 
the Ubuntu server.
I agree that you should not be using 123.123.123.0/24 [1]. Please read 
RFC1918 for guidance on private addressing.


Again, 123.123.123.0/24 is not the actual subnet address. It's just a 
place holder in the named.conf.options file to mask the real subnet 
address. For security reasons, I do not publish the actual internal 
subnet address. But rest assured, the real subnet address definitely 
falls within the correct publishing guidelines (i.e. 19*) for the head 
octet.


tcpdump has a lot of options. For capturing DNS traffic to disk I would 
suggest this as a first pass:


sudo tcpdump -c 1000 -n -i all -w  port 53

This captures all port 53 traffic on any interface (including the 
loopback), stops after 1000 packets (if you don't stop it yourself with 
ctrl-C), writes binary capture data to the file  (you choose 
whatever name you like) and tells tcpdump to *not* attempt to resolve 
addresses to names. This may be irrelevant since it is capturing to 
disk but doesn't hurt.


Thanks much! This will help quite a bit.

Over to the Windows machine now. You will not have dig by default. BIND 
for Windows (including utilities like dig) hasn't existed for several 
years. It is still available to download but I *don't* recommend you 
install it.


I won't.  Not worth it.  nslookup seems to be working well enough. And, 
as stated below, I'll get Wireshark installed.


Windows nslookup is actually not bad for making test queries, 
especially if used in interactive mode. Again, read the help to see 
what options it has.


Precisely.
Wireshark can be downloaded and installed for free and I recommend that 
you do that on the Windows machine, so that when you have captured 
traffic on the Ubuntu server, once you have copied the capture file to 
Windows you can open it in Wireshark there. Wireshark can also capture 
packets, like tcpdump, so you can use it to see exactly what your 
Windows machine is doing with DNS.


I'll go ahead and do it.  I might actually have it already for install 
on Windows, but I'll check for the most current version.


Hopefully this lot gives you some things to try and also to read, to 
understand the behaviour you are seeing.

Cheers, Greg

Thanks much again!

On Sat, 10 May 2025 at 06:01, Danilo Godec via bind-users 
 wrote:


On 10.05.2025 05:29, bi...@clearviz.biz wrote:

Also check /etc/resolv.conf and see what address(es) is/are listed as 
nameservers.


The resolv.conf file contains:

nameserver 127.0.0.53

search mydomain.net [2]   (where mydomain is my actual domain name and 
not the FQDN of the machine (i.e. "machine01.mydomain.net [3]")).


This was entered by default as BIND

Re: My Introduction and current issues -

[Hika van den Hoven]

Hoi Arnold,

Be aware that in most configurations /etc/resolv.conf is (re)created
at boot time on configuration of the nic. If the nic is configured
through dhcp, check there for the weird ip address! If it is
configured otherwise, check there.
It might be that the stub file is not overwritten at boot.

Saturday, May 10, 2025, 2:40:30 PM, you wrote:

>  
> On 2025-05-10 02:03, Greg Choules wrote:
>  
>  
>  
>  
> @Danilo you are correct, the contents of /etc/resolv.conf are not
> set by BIND and BIND itself does not use them. But all applications
> running on that machine (including dig, unless you specify
> @) that want some kind of name resolution will make OS
> system calls and then the OS *will* use what's in resolv.conf to
> determine where to send DNS queries on behalf of the application. 
>   
> Therefore, I will change resolv.conf to replace the current IP with
> the IP of the server machine itself and, perhaps, Localhost itself
> (127.0.0.1). I never created resolv.conf and have no idea how it got
> created. It's weird because "/etc/resolv.conf" is actally a symlink
> to /run/systemd/resolve/stub-resolv.conf"... the file I need to change.
>   
 


Tot mails,
 bind userlist  mailto:bind-users@lists.isc.org

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens
--

-- 
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: My Introduction and current issues -

[bind9]

On 2025-05-10 04:26, Ondřej Surý wrote:


I think there's too many moving parts.

Personally, I would suggest to remove systemd-resolved as a first step 
and configure the system to use the configured resolver directly.


Systemd-resolved was disabled a while ago.  One of the first things I 
did.


However, it is also unclear to me whether the desktop station in 
question is Linux, Windows and if it is Linux what distribution does it 
use.


I have both. Mostly, I'm using a Windows 7 desktop (the one I'm on 
right now) to do testing. I also have two Windows 10 laptops. There is 
also one Ubuntu client (22.04, same as the server).


As I said - too many moving parts and it's not even clear where to 
start the debugging.


I appreciate your help, nonetheless.  I will try to stabilize things to 
make the parts "less moving."  I will focus upon eliminating any 
remnants of Systemd-resolved first and then take it from there.


Ondrej

-- Ondřej Surý -- ISC (He/Him)

My working hours and your working hours may be different. Please do not 
feel obligated to reply outside your normal working hours.


On 10. 5. 2025, at 9:03, Greg Choules via bind-users 
 wrote:


@Danilo you are correct, the contents of /etc/resolv.conf are not set 
by BIND and BIND itself does not use them. But all applications running 
on that machine (including dig, unless you specify @) that 
want some kind of name resolution will make OS system calls and then 
the OS *will* use what's in resolv.conf to determine where to send DNS 
queries on behalf of the application.


In the very first mail, bind9 said that the BIND config contains this:

listen-on port 53 { 123.123.123.10; 127.0.0.1; };
At startup, the named process will tell the OS to send it packets that 
have those destination addresses AND destination port 53. All fine so 
far.


However, bind9 also said this:

The resolv.conf file contains:

nameserver 127.0.0.53 Confining things to the Ubuntu box for now, this 
tells the OS to make DNS queries to 127.0.0.53 - the 53 is *not* the 
port number, it is the 4th octet of the IPV4 address.
So the OS sends queries to 127.0.0.53 and named is listening on 
127.0.0.1. I think you can see that this isn't going to work.
I don't know why resolv.conf contains that nameserver address (and it 
is an address, not a name - read the man page for resolv.conf), but the 
easiest solution would be to add that address to the set that named is 
listening on. i.e.


listen-on port 53 { 123.123.123.10; 127.0.0.1; 127.0.0.53;};
You will need to stop/edit/start named for this change to take 
effect.This should fix your issues with apt and other applications 
running on the Ubuntu server.
I agree that you should not be using 123.123.123.0/24 [1]. Please read 
RFC1918 for guidance on private addressing.


tcpdump has a lot of options. For capturing DNS traffic to disk I would 
suggest this as a first pass:


sudo tcpdump -c 1000 -n -i all -w  port 53

This captures all port 53 traffic on any interface (including the 
loopback), stops after 1000 packets (if you don't stop it yourself with 
ctrl-C), writes binary capture data to the file  (you choose 
whatever name you like) and tells tcpdump to *not* attempt to resolve 
addresses to names. This may be irrelevant since it is capturing to 
disk but doesn't hurt.


Over to the Windows machine now. You will not have dig by default. BIND 
for Windows (including utilities like dig) hasn't existed for several 
years. It is still available to download but I *don't* recommend you 
install it.
Windows nslookup is actually not bad for making test queries, 
especially if used in interactive mode. Again, read the help to see 
what options it has.
Wireshark can be downloaded and installed for free and I recommend that 
you do that on the Windows machine, so that when you have captured 
traffic on the Ubuntu server, once you have copied the capture file to 
Windows you can open it in Wireshark there. Wireshark can also capture 
packets, like tcpdump, so you can use it to see exactly what your 
Windows machine is doing with DNS.


Hopefully this lot gives you some things to try and also to read, to 
understand the behaviour you are seeing.

Cheers, Greg

On Sat, 10 May 2025 at 06:01, Danilo Godec via bind-users 
 wrote:


On 10.05.2025 05:29, bi...@clearviz.biz wrote:

Also check /etc/resolv.conf and see what address(es) is/are listed as 
nameservers.


The resolv.conf file contains:

nameserver 127.0.0.53

search mydomain.net [2]   (where mydomain is my actual domain name and 
not the FQDN of the machine (i.e. "machine01.mydomain.net [3]")).


This was entered by default as BIND was installed.   I am wondering if 
the "namesever" should be the machine name on which the server is 
running and not 127.0.0.53 And I gather the 53 on the end has to do 
with the port on which it's listening. I'm not sure if it's correct 
that the 4th octet is substituted like that.


/etc/resolv.conf is not changed or set by BIND, as far as I know it's

Re: My Introduction and current issues -

[Fred Morris]

Of course: it's ALWAYS DNS! (Sorry, I had to say that because it's 
Saturday. I'll move on.)


Actually in this case I'm pretty sure it /is/ systemd resolved, so yeah it 
is kinda DNS because systemd is kinda trying to do DNS.


On Sat, 10 May 2025, Greg Choules via bind-users wrote:


[...] But all applications running on
that machine (including dig, unless you specify @) that want some
kind of name resolution will make OS system calls and then the OS *will*
use what's in resolv.conf to determine where to send DNS queries on behalf
of the application.


Yup. And that may be ignored by e.g. the web browser or some webified app 
attempting to do its own recursing; and that's the reason why we specify 
trying with certain applications, because I think we understand their 
behavior. Not directed at you, Greg.



In the very first mail, bind9 said that the BIND config contains this:

listen-on port 53 { 123.123.123.10; 127.0.0.1; };

At startup, the named process will tell the OS to send it packets that have
those destination addresses AND destination port 53. All fine so far.
[...]
I think you can see that this isn't going to work.
I don't know why resolv.conf contains that nameserver address (and it is an
address, not a name - read the man page for resolv.conf), but the easiest
solution would be to add that address to the set that named is listening
on. i.e.

listen-on port 53 { 123.123.123.10; 127.0.0.1; 127.0.0.53;};


I'll bet you a beer that it doesn't work... or not the way you think it 
does. BIND may start (or not), but check the logs and see if it's really 
listening on 127.0.0.53.


I'll bet you find it isn't. Check with "ifconfig" ("ip address show") 
and see if 127.0.0.53 is bound to an interface. Actually, I'm not certain 
that ifconfig and ip utilize the exact same library codepaths. Anyway, 
last time I tried this wasn't the very latest version of Ubuntu or BIND, 
but BIND refused to bind the address unless it was explicitly bound to an 
interface.


So while TECHNICALLY any address in 127.0.0.0/8 should be loopback, not 
everything sees it this way. It didn't rise in my mind to the level of a 
BIND bug, but it does expose a shear layer in the compatibility tooling. I 
didn't take the time to figure out how to bind additional loopback 
addresses in order to make BIND happy, the revelation that systemd was 
running something was enough to make me look for something to throw.



You will need to stop/edit/start named for this change to take effect.


Stop! Squirrel wearing a systemd tshirt! Kill / maim / destroy / drive off 
systemd resolved. Then make sure that resolv.conf is not being hijacked.


Now try again.

--

Fred

--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: My Introduction and current issues -

[Nick Tait via bind-users]

On 11/05/2025 07:28, Fred Morris wrote:
Stop! Squirrel wearing a systemd tshirt! Kill / maim / destroy / drive 
off systemd resolved. Then make sure that resolv.conf is not being 
hijacked.


Now try again. 


Contrary to popular opinion -- on this list at least -- systemd-resolved 
is /not/ evil. It is just misunderstood...


Yes it is complex, and yes you can avoid that complexity by getting rid 
of it. But it also has a few features that I personally find useful. So 
before you run off to get rid of it, let me at least highlight some of 
those features? But first, let me set the record straight on a few things:


 * Systemd-resolved is the resolver component of the systemd suite.
   (From Wikipedia : "systemd is
   a software suite that provides an array of system components for
   Linux operating systems.")
 * Ubuntu uses systemd, including systemd-resolved by default.
 * In the default set-up, systemd-resolved provides a local DNS stub
   listener on the IP addresses 127.0.0.53 and 127.0.0.54 on the local
   loopback interface, and /etc/resolv.conf is a symbolic link to
   /run/systemd/resolve/stub-resolv.conf. This is done to allow name
   resolution on the local machine to be serviced by the local
   systemd-resolved service.
 * The systemd-resolved service has its own configuration which
   determines which mechanisms to use to answer name resolution
   queries, and (assuming that it is configured to use DNS) which DNS
   server(s) to use as a recursive resolver.

I could be mistaken, but my belief is that the goal of this set-up was 
to make name resolution work consistently, regardless of which mechanism 
(i.e. C function call) is used by an application. To illustrate my 
point, here is the output I get from two different name resolution 
utilities when trying to resolve a name that only exists in my 
/etc/hosts file:


   $*getent hosts ip6-loopback*
   ::1 ip6-localhost ip6-loopback
   $*host ip6-loopback*
   Host ip6-loopback not found: 3(NXDOMAIN)

(The reason for this difference is that the "getent" command uses the 
NSS library to resolve the name, which checks my /etc/hosts file before 
going to DNS; whereas the "host" command uses the Resolver library which 
only uses DNS.)


Unfortunately there are (or at least were) problems with the default 
set-up, including the limitation that the stub listener wouldn't pass 
through the AD flag in a DNS response. (The AD flag is used with DNSSEC 
to indicate that the data is authentic.) I'm not sure if this has been 
fixed, but this is/was a good reason not to use the stub listener -- and 
is the reason I /don't/ use the stub listener. Luckily the stub listener 
can be easily disabled by setting "DNSStubListener=no" in the 
systemd-resolved configuration. But of course doing this means that 
systemd-resolved isn't being used for much (if anything). So at this 
point (to continue to use it at all) it is necessary to install the 
nss-resolve library and tweak your /etc/nsswitch.conf file. But I'm not 
going to get into that detail in this email...


Getting back to the features of systemd-resolved:

 * It is a one-stop shop for host name resolution. It can provide:
 o synthetic records (including localhost, and the host's own name
   -- which admittedly isn't necessarily a good thing).
 o LLMNR (which is kind of obsolete now) for single-label names.
 o MDNS for names with ".local" suffix.
 o DNS for multi-label names (excluding ".local" suffix), and
   single-label names with search suffix applied to them.
 * I like the fact that it 'feels' like part of systemd, including
   stuff like:
 o You can specify search domains in your netplan configuration
   (using networkd as the renderer in netplan).
 o The "resolvectl" utility feels like a sibling to the other
   systemd utilities like "systemctl", "journalctl", etc.

Nick.

P.S. I hope I'm not (re-) starting some sort of holy war. That is not my 
intention, and I'm definitely /not/ trying to say that everyone should 
use systemd-resolved. I'm just trying to be an "active bystander". :-)
-- 
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: My Introduction and current issues -

[Fred Morris]

BIND insists on addresses bound to interfaces (at least, that's my 
contention, based on experience yesterday, which may or may not reflect 
some reality which has been manufactured today).


resolved uses a loopback address which is not bound to an interface (at 
least that's my experience, which may or may not reflect some reality 
which has been manufactured today).


Nick, I'll ask before the fold: how do I explicitly bind 127.0.0.53 to the 
lo interface before systemd starts?


On Sun, 11 May 2025, Nick Tait via bind-users wrote:


On 11/05/2025 07:28, Fred Morris wrote:

 Stop! Squirrel wearing a systemd tshirt! Kill / maim / destroy / drive off
 systemd resolved. Then make sure that resolv.conf is not being hijacked.

 Now try again. 


Contrary to popular opinion -- on this list at least -- systemd-resolved is 
/not/ evil. It is just misunderstood...


Yes it is complex, and yes you can avoid that complexity by getting rid of 
it. But it also has a few features that I personally find useful. So before 
you run off to get rid of it, let me at least highlight some of those 
features?


You know what? I'd like some features too. But I don't go around binding 
to addresses which are not bound to interfaces. Never. I just don't do 
that. Venturing close to the "political" line: I don't see anything in 
BIND which even hints at a whiff of dbus.



 * In the default set-up, systemd-resolved provides a local DNS stub
   listener on the IP addresses 127.0.0.53 and 127.0.0.54 on the local
   loopback interface, and /etc/resolv.conf is a symbolic link to
   /run/systemd/resolve/stub-resolv.conf. This is done to allow name
   resolution on the local machine to be serviced by the local
   systemd-resolved service.


From where I sit it looks like it sits on an unbound address to shim into 
established, conformant, admittedly baroque and crenellated mechanisms for 
managing name resolution... I actually laughed when you mentioned NSS 
(thanks)... while staying as catastrophically inscrutable as wiring the 
red wire to ground; and that this works to its advantage, making it 
difficult to remove by people who would never, ever imagine that core 
software would abrogate established contractual mechanisms without copious 
documentation... and that the best we would do would be apologaeia from 
the likes of Fred Morris or Nick Tait!


I could be mistaken, but my belief is that the goal of this set-up was to 
make name resolution work consistently, regardless of which mechanism (i.e. C 
function call) is used by an application.


libc. Granted, your mileage may vary with your implementation, tire 
inflation, RAM color and CPU orientation... but charm never matters.


Rhetorically, how much does it take to get your stack explicitly unloved? 
I don't know exactly, we don't have a lot of data points. 
https://security.opensuse.org/2025/05/07/deepin-desktop-removal.html


As far as I know, BIND has never chosen "DNS eins" as a molehill to die 
on.


--

Fred Morris, internet plumber

--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: My Introduction and current issues -

[Nick Tait via bind-users]

On 11/05/2025 17:17, Fred Morris wrote:
BIND insists on addresses bound to interfaces (at least, that's my 
contention, based on experience yesterday, which may or may not 
reflect some reality which has been manufactured today).


resolved uses a loopback address which is not bound to an interface 
(at least that's my experience, which may or may not reflect some 
reality which has been manufactured today).


Nick, I'll ask before the fold: how do I explicitly bind 127.0.0.53 to 
the lo interface before systemd starts? 


I'm not sure why you would even want to do that? It will only create 
confusion about which process is servicing DNS requests sent to 
127.0.0.53. What are you attempting to achieve by doing that?


Nick.

--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: My Introduction and current issues -

[Nick Tait via bind-users]

Sorry let me try again. I missed your other questions...

On 11/05/2025 17:17, Fred Morris wrote:
BIND insists on addresses bound to interfaces (at least, that's my 
contention, based on experience yesterday, which may or may not 
reflect some reality which has been manufactured today).


resolved uses a loopback address which is not bound to an interface 
(at least that's my experience, which may or may not reflect some 
reality which has been manufactured today).


Nick, I'll ask before the fold: how do I explicitly bind 127.0.0.53 to 
the lo interface before systemd starts?


Not sure why you're asking. Systemd does this without you having to 
explicitly do anything.




You know what? I'd like some features too. But I don't go around 
binding to addresses which are not bound to interfaces. Never. I just 
don't do that. Venturing close to the "political" line: I don't see 
anything in BIND which even hints at a whiff of dbus.



...


From where I sit it looks like it sits on an unbound address to shim 
into established, conformant, admittedly baroque and crenellated 
mechanisms for managing name resolution... I actually laughed when you 
mentioned NSS (thanks)... while staying as catastrophically 
inscrutable as wiring the red wire to ground; and that this works to 
its advantage, making it difficult to remove by people who would 
never, ever imagine that core software would abrogate established 
contractual mechanisms without copious documentation... and that the 
best we would do would be apologaeia from the likes of Fred Morris or 
Nick Tait!



...


libc. Granted, your mileage may vary with your implementation, tire 
inflation, RAM color and CPU orientation... but charm never matters.


Rhetorically, how much does it take to get your stack explicitly 
unloved? I don't know exactly, we don't have a lot of data points. 
https://security.opensuse.org/2025/05/07/deepin-desktop-removal.html


As far as I know, BIND has never chosen "DNS eins" as a molehill to 
die on.


Like I said, I wasn't trying to start a holy war, and I wasn't saying 
that systemd-resolved is good or bad. I just wanted to correct a few 
misconceptions, so that people are provided with accurate information 
and can make their own informed choices. :-)


Nick.


--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: My Introduction and current issues -

[Ondřej Surý]

I think there’s too many moving parts.Personally, I would suggest to remove systemd-resolved as a first step and configure the system to use the configured resolver directly.However, it is also unclear to me whether the desktop station in question is Linux, Windows and if it is Linux what distribution does it use.As I said - too many moving parts and it’s not even clear where to start the debugging.Ondrej--Ondřej Surý — ISC (He/Him)My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.On 10. 5. 2025, at 9:03, Greg Choules via bind-users  wrote:@Danilo you are correct, the contents of /etc/resolv.conf are not set by BIND and BIND itself does not use them. But all applications running on that machine (including dig, unless you specify @) that want some kind of name resolution will make OS system calls and then the OS *will* use what's in resolv.conf to determine where to send DNS queries on behalf of the application.In the very first mail, bind9 said that the BIND config contains this:	listen-on port 53 { 123.123.123.10; 127.0.0.1; };At startup, the named process will tell the OS to send it packets that have those destination addresses AND destination port 53. All fine so far.However, bind9 also said this:The resolv.conf file contains:
  nameserver 127.0.0.53Confining things to the Ubuntu box for now, this tells the OS to make DNS queries to 127.0.0.53 - the 53 is *not* the port number, it is the 4th octet of the IPV4 address.So the OS sends queries to 127.0.0.53 and named is listening on 127.0.0.1. I think you can see that this isn't going to work.I don't know why resolv.conf contains that nameserver address (and it is an address, not a name - read the man page for resolv.conf), but the easiest solution would be to add that address to the set that named is listening on. i.e.	listen-on port 53 { 123.123.123.10; 127.0.0.1; 127.0.0.53;};You will need to stop/edit/start named for this change to take effect.This should fix your issues with apt and other applications running on the Ubuntu server.I agree that you should not be using 123.123.123.0/24. Please read RFC1918 for guidance on private addressing.tcpdump has a lot of options. For capturing DNS traffic to disk I would suggest this as a first pass:sudo tcpdump -c 1000 -n -i all -w  port 53This captures all port 53 traffic on any interface (including the loopback), stops after 1000 packets (if you don't stop it yourself with ctrl-C), writes binary capture data to the file  (you choose whatever name you like) and tells tcpdump to *not* attempt to resolve addresses to names. This may be irrelevant since it is capturing to disk but doesn't hurt.Over to the Windows machine now. You will not have dig by default. BIND for Windows (including utilities like dig) hasn't existed for several years. It is still available to download but I *don't* recommend you install it.Windows nslookup is actually not bad for making test queries, especially if used in interactive mode. Again, read the help to see what options it has.Wireshark can be downloaded and installed for free and I recommend that you do that on the Windows machine, so that when you have captured traffic on the Ubuntu server, once you have copied the capture file to Windows you can open it in Wireshark there. Wireshark can also capture packets, like tcpdump, so you can use it to see exactly what your Windows machine is doing with DNS.Hopefully this lot gives you some things to try and also to read, to understand the behaviour you are seeing.Cheers, GregOn Sat, 10 May 2025 at 06:01, Danilo Godec via bind-users  wrote:

  

  
  
On 10.05.2025 05:29, bi...@clearviz.biz
  wrote:

  >Also check /etc/resolv.conf and see what address(es) is/are
listed as nameservers.
  The resolv.conf file
contains:
    nameserver
127.0.0.53
    search
mydomain.net   (where mydomain is my actual domain name and
not the FQDN of the machine (i.e.
"machine01.mydomain.net")).   
  This was entered by
default as BIND was installed.   I am wondering if the
"namesever" should be the machine name on which the server
is running and not 127.0.0.53 And I gather the 53 on the end
has to do with the port on which it's listening. I'm not
sure if it's correct that the 4th octet is substituted like
that. 
  

/etc/resolv.conf is not changed or set by BIND, as far as I know
  it's got nothing to do with BIND at all.

IIRC Ubuntu is using 'systemd-resolved' (a local resolver with
  cache) and 127.0.0.53 is the address it listens on, so you might
  need to check that with 'resolvectl dns'.

Then check what is listening on port 53 (netstat -anp | egrep
  ":53.*LISTEN") on the server. 

And also check what DNS serve

Re: My Introduction and current issues -

[Greg Choules via bind-users]

127.anything is valid on the loopback interface as it is a /8. You will
have to add addresses as aliases, but that is easy. Read the man pages
first and check what addresses already exist on lo0. Ubuntu must have
gotten 127.0.0.53 from somewhere.
Get tcpdump and Wireshark working so you can see what's actually happening.
Work on and fix resolution on the Ubuntu server first, then move to
Windows.

As for "search???" In resolv.conf, personally I don't like it. DNS works on
FQDNs and IMHO applications should ask for these every time, making search
unnecessary. I know that others on this list would disagree with me, but
that's just my 2p.

Cheers, Greg.

On Sat, 10 May 2025, 13:43 ,  wrote:

> On 2025-05-10 02:03, Greg Choules wrote:
>
> @Danilo you are correct, the contents of /etc/resolv.conf are not set by
> BIND and BIND itself does not use them. But all applications running on
> that machine (including dig, unless you specify @) that want some
> kind of name resolution will make OS system calls and then the OS *will*
> use what's in resolv.conf to determine where to send DNS queries on behalf
> of the application.
>
> *Therefore, I will change resolv.conf to replace the current IP with the
> IP of the server machine itself and, perhaps, Localhost itself (127.0.0.1).
> I never created resolv.conf and have no idea how it got created. It's weird
> because "/etc/resolv.conf" is actally a symlink to
> /run/systemd/resolve/stub-resolv.conf"... the file I need to change. *
>
> In the very first mail, bind9 said that the BIND config contains this:
>
>   listen-on port 53 { 123.123.123.10; 127.0.0.1; };  *Correct*
>
> At startup, the named process will tell the OS to send it packets that
> have those destination addresses AND destination port 53. All fine so far.
>
> However, bind9 also said this:
>
> *The resolv.conf file contains:*
>
> *  nameserver 127.0.0.53*
> Confining things to the Ubuntu box for now, this tells the OS to make DNS
> queries to 127.0.0.53 - the 53 is *not* the port number, it is the 4th
> octet of the IPV4 address.
> So the OS sends queries to 127.0.0.53 and named is listening on 127.0.0.1.
> I think you can see that this isn't going to work.
>
> *I will change that immediately. I will make that entry the same IP as my
> server machine itself. Do I need a "search" entry for the name server as
> well? And if yes, should it be just the domain name or the FQDN of the
> server machine? *
>
> I don't know why resolv.conf contains that nameserver address (and it is
> an address, not a name - read the man page for resolv.conf), but the
> easiest solution would be to add that address to the set that named is
> listening on. i.e.
>
>   listen-on port 53 { 123.123.123.10; 127.0.0.1; 127.0.0.53;};
>
> *The 127.0.0.53 addr is invalid for any form of listening. I will eliminate 
> any reference to it. I will use only the server machine's IP and the 
> loopback. *
>
> You will need to stop/edit/start named for this change to take effect.
>
> *I usually do "systemctl restart named".*
>
> This should fix your issues with apt and other applications running on the
> Ubuntu server.
> I agree that you should not be using 123.123.123.0/24. Please read
> RFC1918 for guidance on private addressing.
>
> *Again, 123.123.123.0/24  is not the actual
> subnet address. It's just a place holder in the named.conf.options file to
> mask the real subnet address. For security reasons, I do not publish the
> actual internal subnet address. But rest assured, the real subnet address
> definitely falls within the correct publishing guidelines (i.e. 19*) for
> the head octet.  *
>
> tcpdump has a lot of options. For capturing DNS traffic to disk I would
> suggest this as a first pass:
>
> sudo tcpdump -c 1000 -n -i all -w  port 53
>
> This captures all port 53 traffic on any interface (including the
> loopback), stops after 1000 packets (if you don't stop it yourself with
> ctrl-C), writes binary capture data to the file  (you choose
> whatever name you like) and tells tcpdump to *not* attempt to resolve
> addresses to names. This may be irrelevant since it is capturing to disk
> but doesn't hurt.
>
> *Thanks much! This will help quite a bit.*
>
> Over to the Windows machine now. You will not have dig by default. BIND
> for Windows (including utilities like dig) hasn't existed for several
> years. It is still available to download but I *don't* recommend you
> install it.
>
> *I won't.  Not worth it.  nslookup seems to be working well enough. And,
> as stated below, I'll get Wireshark installed.*
>
> Windows nslookup is actually not bad for making test queries, especially
> if used in interactive mode. Again, read the help to see what options it
> has.
>
> *Precisely. *
>
> Wireshark can be downloaded and installed for free and I recommend that
> you do that on the Windows machine, so that when you have captured traffic
> on the Ubuntu server, once you have copied the capture file to Windows 

Re: My Introduction and current issues -

[Greg Choules via bind-users]

@Danilo you are correct, the contents of /etc/resolv.conf are not set by
BIND and BIND itself does not use them. But all applications running on
that machine (including dig, unless you specify @) that want some
kind of name resolution will make OS system calls and then the OS *will*
use what's in resolv.conf to determine where to send DNS queries on behalf
of the application.

In the very first mail, bind9 said that the BIND config contains this:

listen-on port 53 { 123.123.123.10; 127.0.0.1; };

At startup, the named process will tell the OS to send it packets that have
those destination addresses AND destination port 53. All fine so far.

However, bind9 also said this:

*The resolv.conf file contains:*

*  nameserver 127.0.0.53*
Confining things to the Ubuntu box for now, this tells the OS to make DNS
queries to 127.0.0.53 - the 53 is *not* the port number, it is the 4th
octet of the IPV4 address.
So the OS sends queries to 127.0.0.53 and named is listening on 127.0.0.1.
I think you can see that this isn't going to work.
I don't know why resolv.conf contains that nameserver address (and it is an
address, not a name - read the man page for resolv.conf), but the easiest
solution would be to add that address to the set that named is listening
on. i.e.

listen-on port 53 { 123.123.123.10; 127.0.0.1; 127.0.0.53;};

You will need to stop/edit/start named for this change to take effect.This
should fix your issues with apt and other applications running on the
Ubuntu server.
I agree that you should not be using 123.123.123.0/24. Please read RFC1918
for guidance on private addressing.

tcpdump has a lot of options. For capturing DNS traffic to disk I would
suggest this as a first pass:

sudo tcpdump -c 1000 -n -i all -w  port 53

This captures all port 53 traffic on any interface (including the
loopback), stops after 1000 packets (if you don't stop it yourself with
ctrl-C), writes binary capture data to the file  (you choose
whatever name you like) and tells tcpdump to *not* attempt to resolve
addresses to names. This may be irrelevant since it is capturing to disk
but doesn't hurt.

Over to the Windows machine now. You will not have dig by default. BIND for
Windows (including utilities like dig) hasn't existed for several years. It
is still available to download but I *don't* recommend you install it.
Windows nslookup is actually not bad for making test queries, especially if
used in interactive mode. Again, read the help to see what options it has.

Wireshark can be downloaded and installed for free and I recommend that you
do that on the Windows machine, so that when you have captured traffic on
the Ubuntu server, once you have copied the capture file to Windows you can
open it in Wireshark there. Wireshark can also capture packets, like
tcpdump, so you can use it to see exactly what your Windows machine is
doing with DNS.

Hopefully this lot gives you some things to try and also to read, to
understand the behaviour you are seeing.
Cheers, Greg


On Sat, 10 May 2025 at 06:01, Danilo Godec via bind-users <
bind-users@lists.isc.org> wrote:

> On 10.05.2025 05:29, bi...@clearviz.biz wrote:
>
> >Also check /etc/resolv.conf and see what address(es) is/are listed as
> nameservers.
>
> *The resolv.conf file contains:*
>
> *  nameserver 127.0.0.53*
>
> *  search mydomain.net    (where mydomain is my
> actual domain name and not the FQDN of the machine (i.e.
> "machine01.mydomain.net ")).   *
>
>
> *This was entered by default as BIND was installed.   I am wondering if
> the "namesever" should be the machine name on which the server is running
> and not 127.0.0.53 And I gather the 53 on the end has to do with the port
> on which it's listening. I'm not sure if it's correct that the 4th octet is
> substituted like that. *
>
> /etc/resolv.conf is not changed or set by BIND, as far as I know it's got
> nothing to do with BIND at all.
>
> IIRC Ubuntu is using 'systemd-resolved' (a local resolver with cache) and
> 127.0.0.53 is the address it listens on, so you might need to check that
> with 'resolvectl dns'.
>
> Then check what is listening on port 53 (netstat -anp | egrep
> ":53.*LISTEN") on the server.
>
> And also check what DNS servers your DHCP sets.
>
>
>Danilo
>
>
> --
> 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@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-- 
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/b

Re: My Introduction and current issues -

[Niall O'Reilly]

On 10 May 2025, at 4:29, bi...@clearviz.biz wrote:


The resolv.conf file contains:

  nameserver 127.0.0.53
  search mydomain.net


On a "vanilla" Ubuntu system, the file to which */etc/resolv.conf*
is a symlink contains (in addition to the above) relevant comments,
including the following.

```
# Third party programs should typically not access this file directly, 
but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) 
in a
# different way, replace this symlink by a static file or a different 
symlink.

#
# See man:systemd-resolved.service(8) for details about the supported 
modes of

# operation for /etc/resolv.conf.
```

What I do, is to create a file with a name which I hope will
be safe from future interfering Ubuntu updates and set it up to
refer to my actual nameserver addresses, rename *resolv.conf*
(the symlink) to something harmless (or so I hope), and copy
my "safe" file as */etc/resolv.conf*, with the results shown below.

```
turf(p84)11: ls -l /etc/resolv.conf*
-rw-r--r-- 1 root root 155 Nov 23 16:22 /etc/resolv.conf
lrwxrwxrwx 1 root root  39 Sep 28  2024 /etc/resolv.conf-original -> 
../run/systemd/resolve/stub-resolv.conf

-rw-r--r-- 1 root root 155 Nov 23 16:21 /etc/resolv.conf-tailored
turf(p84)12: diff -qs /etc/resolv.conf{,-tailored}
Files /etc/resolv.conf and /etc/resolv.conf-tailored are identical
turf(p84)12:
```

It seems that I never bothered to disable the systemd-resolved
service. I don't recall whether I gave up trying, or just couldn't
be arsed to work out how.

IMHO, systemd is an abomination, but it's easier to go with the
flow than to eliminate it.

I hope this helps.

/Niall
-- 
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: My Introduction and current issues -

[Paul Kosinski via bind-users]

Have patience.

When the various current DNS resolution mechanisms (systemd-resolved, stub 
resolvers, resolv.conf, MDNS, on-LAN DNS servers which forward and cache, 
"secure" lookup over TLS by the browser itself, etc.) are augmented by AI, it 
will all work perfectly.

Or not.

---

On Sun, 11 May 2025 12:37:23 +1200
Nick Tait via bind-users  wrote:

> On 11/05/2025 07:28, Fred Morris wrote:
> > Stop! Squirrel wearing a systemd tshirt! Kill / maim / destroy / drive 
> > off systemd resolved. Then make sure that resolv.conf is not being 
> > hijacked.
> >
> > Now try again.   
> 
> Contrary to popular opinion -- on this list at least -- systemd-resolved 
> is /not/ evil. It is just misunderstood...
> 
> Yes it is complex, and yes you can avoid that complexity by getting rid 
> of it. But it also has a few features that I personally find useful. So 
> before you run off to get rid of it, let me at least highlight some of 
> those features? But first, let me set the record straight on a few things:
> 
>   * Systemd-resolved is the resolver component of the systemd suite.
> (From Wikipedia : "systemd is
> a software suite that provides an array of system components for
> Linux operating systems.")
>   * Ubuntu uses systemd, including systemd-resolved by default.
>   * In the default set-up, systemd-resolved provides a local DNS stub
> listener on the IP addresses 127.0.0.53 and 127.0.0.54 on the local
> loopback interface, and /etc/resolv.conf is a symbolic link to
> /run/systemd/resolve/stub-resolv.conf. This is done to allow name
> resolution on the local machine to be serviced by the local
> systemd-resolved service.
>   * The systemd-resolved service has its own configuration which
> determines which mechanisms to use to answer name resolution
> queries, and (assuming that it is configured to use DNS) which DNS
> server(s) to use as a recursive resolver.
> 
> I could be mistaken, but my belief is that the goal of this set-up was 
> to make name resolution work consistently, regardless of which mechanism 
> (i.e. C function call) is used by an application. To illustrate my 
> point, here is the output I get from two different name resolution 
> utilities when trying to resolve a name that only exists in my 
> /etc/hosts file:
> 
> $*getent hosts ip6-loopback*
> ::1 ip6-localhost ip6-loopback
> $*host ip6-loopback*
> Host ip6-loopback not found: 3(NXDOMAIN)
> 
> (The reason for this difference is that the "getent" command uses the 
> NSS library to resolve the name, which checks my /etc/hosts file before 
> going to DNS; whereas the "host" command uses the Resolver library which 
> only uses DNS.)
> 
> Unfortunately there are (or at least were) problems with the default 
> set-up, including the limitation that the stub listener wouldn't pass 
> through the AD flag in a DNS response. (The AD flag is used with DNSSEC 
> to indicate that the data is authentic.) I'm not sure if this has been 
> fixed, but this is/was a good reason not to use the stub listener -- and 
> is the reason I /don't/ use the stub listener. Luckily the stub listener 
> can be easily disabled by setting "DNSStubListener=no" in the 
> systemd-resolved configuration. But of course doing this means that 
> systemd-resolved isn't being used for much (if anything). So at this 
> point (to continue to use it at all) it is necessary to install the 
> nss-resolve library and tweak your /etc/nsswitch.conf file. But I'm not 
> going to get into that detail in this email...
> 
> Getting back to the features of systemd-resolved:
> 
>   * It is a one-stop shop for host name resolution. It can provide:
>   o synthetic records (including localhost, and the host's own name
> -- which admittedly isn't necessarily a good thing).
>   o LLMNR (which is kind of obsolete now) for single-label names.
>   o MDNS for names with ".local" suffix.
>   o DNS for multi-label names (excluding ".local" suffix), and
> single-label names with search suffix applied to them.
>   * I like the fact that it 'feels' like part of systemd, including
> stuff like:
>   o You can specify search domains in your netplan configuration
> (using networkd as the renderer in netplan).
>   o The "resolvectl" utility feels like a sibling to the other
> systemd utilities like "systemctl", "journalctl", etc.
> 
> Nick.
> 
> P.S. I hope I'm not (re-) starting some sort of holy war. That is not my 
> intention, and I'm definitely /not/ trying to say that everyone should 
> use systemd-resolved. I'm just trying to be an "active bystander". :-)
-- 
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-use