AW: Strange db-files in working directory

[Walkenhorst, Benjamin]

Hello,

> Yes you're correct.  I should have wrote that Bind didn't
> have write permissions to the zone files, but was able to
> write to the directory.

That *might* have been the problem. 
However, Mark Andrews told me in another reply  that db-XXXXXXX files are zone
files that after transfer are for some reason rejected by BIND (for e.g. 
invalid syntax) while temporary files would be named tmp-XXXXXXXX:

	The db-XXXXXXXX files are copies of zone files named rejected
	when loading.  There would have been log messages associated
	with its creation.   Migrating from BIND 8 to BIND 9 can
	create them due to differing handling of missing TTL fields.
	As can manually editing them.
	[...]
	The temporary files have a different prefix (tmp-XXXXXXXXXX)
	and get renamed to that specified in the zone declaration once
	the write to disk is complete.

Since the master server is still running BIND4, maybe BIND9 refused to
accept something BIND4 transferred...
Unfortunately, I removed the files already and can't e.g. run named-checkzone
on them.
On the other hand, like I said, both files hadn't been touched in more than 
a month, and I was not able to reproduce the problem. 

If it was a case of permission weirdness, I wouldn't be surprised too much,
either: z/OS has a security subsystem called RACF where user accounts are set up.
In the Unix-subsystem, not only ordinary unix-style file-permissions determine what a
user can and cannot do, but also the RACF profile for that user. E.g. it is possible
to act with a uid of 0 (i.e. with root-privileges) in the unix-subsystem without being
able to, say, read/modify certain files or bind to a port <1024.
BIND is of course running in a chroot as a non-root user, and after that user account was
first set up, there were in fact some permission problems like BIND being unable to write
to its own log files.

Anyway, the permission problems have been solved by now and BIND is running fine now on the 
development-/testbed-machine. The db-XXXXXXXX have not reappeared, so I regard this a case of
occasional weirdness. 

Once again, thanks to everyone, 
Benjamin