named and its hourly reports

[Ian Smith]

On Tue, 15 Jul 2008 12:22:06 +1000 jonathan michaels <jlm at caamora.com.au> wrote:

 > named now reports hourly
 > 
 > Jul 15 06:55:10 hid named[617]: could not listen on UDP socket: permission denied
 > Jul 15 06:55:10 hid named[617]: creating IPv4 interface tun0 failed; interface ignored
 > Jul 15 07:55:10 hid named[617]: could not listen on UDP socket: permission denied
 > Jul 15 07:55:10 hid named[617]: creating IPv4 interface tun0 failed; interface ignored
 > Jul 15 08:55:10 hid named[617]: could not listen on UDP socket: permission denied
 > Jul 15 08:55:10 hid named[617]: creating IPv4 interface tun0 failed; interface ignored
 > Jul 15 09:55:10 hid named[617]: could not listen on UDP socket: permission denied
 > Jul 15 09:55:10 hid named[617]: creating IPv4 interface tun0 failed; interface ignored
 > 
 > i've tried teh hand book, even muddled my way through google, teh only
 > reference that has surfaced is a pointer to the fact the this error
 > message is because named is running in a sandbox ??? d'ont know when
 > that happened but freebsd now runs named from a sandbox ..

By default .. you don't have to, but it's a very good idea these days.

 > this machine is a router/gateway and old 486 with a small scsi hdd that
 > is rapidly filling up from this and others, to my mind silly error
 > messages.
 > 
 > is there some way to fix thins, is it a hard error, can i run named not
 > in a sandbox, i'm also seeing other errors that seem (to my mind) to be
 > related to this, but i am not sure so i'm keeping my mouth shut untill
 > i can work it out and find teh real culprit ..

Jonathan, I don't think not running named in a sandbox would help here. 

As Yuri pointed out, named is scanning all interfaces, default hourly. 
I had a related problem on this laptop, with the same error messages -
after a suspend/resume the (pccard) interface wasn't coming up quickly
enough to beat named's (then overdue) interface scan, so named wouldn't
bind to that interface.  I fixed that by running the following script
from /etc/rc.resume:

#!/bin/sh
# 28/12/6 called by rc.resume; wait for pccard resume to reattach xe0 ..
doit() {
    sleep $1
    # logger -p user.notice stopping named
    /etc/rc.d/named stop
    # + 31/12/6 missed restart once .. try:
    sleep 1
    # logger -p user.notice restarting named
    /etc/rc.d/named start
}
delay=5; [ "$1" ] && delay=$1
doit $delay &
exit 0          # finish rc.resume so pccard resume can get on with it ..
 
Note that /etc/rc.d/named restart didn't work for me, nor rndc restart. 

However there are perhaps better ways to tackle this, depending on which
interface/s you *need* to have named listening on.  If you need named to
listen on the adddress of tun0 (pppoe, I suppose?) then you may need to
do something like the above whenever ppp connects, or reconnects, from a
suitable up-script for ppp.  The disadvantage is clearing named's cache.

If on the other hand you only need named listening on other interface/s
than tun0, use the 'listen on { $address; };' option/s to specify the
address/es to listen on.  The default is '*', the addresses associated
with each interface, as 'sockstat -4 | grep named' will show.  Don't
forget to include a 'listen on { 127.0.0.1; }' if you want localhost.

 > some pointers would be most appreciated .. i've been struggling with
 > this for aover a year now and do not know where else to go ??

You could have come here a year ago :)

cheers, Ian