Also ISP DNS:
joe@jrenewsid:~$ host 82.195.75.100
100.75.195.82.in-addr.arpa is an alias for100.64-26.75.195.82.in-addr.arpa. 100.64-26.75.195.82.in-addr.arpa domain name pointer bendel.debian.org.
Also BIND9:
joe@piserve1:~ $ host 82.195.75.100
Host 100.75.195.82.in-addr.arpa not found: 2(SERVFAIL)
ISP DNS:
joe@jrenewsid:~$ dig -x 82.195.75.100
;; ANSWER SECTION:
100.75.195.82.in-addr.arpa. 851 IN CNAME 100.64-26.75.195.82.in-addr.arpa.
100.64-26.75.195.82.in-addr.arpa. 851 IN PTR bendel.debian.org.
BIND9:
joe@jrenewsid:~$ dig @192.168.71.8 -x 82.195.75.100
; <<>> DiG 9.20.24-1+b1-Debian <<>> @192.168.71.8 -x 82.195.75.100
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31340
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
Then I switched DNS to BIND9 running on the other Pi. All OK, then an
email from this list came in and was bounced for having no PTR. I very quickly restored DNS to the router and investigated. It turns out that
the router DNS server, whatever it is, can see bendel, but BIND9
cannot. I've run bind for decades, the last thirteen years on the Microserver, and never had a problem with bendel. The current BIND9 is running without forwarders, as previous versions have. Here's what dig
shows:
Then I switched DNS to BIND9 running on the other Pi.
It is a bug in systemd-resolve, I noticed that and blamed sendmail first...
Hi,
On Wed, Jul 15, 2026 at 11:28:56AM +0200, Marco Moock wrote:
It is a bug in systemd-resolve, I noticed that and blamed sendmail first...
Can it still be this even though OP reproduced it by directly querying
their bind9 server with dig?
There are so many bugs in systemd-resolved though, it's quite
disappointing.
What does:
dig +trace -x 82.195.75.100 @192.168.71.8
output?
It will show you each step of the recursive resolving.
Do note that part of this recursion uses DNSSEC. If validation fails
for some reason then SERVFAIL is the usual outcome. BIND9 as a
resolver does do DNSSEC validation by default, whereas your ISP
router's resolver probably does not. So your DNSSEC validation setup
may be iffy.
Anything in bind9's logs?
;; UDP setup with 2001:500:a8::e#53(2001:500:a8::e) for 100.75.195.82.in-addr.arpa. failed: network unreachable.
Maybe a clue: my ISP doesn't yet do IPv6, though I can't see why that
should affect a DNS enquiry for an IPv4 address.
Can it still be this even though OP reproduced it by directly querying
their bind9 server with dig?
Hi,
On Wed, Jul 15, 2026 at 12:16:14PM +0100, Joe wrote:
;; UDP setup with 2001:500:a8::e#53(2001:500:a8::e) for 100.75.195.82.in-addr.arpa. failed: network unreachable.
[?]
Maybe a clue: my ISP doesn't yet do IPv6, though I can't see why
that should affect a DNS enquiry for an IPv4 address.
You definitely have a problem with IPv6 in that your DNS resolver
machine is trying to communicate with IPv6 addresses while not being
able to. This indicates that the machine thinks it has a global scope
IPv6 address, but it has no IPv6 route. It thinks it SHOULD be able to
use IPv6 but it will always fail.
You should either fix IPv6 or else remove the IPv6 address - IPv6 will
always be tried first so it's making everything slower for you. I
don't think it is the root of your problem though. I still think
there is some misconfiguration of your bind9 server, as this thing is resolvable by everyone else.
I don't make any use of IPv6 in my network, so can I just disable it at
the operating system level? At least until Plusnet roll it out to its customers.
I don't make any use of IPv6 in my network, so can I just disable it at
the operating system level? At least until Plusnet roll it out to its customers.
Am 15.07.26 um 16:30 schrieb Joe:
I don't make any use of IPv6 in my network, so can I just disable
it at the operating system level? At least until Plusnet roll it
out to its customers.
No, this is a bad idea. You need to figure out why your system has a non-working GUA address.
Show the output of
ip a
ip -6 route show
My ISP does not currently provide IPv6 connection to the Internet.
Nothing I can do about it.
Hi,
On Thu, Jul 16, 2026 at 08:00:52AM +0100, Joe wrote:
My ISP does not currently provide IPv6 connection to the Internet.
Nothing I can do about it.
The router is misconfigured if it is handing out addresses and IPv6
default route that do not work (or no default route). Possibly there
is a way you can fix that, and that would be the best place to fix
it. If you can't fix it then you will need to either ignore SLAAC or
disable IPv6 as I mentioned in the prior reply.
The thing is that if you have a router handing out IPv6 addresses and
route by SLAAC then potentially every device on your network will be
trying to use IPv6, which is obviously bad if that's not going to
work. Disabling it on every host is also clearly more work.
It is not normal for a Plusnet router to be giving out SLAAC details
that don't work. This will cause problems. Either customer services or
other customers (in some sort of forum) should be able to advise you
how to disable SLAAC in the router if it's not going to work. "We
don't support IPv6" can't be the end of the conversation, because
this is broken.
Thanks,
Andy
All three of my Linux computers have IPv6 addresses, the sid
workstation having two. I've never used it so I've no idea where they
have come from. Neither /etc/network nor Network Manager have any IPv6 configurations.
Am 16.07.26 um 10:40 schrieb Joe:
All three of my Linux computers have IPv6 addresses, the sid
workstation having two. I've never used it so I've no idea where
they have come from. Neither /etc/network nor Network Manager have
any IPv6 configurations.
They will generate link-local addresses automatically, but that is
intended, no issue.
It will never use them for outgoing traffic to GUA addresses.
Does it have other addresses assigned?
On Wed, 15 Jul 2026 11:30:52 +0000
Andy Smith <andy@strugglers.net> wrote:
Hi,
On Wed, Jul 15, 2026 at 12:16:14PM +0100, Joe wrote:
;; UDP setup with 2001:500:a8::e#53(2001:500:a8::e) for 100.75.195.82.in-addr.arpa. failed: network unreachable.
[?]
Maybe a clue: my ISP doesn't yet do IPv6, though I can't see why
that should affect a DNS enquiry for an IPv4 address.
You definitely have a problem with IPv6 in that your DNS resolver
machine is trying to communicate with IPv6 addresses while not being
able to. This indicates that the machine thinks it has a global scope
IPv6 address, but it has no IPv6 route. It thinks it SHOULD be able to
use IPv6 but it will always fail.
Not up to me, the router apparently has access to IPv6 but doesn't pass
it through, though from the menu it looks capable of doing it. But
there's no option to enable it, and the ISP (Plusnet, owned by BT) says
a trial is under way.
But there's no errors in the log with the trace option running, even
though something further along is getting network unreachable messages,
and the correct data is returned. Without trace the local BIND9 is
attempting use of IPv6, which it obviously isn't with trace running.
You should either fix IPv6 or else remove the IPv6 address - IPv6 will always be tried first so it's making everything slower for you. I
don't think it is the root of your problem though. I still think
there is some misconfiguration of your bind9 server, as this thing is resolvable by everyone else.
That's what I hoped, but it is the Debian original setup plus local
forward and reverse zones, as I have always done. I used to link it to
DHCP to get dynamic updates, but I don't bother these days.
I don't make any use of IPv6 in my network, so can I just disable it at
the operating system level? At least until Plusnet roll it out to its customers.
On Thu, Jul 16, 2026 at 3:01?AM Joe wrote:
On Thu, 16 Jul 2026 08:39:29 +0200
Marco Moock wrote:
Am 15.07.26 um 16:30 schrieb Joe:
I don't make any use of IPv6 in my network, so can I just
disable it at the operating system level? At least until
Plusnet roll it out to its customers.
No, this is a bad idea. You need to figure out why your system
has a non-working GUA address.
Show the output of
ip a
ip -6 route show
My ISP does not currently provide IPv6 connection to the Internet.
And the problem is that named is trying to use IPv6 to query name
servers on the Internet and that fails? Correct?
you can tell named to use only IPv4 by editing
/etc/default/named
and adding "-4" to the OPTIONS variable - eg:
# startup options for the server
OPTIONS="-4 -u bind"
On Thu, 16 Jul 2026 13:51:18 -0400
Lee <ler762@gmail.com> wrote:
you can tell named to use only IPv4 by editing
/etc/default/named
and adding "-4" to the OPTIONS variable - eg:
# startup options for the server
OPTIONS="-4 -u bind"
Thank you, I was going to look in that direction in a while
Hi,
On Thu, Jul 16, 2026 at 07:03:51PM +0100, Joe wrote:
On Thu, 16 Jul 2026 13:51:18 -0400
Lee <ler762@gmail.com> wrote:
you can tell named to use only IPv4 by editing
/etc/default/named
and adding "-4" to the OPTIONS variable - eg:
# startup options for the server
OPTIONS="-4 -u bind"
Thank you, I was going to look in that direction in a while
Disabling IPv6 in one app on one machine seems like a terrible idea
when the problem is that you have broken IPv6 on every machine in your network.
If you can't fix the router why would you not just disable SLAAC or
IPv6 on each machine?
A lot of work seems to be being made here out of a simple problem.
On Fri, 17 Jul 2026 11:00:22 +0000
Andy Smith <andy@strugglers.net> wrote:
Disabling IPv6 in one app on one machine seems like a terrible idea
when the problem is that you have broken IPv6 on every machine in your network.
If you can't fix the router why would you not just disable SLAAC or
IPv6 on each machine?
A lot of work seems to be being made here out of a simple problem.
Can I ask what the advantages are to using IPv6 inside a four-computer network?
I thought I had said that there is probably nothing wrong with the
router
I just don't have an IPv6 connection to the Internet, because
my ISP does not currently provide it.
When that changes, the inability of BIND9 to see the Debian server
will disappear.
Until then, I will grudgingly use my ISP's DNS servers.
Actually all three have two IPv6 addresses. Presumably they will be
used within the network if necessary.
Can I ask what the advantages are to using IPv6 inside a four-computer network?
I thought I had said that there is probably nothing wrong with the
router, I just don't have an IPv6 connection to the Internet, because
my ISP does not currently provide it.
Am 17.07.26 um 15:10 schrieb Joe:
I thought I had said that there is probably nothing wrong with the
router, I just don't have an IPv6 connection to the Internet, because
my ISP does not currently provide it.
In such a case a machine only has link-local addresses. They will never be used to connect to GUA (public) addresses.
If there are other addresses attached, this is an issue that needs to be examined.
There 100% is a problem with your router. It is most likely sending
IPv6 autoconfig packets that cause your hosts to autoconfigure an IPv6 address by SLAAC. If it's not doing that then it is doing DHCPv6, but
I think SLAAC is more likely.
There is no other way for your hosts to have global scope IPv6
addresses unless you statically configured them, which you say you
did not. We could tell more if you would simply show us the full
output of "ip addr show", which you have also been asked for several
times now.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000 link/loopback 00:00:00:00:00:00 brd
00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UP group default qlen 1000 link/ether 74:46:a0:b2:40:1f brd ff:ff:ff:ff:ff:ff altname enp0s25
altname enx7446a0b2401f
inet 192.168.71.106/24 brd 192.168.71.255 scope global dynamic noprefixroute eno1 valid_lft 86338sec preferred_lft 86338sec
inet6 fdda:67d:d74e:4ed1:3ee3:5e26:8a2b:7db4/64 scope global
dynamic noprefixroute valid_lft 1752sec preferred_lft 1752sec
inet6 fe80::edc9:2f64:d118:e10f/64 scope link noprefixroute
valid_lft forever preferred_lft forever
IPv6 addresses still there. It is certainly Debian putting them there,
not me.
inet6 fd39:8f22:f952:cb29:7bef:e9bc:8ae5:2f96/64 scope global dynamic mngtmpaddr noprefixroute
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 4 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 497102:27:10 |
| Calls: | 182 |
| Files: | 744 |
| D/L today: |
65 files (9,837K bytes) |
| Messages: | 73,659 |