managed-keys-zone file not found

[Jack Tavares]

Hello

While starting up bind I get the following 2 messages

01-Oct-2010 15:13:15.304 set up managed keys zone for view external, file '3c4623849a49a53911c4a3e48d8cead8a1858960bccdea7a1b978d73ec2f06d7.mkeys'

and

01-Oct-2010 15:13:15.309 managed-keys-zone ./IN/external: loading from master file 3c4623849a49a53911c4a3e48d8cead8a1858960bccdea7a1b978d73ec2f06d7.mkeys failed: file not found

 

the number is a hash of the view name ("external")

 

The zones in the view allow dynamic update.

 

I have tried using managed-keys-directory option, but I cannot get rid of this message.

What am I missing?

thanks

 

[Evan Hunt]

On Fri, Oct 01, 2010 at 10:29:34PM +0000, Jack Tavares wrote:
> Hello
> While starting up bind I get the following 2 messages
> 01-Oct-2010 15:13:15.304 set up managed keys zone for view external, file '3c4623849a49a53911c4a3e48d8cead8a1858960bccdea7a1b978d73ec2f06d7.mkeys'
> and
> 01-Oct-2010 15:13:15.309 managed-keys-zone ./IN/external: loading from master file 3c4623849a49a53911c4a3e48d8cead8a1858960bccdea7a1b978d73ec2f06d7.mkeys failed: file not found

The expected behavior is, the first time you start BIND with managed-keys
configured in a view, it will try to load the keys from an existing
managed-keys file. If the file isn't found, it logs this warning,
and then if the directory is writable, it goes ahead and creates the file.

So you should only be seeing this the first time, and not thereafter.
Which is why I'm concerned about this:

> I have tried using managed-keys-directory option, but I cannot get rid of
> this message.

BIND hasn't created the file yet? Is your working directory or
managed-keys-directory writable?

--
Evan Hunt -- ea...@isc.org
Internet Systems Consortium, Inc.

[David Forrest]

Evan, I had this same message and it continued on every start. But it
went ahead and loaded the zone (in memory I surmised) and everything
worked OK. I just tried creating an empty file (via touch) in my working
directory and, viola! No more messages except for the "set up managed
keys zone for view external" and it still works as it should. My working
directory is owned by named and I run as -u named so I don't know why it
does not write the file. I had a similar problem with the internal view
and removed the annoying message in the same manner; touching the file
with the name in the message in the working directory. So I now have two
empty files; No biggie.

I searched in the source code for the message and found it in
./bin/named/server.c but didn't go any further as my invocation hack
worked for me and it just seemed to be a log info message. YMMV.

Dave

--
David Forrest e-mail d...@maplepark.com
Maple Park Development Corporation http://xen.maplepark.com
St. Louis, Missouri (Sent by ALPINE 2.01 FEDORA 11 LINUX)

[Evan Hunt]

> Evan, I had this same message and it continued on every start.

That's a bug, then. Thank you.

[Jack Tavares]

Forgive the top post.

The directory is writable. I run bind chrooted and the directory exists, is owned
by the named user and is writable by the named user.

--
Jack Tavares
"How many more can we sell with this button?"
________________________________________
From: David Forrest [d...@maplepark.com]
Sent: Sunday, October 03, 2010 09:12
To: Evan Hunt
Cc: Jack Tavares; bind-...@lists.isc.org
Subject: Re: managed-keys-zone file not found

[Evan Hunt]

> The directory is writable. I run bind chrooted and the directory exists,
> is owned by the named user and is writable by the named user.

But you don't have managed-keys or dnssec-lookaside auto configured, right?
I was confused, and thought you did. If you had, that would mean this bug
was fairly serious, because it would mean your managed keys weren't stored
permanently.

My statement about the expected behavior (i.e., that you'd see this log
message only on the first start, and not thereafter) turns out to be true
only if there's actually a managed key that needs maintaining. If you
don't have any such keys, named won't create a file to save them in--but,
oops, it still tries to load the file on startup, and so it always logs
the "file not found" message.

This is essentially a cosmetic bug, and will be fixed in a future release.
You can work around it, as others have mentioned, by touching the file so
that named will shut up, or you can ignore it.

Thanks for your help with it.

[Jack Tavares]

Evan:

> My statement about the expected behavior (i.e., that you'd see this log
> message only on the first start, and not thereafter) turns out to be
> true
> only if there's actually a managed key that needs maintaining. If you
> don't have any such keys, named won't create a file to save them in--
> but,
> oops, it still tries to load the file on startup, and so it always logs
> the "file not found" message.
>
> This is essentially a cosmetic bug, and will be fixed in a future
> release.
> You can work around it, as others have mentioned, by touching the file
> so
> that named will shut up, or you can ignore it.
>
> Thanks for your help with it.
>

that makes sense. It did go away when I set up lookaside properly,
and I thought I knew how to make it go away.

Then I reconfigured (as a test) without lookaside (or any dnssec features
enabled for that matter) and the problem returned.

I agree it is cosmetic and we can live with it.
Thank you