Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-14 Thread Greg Wooledge 
On Tue, Mar 14, 2023 at 08:05:55PM +, Darac Marjal wrote:
> 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.

Hmm.  Well, on my system there's a
/lib/systemd/system-preset/90-systemd.preset file which contains, among
other things:

enable systemd-resolved.service

I'm guessing this file came straight from upstream, and hasn't been
modified by Debian.  I'm also guessing this file is read by
"systemctl status" (or something acting on its behalf) to generate
that "vendor preset: enabled" verbiage.

But because Debian doesn't actually *adhere* to all of the upstream
semantics, this file and the "vendor preset" verbiage are not correct.
They don't reflect reality on a Debian system.

Which is fine.  I'll just continue ignoring the "vendor preset" section
as I have been doing.  I mean, it would be *nice* if it actually showed
the Debian system defaults rather than the upstream defaults, but I can
live without that.

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-14 Thread Darac Marjal 


On 13/03/2023 23:23, Greg Wooledge wrote:

On Tue, Mar 14, 2023 at 07:04:02AM +0800, Jeremy Ardley wrote:

I replicated your test above and it seems your listing has been accidentally
truncated...

Pipe it through cat to avoid the "left/right scrolling" crap.

If you want to do this regularly, you can set SYSTEMD_PAGER=cat



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.
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.


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.



OpenPGP_signature
Description: OpenPGP digital signature

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread local10 
Mar 13, 2023, 23:33 by jer...@ardley.org:

> 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 Debian 12 Bookworm it could be done:

# aptitude show systemd-resolved
Package: systemd-resolved   
Version: 252.6-1
New: yes
State: not installed
...


# aptitude install systemd-resolved --simulate
The following NEW packages will be installed:
  libnss-myhostname{a} libnss-resolve{a} systemd-resolved
0 packages upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 484 kB of archives. After unpacking 1,234 kB will be used.

Note: Using 'Simulate' mode.
Do you want to continue? [Y/n/?] n
Abort.


Regards,

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Greg Wooledge 
On Tue, Mar 14, 2023 at 07:33:00AM +0800, Jeremy Ardley wrote:
> 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

unicorn:~$ dpkg -S systemd-resolved
systemd: /usr/share/man/man8/systemd-resolved.8.gz
systemd: /lib/systemd/systemd-resolved
systemd: /lib/systemd/system/systemd-resolved.service
systemd: /usr/share/man/man8/systemd-resolved.service.8.gz

It's installed by default, but it's not ENABLED by default.

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Jeremy Ardley 



On 14/3/23 07:23, Greg Wooledge wrote:


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.


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

It's on the test VM I built recently so it comes from somewhere

The general documentation says that if you install it as a package then 
it will rewrite various config files to take over the machine DNS.


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


--
Jeremy
(Lists)

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Greg Wooledge 
On Tue, Mar 14, 2023 at 07:04:02AM +0800, Jeremy Ardley wrote:
> I replicated your test above and it seems your listing has been accidentally
> truncated...

Pipe it through cat to avoid the "left/right scrolling" crap.

> 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.

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Jeremy Ardley 



On 14/3/23 06:34, Greg Wooledge wrote:

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 be
enabled by default.

It is NOT 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.

Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; 
vendor preset: enabled)


--
Jeremy
(Lists)

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Jeremy Ardley 



On 14/3/23 06:34, Greg Wooledge wrote:

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 be
enabled by default.

It is NOT enabled by default.


It is if you are using NetworkManager

--
Jeremy
(Lists)

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Jeremy Ardley 


On 14/3/23 06:23, Jeremy Ardley wrote:


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

Also FYI you can run bind9 and systemd-resolved at the same time and set 
bind9 to use systemd-resolved as forwarder



|options { directory "/var/cache/bind"; // Use systemd-resolved as a DNS 
resolver forwarders { 127.0.0.53 port 53; }; dnssec-validation auto; 
auth-nxdomain no; # conform to RFC1035 ... Its probably a good idea to 
not be too keen on dnssec validation - as above. |

--
Jeremy
(Lists)

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Greg Wooledge 
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 be
> enabled by default.

It is NOT 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>

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Greg Wooledge 
On Mon, Mar 13, 2023 at 11:14:20PM +0100, local10 wrote:
> 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 
> ;; 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.

UDP doesn't have a "connection".  The client sends a datagram (a one-way
message) to the UDP service, and then waits to receive a reply.

If the UDP service in turn sends a datagram to a third party, and waits
for a reply, but never receives one... and thus never responds to the
original client... then all the client knows is that it never got a
response.  It doesn't know why.

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Jeremy Ardley 



On 14/3/23 06:14, local10 wrote:


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 
;; 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.



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

--
Jeremy
(Lists)

[SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread local10 
Mar 13, 2023, 21:42 by recovery...@enotuniq.net:

> 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 
;; 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.

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Reco 
Hi.

On Mon, Mar 13, 2023 at 08:53:35PM +0100, local10 wrote:
> Mar 13, 2023, 12:06 by recovery...@enotuniq.net:
> 
> > Looks correct, assuming that the contents of the key start with AwEAAaz
> > and end with V74bU=.
> >
> > 
> > Look at /usr/share/dns/root.key. Compare its contents with
> > /etc/bind/bind.keys. Replace the latter if needed.
> >
> > "dpkg-reconfigure -plow bind9" is probably more preferred way of doing
> > it.
> >
> 
> They keys in the "/etc/bind/bind.keys" and "/usr/share/dns/root.key" are 
> identical:

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.

Reco

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread local10 
Mar 13, 2023, 11:50 by mv...@free.fr:

> Did you check memory and disk space as suggested by jeremy ?
>

There's plenty of free RAM (4GB) and disk space (hundreds of GBs).

Regards,

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread local10 
Mar 13, 2023, 14:11 by ca...@deccio.net:

> Based on what I saw in the logs, your resolver is having trouble reaching the 
> internet.  It shows problems with both the priming query (./NS) and the trust 
> query (./DNSKEY).  Could you try running the following?
>
> $ dig +norec @198.41.0.4 . NS
> $ dig +norec @2001:503:ba3e::2:30 . NS
> $ dig +norec @198.41.0.4 . DNSKEY
> $ dig +norec @2001:503:ba3e::2:30 . DNSKEY
>
> These manually send the same queries to the internet that your resolver is 
> attempting.
>
> Cheers,
> Casey
>

$ dig +norec @198.41.0.4 . NS

; <<>> DiG 9.18.12-1-Debian <<>> +norec @198.41.0.4 . NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19016
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.  IN  NS

;; ANSWER SECTION:
.   518400  IN  NS  e.root-servers.net.
.   518400  IN  NS  h.root-servers.net.
.   518400  IN  NS  l.root-servers.net.
.   518400  IN  NS  i.root-servers.net.
.   518400  IN  NS  a.root-servers.net.
.   518400  IN  NS  d.root-servers.net.
.   518400  IN  NS  c.root-servers.net.
.   518400  IN  NS  b.root-servers.net.
.   518400  IN  NS  j.root-servers.net.
.   518400  IN  NS  k.root-servers.net.
.   518400  IN  NS  g.root-servers.net.
.   518400  IN  NS  m.root-servers.net.
.   518400  IN  NS  f.root-servers.net.

;; ADDITIONAL SECTION:
e.root-servers.net. 518400  IN  A   192.203.230.10
e.root-servers.net. 518400  IN      2001:500:a8::e
h.root-servers.net. 518400  IN  A   198.97.190.53
h.root-servers.net. 518400  IN      2001:500:1::53
l.root-servers.net. 518400  IN  A   199.7.83.42
l.root-servers.net. 518400  IN      2001:500:9f::42
i.root-servers.net. 518400  IN  A   192.36.148.17
i.root-servers.net. 518400  IN      2001:7fe::53
a.root-servers.net. 518400  IN  A   198.41.0.4
a.root-servers.net. 518400  IN      2001:503:ba3e::2:30
d.root-servers.net. 518400  IN  A   199.7.91.13
d.root-servers.net. 518400  IN      2001:500:2d::d
c.root-servers.net. 518400  IN  A   192.33.4.12
c.root-servers.net. 518400  IN      2001:500:2::c
b.root-servers.net. 518400  IN  A   199.9.14.201
b.root-servers.net. 518400  IN      2001:500:200::b
j.root-servers.net. 518400  IN  A   192.58.128.30
j.root-servers.net. 518400  IN      2001:503:c27::2:30
k.root-servers.net. 518400  IN  A   193.0.14.129
k.root-servers.net. 518400  IN      2001:7fd::1
g.root-servers.net. 518400  IN  A   192.112.36.4
g.root-servers.net. 518400  IN      2001:500:12::d0d
m.root-servers.net. 518400  IN  A   202.12.27.33
m.root-servers.net. 518400  IN      2001:dc3::35
f.root-servers.net. 518400  IN  A   192.5.5.241
f.root-servers.net. 518400  IN      2001:500:2f::f

;; Query time: 43 msec
;; SERVER: 198.41.0.4#53(198.41.0.4) (UDP)
;; WHEN: Mon Mar 13 15:54:28 EDT 2023
;; MSG SIZE  rcvd: 811


# Note that I'm running bind with "-4" option, that is, IPv4 only
$ dig +norec @2001:503:ba3e::2:30 . NS
;; UDP setup with 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30) for . failed: 
network unreachable.
;; UDP setup with 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30) for . failed: 
network unreachable.
;; UDP setup with 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30) for . failed: 
network unreachable.



$ dig +norec @198.41.0.4 . DNSKEY

; <<>> DiG 9.18.12-1-Debian <<>> +norec @198.41.0.4 . DNSKEY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60299
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;.  IN  DNSKEY

;; ANSWER SECTION:
.   172800  IN  DNSKEY  256 3 8 
AwEAAcVnO2jZFx4756Rb/yAhJnsl72eemsObU43nclmXwqdJlp+kC5WQ 
jGYkqLT5xkaUCPhkr4NKLLrIBZXeSGazc6gx/yrrMtUpXcQvax6kfDJP 
Tu974OmeEbtjyyP7ZG5tUfSwNWt/4EuxDNmZTESG8jU0ZLjYIB11pK0g 
SXQbMVPyIyGtFGHMPx6UxWn6zUzpECWRFbqEvkA6Y13zeJ1jG2Rki/zs 
7a/o13FTl/kI9013Eh6l6Kc2zxbc14GS8fpM0/xQIrZZyeiXj/2C4Rcs 
PeqWuNj9m0qSQrbrCZtLHb20U8x1uue4iwSX9y7LpwZd6vjYd1d6dgBa 1Xxgc/TC+m8=
.   172800  IN  DNSKEY  257 3 8 
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread local10 
Mar 13, 2023, 12:06 by recovery...@enotuniq.net:

> Looks correct, assuming that the contents of the key start with AwEAAaz
> and end with V74bU=.
>
> 
> Look at /usr/share/dns/root.key. Compare its contents with
> /etc/bind/bind.keys. Replace the latter if needed.
>
> "dpkg-reconfigure -plow bind9" is probably more preferred way of doing
> it.
>

They keys in the "/etc/bind/bind.keys" and "/usr/share/dns/root.key" are 
identical:

# cat /etc/bind/bind.keys
...
trust-anchors {
    # This key (20326) was published in the root zone in 2017.
    . initial-key 257 3 8 
"AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
    +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
    ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
    0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
    oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
    RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
    R1AkUTV74bU=";
};


Regards,

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Casey Deccio 

> On Mar 13, 2023, at 12:08 AM, local10  wrote:
> 
> I have  a local caching DNS server that was working fine for a long time but 
> today, all of a sudden, it stopped resolving queries.
> 
> More info: https://pastebin.com/iW5YeXgS
> 
> Any ideas? Thanks

Based on what I saw in the logs, your resolver is having trouble reaching the 
internet.  It shows problems with both the priming query (./NS) and the trust 
query (./DNSKEY).  Could you try running the following?

$ dig +norec @198.41.0.4 . NS
$ dig +norec @2001:503:ba3e::2:30 . NS
$ dig +norec @198.41.0.4 . DNSKEY
$ dig +norec @2001:503:ba3e::2:30 . DNSKEY

These manually send the same queries to the internet that your resolver is 
attempting.

Cheers,
Casey

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Reco 
On Mon, Mar 13, 2023 at 12:29:44PM +0100, local10 wrote:
> Mar 13, 2023, 10:57 by recovery...@enotuniq.net:
> 
> > And now to the serious stuff.
> >
> > First things first, the log.
> >
> > Mar 13 05:03:18 tst named[52836]: 13-Mar-2023 05:03:18.963 queries: info: 
> > client @0x7f7812816d68 127.0.0.1#38800 (www.yahoo.com 
> > ): query:
> > www.yahoo.com  IN A +E(0)K (127.0.0.1)
> > Mar 13 05:03:21 tst named[52836]: 13-Mar-2023 05:03:21.631 dnssec: warning: 
> > managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
> >
> > The keyword here is not "managed-keys-zone", it's "dnssec".
> >
> > Second, to put it bluntly, if you force bind9 to do DNSSEC validation
> > (which is enabled by default), bind9 won't be able to lookup anything
> > unless it is trusting root DNSSEC key. Like, for your own security and
> > stuff :)
> >
> > Third, as every DNSSEC key, root zone keys have their expiration.
> > Meaning, you did not have to change anything to break your setup, every
> > time you deal with DNSSEC you're dealing with a ticking bomb anyway.
> >
> > Fourth, Debian packaging helpfully forces bind9 to depend on dns-root-data,
> > which should provide a current DNSSEC root key (KSK to be precise), but
> > bind9 could also take said key from /etc/bind/bind.keys.
> >
> >
> > In conclusion:
> >
> > 1) Check the contents of your /etc/bind/bind.keys, update if needed.
> > 2) Check the version of your dns-root-data, versions above and including
> > 2021011101 (aka ksk id 20326) are good.
> > 3) Set "dnssec-validation no;" at named.conf.options as a last resort.
> > 4) If you intend to troubleshoot DNS queries then consider installing
> > tcpdump. The thing helps.
>
> 
> Very interesting, thanks. in the "bind.keys" I have only one entry:
> 
> trust-anchors {
>     # This key (20326) was published in the root zone in 2017.
>     . initial-key 257 3 8 "";
> };

Looks correct, assuming that the contents of the key start with AwEAAaz
and end with V74bU=.


> But in "/etc/bind/named.conf.options" I have "dnssec-validation
> auto;", which, as I understand it should force bind to use the
> built-in root key, no?

Not exactly. "dnssec-validation auto;" should point BIND at
/etc/bind/bind.keys. And bind.keys should be created (or updated) by
debconf.
At least debconf did it for me back in 2021 during buster->bullseye
upgrade.


> Anyhow, how would I know if an update of /etc/bind/bind.keys is needed (it's 
> not obvious just by looking at the key)

Obviously you cannot know that ;)
Luckily "Root KSK Rollovers", as they call it, are rare. Last one was in
2018, and the key (aka ksk id 20326) in question was released in 2017.

> and, if so, how do I update it?

Look at /usr/share/dns/root.key. Compare its contents with
/etc/bind/bind.keys. Replace the latter if needed.

"dpkg-reconfigure -plow bind9" is probably more preferred way of doing
it.

Reco

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Michel Verdier 
Le 13 mars 2023 local a écrit :

> Sure, I could have used some public DNS server and I may have to do that if I 
> can't get this issue resolved. Still, I'd like to understand why BIND 
> suddenly stopped working[1] for me and how to fix it.
>
> Regards,
>
> 1. It was working fine yesterday and I haven't done any config changes since.

Did you check memory and disk space as suggested by jeremy ?

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread local10 
Mar 13, 2023, 11:24 by g...@wooledge.org:

> For the record:
>
> unicorn:~$ sudo ss -ntlp | grep :53
> [sudo] password for greg: 
> LISTEN 0  20   0.0.0.0:53 0.0.0.0:*
> users:(("dnscache",pid=664,fd=4))
>
> In general, ss replaces netstat for this kind of query.  I don't know
> all the options, so you may need to read the manual if this isn't
> enough.
>

I see, thanks. The following is what I have:

# ss -ntlp | grep :53
LISTEN 0  10 127.0.0.1:53    0.0.0.0:*    
users:(("named",pid=6233,fd=19))
LISTEN 0  10 127.0.0.1:53    0.0.0.0:*    
users:(("named",pid=6233,fd=20))
LISTEN 0  10   xxx.xxx.xxx.xxx:53    0.0.0.0:*    
users:(("named",pid=6233,fd=25))
LISTEN 0  10   xxx.xxx.xxx.xxx:53    0.0.0.0:*    
users:(("named",pid=6233,fd=26))

Regards,

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread local10 
Mar 13, 2023, 10:57 by recovery...@enotuniq.net:

> And now to the serious stuff.
>
> First things first, the log.
>
> Mar 13 05:03:18 tst named[52836]: 13-Mar-2023 05:03:18.963 queries: info: 
> client @0x7f7812816d68 127.0.0.1#38800 (www.yahoo.com 
> ): query:
> www.yahoo.com  IN A +E(0)K (127.0.0.1)
> Mar 13 05:03:21 tst named[52836]: 13-Mar-2023 05:03:21.631 dnssec: warning: 
> managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
>
> The keyword here is not "managed-keys-zone", it's "dnssec".
>
> Second, to put it bluntly, if you force bind9 to do DNSSEC validation
> (which is enabled by default), bind9 won't be able to lookup anything
> unless it is trusting root DNSSEC key. Like, for your own security and
> stuff :)
>
> Third, as every DNSSEC key, root zone keys have their expiration.
> Meaning, you did not have to change anything to break your setup, every
> time you deal with DNSSEC you're dealing with a ticking bomb anyway.
>
> Fourth, Debian packaging helpfully forces bind9 to depend on dns-root-data,
> which should provide a current DNSSEC root key (KSK to be precise), but
> bind9 could also take said key from /etc/bind/bind.keys.
>
>
> In conclusion:
>
> 1) Check the contents of your /etc/bind/bind.keys, update if needed.
> 2) Check the version of your dns-root-data, versions above and including
> 2021011101 (aka ksk id 20326) are good.
> 3) Set "dnssec-validation no;" at named.conf.options as a last resort.
> 4) If you intend to troubleshoot DNS queries then consider installing
> tcpdump. The thing helps.
>
> Reco
>

Very interesting, thanks. in the "bind.keys" I have only one entry:

trust-anchors {
    # This key (20326) was published in the root zone in 2017.
    . initial-key 257 3 8 "";
};

But in "/etc/bind/named.conf.options" I have "dnssec-validation auto;", which, 
as I understand it should force bind to use the built-in root key, no?

Anyhow, how would I know if an update of /etc/bind/bind.keys is needed (it's 
not obvious just by looking at the key) and, if so, how do I update it?

Regards,

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Greg Wooledge 
On Mon, Mar 13, 2023 at 09:19:41AM +0100, local10 wrote:
> Mar 13, 2023, 07:25 by jer...@ardley.org:
> 
> > Try
> >
> > netstat -tulpnW | grep 53
> >
> > and see what's listening
> >
> 
> Bind seems to be listening on 127.0.0.1 port 53.
> 
> I don't have netstat installed and can't easily install it as aptitude can't 
> resolve Debian server's name to an IP, so the following is what I tried:

For the record:

unicorn:~$ sudo ss -ntlp | grep :53
[sudo] password for greg: 
LISTEN 0  20   0.0.0.0:53 0.0.0.0:*
users:(("dnscache",pid=664,fd=4))

In general, ss replaces netstat for this kind of query.  I don't know
all the options, so you may need to read the manual if this isn't
enough.

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Reco 
Hi.

On Mon, Mar 13, 2023 at 10:57:48AM +0100, local10 wrote:
> Mar 13, 2023, 09:32 by jer...@ardley.org:
> 
> > My next best option is simply to remove your bind caching server (it sounds 
> > like it's not really necessary in your application)
> >
> > Backup /etc/bind and /var/cache/bind
> > then
> > systemctl remove bind9
> > systemctl purge bind9

LOL.

> > And then edit /etc/resolv.conf to
> >
> > nameserver 8.8.8.8
> > nameserver 8.8.4.4

And redirect all your DNS queries to Google.
I mean, people, if you suggest using a public DNS you could at least
consider suggesting a privacy-respecting one, like 9.9.9.9.


> Sure, I could have used some public DNS server and I may have to do that if I 
> can't get this issue resolved. Still, I'd like to understand why BIND 
> suddenly stopped working[1] for me and how to fix it.

And now to the serious stuff.

First things first, the log.

Mar 13 05:03:18 tst named[52836]: 13-Mar-2023 05:03:18.963 queries: info: 
client @0x7f7812816d68 127.0.0.1#38800 (www.yahoo.com ): 
query:
www.yahoo.com  IN A +E(0)K (127.0.0.1)
Mar 13 05:03:21 tst named[52836]: 13-Mar-2023 05:03:21.631 dnssec: warning: 
managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

The keyword here is not "managed-keys-zone", it's "dnssec".

Second, to put it bluntly, if you force bind9 to do DNSSEC validation
(which is enabled by default), bind9 won't be able to lookup anything
unless it is trusting root DNSSEC key. Like, for your own security and
stuff :)

Third, as every DNSSEC key, root zone keys have their expiration.
Meaning, you did not have to change anything to break your setup, every
time you deal with DNSSEC you're dealing with a ticking bomb anyway.

Fourth, Debian packaging helpfully forces bind9 to depend on dns-root-data,
which should provide a current DNSSEC root key (KSK to be precise), but
bind9 could also take said key from /etc/bind/bind.keys.


In conclusion:

1) Check the contents of your /etc/bind/bind.keys, update if needed.
2) Check the version of your dns-root-data, versions above and including
2021011101 (aka ksk id 20326) are good.
3) Set "dnssec-validation no;" at named.conf.options as a last resort.
4) If you intend to troubleshoot DNS queries then consider installing
tcpdump. The thing helps.

Reco

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread local10 
Mar 13, 2023, 09:32 by jer...@ardley.org:

> My next best option is simply to remove your bind caching server (it sounds 
> like it's not really necessary in your application)
>
> Backup /etc/bind and /var/cache/bind
>
> then
>
> systemctl remove bind9
>
> systemctl purge bind9
>
> And then edit /etc/resolv.conf to
>
> nameserver 8.8.8.8
> nameserver 8.8.4.4
>
> and with luck everything will work O.K.
>
> You can do variants on that to use your ISP DNS servers instead
> ...
>


Sure, I could have used some public DNS server and I may have to do that if I 
can't get this issue resolved. Still, I'd like to understand why BIND suddenly 
stopped working[1] for me and how to fix it.

Regards,


1. It was working fine yesterday and I haven't done any config changes since.

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Jeremy Ardley 



On 13/3/23 17:12, local10 wrote:


"debug 1;" doesn't seem to be a valid option, couldn't start BIND with it.  Anyhow, the 
following is what I get when running "dig www.yahoo.com"

Mar 13 05:03:11 tst systemd[1]: Started named.service - BIND Domain Name Server.
Mar 13 05:03:11 tst named[52836]: 13-Mar-2023 05:03:11.639 general: notice: 
running
Mar 13 05:03:18 tst named[52836]: 13-Mar-2023 05:03:18.963 queries: info: client 
@0x7f7812816d68 127.0.0.1#38800 (www.yahoo.com ): query: 
www.yahoo.com  IN A +E(0)K (127.0.0.1)
Mar 13 05:03:21 tst named[52836]: 13-Mar-2023 05:03:21.631 dnssec: warning: 
managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
Mar 13 05:03:21 tst named[52836]: 13-Mar-2023 05:03:21.711 resolver: info: 
resolver priming query complete: timed out
Mar 13 05:03:23 tst named[52836]: 13-Mar-2023 05:03:23.966 queries: info: client 
@0x7f7812817b68 127.0.0.1#51554 (www.yahoo.com ): query: 
www.yahoo.com  IN A +E(0)K (127.0.0.1)
Mar 13 05:03:28 tst named[52836]: 13-Mar-2023 05:03:28.970 queries: info: client 
@0x7f78c9eb1168 127.0.0.1#42404 (www.yahoo.com ): query: 
www.yahoo.com  IN A +E(0)K (127.0.0.1)
Mar 13 05:03:30 tst named[52836]: 13-Mar-2023 05:03:30.970 resolver: info: shut down 
hung fetch while resolving 'www.yahoo.com/A '
Mar 13 05:03:30 tst named[52836]: 13-Mar-2023 05:03:30.970 query-errors: info: client 
@0x7f78c9eb1168 127.0.0.1#42404 (www.yahoo.com ): query failed 
(operation canceled) for www.yahoo.com/IN/A  at 
query.c:7775
Mar 13 05:03:30 tst named[52836]: 13-Mar-2023 05:03:30.970 query-errors: info: client 
@0x7f7812816d68 127.0.0.1#38800 (www.yahoo.com ): query failed 
(operation canceled) for www.yahoo.com/IN/A  at 
query.c:7775
Mar 13 05:03:30 tst named[52836]: 13-Mar-2023 05:03:30.970 query-errors: info: client 
@0x7f7812817b68 127.0.0.1#51554 (www.yahoo.com ): query failed 
(operation canceled) for www.yahoo.com/IN/A  at 
query.c:7775
Mar 13 05:03:38 tst named[52836]: 13-Mar-2023 05:03:38.966 resolver: info: 
resolver priming query complete: timed out

My next best option is simply to remove your bind caching server (it 
sounds like it's not really necessary in your application)


Backup /etc/bind and /var/cache/bind

then

systemctl remove bind9

systemctl purge bind9

And then edit /etc/resolv.conf to

nameserver 8.8.8.8
nameserver 8.8.4.4

and with luck everything will work O.K.

You can do variants on that to use your ISP DNS servers instead

You have to be careful in systemd about network processes overwriting 
/etc/resolv.conf. e.g. if you get a DHCP address, or if your system is 
somehow configured to use systemd-resolved which I know to have problems.


Actually before your start anything do

systemctl status systemd-resolved

and if it's not installed things should be fine.

You may get

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

which is fine also.

In any case research on its configuration with

man systemd-resolved

I recall it uses a local address 127.0.0.53 to receive DNS queries

--
Jeremy
(Lists)

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread local10 
Mar 13, 2023, 08:31 by jer...@ardley.org:

> Sorry. Last message was garbled. Try this in /etc/bind/named.conf.options
>
> options {
>     // other configuration options ...
>     debug 1;
>     logging {
>     channel debug_log {
>     file "/var/log/bind9/debug.log" versions 3 size 5m;
>     severity dynamic;
>     print-time yes;
>     print-severity yes;
>     print-category yes;
>     };
>     category default {
>     debug_log;
>     };
>     };
> };
>
> also try setting /etc/resolv.conf to your ISP DNS servers - at least to get 
> software updates
>

"debug 1;" doesn't seem to be a valid option, couldn't start BIND with it.  
Anyhow, the following is what I get when running "dig www.yahoo.com"

Mar 13 05:03:11 tst systemd[1]: Started named.service - BIND Domain Name Server.
Mar 13 05:03:11 tst named[52836]: 13-Mar-2023 05:03:11.639 general: notice: 
running
Mar 13 05:03:18 tst named[52836]: 13-Mar-2023 05:03:18.963 queries: info: 
client @0x7f7812816d68 127.0.0.1#38800 (www.yahoo.com ): 
query: www.yahoo.com  IN A +E(0)K (127.0.0.1)
Mar 13 05:03:21 tst named[52836]: 13-Mar-2023 05:03:21.631 dnssec: warning: 
managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
Mar 13 05:03:21 tst named[52836]: 13-Mar-2023 05:03:21.711 resolver: info: 
resolver priming query complete: timed out
Mar 13 05:03:23 tst named[52836]: 13-Mar-2023 05:03:23.966 queries: info: 
client @0x7f7812817b68 127.0.0.1#51554 (www.yahoo.com ): 
query: www.yahoo.com  IN A +E(0)K (127.0.0.1)
Mar 13 05:03:28 tst named[52836]: 13-Mar-2023 05:03:28.970 queries: info: 
client @0x7f78c9eb1168 127.0.0.1#42404 (www.yahoo.com ): 
query: www.yahoo.com  IN A +E(0)K (127.0.0.1)
Mar 13 05:03:30 tst named[52836]: 13-Mar-2023 05:03:30.970 resolver: info: shut 
down hung fetch while resolving 'www.yahoo.com/A '
Mar 13 05:03:30 tst named[52836]: 13-Mar-2023 05:03:30.970 query-errors: info: 
client @0x7f78c9eb1168 127.0.0.1#42404 (www.yahoo.com ): 
query failed (operation canceled) for www.yahoo.com/IN/A 
 at query.c:7775
Mar 13 05:03:30 tst named[52836]: 13-Mar-2023 05:03:30.970 query-errors: info: 
client @0x7f7812816d68 127.0.0.1#38800 (www.yahoo.com ): 
query failed (operation canceled) for www.yahoo.com/IN/A 
 at query.c:7775
Mar 13 05:03:30 tst named[52836]: 13-Mar-2023 05:03:30.970 query-errors: info: 
client @0x7f7812817b68 127.0.0.1#51554 (www.yahoo.com ): 
query failed (operation canceled) for www.yahoo.com/IN/A 
 at query.c:7775
Mar 13 05:03:38 tst named[52836]: 13-Mar-2023 05:03:38.966 resolver: info: 
resolver priming query complete: timed out

Regards,

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Jeremy Ardley 



On 13/3/23 16:19, local10 wrote:

Mar 13, 2023, 07:25 by jer...@ardley.org:


Try

netstat -tulpnW | grep 53

and see what's listening


Bind seems to be listening on 127.0.0.1 port 53.

I don't have netstat installed and can't easily install it as aptitude can't 
resolve Debian server's name to an IP, so the following is what I tried:


# telnet -4 127.0.0.1 53
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
#
#
# systemctl stop  named.service
#
#
# telnet -4 127.0.0.1 53
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
#
#
# systemctl restart  named.service
#
#
# telnet -4 127.0.0.1 53
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
#


Sorry. Last message was garbled. Try this in /etc/bind/named.conf.options

options {
    // other configuration options ...
    debug 1;
    logging {
    channel debug_log {
    file "/var/log/bind9/debug.log" versions 3 size 5m;
    severity dynamic;
    print-time yes;
    print-severity yes;
    print-category yes;
    };
    category default {
    debug_log;
    };
    };
};

also try setting /etc/resolv.conf to your ISP DNS servers - at least to 
get software updates






--
Jeremy
(Lists)

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Jeremy Ardley 



On 13/3/23 16:19, local10 wrote:


Bind seems to be listening on 127.0.0.1 port 53.
I don't have netstat installed and can't easily install it as aptitude can't 
resolve Debian server's name to an IP, so the following is what I tried:


# telnet -4 127.0.0.1 53
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
#
#
# systemctl stop  named.service
#
#
# telnet -4 127.0.0.1 53
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
#
#
# systemctl restart  named.service
#
#
# telnet -4 127.0.0.1 53
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
#



At this stage I'd suggest wireshark but that won't be an option. Perhaps 
tcpdump is available?


Another option might be to set up a forwarder such as 8.8.8.8 or 1.1.1.1.

You can also edit debug options into to /etc/bind/named.conf.options

|options { // other configuration options ... // Debug Options debug 1; 
logging { channel debug_log { file "/var/log/bind9/debug.log" versions 3 
size 5m; severity dynamic; print-time yes; print-severity yes; 
print-category yes; }; category default { debug_log; }; }; // End debug 
options }; |



--
Jeremy
(Lists)

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread local10 
Mar 13, 2023, 07:25 by jer...@ardley.org:

> Try
>
> netstat -tulpnW | grep 53
>
> and see what's listening
>

Bind seems to be listening on 127.0.0.1 port 53.

I don't have netstat installed and can't easily install it as aptitude can't 
resolve Debian server's name to an IP, so the following is what I tried:


# telnet -4 127.0.0.1 53
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
#
#
# systemctl stop  named.service
#
#
# telnet -4 127.0.0.1 53
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
#
#
# systemctl restart  named.service
#
#
# telnet -4 127.0.0.1 53
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
#


Regards,

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Jeremy Ardley 



On 13/3/23 14:34, local10 wrote:

Mar 13, 2023, 06:19 by jer...@ardley.org:


The contents of /etc/resolv.conf are always of interest.



There's really not much there:

# cat /etc/resolv.conf
nameserver 127.0.0.1




That and /etc/nsswitch.conf a/etc/hosts


# cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd: files
group:  files
shadow: files
gshadow:    files

hosts:  files mdns4_minimal [NOTFOUND=return] dns
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:    db files

netgroup:   nis


# cat /etc/hosts

127.0.0.1   localhost




You should also check if there are any new firewall issues, and that you 
haven't run out of space somewhere.

Finally, you may have forwarder(s) in your bind. It's best to check if that is 
working



No changes were made to the firewall and there are no firewall issues I'm aware of. The 
forwarder's section in the "/etc/bind/named.conf.options" is commented out so 
there are no forwarders:

    // forwarders {
     //  0.0.0.0;
     // };


# aptitude show bind9
Package: bind9
Version: 1:9.18.12-1


Try

netstat -tulpnW | grep 53

and see what's listening

--
Jeremy
(Lists)

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread local10 
Mar 13, 2023, 06:19 by jer...@ardley.org:

> The contents of /etc/resolv.conf are always of interest.
>


There's really not much there:

# cat /etc/resolv.conf
nameserver 127.0.0.1



> That and /etc/nsswitch.conf a/etc/hosts
>

# cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd: files
group:  files
shadow: files
gshadow:    files

hosts:  files mdns4_minimal [NOTFOUND=return] dns
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:    db files

netgroup:   nis


# cat /etc/hosts

127.0.0.1   localhost



> You should also check if there are any new firewall issues, and that you 
> haven't run out of space somewhere.
>
> Finally, you may have forwarder(s) in your bind. It's best to check if that 
> is working
>


No changes were made to the firewall and there are no firewall issues I'm aware 
of. The forwarder's section in the "/etc/bind/named.conf.options" is commented 
out so there are no forwarders:

   // forwarders {
    //  0.0.0.0;
    // };


# aptitude show bind9
Package: bind9  
Version: 1:9.18.12-1


Regards,

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

2023-03-13 Thread Jeremy Ardley 



On 13/3/23 14:08, local10 wrote:

Hi,

I have  a local caching DNS server that was working fine for a long time but 
today, all of a sudden, it stopped resolving queries.

More info: https://pastebin.com/iW5YeXgS

Any ideas? Thanks


The contents of /etc/resolv.conf are always of interest.

That and /etc/nsswitch.conf a/etc/hosts

You should also check if there are any new firewall issues, and that you 
haven't run out of space somewhere.


Finally, you may have forwarder(s) in your bind. It's best to check if 
that is working


--


Jeremy
(Lists)