nsd users - Feb 2011 - warning: local hostname 'NOKEY' not found?

I upgraded my NSD master from 3.2.4 to 3.2.7.  When I restarted the 
server and did a 'nsdc notify', I got a long stream of errors like this:

[1298460362] nsd-notify[98129]: warning: local hostname 'NOKEY' not 
found: hostname nor servname provided, or not known

The only difference between each error was the timestamp and pid in 
brackets.  I made no changes to nsd.conf across the upgrade.  My 
nsd.conf has a few dozen zones configured all of which look like this 
(except for the name/zonefile):

zone:
         name: "example.com"
         zonefile: "master/forward/example.com"
         notify: 192.0.2.2 NOKEY
         notify: 192.0.2.3 NOKEY
         notify: 192.0.2.4 NOKEY
         provide-xfr: 192.0.2.2 NOKEY
         provide-xfr: 192.0.2.3 NOKEY
         provide-xfr: 192.0.2.4 NOKEY
         outgoing-interface: 192.0.2.1
         notify-retry: 5

I tried reading the nsd-notify.c, but I can't figure out why nsd would 
try to do a DNS lookup on "NOKEY" as a hostname.

On 2011-02-23 03:39, Darren Pilgrim wrote:
> [1298460362] nsd-notify[98129]: warning: local hostname 'NOKEY' not
> found: hostname nor servname provided, or not known
In the code citations below, the leading number is a line number.

There's a bug in how nsdc parses the output of nsd-checkconf.  As part 
of its processing to generate the series of nsd-notify commands, nsdc 
runs this command:

400 local_ifc=`${nsd_checkconf} -z "${zonename}" -o outgoing-interface
${configfile}`

Producing output like this:

192.0.2.0 NOKEY

Which nsdc then parses using:

405 for ifc in ${local_ifc}; do
406     send_notify ${zonename} ${ifc} ${notify}
407 done

Producing a series of commands like this:

send_notify example.com 192.0.2.1 192.0.2.2 NOKEY 192.0.2.3 NOKEY 
send_notify example.com NOKEY 192.0.2.2 NOKEY 192.0.2.3 NOKEY

The first command is correct, the second is what generates the error.  I 
fixed this by changing nsdc to:

400 local_ifc=`${nsd_checkconf} -z "${zonename}" -o outgoing-interface
${configfile} | cut -d ' ' -f 1`

But that's a quick hack and may not be portable.  Granted I'm a pretty 
fresh set of eyeballs with the NSD source code, but it looks like the 
culprit is outgoing-interface being treated like an ACL and printed 
using ZONE_GET_ACL() instead of an ipspec using a (seemingly 
non-existent) zone analog of SERV_GET_IP().