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

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,

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

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

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

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

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 ●

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

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

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

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

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

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

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

ni 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 issu

[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 l

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

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

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

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

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

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

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

; 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

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

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

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

ld 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 an

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: Name or Sevice not known - bind

On Thu, Jan 19, 2023 at 09:12:19PM +0100, Maurizio Caloro wrote: > # host -t A pluto.sternbild.m 127.0.0.1 > Using domain server: > Name: 127.0.0.1 > Address: 127.0.0.1#53 > Aliases: > > Host pluto.sternbild.m not found: 3(NXDOMAIN) Hmm. In your previous message, you hav

Re: Name or Sevice not known - bind

  17207/named # systemctl stop systemd-resolved.service # netstat -plnt | grep ':53' tcp    0  0 127.0.0.1:53 0.0.0.0:*   LISTEN  17207/named tcp6   0  0 :::53 :::*    LISTEN  17207/named - bind are restarted and running # systemctl status

Re: Name or Sevice not known - bind

On Thu, Jan 19, 2023 at 07:45:34PM +0100, Maurizio Caloro wrote: > fighting little with bind9, on Debian 10.13, in my opinion appair right, but > # cat /etc/resolv.conf > search sternbild.m > nameserver 127.0.0.1 > nameserver A.B.C.D -> other Nameservers > nameserver A.B.C.D -> other Nameservers

Name or Sevice not known - bind

hello fighting little with bind9, on Debian 10.13, in my opinion appair right, but arn't possible to ping local/inside the Client that i have add to my config. information this machine running on a VPS envirment. also the checks are positiv # named-checkzone sternbild.m /var/cache/bind

Re: Q 2 Bind?

On Wed, Jun 22, 2022 at 09:13:20PM +0200, Maurizio Caloro wrote: > pls, why this key arnt found? the file are here in this folder and write > *root:bind* it's set > > Jun 22 21:03:56 nmail named[27607]: zone 127.in-addr.arpa/IN: loaded serial > 1 > Jun 22 21:03:56 nmail named[27607]: zone

Q 2 Bind?

pls, why this key arnt found? the file are here in this folder and write *root:bind* it's set Jun 22 21:03:56 nmail named[27607]: zone 127.in-addr.arpa/IN: loaded serial 1 Jun 22 21:03:56 nmail named[27607]: zone 190.120.37.in-addr.arpa/IN: loaded serial 1 Jun 22 21:03:56 nmail named[27607]:

Re: WARNING: debian11 + bind-9.16.15 + dnssec-policy in options{} = crashes

On Mon, 16 Aug 2021, raf wrote: > If like me, you've been eagerly awaiting debian11 to > get bind-9.16.15, which finally lets you implement > DNSSEC extremely easily on debian stable, I have a > warning. And I have another: make sure your system clock is correct. DNSSEC will fail if

WARNING: debian11 + bind-9.16.15 + dnssec-policy in options{} = crashes

Hi, If like me, you've been eagerly awaiting debian11 to get bind-9.16.15, which finally lets you implement DNSSEC extremely easily on debian stable, I have a warning. Bind has a dnssec-policy {} stanza for defining your own policy if you're feeling adventurous, but there's also a default policy

ProFTPd : error: unable to bind to local socket: Address already in use

ProFTPd :error: unable to bind to local socket: Address already in use Debian 10. Issue réouverte pour ProFTPd : https://github.com/proftpd/proftpd/issues/914 Le copié collé du problème rencontré : sudo dpkg -l| grep proftpd ii proftpd-basic 1.3.6-6 amd64 Versatile, virtual-hosting FTP daemon

Re: sshd fails to bind to port to IP on boot

solved issue ... thank u On Fri, Sep 27, 2019 at 11:55 AM Greg Wooledge wrote: > On Fri, Sep 27, 2019 at 11:44:25AM -0400, yoda woya wrote: > > The public interface is listed defined as > > > > # The public network interface > > allow-hotplug eno1 > > iface eno1 inet static > > address

Re: sshd fails to bind to port to IP on boot

On Fri, Sep 27, 2019 at 11:44:25AM -0400, yoda woya wrote: > The public interface is listed defined as > > # The public network interface > allow-hotplug eno1 > iface eno1 inet static > address x.x.x.x > > > But I have that same configuration on another server and it works fine.

Re: sshd fails to bind to port to IP on boot

Hi. Please do not top-post. On Fri, Sep 27, 2019 at 11:51:08AM -0400, yoda woya wrote: > How can I use to solve the problem: > > "ssh.service has "After=network.target", and network.target only waits > for interfaces marked as "auto" to come up." You have this in your

Re: sshd fails to bind to port to IP on boot

art job for unit ssh.service has begun execution. > > Sep 27 10:52:31 nat6pub sshd[690]: error: Bind to port 2022 on x.x.x.x > > failed: Cannot assign requested address. > > Sep 27 10:52:31 nat6pub sshd[690]: fatal: Cannot bind any address. > > Sep 27 10:52:31 nat6pub systemd

Re: sshd fails to bind to port to IP on boot

commented out or set to 0.0.0.0. The service works >> > manually ( /etc/init.d/ssh start) >> > -- Subject: A start job for unit ssh.service has begun execution >> > -- A start job for unit ssh.service has begun execution. >> > Sep 27 10:52:31 nat6pub sshd[690]:

Re: sshd fails to bind to port to IP on boot

nted out or set to 0.0.0.0. The service works > > manually ( /etc/init.d/ssh start) > > -- Subject: A start job for unit ssh.service has begun execution > > -- A start job for unit ssh.service has begun execution. > > Sep 27 10:52:31 nat6pub sshd[690]: error: Bind to port 2022 on x.x.

Re: sshd fails to bind to port to IP on boot

ce has begun execution > -- A start job for unit ssh.service has begun execution. > Sep 27 10:52:31 nat6pub sshd[690]: error: Bind to port 2022 on x.x.x.x > failed: Cannot assign requested address. > Sep 27 10:52:31 nat6pub sshd[690]: fatal: Cannot bind any address. > Sep 27 10:52:31 nat6

Re: sshd fails to bind to port to IP on boot

nit ssh.service has begun execution. > Sep 27 10:52:31 nat6pub sshd[690]: error: Bind to port 2022 on x.x.x.x > failed: Cannot assign requested address. Do you have an existing interface with x.x.x.x assigned to it? -dsr-

Re: sshd fails to bind to port to IP on boot

10:52:31 nat6pub sshd[690]: error: Bind to port 2022 on x.x.x.x failed: Cannot assign requested address. Sep 27 10:52:31 nat6pub sshd[690]: fatal: Cannot bind any address. Sep 27 10:52:31 nat6pub systemd[1]: ssh.service: Main process exited, code=exited, status=255/EXCEPTION -- An ExecStart= process

Re: sshd fails to bind to port to IP on boot

On Thu, Sep 26, 2019 at 05:34:02PM -0400, yoda woya wrote: > when I use this, the binding fails: > Port 2022 > #AddressFamily any > ListenAddress x.x.x.x > #ListenAddress :: > > but if I do , it binds it to the ip on boot > Port 2022 > #AddressFamily any > #ListenAddress x.x.x > #ListenAddress ::

Re: sshd fails to bind to port to IP on boot

On Thu, Sep 26, 2019 at 05:34:02PM -0400, yoda woya wrote: >when I use this, the binding fails: >Port 2022 >#AddressFamily any >ListenAddress x.x.x.x >#ListenAddress :: >but if I do , it binds it to the ip on boot >Port 2022 >#AddressFamily any >#ListenAddress

sshd fails to bind to port to IP on boot

when I use this, the binding fails: Port 2022 #AddressFamily any ListenAddress x.x.x.x #ListenAddress :: but if I do , it binds it to the ip on boot Port 2022 #AddressFamily any #ListenAddress x.x.x #ListenAddress :: How can i fix this. I want sshd to run only on this one IP

Re: bind9 startup problems: /var/cache /bind

I tested my suspicion that bind9-resolvconf was somehow implicated in the bind9 start problems by returning bind9-resolvconf to its original, disabled, state and restarting the system. Unfortunately, it didn't help: May 25 19:05:34 barley named[804]: /etc/bind/named.conf.options:2: change

Re: bind9 startup problems: /var/cache /bind

fter rebooting I still get -- May 22 18:38:49 barley named[829]: loading configuration from '/etc/bind/named.conf' May 22 18:38:49 barley named[829]: /etc/bind/named.conf.options:2: change directory to '/var/cache/bind' failed: file not found May 22 18:38:49 barley named[8

Re: bind9 startup problems: /var/cache /bind

s while some of the mounts (and the > required decryption) are still to be done? > > Is there some systemd way to ensure the file system is mounted before > launching bind? But I'd think if /var weren't available, bind > wouldn't be the only one with a problem. Well, I don't se

Re: bind9 startup problems: /var/cache /bind

) are still to be done? Is there some systemd way to ensure the file system is mounted before launching bind? But I'd think if /var weren't available, bind wouldn't be the only one with a problem. Ross

Re: bind9 startup problems: /var/cache /bind

On 23/05/19 8:00 AM, Ross Boylan wrote: > At system start, bind9 fails to start on a recently created buster > system. Some of the local bind is based on configuration from an > earlier bind. The logs show > /etc/bind/named.conf.options:2: change directory to '/var/cache/bind' &g

bind9 startup problems: /var/cache /bind

At system start, bind9 fails to start on a recently created buster system. Some of the local bind is based on configuration from an earlier bind. The logs show /etc/bind/named.conf.options:2: change directory to '/var/cache/bind' failed: file not found But if I then start it manually via

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

ut just below that is # some people like to put logs in /var/log/named/ instead of having # syslog do the heavy lifting. /var/log/named/** rw, /var/log/named/ rw, so if I switch my logs to there (and rename the directory), instead of /var/log/bind, the logging should work too. Or I could ad

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

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

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::/v

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 i

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 gets permission errors in buster--systemd-related?

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 this failed with permission problems. I'm

BIND forward de una zona publica al resolver 8.8.8.8 de Google

clientes puedan resolver solamente el dominio publico "linux.org", el resto de los dominios publicos en Internet no se pueden resolver. Para ello en named.conf.options definir: options { directory "/var/cache/bind"; dnssec-validation auto; dnssec-enable yes;

BIND forward de una zona publica a un resolver externo

clientes puedan resolver solamente el dominio publico "linux.org", el resto de los dominios publicos en Internet no se pueden resolver. Para ello en named.conf.options definir: options { directory "/var/cache/bind"; dnssec-validation auto; dnssec-enable yes;

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

ected behaviour that a cached record is discarded when its TTL > expires. > Check if BIND has options to force a minimal TTL on cached records. > Bind, as I understand it, does not have a setting that allows to change the minimal TTL but unbound and dnsmasq (the later versions) do. Instea

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

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

Bind: A caching local server caches but not for long

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" but 8 minutes later tries

Bind bug

Hi there See; https://kb.isc.org/article/AA-01639/0 I don't think not using deny-answer-aliases is really an option. Regards, Rob

Re: BIND and iptables config

; Hello, > > > no your english was good enough to describe your setup. And I would say > > > that 90% of "us" have a form of "dialup" with on routable ip address and a > > > NAT setup. > > > First bind is not "standard" in this kind of s

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

ur home LAN to have access to internet. > > > Thanks for your interest anyway. > > > Jacques > > > > > > > Hello, > > no your english was good enough to describe your setup. And I would say > > that 90% of "us" have a form of &

Re: BIND and iptables config

to have access to > > > internet. I don't understand--what are the two wired interfaces that you have connected to your computer? > > Hello, > > no your english was good enough to describe your setup. And I would say > > that 90% of "us" have a form o

Re: BIND and iptables config

Jacques > > > > Hello, > no your english was good enough to describe your setup. And I would say > that 90% of "us" have a form of "dialup" with on routable ip address and a > NAT setup. > First bind is not "standard" in this kind of

Re: BIND and iptables config

Jacques > > > > Hello, > no your english was good enough to describe your setup. And I would say > that 90% of "us" have a form of "dialup" with on routable ip address and a > NAT setup. > First bind is not "standard" in this kind of

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

Re: BIND and iptables config

90% of "us" have a form of "dialup" with on routable ip address and a NAT setup. First bind is not "standard" in this kind of situation and makes things overly complicated. I would recommend dnsmasq instead. It is much more staight forward for a NAT box to setup. It

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

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

ng installation) > with all my DNS servers ( the master server is on my box and can't be reached > before BIND (4, 8 or 9) is activated) . I also had to create a new profile on > my external interface with all the DNS servers. > All this done (two or three weeks), I can launch

BIND and iptables config

stem/bind9-resolvconf.service as Docu never was on my system). So I had to cheat with NetworkManager: I removed the link /etc/resolv.conf, and edited the original one (created during installation) with all my DNS servers ( the master server is on my box and can't be reached before BIND

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

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

Re: BIND DNS problem after upgrading from Wheezy to Squeeze

Andrew Wood <aw...@comms.org.uk> 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

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

BIND DNS problem after upgrading from Wheezy to Squeeze

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 machine set as their only DNS

BIND DNS problem after upgrading from Wheezy to Squeeze

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 machine set as their only DNS

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

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

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

  1   2   3   4   5   6   7   8   9   10   >