journal rollforward failed: journal out of sync with zone
Hi, I have observer a SERVFAIL error in one of my zone.On checking the logs I realized there is this error /journal rollforward failed: journal out of sync with zone/ I tried to learn more about it and I found out the solution is to delete the journal file and restart bind.I tried that and it works.Now I wonder what is the reason for such error and what the permanent solution to mitigate it. Regards, Bryton. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: journal rollforward failed: journal out of sync with zone
On 12/04/12 11:50, Bryton wrote: Hi, I have observer a SERVFAIL error in one of my zone.On checking the logs I realized there is this error /journal rollforward failed: journal out of sync with zone/ I tried to learn more about it and I found out the solution is to delete the journal file and restart bind.I tried that and it works.Now I wonder what is the reason for such error and what the permanent solution to mitigate it. Did you or someone else edit the zone file by hand, without freeze/thaw the zone first? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: journal rollforward failed: journal out of sync with zone
Not at all.Everything is automated via cron.Zone is generated from one server cron pushes to another then cron reload bind... On 04/12/2012 02:03 PM, Phil Mayers wrote: On 12/04/12 11:50, Bryton wrote: Hi, I have observer a SERVFAIL error in one of my zone.On checking the logs I realized there is this error /journal rollforward failed: journal out of sync with zone/ I tried to learn more about it and I found out the solution is to delete the journal file and restart bind.I tried that and it works.Now I wonder what is the reason for such error and what the permanent solution to mitigate it. Did you or someone else edit the zone file by hand, without freeze/thaw the zone first? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: journal rollforward failed: journal out of sync with zone
On 12/04/2012 14:19, Bryton wrote: Not at all.Everything is automated via cron.Zone is generated from one server cron pushes to another then cron reload bind... Hi Bryton, If you're pushing the zone to the second server (with scp/rsync) and reloading periodically, there should be no journal. Both your servers should be setup as masters in this case. Journals are normally created only when a zone is a slave, or receives dynamic updates. Can you show us the configuration of this zone on both servers? Anand Buddhdev RIPE NCC ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
re-bind named to all interfaces
Hello list,
I'm running bind9 on my local router which is connected to the internet via a
ppp link over my ADSL modem. This link has a static IP assigned, but is not
permanently up. Once a day the connection is dropped for a few seconds and
re-established, which leads to the following problem:
- starting bind9 (configured with listen-on { any; };) works fine, it binds to
the following interfaces: 127.0.0.1:domain (lo), 192.168.0.1:domain (br0),
85.183.67.131:domain (ppp0)
- once ppp0 goes down, bind9 will drop the binding on 85.183.67.131:domain
(ppp0)
- once ppp0 goes up again, bind9 won't detect the new network topology, thus
remains bound to lo and br0 only; any nameserver on the internet won't be able
to contact my bind9 anymore.
Is there any way to tell bind9 to re-evaluate the network situation and bind to
all new interfaces (if allowed, see listen-on)?
I have tried firing up rndc reload and rndc reconfig via the pppd if-up/if-down
scripts, but neither try was successful.
Seems like the only viable solution for now is to restart bind9 completely over
the init script on ifup/ifdown, but this sounds hacky and is disrupting service
in a way I don't like.
Does anyone here have a similar setup and solved this (admittedly minor)
problem?
If not, I'd opt for re-discovering the network topology on reload/reconfig (as a
restart is flushing caches, loading all zones and discovering network topology
too.)
Best regards,
Mihai
smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: re-bind named to all interfaces
You can set interface-interval to a low number to make BIND scan for new
interfaces frequently:
interface-interval
interface-interval minutes;
interface-interval defines the time in MINUTES when scan all interfaces on the
server and will begin to listen on new interfaces (assuming they are not
prevented by a listen-on option) and stop listening on interfaces which no
longer exist. The default is 60 (1 hour), if specified as 0 NO interface scan
will be performed. The maximum value is 40320 (28 days). This option may only
be specified in a 'global' options statement.
(source: http://www.zytrax.com/books/dns/ch7/periodic.html)
-Original Message-
From: bind-users-bounces+tsnyder=rim@lists.isc.org
[mailto:bind-users-bounces+tsnyder=rim@lists.isc.org] On Behalf Of Mihai
Moldovan
Sent: Thursday, April 12, 2012 10:33 AM
To: bind-users@lists.isc.org
Subject: re-bind named to all interfaces
Hello list,
I'm running bind9 on my local router which is connected to the internet via a
ppp link over my ADSL modem. This link has a static IP assigned, but is not
permanently up. Once a day the connection is dropped for a few seconds and
re-established, which leads to the following problem:
- starting bind9 (configured with listen-on { any; };) works fine, it binds to
the following interfaces: 127.0.0.1:domain (lo), 192.168.0.1:domain (br0),
85.183.67.131:domain (ppp0)
- once ppp0 goes down, bind9 will drop the binding on 85.183.67.131:domain
(ppp0)
- once ppp0 goes up again, bind9 won't detect the new network topology, thus
remains bound to lo and br0 only; any nameserver on the internet won't be able
to contact my bind9 anymore.
Is there any way to tell bind9 to re-evaluate the network situation and bind to
all new interfaces (if allowed, see listen-on)?
I have tried firing up rndc reload and rndc reconfig via the pppd if-up/if-down
scripts, but neither try was successful.
Seems like the only viable solution for now is to restart bind9 completely over
the init script on ifup/ifdown, but this sounds hacky and is disrupting service
in a way I don't like.
Does anyone here have a similar setup and solved this (admittedly minor)
problem?
If not, I'd opt for re-discovering the network topology on reload/reconfig (as
a restart is flushing caches, loading all zones and discovering network
topology too.)
Best regards,
Mihai
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: re-bind named to all interfaces
On 12/04/12 15:32, Mihai Moldovan wrote: Is there any way to tell bind9 to re-evaluate the network situation and bind to all new interfaces (if allowed, see listen-on)? I have tried firing up rndc reload and rndc reconfig via the pppd if-up/if-down scripts, but neither try was successful. rndc reconfig has worked when I've tried it in the past; are you sure you're running it in the right place? You want to run it in the ip-up / ip-down scripts, because IP might not be up when LCP is. There was some discussion on the list about setting the timer for re-discovery to zero; see the archives. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: re-bind named to all interfaces
* On 12.04.2012 04:49 PM, Phil Mayers wrote:
rndc reconfig has worked when I've tried it in the past; are you sure you're
running it in the right place? You want to run it in the ip-up / ip-down
scripts, because IP might not be up when LCP is.
Absolutely positive. I'm running rndc reconfig in ip-up.d/90-named and
ip-down.d/90-named which are sourced by the ip-up/ip-down scripts. Did not work
for me. I should have added that I also tried firing up rndc reconfig manually
when ppp0 was certainly up, to no avail.
[0 running job(s)] {history#10003} 16:52:37 12-04-12
root@valery~# lsof -n -i :domain
COMMANDPID USER FD TYPE DEVICE SIZE/OFF NODE NAME
named 982091 named 20u IPv6 3247439153 0t0 TCP *:domain (LISTEN)
named 982091 named 21u IPv4 3247439158 0t0 TCP 127.0.0.1:domain
(LISTEN)
named 982091 named 22u IPv4 3247439160 0t0 TCP 192.168.0.1:domain
(LISTEN)
named 982091 named 512u IPv6 3247439152 0t0 UDP *:domain
named 982091 named 513u IPv4 3247439157 0t0 UDP 127.0.0.1:domain
named 982091 named 514u IPv4 3247439159 0t0 UDP 192.168.0.1:domain
[0 running job(s)] {history#10004} 16:52:40 12-04-12
root@valery~# ip addr sh dev ppp0
202: ppp0: POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP mtu 1492 qdisc htb state
UNKNOWN qlen 3
link/ppp
inet 85.183.67.131 peer 213.191.89.42/32 scope global ppp0
[0 running job(s)] {history#10005} 16:53:08 12-04-12
root@valery~# which rndc
rndc: aliased to rndc -k /chroot/dns/etc/bind/rndc.key
[0 running job(s)] {history#10006} 16:53:12 12-04-12
root@valery~# rndc reconfig
[0 running job(s)] {history#10007} 16:53:15 12-04-12
root@valery~# lsof -n -i :domain
COMMANDPID USER FD TYPE DEVICE SIZE/OFF NODE NAME
named 982091 named 20u IPv6 3247439153 0t0 TCP *:domain (LISTEN)
named 982091 named 21u IPv4 3247439158 0t0 TCP 127.0.0.1:domain
(LISTEN)
named 982091 named 22u IPv4 3247439160 0t0 TCP 192.168.0.1:domain
(LISTEN)
named 982091 named 512u IPv6 3247439152 0t0 UDP *:domain
named 982091 named 513u IPv4 3247439157 0t0 UDP 127.0.0.1:domain
named 982091 named 514u IPv4 3247439159 0t0 UDP 192.168.0.1:domain
There was some discussion on the list about setting the timer for re-discovery
to zero; see the archives.
I guess that's the interface-interval directive Todd suggested... I'll reply to
that on his sub-thread.**
smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: re-bind named to all interfaces
* On 12.04.2012 04:44 PM, Todd Snyder wrote: You can set interface-interval to a low number to make BIND scan for new interfaces frequently: Interesting option! Weird thing is, the documentation as per /usr/share/doc/bind-9.9.0/html/Bv9ARM.ch06.html says: The server will scan the network interface list every interface-interval minutes. The default is 60 minutes. The maximum value is 28 days (40320 minutes). If set to 0, interface scanning will only occur when the configuration file is loaded. After the scan, the server will begin listening for queries on any newly discovered interfaces (provided they are allowed by the listen-on configuration), and will stop listening on interfaces that have gone away. So the default value is 60 minutes. In theory, I should see named binding to ppp0 after about 60 minutes after the ppp0 interface gets up again. This never happened to me. I set the interval to zero and forced a reconfig/reload via rndc. I feel so stupid for not grepping the log file for ppp0 before, anyway, here's the culprit: 12-Apr-2012 17:03:38.661 general: info: received control channel command 'reconfig' 12-Apr-2012 17:03:38.661 general: info: loading configuration from '/etc/bind/named.conf' 12-Apr-2012 17:03:38.662 general: info: reading built-in trusted keys from file '/etc/bind/bind.keys' 12-Apr-2012 17:03:38.662 general: info: using default UDP/IPv4 port range: [1024, 65535] 12-Apr-2012 17:03:38.662 general: info: using default UDP/IPv6 port range: [1024, 65535] 12-Apr-2012 17:03:38.664 network: info: listening on IPv4 interface ppp0, 85.183.67.131#53 12-Apr-2012 17:03:38.664 network: error: could not listen on UDP socket: permission denied 12-Apr-2012 17:03:38.664 network: error: creating IPv4 interface ppp0 failed; interface ignored 12-Apr-2012 17:03:38.679 general: info: sizing zone task pool based on 6 zones 12-Apr-2012 17:03:38.680 database: debug 1: decrement_reference: delete from rbt: 0x7f667e609e28 . 12-Apr-2012 17:03:38.680 general: debug 1: managed-keys-zone: synchronizing trusted keys 12-Apr-2012 17:03:38.681 general: debug 1: now using logging configuration from config file 12-Apr-2012 17:03:38.682 network: info: additionally listening on IPv4 interface ppp0, 85.183.67.131#53 12-Apr-2012 17:03:38.682 network: error: could not listen on UDP socket: permission denied 12-Apr-2012 17:03:38.682 network: error: creating IPv4 interface ppp0 failed; interface ignored 12-Apr-2012 17:03:38.682 general: debug 1: load_configuration: success 12-Apr-2012 17:03:38.682 general: info: reloading configuration succeeded Hmm, permission denied while binding to ppp0? Maybe that's because my named is running as the non-privileged system user named and binding to the privileged port 53? Makes sense... but... hm. I guess in this case there's no other way but running named as root? I've tried using setcap to give /usr/sbin/named privileged port binding capabilities: root@valery~# getcap /usr/sbin/named /usr/sbin/named = cap_net_bind_service+ep Restarted bind9, killed -1 pppd and watched the permission denied error flying by again. smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: journal rollforward failed: journal out of sync with zone
On Apr 12, 2012, at 5:19 AM, Bryton wrote: Not at all.Everything is automated via cron.Zone is generated from one server cron pushes to another then cron reload bind... Figure out why you're getting a journal file. If you need to have a journal file (i.e. you need whatever mechanism caused it to be created), then you have to get rid of your cron job, or modify how it works. Arbitrarily replacing a zone file when there's a journal file can cause exactly the problem you're seeing. Chris Buxton BlueCat Networks On 04/12/2012 02:03 PM, Phil Mayers wrote: On 12/04/12 11:50, Bryton wrote: Hi, I have observer a SERVFAIL error in one of my zone.On checking the logs I realized there is this error /journal rollforward failed: journal out of sync with zone/ I tried to learn more about it and I found out the solution is to delete the journal file and restart bind.I tried that and it works.Now I wonder what is the reason for such error and what the permanent solution to mitigate it. Did you or someone else edit the zone file by hand, without freeze/thaw the zone first? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: re-bind named to all interfaces
On 12/04/12 16:44, Mihai Moldovan wrote: Hmm, permission denied while binding to ppp0? Maybe that's because my named is running as the non-privileged system user named and binding to the privileged port 53? Makes sense... but... hm. I guess in this case there's no other way but running named as root? I vaguely seem to recall this has come up on the list before. However: at our site: 1. Bind runs as user named 2. rndc reconfig works with a new IP, e.g. # rndc reconfig # lsof -n -i :53 | fgrep 192.168. # ip addr add 192.168.230.230/32 dev lo # rndc reconfig # lsof -n -i :53 | fgrep 192.168. named 17052 named 32u IPv4 1395639422 TCP 192.168.230.230:domain (LISTEN) named 17052 named 531u IPv4 1395639421 UDP 192.168.230.230:domain This is on RHEL5, with SELinux enabled. So, it's definitely possible to do this as non-root. As above, I'm sure this has been discussed, but I can't remember what we decided the mechanism that allowed this was. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: re-bind named to all interfaces
It probably has to do with BIND dropping privileges. If you run BIND with -u so it changes to an unprivileged user, then BIND may not be able to bind() to new interfaces created on your system. I use FreeBSD, and my solution was to do this every time I add a new interface: RESET=`sysctl -e net.inet.ip.portrange.reservedhigh` sysctl net.inet.ip.portrange.reservedhigh=52 rndc reconfig wait for named to start responding sysctl $RESET Linux has some hacks that let you bypass those steps. FreeBSD also has a kernel feature called MAC-PORTACL that behaves like the Linux hack, but since enabling that would require a kernel recompile on more than a thousand servers, we decided not to do that. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac-portacl.html What OS are you using, and what's the command-line you use to launch BIND? On Apr 12, 2012, at 9:52 AM, Phil Mayers wrote: On 12/04/12 16:44, Mihai Moldovan wrote: Hmm, permission denied while binding to ppp0? Maybe that's because my named is running as the non-privileged system user named and binding to the privileged port 53? Makes sense... but... hm. I guess in this case there's no other way but running named as root? I vaguely seem to recall this has come up on the list before. However: at our site: 1. Bind runs as user named 2. rndc reconfig works with a new IP, e.g. # rndc reconfig # lsof -n -i :53 | fgrep 192.168. # ip addr add 192.168.230.230/32 dev lo # rndc reconfig # lsof -n -i :53 | fgrep 192.168. named 17052 named 32u IPv4 1395639422 TCP 192.168.230.230:domain (LISTEN) named 17052 named 531u IPv4 1395639421 UDP 192.168.230.230:domain This is on RHEL5, with SELinux enabled. So, it's definitely possible to do this as non-root. As above, I'm sure this has been discussed, but I can't remember what we decided the mechanism that allowed this was. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: journal rollforward failed: journal out of sync with zone
You don't necessarily have to get rid of the cron job to keep journal files. ixfr-from-differences is intentionally designed to allow you to arbitrarily replace the zone file and yet continue to keep your .jnl files. However, I too have run into rollforward errors with my use of ixfr-from-differences and overwriting the zone file. It has to do with how updates are processed and changes written to the journal. I have a bug open with ISC and they're working on it. It's a very serious issue for us because it takes zones completely offline, which is not acceptable in a production setting. TL;DR: Be careful with ixfr-from-differences and make sure you're not getting rollforward errors. On Apr 12, 2012, at 9:46 AM, Chris Buxton wrote: On Apr 12, 2012, at 5:19 AM, Bryton wrote: Not at all.Everything is automated via cron.Zone is generated from one server cron pushes to another then cron reload bind... Figure out why you're getting a journal file. If you need to have a journal file (i.e. you need whatever mechanism caused it to be created), then you have to get rid of your cron job, or modify how it works. Arbitrarily replacing a zone file when there's a journal file can cause exactly the problem you're seeing. Chris Buxton BlueCat Networks On 04/12/2012 02:03 PM, Phil Mayers wrote: On 12/04/12 11:50, Bryton wrote: Hi, I have observer a SERVFAIL error in one of my zone.On checking the logs I realized there is this error /journal rollforward failed: journal out of sync with zone/ I tried to learn more about it and I found out the solution is to delete the journal file and restart bind.I tried that and it works.Now I wonder what is the reason for such error and what the permanent solution to mitigate it. Did you or someone else edit the zone file by hand, without freeze/thaw the zone first? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: re-bind named to all interfaces
* On 12.04.2012 09:11 PM, Mark Pettit wrote: If you run BIND with -u so it changes to an unprivileged user, then BIND may not be able to bind() to new interfaces created on your system. [...] What OS are you using, and what's the command-line you use to launch BIND? I'm using Linux 3.0.2 w/ bind 9.9.0, so all this should work fine, quoting the man page: -u user Setuid to user after completing privileged operations, such as creating sockets that listen on privileged ports. Note: On Linux, named uses the kernel's capability mechanism to drop all root privileges except the ability to bind(2) to a privileged port and set process resource limits. Unfortunately, this means that the -u option only works when named is run on kernel 2.2.18 or later, or kernel 2.3.99-pre3 or later, since previous kernels did not allow privileges to be retained after setuid(2). Seems fine... but: I found out my bind was built with --disable-linux-caps and --disable-threads... enabling the first option sounds promising (second one is just for my own pleasure.) Rebuilding... I'll report back once I know whether this fixes my problem. :) smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: re-bind named to all interfaces
* On 12.04.2012 10:01 PM, Mihai Moldovan wrote: Seems fine... but: I found out my bind was built with --disable-linux-caps and --disable-threads... enabling the first option sounds promising (second one is just for my own pleasure.) Rebuilding... I'll report back once I know whether this fixes my problem. :) Indeed... enabling linux-caps works great, rndc reconfig now lets named bind to new addresses/interfaces! Thanks for the pointers and ideas. Also, sorry for the noise, as this was a stupid layer 8 problem which I could/should have easily detected earlier. smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Question
Any Reason people could see why this config would not allow remote systems that
can ping this server to do lookups on it?
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
options {
#listen-on port 53 { 127.0.0.1; };
listen-on port 53 { 10.0.193.14; };
listen-on-v6 port 53 { ::1; };
directory /var/named;
dump-file /var/named/data/cache_dump.db;
statistics-file /var/named/data/named_stats.txt;
memstatistics-file /var/named/data/named_mem_stats.txt;
allow-query { localhost; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file /etc/named.iscdlv.key;
};
logging {
channel default_debug {
file data/named.run;
severity dynamic;
};
};
zone . IN {
type hint;
file named.ca;
};
zone 3rc.local IN {
type master;
file 3rc.local;
};
include /etc/named.rfc1912.zones;
/etc/named.conf (END)
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Question
On Apr 12, 2012, at 3:38 PM, Dustin Moon wrote:
Any Reason people could see why this config would not allow remote systems
that can ping this server to do lookups on it?
Why, yes-- see the following line:
allow-query { localhost; };
...?
Regards,
--
-Chuck
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Question
Hi Dustin,
allow-query { localhost; } limits queries to localhost. You need to
add your users' network(s) to that ACL.
On 13/04/2012 00:38, Dustin Moon wrote:
Any Reason people could see why this config would not allow remote
systems that can ping this server to do lookups on it?
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
options {
#listen-on port 53 { 127.0.0.1; };
listen-on port 53 { 10.0.193.14; };
listen-on-v6 port 53 { ::1; };
directory /var/named;
dump-file /var/named/data/cache_dump.db;
statistics-file /var/named/data/named_stats.txt;
memstatistics-file /var/named/data/named_mem_stats.txt;
allow-query { localhost; };
recursion yes;
[snip]
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Update
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
options {
listen-on port 53 { 127.0.0.1; };
listen-on port 53 { 10.0.193.14; };
listen-on-v6 port 53 { ::1; };
directory /var/named;
dump-file /var/named/data/cache_dump.db;
statistics-file /var/named/data/named_stats.txt;
memstatistics-file /var/named/data/named_mem_stats.txt;
#allow-query { any; };
recursion yes;
dnssec-enable no;
dnssec-validation no;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file /etc/named.iscdlv.key;
};
logging {
channel default_debug {
file data/named.run;
severity dynamic;
};
};
zone . IN {
type hint;
file named.ca;
};
zone 3rc.local IN {
type master;
file 3rc.local;
};
include /etc/named.rfc1912.zones;
still gives me:
; DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5 @10.0.193.14
esa-server.3rc.local
; (1 server found)
;; global options: printcmd
;; connection timed out; no servers could be reached
[root@localhost ~]# dig @10.0.193.14 esa-server.3rc.local
; DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5 @10.0.193.14
esa-server.3rc.local
; (1 server found)
;; global options: printcmd
;; connection timed out; no servers could be reached
[root@localhost ~]#
from a host on the same subnet
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Update
On Apr 12, 2012, at 3:52 PM, Dustin Moon wrote:
#allow-query { any; };
Commenting it out entirely is *not* the same thing as changing it to a setting
which allows remote clients to make queries.
Regards,
--
-Chuck
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
