NSD 2.3.4 released

2.3.4

BUG FIXES:
        - Unknown type codes for type code numbers > 48 and < 97 work again.
          (this implies --enable-checking can be enabled again)
        - nsd: sighandler() fixes
        - Bug #118: nsd: nsd_notify waits for a response. Will retry the notify
          after a timeout.

It still takes a long time for nsd to startup when there are problems with
secondaries.

        - Bug #124: $(DESTDIR) was added to Makefile.in.

This was very useful, thanks :slight_smile:

        - Bug #128: zonec: parser can handle \\ at the end of a string.
        - zonec: lexer: add \r to the newline delimeter
        - zonec: use strtol with an explicit base 10 as parameter.
          (Scott Rose, Roy Arends)
        - nsd-xfer: print human readable error codes. Change logging to
          be more in line with the rest

However, the no-ipv6 bug, as described here:
  http://open.nlnetlabs.nl/pipermail/nsd-users/2003-July/000044.html
has resurfaced. I've added a workaround in the nsd init script to append
"-4" if no IPv6 is detected on Linux.

There were also a few warnings on x86_64 / gcc 4.0.2 (but not on ix86 with
the same gcc):

zlexer.c: In function 'yylex':
zlexer.lex:268: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result

zonec.c: In function 'zparser_conv_loc':
zonec.c:656: warning: ignoring return value of 'strtol', declared with attribute warn_unused_result

nsd-xfer.c: In function 'print_rr':
nsd-xfer.c:459: warning: ignoring return value of 'fwrite', declared with attribute warn_unused_result

Updated packages should appear in Fedora Extras branches shortly.

Paul

[On 07 May, @21:18, Paul Wouters wrote in "Re: NSD 2.3.4 released ..."]

> - Bug #118: nsd: nsd_notify waits for a response. Will retry the notify
> after a timeout.

It still takes a long time for nsd to startup when there are problems with
secondaries.

Could you elaborate a bit more on that?

However, the no-ipv6 bug, as described here:
  http://open.nlnetlabs.nl/pipermail/nsd-users/2003-July/000044.html
has resurfaced. I've added a workaround in the nsd init script to append
"-4" if no IPv6 is detected on Linux.

hmmpf... I agree what is says in the thread on bugzilla, checking for
ipv6 should be done outside of NSD. Strange though that this pops
up now...

There were also a few warnings on x86_64 / gcc 4.0.2 (but not on ix86 with
the same gcc):

Thanks, I tweaked the code a bit, but most function we're already
casted to void. (Which will not make gcc on x86_64 stop complaining
though)

Updated packages should appear in Fedora Extras branches shortly.

thanks!

> It still takes a long time for nsd to startup when there are problems with
> secondaries.

Could you elaborate a bit more on that?

I am seeing this:

[1147094258] nsd-xfer[4301]: error: answer section is empty
[1147094258] nsd-xfer[4303]: error: answer section is empty
[1147094259] nsd-xfer[4305]: error: answer section is empty
[1147094259] nsd-xfer[4307]: error: answer section is empty
Starting nsd...
[1147094264] nsd-notify[4352]: warning: bad reply from 192.139.46.149, error respons NOT IMPL (4).
[1147094264] nsd-notify[4352]: warning: bad reply from 192.139.46.149, error respons NOT IMPL (4).
[1147094265] nsd-notify[4353]: warning: bad reply from 192.139.46.149, error respons NOT IMPL (4).
[1147094265] nsd-notify[4353]: warning: bad reply from 192.139.46.149, error respons NOT IMPL (4).
[1147094265] nsd-notify[4354]: warning: bad reply from 192.139.46.149, error respons NOT IMPL (4).
[1147094272] nsd-notify[4367]: warning: bad reply from 205.150.200.178, error respons NOT AUTHORIZED (9).

Though I have to correct myself, those first 5 messages happen pretty quickly,
and then nsd is listening already. Perhaps it is better to change the
order in the init scripts to run things. Now I do:

        /usr/sbin/nsdc rebuild >/dev/null
        /usr/sbin/nsdc update >/dev/null
        echo -n $"Starting nsd... "
        nsd $OTHER_NSD_OPTS

The problem is during rebuild and update, nsd is not running. Perhaps rebuild
be run before stopping nsd, and update can be run after starting nsd?

I notice a few seconds of downtime, and we only have about 25 zones. I think
with thousands of zones, the downtime might be considerable.

> However, the no-ipv6 bug, as described here:
> http://open.nlnetlabs.nl/pipermail/nsd-users/2003-July/000044.html
> has resurfaced. I've added a workaround in the nsd init script to append
> "-4" if no IPv6 is detected on Linux.

hmmpf... I agree what is says in the thread on bugzilla, checking for
ipv6 should be done outside of NSD. Strange though that this pops
up now...

Personally, I think nsd should not NOT start if there is no IPv6 and you
give it no special parameters. Eg typing "/usr/sbin/nsd" should work if
there is no IPv6.

Paul

[On 08 May, @15:22, Paul Wouters wrote in "Re: NSD 2.3.4 released ..."]

> Could you elaborate a bit more on that?

I am seeing this:

[1147094258] nsd-xfer[4301]: error: answer section is empty

<snip>

Starting nsd...

<snip>

[1147094265] nsd-notify[4354]: warning: bad reply from 192.139.46.149, error respons NOT IMPL (4).
[1147094272] nsd-notify[4367]: warning: bad reply from 205.150.200.178, error respons NOT AUTHORIZED (9).

Though I have to correct myself, those first 5 messages happen pretty quickly,
and then nsd is listening already. Perhaps it is better to change the
order in the init scripts to run things. Now I do:

        /usr/sbin/nsdc rebuild >/dev/null
        /usr/sbin/nsdc update >/dev/null
        echo -n $"Starting nsd... "
        nsd $OTHER_NSD_OPTS

The problem is during rebuild and update, nsd is not running. Perhaps rebuild
be run before stopping nsd, and update can be run after starting nsd?

[looking at debian's init.d script]
There is a small check there to see if nsd's zones need recompiling,
but otherwise it just starts NSD.

How about: start NSD, then do the rebuilding/updaing, then restart. The
restart should happen pretty quick.

I notice a few seconds of downtime, and we only have about 25 zones. I think
with thousands of zones, the downtime might be considerable.

> > However, the no-ipv6 bug, as described here:
> > http://open.nlnetlabs.nl/pipermail/nsd-users/2003-July/000044.html
> > has resurfaced. I've added a workaround in the nsd init script to append
> > "-4" if no IPv6 is detected on Linux.
>
> hmmpf... I agree what is says in the thread on bugzilla, checking for
> ipv6 should be done outside of NSD. Strange though that this pops
> up now...

Personally, I think nsd should not NOT start if there is no IPv6 and you
give it no special parameters. Eg typing "/usr/sbin/nsd" should work if
there is no IPv6.

Let me find a box here that does't have ipv6 :slight_smile: I will look into
this.

There is a small check there to see if nsd's zones need recompiling,
but otherwise it just starts NSD.

Ahh, I'll look at that.

How about: start NSD, then do the rebuilding/updaing, then restart. The
restart should happen pretty quick.

And look into this.

Let me find a box here that does't have ipv6 :slight_smile: I will look into
this.

Want a xenu? :slight_smile:

Paul

[On 08 May, @10:30, Miek Gieben wrote in "Re: NSD 2.3.4 released ..."]

> However, the no-ipv6 bug, as described here:
> http://open.nlnetlabs.nl/pipermail/nsd-users/2003-July/000044.html
> has resurfaced. I've added a workaround in the nsd init script to append
> "-4" if no IPv6 is detected on Linux.

hmmpf... I agree what is says in the thread on bugzilla, checking for
ipv6 should be done outside of NSD. Strange though that this pops
up now...

After some more discussion it turned out that is a more longstanding
issue (nsd 2.3.3 has it too, and probably earlier version also).

It is also gets nasty when trying to fix this in the NSD code, so after some
thought we decided to use the following: (which fedora and debian do):

o check if a system has ipv6 in the startup script
o if ipv6 -> nsd
  if no ipv6 -> nsd -4

Note, this is something for the packagers, there is no code added
to nsdc to do this.

regards,