Incorrect header placement when using options '--ns' or '--ds'
Currently, in some cases the messages header is displayed too late (i.e. after some calls to Engine are done). Specifically, when using either option --ns or --ds, it can be seen in case of any system error (SYSTEM:UNSPECIFIED), e.g:
$ zonemaster-cli --show-testcase --no-ipv6 --test basic/basic01 zonemaster.net --ns 'ns1.zonemaster.net'
0.72 ERROR UNSPECIFIED The fake delegation of domain zonemaster.net includes an in-zone name server ns1.zonemaster.net without mandatory glue (without IP address).
Seconds Level Testcase Message
======= ======== ============== =======
I suggest that the code displaying the header is moved earlier in the code. A more appropriate place would be just after the successful normalization of the input domain name (e.g. line 565 or line 578).
It doesn't seem that simple. By moving the display of the header before the management of false ds/ns we obtain the desired output for the given example.
$ ./script/zonemaster-cli --show-testcase --no-ipv6 --test basic/basic01 zonemaster.net --ns 'ns1.zonemaster.net'
Seconds Level Testcase Message
======= ======== ============== =======
5.68 ERROR Unspecified The fake delegation of domain zonemaster.net includes an in-zone name server ns1.zonemaster.net without mandatory glue (without IP address).
But the other errors on the ns are displayed incorrectly (in my opinion):
$ ./script/zonemaster-cli --show-testcase example.fr --ns 'ns1.zonemaster..fr.'
Seconds Level Testcase Message
======= ======== ============== =======
Invalid name in --ns argument:
Domain name has repeated dots.
$ ./script/zonemaster-cli --show-testcase example.fr --ns 'ns1.zonemaster.fr/542.0.0.1'
Seconds Level Testcase Message
======= ======== ============== =======
Invalid IP address in --ns argument:
Invalid quad in IP address 542.0.0.1 - 542
$ ./script/zonemaster-cli --show-testcase example.fr --ns '/215.4.6.1'
Seconds Level Testcase Message
======= ======== ============== =======
--ns must be a name or a name/ip pair.
This came from the fact that the function add_fake_delegation of Zonemaster::CLI call add_fake_delegation of Zonemaster::Engine.
And this last one can emit C<FAKE_DELEGATION_NO_IP> or a C<FAKE_DELEGATION_IN_ZONE_NO_IP>.
One solution is to check in Zonemaster::CLI->add_fake_delegation() if the given ns can be resolved before calling Zonemaster::Engine->add_fake_delegation().