bind 9.7.1-P2 startup: unable to set effective gid to 0

2010-09-17 Thread aldus jung
We recently upgraded from bind version 9.7.0 to 9.7.1-P2 and we noticed that
upon start of named, we are seeing the following warning message:

 [ID 123 daemon.warning] unable to set effective gid to 0: Not owner
 [ID 123 daemon.info] generating session key for dynamic DNS
 [ID 123 daemon.warning] unable to set effective gid to 0: Not owner

On our DNS server, root user is configured as uid=0(root) gid=1(other), but
we didn't encounter these warnings in version 9.7.0.
It would be easy to work around the warnings by adding root to root's group,
but I wanted to understand why we are getting these warning when we didn't
see this on 9.7.0.

Which file or directory is named trying to set gid to 0?

thanks for your help,
AJ
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind 9.7.1-P2 startup: unable to set effective gid to 0

2010-09-17 Thread aldus jung
Just a follow up, I've added some debug statements to bin/named/unix/os.c to
see the files that named is trying to set the effective gid for, and I see:
[ID 873 daemon.warning] Trying to open: '/var/run/named.pid'.
[ID 873 daemon.warning] unable to set effective gid to 0: Not owner
[ID 873 daemon.info] generating session key for dynamic DNS
[ID 873 daemon.warning] Trying to open: '/var/run/named/session.key'.

We are running bind in a chrooted environment, running named as user 'named'
on a Solaris 10 server:
/bind/sbin/named -t /chroot/domain -u named

Only when we make root's primary id to be 0, we can get rid of the warning.
We tried adding root to the group 'root', and we still get the warning.

We've set /chroot/domain/var/run ownership to: drwxrwxr-x   4 root other

And named.pid gets created correctly:
-rw-r--r--   1 namednamed

It could be something simple that I am missing.. we'll well see.  Any
thoughts?   Thanks for your help,

AJ

On Fri, Sep 17, 2010 at 2:42 PM, aldus jung aldus...@gmail.com wrote:

 We recently upgraded from bind version 9.7.0 to 9.7.1-P2 and we noticed
 that upon start of named, we are seeing the following warning message:

  [ID 123 daemon.warning] unable to set effective gid to 0: Not owner
  [ID 123 daemon.info] generating session key for dynamic DNS
  [ID 123 daemon.warning] unable to set effective gid to 0: Not owner

 On our DNS server, root user is configured as uid=0(root) gid=1(other), but
 we didn't encounter these warnings in version 9.7.0.
 It would be easy to work around the warnings by adding root to root's
 group, but I wanted to understand why we are getting these warning when we
 didn't see this on 9.7.0.

 Which file or directory is named trying to set gid to 0?

 thanks for your help,
 AJ


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

negative caching and TTL

2010-06-30 Thread aldus jung
Hi, I am hoping to learn more about how BIND v 9.7.0 implements negative
caching of
delegated subdomains.  I've tested and found that BIND observes a different
TTL for
name errors than I would expect it to abide by, but that could be my lack
of understanding of what TTL a DNS server is supposed to abide by in this
situation.

(I've changed the actual domain names as they are only used in our internal
network and
you can't get to it from the internet anyway.)

We have abc.com that BIND 9.7.0 is authoritative for.
And in named.hosts of (host: bind1.abc.com), we have:

xyz 30  IN   NS dns1.abc.com.
xyz 30  IN   NS dns2.abc.com.


On bind1.abc.com, if you query for a host that doesn't exist, this is dig's
output:
 dig nohost.xyz.abc.com @bind1.abc.com
;  DiG 9.3.5-P1  nohost.xyz.abc.com @bind1.abc.com
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 1298
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;nohost.xyz.abc.com.IN  A

;; AUTHORITY SECTION:
xyz.abc.com. 10800   IN  SOA localhost. admin.abc.com. 1 60 3600
604800 3600

From my tests, Bind is observing the '10800' TTL for nohost.xyz.abc.com, not
'3600' that's
in the SOA minimum field.

The question is why is the TTL of the SOA record used for caching negative
answers, not
the TTL in the SOA minimum field?

Reading http://www.dns.net/dnsrd/rfc/rfc2308.html, it says:

Name servers authoritative for a zone MUST include the SOA record of the
zone in the
authority section of the response when reporting an NXDOMAIN or indicating
that no data
of the requested type exists. This is required so that the response may be
cached.
The TTL of this record is set from the minimum of the MINIMUM field of the
SOA record
and the TTL of the SOA itself, and indicates how long a resolver may cache
the negative answer.

And that doesn't seem clear to me, as TTL of the negative response is cached
from BOTH the
minimum field and the TTL of the SOA record?

But in Bind, it seems like it's taking the TTL of the SOA.  If anyone has an
explanation to this,
please chime in.  thanks.

AJ
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users