Sure. Your decision, of course. But any network application is only going
to work if the underlying network supporting it doesn't do silly things
with its traffic.
On Thu, 22 May 2025 at 15:23, wrote:
> Thank you for all your assistance. I have made the decision to
> decommission Bind9 and insta
Thank you for all your assistance. I have made the decision to
decommission Bind9 and install Unbound in its place. There seem to be a
lot more configuration options that might help me with the problems I am
having. Problems I never had with Windows Server 2003.
Thanks anyway and take care of
>From the correct alias this time!
On Mon, 19 May 2025 at 22:46, Greg Choules
wrote:
> Your router (or your ISP behind it) is losing a lot of traffic. Here is a
> timeline of frames with explanations of each, which would have been so much
> simpler if you hadn't tried to hide your actual address
On 18.05.2025 19:53, bi...@clearviz.biz
wrote:
I include it because all of the packets
seem to have the same problem (the router attempts a ping to my
main server (ending in octet ".10"), which it claims the host is
unreachable. Not sure why tha
All - Here is a general follow up and status report on my activities in
configuring Bind9 and getting it to work.
1) Recursion - I commented out all the elements of recursion in
named.conf.options. At the same time, I also commented out the
"forwarders" clause and "forward only". The result
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
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
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
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 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.
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 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
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
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 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
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.
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
@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.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
mydom
Well, let's put it this way. I have been monitoring the logs
(/var/log/syslog in particular) as well as the separate logs I created
(named.log and query.log). I'm getting a lot of "Connection refused"
errors and a lot of "SERVFAIL" errors in named.log for various sites. I
don't know if the quer
Based on that I'm pretty confident you can remove this as being a general DNS
server issue.
I would not attempt to even change the configuration in bind at this point as
to not introduce more potential changes into your env as doing those tests will
have mostly validated the DNS server is worki
If you’re hobbled by Windows (and ones five years past EOL), I prefer to
fire up PowerShell and use Resolve-DnsName. Also include the -DnsOnly flag.
Have you been looking at the BIND logs?
Also, a BIND installation isn’t going to mess with resolv.conf. That’s
typically managed by the distro’s net
I also suspect it's not BIND, but how the OS is going about resolving
names.
Test your running BIND by using dig (please, not nslookup) @127.0.0.1
[1] for domains you think you are having a problem with.
Should it be @127.0.0.1 or should it be the machine's IP on which the
DNS server is runnin
From the instance with bind running, can you query both your defined
forwarders? Does it work consistently for a variety of domains?
dig @1.1.1.1 isc.org
dig @8.8.8.8 isc.org
Yes, it does. The above two commands work as well as several other
domains I tried, and the response has been immedia
I noted that it appears your internal network is 123.123.123.0/24. This
ip range is assigned globally to a Chinese ISP. This may not be a good
idea.
I agree that using forwarding is not necessary and may introduce some
issues.
And yes, you need to stop using nslookup and use dig instead.
On Saturday, 10 May 2025 01:35:28 CEST Greg Choules via bind-users wrote:
> Third, use tcpdump to capture port 53. Do this to a file, then look at it
> offline in Wireshark. (Michael just beat me to that tip). Check how queries
> are arriving into BIND and what it does with them. Particularly look
Hi.
I also suspect it's not BIND, but how the OS is going about resolving names.
Test your running BIND by using dig (please, not nslookup) @127.0.0.1 for
domains you think you are having a problem with.
Also check /etc/resolv.conf and see what address(es) is/are listed as
nameservers.
Third, use
I get a feeling this is going to be less of a bind issue, and more so some
other configuration issue(s).
>From the instance with bind running, can you query both your defined
>forwarders? Does it work consistently for a variety of domains?
dig @1.1.1.1 isc.org
dig @8.8.8.8 isc.org
>From the cl
On Saturday, 10 May 2025 01:18:17 CEST Michael De Roover wrote:
[...]
I do remember writing a reply that got lost while drafting my previous email,
but I don't remember what exactly it is. I do, however, remember its contents,
somewhat. I'll just rewrite it in reply to.. this, I guess.
You'll wa
On Saturday, 10 May 2025 00:58:25 CEST bi...@clearviz.biz wrote:
> Howdy all!. My name is Arnold, and I'm new to both Bind9 and to the
> Bind user's list. I'm hoping to contribute my findings on the use of
> Bind9. in the future but, for now, I need some help in getting my 1st
> install of Bind 9
30 matches
Mail list logo