NSD 4.2.3 released

NSD
1

Hi,

NSD 4.2.3 is available:
https://nlnetlabs.nl/downloads/nsd/nsd-4.2.3.tar.gz
sha256 817d963b39d2af982f6a523f905cfd5b14a3707220a8da8f3013f34cdfe5c498
pgp https://nlnetlabs.nl/downloads/nsd/nsd-4.2.3.tar.gz.asc

This release has log fixes, features of confine-to-zone and startup
management, an implementation changes in the configuration parser and
socket handling code simplifications. The implementation changes make
the parser context aware, which is useful for the syntax of (future)
config options. The socket handling code was rewritten to split it
apart in separately handleable routines.

The confine-to-zone: yesno option from Greg Bock, if enabled stops NSD
from responding with data outside of the zone the query was aimed at.
Answers contain data that comes from one zone only.

The startup management patch for s6 and other service supervisors from
Cameron Nemo can be used to signal readiness notification to them, it is
in contrib. With that there is the new option that an empty pidfile
statement (pidfile: "") in nsd.conf can be used to run NSD without
having NSD create an nsd.pid file at startup.

There is fix for the sort order of included configuration files with the
include: statement. Due to a programming oversight it was sorted, but
in reverse. Files are now included in the sorted order. Mostly, if
files contain configuration snippets of different zones, or config about
different features, the include order should not matter for them.

4.2.3

2

Hello,

maybe this feature break "minimal-responses: yes"

dig @nsd-4.2.2 www.example. A
-> give only an answer section

dig @nsd-4.2.3 www.example. A
  -> give an answer AND additional section

Andreas

3

answer, authority AND aditional section

4

I just tried every combination of both options as well as defaults at commit 8fd09a59ea50db1daab352b5bce67b66bf533eb6 (where my change was introduced) and was unable to reproduce this. I can reproduce this at tag NSD_4_2_3_REL regardless of either setting. If I find time I'll try to bisect the changes between mine and NSD_4_2_3_REL to find the culprit but at a glance this appears to have been introduced after my changes.

    > The confine-to-zone: yesno option from Greg Bock, if enabled stops NSD
    > from responding with data outside of the zone the query was aimed at.
    > Answers contain data that comes from one zone only.
    
    Hello,
    
    maybe this feature break "minimal-responses: yes"
    
    dig @nsd-4.2.2 www.example. A
     -> give only an answer section
    
    dig @nsd-4.2.3 www.example. A
      -> give an answer AND additional section
    
    Andreas

5

The confine-to-zone: yesno option from Greg Bock, if enabled stops NSD

        > from responding with data outside of the zone the query was aimed at.
        > Answers contain data that comes from one zone only.
        
        Hello,
        
        maybe this feature break "minimal-responses: yes"
        
        dig @nsd-4.2.2 www.example. A
         -> give only an answer section
        
        dig @nsd-4.2.3 www.example. A
          -> give an answer AND additional section
        
        Andreas

Sorry for the top post earlier.

I just tried every combination of both options as well as defaults at commit
8fd09a59ea50db1daab352b5bce67b66bf533eb6 (where my change was introduced) and
was unable to reproduce this. I can reproduce this at tag NSD_4_2_3_REL
regardless of either setting. If I find time I'll try to bisect the changes
between mine and NSD_4_2_3_REL to find the culprit but at a glance this
appears to have been introduced after my changes.

Bisecting shows this commit to be the culprit:

commit 565630575ff0f13144c680d4f216e3d4c673124b
Author: Jeroen Koekkoek <jeroen@nlnetlabs.nl>

    Make configuration parser context aware

6

        > The confine-to-zone: yesno option from Greg Bock, if enabled stops NSD
        > from responding with data outside of the zone the query was aimed at.
        > Answers contain data that comes from one zone only.
        
        Hello,
        
        maybe this feature break "minimal-responses: yes"
        
        dig @nsd-4.2.2 www.example. A
         -> give only an answer section
        
        dig @nsd-4.2.3 www.example. A
          -> give an answer AND additional section
        
        Andreas

Sorry for the top post earlier.

> I just tried every combination of both options as well as defaults at commit
> 8fd09a59ea50db1daab352b5bce67b66bf533eb6 (where my change was introduced) and
> was unable to reproduce this. I can reproduce this at tag NSD_4_2_3_REL
> regardless of either setting. If I find time I'll try to bisect the changes
> between mine and NSD_4_2_3_REL to find the culprit but at a glance this
> appears to have been introduced after my changes.

Bisecting shows this commit to be the culprit:

commit 565630575ff0f13144c680d4f216e3d4c673124b
Author: Jeroen Koekkoek <jeroen@nlnetlabs.nl>
Date: Wed Jun 12 08:41:23 2019 +0200

    Make configuration parser context aware

It appears minimal_responses and round_robin vars should be set:

diff --git a/configparser.y b/configparser.y
index 118f43a..d49eeba 100644
--- a/configparser.y
+++ b/configparser.y
@@ -374,9 +374,16 @@ server_option:
   > VAR_LOG_TIME_ASCII boolean
     { cfg_parser->opt->log_time_ascii = $2; }
   > VAR_ROUND_ROBIN boolean
- { cfg_parser->opt->round_robin = $2; }
+ {
+ cfg_parser->opt->round_robin = $2;
+ round_robin = cfg_parser->opt->round_robin;
+ }
   > VAR_MINIMAL_RESPONSES boolean
- { cfg_parser->opt->minimal_responses = $2; }
+ {
+ cfg_parser->opt->minimal_responses = $2;
+ minimal_responses = cfg_parser->opt->minimal_responses;
+ }

7

Hi Greg, Andreas,

I'll have a go at this tomorrow (and diff the old vs new parser).
Thanks for noticing.

- Jeroen

P.S.
I'll be sure to add a test case...

8

Hi Greg, Andreas,

I went over the changes again today and found another global variable
that's not set after the changes. I fixed the issues locally and am
working on a test case to detect regressions in the future.

Hoping to finish that tomorrow, a bugfix release will happen pretty
soon after that.

Thanks again for the report, it's much appreciated.

Best regards,
Jeroen