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 , <bi...@clearviz.biz> 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 @<address>) 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 <http://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 <filename> 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 <filename> (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 <
> 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 <http://mydomain.net> (where mydomain is my
> actual domain name and not the FQDN of the machine (i.e.
> "machine01.mydomain.net <http://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/bind-users
