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

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 intr

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

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, yo

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

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-

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

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 syste

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

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 ev

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

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

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

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

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

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

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

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

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 Loa

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

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 messa

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

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 "comm

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

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

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

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 wit

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

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

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

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

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 b

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

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

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

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

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

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

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

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 kn

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

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

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

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 i

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

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

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

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 /e

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

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]:

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

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/bin

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

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

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

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 1

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

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 w

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

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/nssw

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

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 configurati

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

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

Re: bind gets permission errors in buster--systemd-related?

On Wed, May 15, 2019 at 10:39 AM Sven Joachim wrote: > I am not really familiar with apparmor or resolvconf, but in > /etc/apparmor.d/usr.sbin.named I found the following: > > , > | # support for resolvconf > | /{,var/}run/named/named.options r, > ` > > which suggests that the sta

Re: bind gets permission errors in buster--systemd-related?

I also have a similar problem accessing /run/named.  bind can't create the directory or any files in it.  The error messages: couldn't mkdir '//run/named': Permission denied could not create //run/named/session.key Apparmor problems can be fixed by running aa-logprof and selecting the best "f

Re: bind gets permission errors in buster--systemd-related?

On 2019-05-15 09:33 -0700, Ross Boylan wrote: > Sven, thanks for the tip about AppArmor. Yet another presumably > complicated system I've avoided learning about til now. I guess it's > time. > > As to why bind is trying to open /run/named/named.resolvers: that is a > customized integration with

Re: bind gets permission errors in buster--systemd-related?

On Wed, May 15, 2019 at 12:11:58PM -0400, Lee wrote: > The way I fixed my permission problems after telling bind to log to a > file instead of syslog was > su - > to become root > su bind > which didn't work because > # grep bind /etc/passwd > bind:x:116:119::/var/cache/bind:/bin/false > so

Re: bind gets permission errors in buster--systemd-related?

Sven, thanks for the tip about AppArmor. Yet another presumably complicated system I've avoided learning about til now. I guess it's time. As to why bind is trying to open /run/named/named.resolvers: that is a customized integration with resolvconf. It is not the default, but it is something I

Re: bind gets permission errors in buster--systemd-related?

On 5/15/19, Ross Boylan wrote: > I have a new buster system with a bind setup based on (much) older* > systems, on which it worked fine. On buster, it doesn't. > In two different places in my configuration I referred to files or > directories that were outside of bind proper, and in both cases th

Re: bind gets permission errors in buster--systemd-related?

On 2019-05-14 21:50 -0700, Ross Boylan wrote: > I have a new buster system with a bind setup based on (much) older* > systems, on which it worked fine. On buster, it doesn't. > In two different places in my configuration I referred to files or > directories that were outside of bind proper, and i

[SOLVED] Re: Bind: A caching local server caches but not for long

Sep 16, 2018, 6:40 PM by pas...@plouf.fr.eu.org: > old.reddit.com. 300 IN CNAME reddit.map.fastly.net. > reddit.map.fastly.net.30 IN A 151.101.121.140 > > These DNS records have short TTL, less than 8 minutes. > It is expected behaviour that a cache

Re: Bind: A caching local server caches but not for long

On Mon, Sep 17, 2018 at 12:20:51AM +0200, local10 wrote: ;; ANSWER SECTION: old.reddit.com. 241 IN  CNAME   reddit.map.fastly.net. reddit.map.fastly.net.  8   IN  A   151.101.21.140 this number ^^^ is the TTL/"time to live" in seconds. It is set by the s

Re: Bind: A caching local server caches but not for long

Le 17/09/2018 à 00:20, local10 a écrit : Hi, So I set up a local caching server with bind. It seems to work, kind of, the problem is that cached results do not stay in cache for long, if they placed in cache at all. For example, in the example below bind caches the result for "old.reddit.com"

Re: BIND and iptables config

On Fri 16 Feb 2018 at 08:53:27 (-0500), Henning Follmann wrote: > On Fri, Feb 16, 2018 at 04:26:14AM +0100, Rodary Jacques wrote: > > Le jeudi 15 février 2018, 11:44:36 CET Henning Follmann a écrit : > > > On Thu, Feb 15, 2018 at 05:01:52PM +0100, Rodary Jacques wrote: > > > > With NetworkManager,

Re: Re: BIND and iptables config

Because when I did , witen iI just installed Jessie in April 2016, my mailbox which is dedicated to debian-user was flooded with useless or even stupid posts. Sorry for my fellow countrymen. Salut. Jacques

Re: BIND and iptables config

On Fri, Feb 16, 2018 at 04:26:14AM +0100, Rodary Jacques wrote: > Le jeudi 15 février 2018, 11:44:36 CET Henning Follmann a écrit : > > On Thu, Feb 15, 2018 at 05:01:52PM +0100, Rodary Jacques wrote: > > > With NetworkManager, /etc/network/interfaces has only the loopbak > > > interface, and I can

Re: BIND and iptables config

On Thursday, February 15, 2018 10:26:14 PM Rodary Jacques wrote: > Le jeudi 15 février 2018, 11:44:36 CET Henning Follmann a écrit : > > On Thu, Feb 15, 2018 at 05:01:52PM +0100, Rodary Jacques wrote: > > > With NetworkManager, /etc/network/interfaces has only the loopbak > > > interface, and I can

Re: BIND and iptables config

Le jeudi 15 février 2018, 11:44:36 CET Henning Follmann a écrit : > On Thu, Feb 15, 2018 at 05:01:52PM +0100, Rodary Jacques wrote: > > With NetworkManager, /etc/network/interfaces has only the loopbak > > interface, and I can't use wicd which can't deal with two wired interfaces. > > And, Hennin

Re: BIND and iptables config

Le jeudi 15 février 2018, 11:44:36 CET Henning Follmann a écrit : > On Thu, Feb 15, 2018 at 05:01:52PM +0100, Rodary Jacques wrote: > > With NetworkManager, /etc/network/interfaces has only the loopbak > > interface, and I can't use wicd which can't deal with two wired interfaces. > > And, Hennin

Re: BIND and iptables config

Le 15/02/2018 à 17:01, Rodary Jacques a écrit : my English is too poor to explain clearly my setup Why don't you post in French in the debian-user-french mailing list ?

Re: BIND and iptables config

On Thu, 15 Feb 2018 08:08:59 -0500 Greg Wooledge wrote: > > > But NetworkManager > > *shudder* You're on your own with that one. > Datum: I remember Notwork Manager, but I've used it for at least five years on a netbook, with wi-fi, openvpn and a number of pre-set fixed IP wired schemes,

Re: BIND and iptables config

On Thu, Feb 15, 2018 at 05:01:52PM +0100, Rodary Jacques wrote: > With NetworkManager, /etc/network/interfaces has only the loopbak interface, > and I can't use wicd which can't deal with two wired interfaces. And, Henning > Follmann, my English is too poor to explain clearly my setup which is th

Re: BIND and iptables config

With NetworkManager, /etc/network/interfaces has only the loopbak interface, and I can't use wicd which can't deal with two wired interfaces. And, Henning Follmann, my English is too poor to explain clearly my setup which is the standard one when your ISP gives you one routable address and you w

Re: BIND and iptables config

On Wed, Feb 14, 2018 at 11:51:50PM +0100, Rodary Jacques wrote: > I have my own DNS config t so that my home LAN can access internet (with > SNAT) to "the" internet which I created under Redhat 7.2! It did work on a > Redhat box with Systemd, NetworkManager , and the bind9 RPM. On Debian the >

Re: BIND and iptables config

On Wed, Feb 14, 2018 at 11:51:50PM +0100, Rodary Jacques wrote: > I have my own DNS config t so that my home LAN can access internet (with > SNAT) to "the" internet which I created under Redhat 7.2! It did work on a > Redhat box with Systemd, NetworkManager , and the bind9 RPM. On Debian the >

Re: BIND DNS problem after upgrading from Wheezy to Squeeze

Pascal Hambourg wrote: > Le 29/12/2017 à 18:27, Andrew W a écrit : >> >> On 27/12/2017 13:18, Bernhard Schmidt wrote: >>> Current BIND9 defaults to doing DNSSEC verification. DNSSEC needs large >>> packets. You might have an issue with UDP fragments being dropped at >>> your firewall/NAT Gateway?

Re: BIND DNS problem after upgrading from Wheezy to Squeeze

Le 29/12/2017 à 18:27, Andrew W a écrit : On 27/12/2017 13:18, Bernhard Schmidt wrote: Current BIND9 defaults to doing DNSSEC verification. DNSSEC needs large packets. You might have an issue with UDP fragments being dropped at your firewall/NAT Gateway? Thanks for this tip. Looking into it I

Re: BIND DNS problem after upgrading from Wheezy to Squeeze

On 27/12/2017 13:18, Bernhard Schmidt wrote: Current BIND9 defaults to doing DNSSEC verification. DNSSEC needs large packets. You might have an issue with UDP fragments being dropped at your firewall/NAT Gateway? Thanks for this tip. Looking into it I discovered TCP seems to be recommened fo

Re: BIND DNS problem after upgrading from Wheezy to Squeeze

Andrew Wood wrote: Hi, > I have a server which acts as a DNS server for our LAN. All our internal > servers have A records on it using a .local domain and it forwards all > other requests out to the root servers using the in built list provided > with BIND. All clients on the LAN have this ma

Re: BIND DNS problem after upgrading from Wheezy to Squeeze

Andrew W wrote: > > > Does anyone have any ideas please? > I had the same experience - I think (after trying this and that) the solution was ntp (time was behind on the server), but I am not really 100%. I was thinking first it has something to do with ipv6 or firewall, but after updating the

Re: Bind 9: consequences of completely removind all bind9 packages on jessie and stretch)?

On Mon, Jul 24, 2017 at 11:57 AM, Sven Hartge wrote: > Tom Browder wrote: ... >> Greg, I appreciate your advice, and I would love to stay with the >> debian packages. However, I also want to be able to use a debian >> installation a long time and I see lots of changes on dns resource >> records.

Re: Bind 9: consequences of completely removind all bind9 packages on jessie and stretch)?

Tom Browder wrote: > On Mon, Jul 24, 2017 at 8:23 AM, Greg Wooledge wrote: >> On Sun, Jul 23, 2017 at 06:55:09AM -0500, Tom Browder wrote: >>> I would like to remove all bind9 packages from servers running bind9 >>> and install the latest bind9 from source. >> Because you want to satisfy intern

Re: Bind 9: consequences of completely removind all bind9 packages on jessie and stretch)?

On Mon, Jul 24, 2017 at 8:23 AM, Greg Wooledge wrote: > On Sun, Jul 23, 2017 at 06:55:09AM -0500, Tom Browder wrote: >> I would like to remove all bind9 packages from servers running bind9 >> and install the latest bind9 from source. > > Because you want to satisfy internal audits that don't under

Re: Bind 9: consequences of completely removind all bind9 packages on jessie and stretch)?

On Sun, Jul 23, 2017 at 06:55:09AM -0500, Tom Browder wrote: > I would like to remove all bind9 packages from servers running bind9 > and install the latest bind9 from source. Because you want to satisfy internal audits that don't understand how Debian security patching works, right? Right? Righ

Re: Bind 9: consequences of completely removind all bind9 packages on jessie and stretch)?

On Sun, Jul 23, 2017 at 07:13 Lck Ras wrote: > On 07/23/2017 08:55 PM, Tom Browder wrote: > > I would like to remove all bind9 packages from servers running bind9 > > and install the latest bind9 from source. > > > > Two questions, please: > > > > 1. Will there be any adverse consequences from t

Re: BIND problem

> On Feb 23, 2016, at 2:46 PM, Reco wrote: > > Why, it's worth a shot. But doing it by hand would be > counter-productive. They have invented 'debsums' for cases like this, > after all. OK. Sounds reasonable. I'll try it in the morning. -- Glenn English

Re: BIND problem

On Tue, 23 Feb 2016 14:04:52 -0700 Glenn English wrote: > > > On Feb 23, 2016, at 8:56 AM, Reco wrote: > > > > First things first, unless someone deliberately customized > > it, /etc/rc.local should contain exactly one meaningful line - 'exit > > 0'. > > It does. See below. > > > Your result

Re: BIND problem

> On Feb 23, 2016, at 8:56 AM, Reco wrote: > > First things first, unless someone deliberately customized > it, /etc/rc.local should contain exactly one meaningful line - 'exit > 0'. It does. See below. > Your result shows entirely different thing though. Well, I just asked egrep to look for

Re: BIND problem

On Tue, 23 Feb 2016 07:42:59 -0700 Glenn English wrote: > > > On Feb 23, 2016, at 1:45 AM, Reco wrote: > > > I'd start with rkhunter check first. Just to be sure. > > Checking for enabled inetd services [ Warning ] > > That's AmandaClient, the backup software. Harml

Re: BIND problem

> On Feb 23, 2016, at 1:45 AM, Reco wrote: > I'd start with rkhunter check first. Just to be sure. Checking for enabled inetd services [ Warning ] That's AmandaClient, the backup software. Checking if SSH root access is allowed [ Warning ] It is

Re: BIND problem

Hi. On Mon, 22 Feb 2016 20:44:23 -0700 Glenn English wrote: > > > On Feb 22, 2016, at 3:58 PM, Reco wrote: > > > > First one is 'ls -ald /var/cache'. > > root@log:~# ls -ald /var/cache > drwxr-xr-x 14 root root 4096 Oct 12 2013 /var/cache > > > Second one is 'sudo -u touch /var/cac

Re: BIND problem

> On Feb 22, 2016, at 3:58 PM, Reco wrote: > > First one is 'ls -ald /var/cache'. root@log:~# ls -ald /var/cache drwxr-xr-x 14 root root 4096 Oct 12 2013 /var/cache > Second one is 'sudo -u touch /var/cache/bind/slaves/1'. sudo: unknown user: touch sudo: unable to initialize policy plugin (

Re: BIND problem

On Mon, 22 Feb 2016 15:33:54 -0700 Glenn English wrote: > > > On Feb 22, 2016, at 3:16 PM, Reco wrote: > > > > So, what permissions does /var/cache and /var/cache/bind have? > > root@log:~# ls -lh /var/cache/bind > total 48K > -rw-rw-r-- 1 bind bind 221 Oct 12 2013 managed-keys.bind > -rw-r

Re: BIND problem

> On Feb 22, 2016, at 3:16 PM, Reco wrote: > > So, what permissions does /var/cache and /var/cache/bind have? root@log:~# ls -lh /var/cache/bind total 48K -rw-rw-r-- 1 bind bind 221 Oct 12 2013 managed-keys.bind -rw-rw-r-- 1 bind bind 512 Oct 12 2013 managed-keys.bind.jnl drwxrwxr-x 2 bind

Re: BIND problem

On Mon, 22 Feb 2016 14:33:03 -0700 Glenn English wrote: > > > On Feb 22, 2016, at 1:59 PM, Reco wrote: > > > > No, that's not how you check it. Every Debian system has those records. > > I meant something like 'ls -alZ /'. > > drwxr-xr-x 25 root root? 4096 Jun 6 2014 . > drwxr-xr-x

Re: BIND problem

> On Feb 22, 2016, at 1:59 PM, Reco wrote: > > No, that's not how you check it. Every Debian system has those records. > I meant something like 'ls -alZ /'. drwxr-xr-x 25 root root? 4096 Jun 6 2014 . drwxr-xr-x 25 root root? 4096 Jun 6 2014 .. drwxr-xr-x 2 root root?

Re: BIND problem

Hi. On Mon, 22 Feb 2016 13:07:44 -0700 Glenn English wrote: > > > On Feb 22, 2016, at 3:14 AM, Reco wrote: > > > > Please post the output of: > > > > ls -ald /var/cache/bind/slaves > > drwxrwxr-x 2 bind bind 4096 Feb 5 07:52 /var/cache/bind/slaves > > > lsattr /var/cache/bind/slav

Re: BIND problem

> On Feb 22, 2016, at 3:14 AM, Reco wrote: > > Please post the output of: > > ls -ald /var/cache/bind/slaves drwxrwxr-x 2 bind bind 4096 Feb 5 07:52 /var/cache/bind/slaves > lsattr /var/cache/bind/slaves -e-- /var/cache/bind/slaves/db.172.16.0 -e-- /var/cache/bind/sl

Re: BIND problem

Hi. On Mon, 22 Feb 2016 02:35:52 -0700 Glenn English wrote: > I'm seeing lots of: > > > Feb 21 23:32:24 log named[20061]: dumping master file: > > /var/cache/bind/slaves/tmp-I5cJjYH7fV: open: permission denied > > Feb 21 23:36:54 log named[20117]: dumping master file: > > /var/cache/b

Re: Re: Bind 9 unknown option 'logging'[Solved]

OK solved. I had the include "/etc/bind/named.conf.log"; statement in the wrong place in the named.conf file. I had it inside the options { } -- Gerard Hooton. Senior Technical Officer School of Engineering. University College Cork. College Road. Cork. Ireland. Tel: +353 21 4902296 Mobile: +353

Re: Bind 9 unknown option 'logging'

On 12/06/15 15:31, to...@tuxteam.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jun 12, 2015 at 03:21:26PM +0100, Gerard Hooton wrote: Hi All, I already sent that was but before I subscribed to the list. I have included the following in my named.conf logging { channel b

Re: Bind 9 unknown option 'logging'

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jun 12, 2015 at 03:21:26PM +0100, Gerard Hooton wrote: > Hi All, > I already sent that was but before I subscribed to the list. > > I have included the following in my named.conf > > logging { > channel bind_log { > file "/var/log/bind

Re: bind mount

From: The Wanderer Date: Tue, 23 Dec 2014 13:01:37 -0500 > I think what Andrei meant is asking what you're trying to accomplish by > bind-mounting the one directory on the other as an ordinary user. That > is, what is the problem to which you are attempting to apply this as a > solution?

Re: bind mount

From: The Wanderer Date: Tue, 23 Dec 2014 13:01:37 -0500 > I think what Andrei meant is asking what you're trying to accomplish by > bind-mounting the one directory on the other as an ordinary user. That > is, what is the problem to which you are attempting to apply this as a > solution?

Re: bind mount

From: Andrei POPESCU Date: Mon, 22 Dec 2014 22:51:47 +0200 > What are you trying to accomplish? Mount a directory on a directory. Scroll down to "--bind". http://linux.die.net/man/8/mount Seems odd that ordinary mounts are available to users but "bind" is only for root. Thanks,

Re: bind mount

On 12/23/2014 at 11:38 AM, pe...@easthope.ca wrote: > From: Andrei POPESCU Date: Mon, 22 Dec > 2014 22:51:47 +0200 >> What are you trying to accomplish? > > Mount a directory on a directory. Scroll down to "--bind". > http://linux.die.net/man/8/mount I think what Andrei meant is asking what y

Re: bind mount

On Lu, 22 dec 14, 11:03:07, pe...@easthope.ca wrote: > This line in /etc/fstab allows bind mounting, except that > the user option has no effect. > /usr/bin/aos /home/usr/.aoshome none bind,user > > There is no simple way to allow a user? What are you trying to accomplish? Kind regards, Andrei

Re: BIND RRL

Hello all, On Sat, Oct 05, 2013 at 03:05:02PM +0200, pch0317 wrote: > Is DDoS Defense Module for BIND RRL available in Debian 7.1? If by that you mean the patches from http://www.redbarn.org/dns/ratelimits then yes, they are included in Wheezy and additionally available via squeeze-backports. HT

Re: Bind wildcard and DNSsec

Hi there Rob van der Putten wrote: 1:9.8.4 is now in unstable. Build my own Squeeze backport. Seems to work. Regards, Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://list

Re: bind alt + . in bash vi mode

This took me too long to figure it out but in case anybody else was wondering how to do this. This is the correct line... bind -m vi-insert '"\e.": yank-last-arg' On Sat, Jun 9, 2012 at 8:36 PM, alberto fuentes wrote: > I set it to emacs > set -o emacs > then i saw the function i was loo

Re: Bind wildcard and DNSsec

Hi there Rob van der Putten wrote: 9.9.2 is now in Experimental; http://packages.debian.org/experimental/bind9 1:9.8.4 is now in unstable. Regards, Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.de

Re: Bind wildcard and DNSsec

Hi there Rob van der Putten wrote: Unstable may move to 9.8.2 at some point. It might be possible to backport 9.8.2 to stable when this happens. 9.9.2 is now in Experimental; http://packages.debian.org/experimental/bind9 Regards, Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.

Re: Bind wildcard and DNSsec

Hi there Mike Viau wrote: Thanks for you updates and efforts on this issue Rob! Unstable may move to 9.8.2 at some point. It might be possible to backport 9.8.2 to stable when this happens. Regards, Rob -- Abolish all anti blasphemy legislation. -- To UNSUBSCRIBE, email to debian-user-

RE: Bind wildcard and DNSsec

> On Date: Tue, 23 Oct 2012 11:44:03 +0200 wrote: > > Hi there > > > Rob van der Putten wrote: > > > I filed a bug report; > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690569 > > > > Bind refers to this bug as 'RT #26200' > > Bind fixed this in January. > I don't expect Debian to implement

Re: Bind wildcard and DNSsec

Hi there Rob van der Putten wrote: I filed a bug report; http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690569 Bind refers to this bug as 'RT #26200' Bind fixed this in January. I don't expect Debian to implement this fix soon. It's probably best to disable DNSsec in your resolver. Rega

Re: Bind wildcard and DNSsec

Hi there Rob van der Putten wrote: My resolver (Bind9 with DNSsec enabled) doesn't resolve 'www.nuonexclusief.nl', but it does resolve 'nuonexclusief.nl'. Apparently this is due to a DNSsec + wildcard problem (*.nuonexclusief.nl), which has been fixed in 9.6-ESV-R6, 9.7.5 and 9.8.2. AFAIK ther

Re: bind: Address already in use

On 06/07/12 02:17 PM, Chris Davies wrote: Gary Dale wrote: I've been connecting to the workstations by running: ssh -L 5900::5900 Today I'm getting the error: bind: Address already in use Any ideas? The address is already in use, probably from another ssh session using the same local an

Re: bind: Address already in use

On 06/07/12 02:17 PM, Chris Davies wrote: Gary Dale wrote: I've been connecting to the workstations by running: ssh -L 5900::5900 Today I'm getting the error: bind: Address already in use Any ideas? The address is already in use, probably from another ssh session using the same local an

Re: bind: Address already in use

Gary Dale wrote: > I've been connecting to the workstations by running: > ssh -L 5900::5900 IP address> > Today I'm getting the error: >bind: Address already in use > Any ideas? The address is already in use, probably from another ssh session using the same local and/or remote port. On

Re: bind: Address already in use

On 06/07/12 12:42 PM, Gary Dale wrote: This has just started happening. I remotely administer an office by using ssh and vnc. Ssh is running on a Debian/Squeeze server while I have vnc on each of the workstations. I've been connecting to the workstations by running: ssh -L 5900::5900 IP addre

  1   2   3   >