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 syste
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 b
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.
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 al
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.
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
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 interfac
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
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 distribut
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 wha
@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 r
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 followin
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.
--
13 matches
Mail list logo
