New implementation of Nameserver11 - #1110

[tgreenx]

Purpose

This PR proposes a new implementation for Nameserver11, following the update of the specification in zonemaster/zonemaster#1111.

Context

Addresses zonemaster/zonemaster#1110 (previously zonemaster/zonemaster#993)

Testing

zonemaster-cli --test=nameserver/nameserver11 bemacom.se --level=INFO --show-testcase --raw
   0.00 INFO      UNSPECIFIED    GLOBAL_VERSION   version=v4.5.1
   3.83 WARNING   NAMESERVER11   N11_UNEXPECTED_RCODE   ns_ip_list=194.17.14.66;92.33.14.98; rcode=FORMERR

[matsduf]

The process we have followed so far is to have the specification completed before implementation starts. In that we lower that risk of have work to be redone. I suggest that the implementation is paused until the specification is done.

[vlevigneron]

I agree with @matsduf. We should follow the same process we had before. Specifications first, then implementation.
BTW @tgreenx, some links in your PR are wrong, for instance you refer to #993 instead of zonemaster/zonemaster#993 in many places

[tgreenx]

Commit 39bb1c7 addresses PR zonemaster/zonemaster#1093.

[matsduf]

It turns out that the update done by zonemaster/zonemaster#993 misses some error scenarious. See zonemaster/zonemaster#1110. There is a new update of the test case specification in zonemaster/zonemaster#1111 to be reviewed.

[matsduf]

@tgreenx, can zonemaster/zonemaster#1111 be merged and incorporated in this update?

[tgreenx]

@tgreenx, can zonemaster/zonemaster#1111 be merged and incorporated in this update?

Yes

[tgreenx]

Implementation is updated to latest specification (zonemaster/zonemaster#1111). However we should wait that #1147 is merged first before merging this PR, then rebase on latest develop and do the changes to EDNS queries as mentioned in the code of this PR (see commit 5cc0f15)

[matsduf]

This looks fine, and I see no obvious error. There are, however, not enough unit tests or test zones to verify this implementation. I think we can merge, and then let the upcoming tests zones that are defined in zonemaster/zonemaster#1113 verify it. In that PR there is a test-data specification for the test case.

[mattias-p]

LGTM. I found one small thing that could be improved but from my understanding it's not big enough to block merging.

[mattias-p]

This check is more general than what is prescribed in the specification. It doesn't seem like a huge deal, but I wanted to point it out.

[matsduf]

I looked at that, and since the query has no flags and no other options in EDNS, besides the undefined option, which the server is expected to ignore and not include in the response, I think this should work.