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