| Subject: | further session-key complaints |
Comments from Timothe Litt, copied from RT #39440:
Sorry, but I can't agree with that inclination :-( Even though I don't
use the feature.
Several reasons:
1) You can still do a lazy create. Just create the key when you
encounter "update-policy local"
OR the "local-ddns" token, unless "session-keyfile none" was encountered.
2) "session-keyfile" is documented as taking a path, not a keyword. So
how does one
know to specify "none" to disable the feature... I just rechecked the
9.10 ARM and
don't see any hint of this.
ftp://ftp.isc.org/isc/bind/cur/9.10/doc/arm/Bv9ARM.pdf
And I don't think a reserved filename is a good idea. "none" should
create a file
called "none", just as
zone example.net { type slave; file "none" };
would :-)
Perhaps "local-session-key yes_or_no"? As what you report is
undocumented, it
should be OK to change to something more consistent with the way things
work in the rest of the configuration language.
3) It doesn't make sense to create a file that's not used, much less to
attempt to create the
containing directory. The latter is pretty much guaranteed to fail if
running under a
non-privileged user, as /usr/var/run is owned by root.
4) Further, life would be easier for clients if the file didn't exist
unless the feature is
enabled. Then a client can check for the presence of the key. E.g.
nsupdate wouldn't
need -l; if session.key exists, it can try it. If not, it can complain
intelligently. And a script
can invoke nsupdate with -l IFF session.key exists.
5) I still find it confusing for there to be errors creating a file that
the user did not specify.
I guess another option is to change the default for "session-keyfile" to
"none"
(or whatever mechanism actually does disable the feature), but that
contradicts the
"it works out of the box" intent of the feature... Still, one enable
statement doesn't
seem to be an unreasonable burden.
6) If I look in /usr/var/run/named (here, a symlink to /var/run/named),
session.key
looks like this:
-rw------- 1 named named 102 May 5 17:54 session.key
Shouldn't it be g:r (-rw-r-----)? If named runs -u named:dnsadmin,
shouldn't a
user in group dnsadmin be able to manage DNS? One can get there if the
directory
is g+s, but that's not common, and this is an 'out of the box should
work' feature.
The log entries:
Without /usr/var/run/named symlink:
May 5 12:43:31 castaway named[24680]: listening on IPv4 interface
eth0:2, 192.168.148.106#53
May 5 12:43:31 castaway named[24680]: couldn't mkdir
'/usr/var/run/named': Permission denied
May 5 12:43:31 castaway named[24680]: generating session key for
dynamic DNS
May 5 12:43:31 castaway named[24680]: couldn't mkdir
'/usr/var/run/named': Permission denied
May 5 12:43:31 castaway named[24680]: could not create
/usr/var/run/named/session.key
May 5 12:43:31 castaway named[24680]: failed to generate session key
for dynamic DNS: permission denied
With symlink:
05-May-2015 18:23:36.917 listening on IPv4 interface eth0:2,
192.168.148.106#53
05-May-2015 18:23:36.923 generating session key for dynamic DNS
05-May-2015 18:23:36.925 sizing zone task pool based on 138 zones