Well, it was worth to check it.
Next idea is somewhat more complicated.
Install tcpdump.
Run:
tcpdump -pni any -s0 -w /tmp/dns.pcap -c 30 udp port 53 or tcp port 53
Bounce BIND, wait for a minute at least.
Do some DNS queries. One or two will do.
Interrupt tcpdump unless it completes by itself.
Post dns.pcap.
Strangely, the issue resolved itself without me having to do anything. Am really puzzled as to what it was. Perhaps the internet provider suddenly started to block DNS queries but then allowed them again? If so, why did dig's message say that there was"communications error to 127.0.0.1#53: timed out"? It really gives an impression that dig was failing to connect 127.0.0.1 port 53, on which bind was running.
# dig www.yahoo.com <http://www.yahoo.com>
;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: timed out
...
Maybe someone will shed some light on this.
Thanks to everyone who responded.
On Tue, Mar 14, 2023 at 06:23:09AM +0800, Jeremy Ardley wrote:
FYI systed-resolved is the inbuilt debian caching DNS server which may beIt is NOT enabled by default.
enabled by default.
Strangely, the issue resolved itself without me having to do anything. Am really puzzled as to what it was. Perhaps the internet provider suddenly started to block DNS queries but then allowed them again? If so, why did dig's message say that there was"communications error to 127.0.0.1#53: timed out"? It really gives an impression that dig was failing to connect 127.0.0.1 port 53, on which bind was running.
# dig www.yahoo.com <http://www.yahoo.com>
;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: timed out
...
Maybe someone will shed some light on this.
I had a signed DNS error in a similar configuration using a bind
authoritive and caching server. It turned out it was systemd-resolved interfering and/or replacing part of the DNS chain
FYI systed-resolved is the inbuilt debian caching DNS server which may
be enabled by default. If you run that you don't need a bind9 caching
name server
What does this report ?
systemctl status systemd-resolved
If there is anything there at all, check logs. You may find something
On Tue, Mar 14, 2023 at 06:23:09AM +0800, Jeremy Ardley wrote:
FYI systed-resolved is the inbuilt debian caching DNS server which may beIt is NOT enabled by default.
enabled by default.
unicorn:~$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; ve>
Active: inactive (dead)
Docs: man:systemd-resolved.service(8)
man:org.freedesktop.resolve1(5)
https://www.freedesktop.org/wiki/Software/systemd/writing-network->
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver>
I replicated your test above and it seems your listing has been accidentally truncated...
jeremy@testldap:~$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled;
vendor preset: enabled)
Active: inactive (dead)
Docs: man:systemd-resolved.service(8)
man:org.freedesktop.resolve1(5) https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
It would seem the debian default is enabled? See vendor preset below.
I have not to this day figured out what "vendor preset" means here.
Mine shows the same as yours -- "disabled; vendor preset: enabled".
All I care about is the part that says "disabled". That's the actual
state.
So the mystery is how it gets onto a system using a standard install and which package it comes from now and what is done with any presets
You may be happy to learn you can't even install it as a separate package any more.
apt install --reinstall systemd-resolved
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package systemd-resolved is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
...
So the mystery is how it gets onto a system using a standard install and which package it comes from now and what is done with any presets
On 13/03/2023 23:23, Greg Wooledge wrote:
I have not to this day figured out what "vendor preset" means here.It would appear to be https://www.freedesktop.org/software/systemd/man/systemd.preset.html. If I'm reading the introduction correctly, this is systemd's equivalent to Debian's policy-rc.d, inasmuch as it's a place to define whether a service starts (or not) _before_ installing the package.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 304 |
Nodes: | 16 (2 / 14) |
Uptime: | 32:01:22 |
Calls: | 6,820 |
Files: | 12,335 |
Messages: | 5,406,974 |