Reverse zones: zonemaster fails to detect NS inconsistencies with parent zone (Nameserver07)

[jonglezb]

I am troubleshooting an IPv6 reverse DNS issue, which turned out to be a NS mismatch between the parent and child zones.

However, zonemaster didn't spot the issue, saying All of the nameserver names are listed both at parent and child..

Here is the full result: https://zonemaster.fr/result/94a0ac91fba2c05a

The zone of interest is 1.0.3.5.0.6.6.0.1.0.0.2.ip6.arpa., the parent zone is 0.6.6.0.1.0.0.2.ip6.arpa.

NS in parent zone:

dig @ns1.renater.fr 1.0.3.5.0.6.6.0.1.0.0.2.ip6.arpa. NS
cosmos.imag.fr.
brahma.imag.fr.
imag.imag.fr.

NS in child zone:

dig @imag.imag.fr 1.0.3.5.0.6.6.0.1.0.0.2.ip6.arpa. NS
eip2.u-ga.fr.
eip1.u-ga.fr.

I would expect zonemaster to catch this mismatch (and the fact that the NS in the parent zones are 2/3 broken). Instead, it incorrectly determined the NS in the parent zone to be equal to those of the child zone:

Parent lists enough (2) nameservers (eip1.u-ga.fr; eip2.u-ga.fr). Lower limit set to 2.

[jonglezb]

Looking quickly at the code, it seems to be simply fetching glue records (Zonemaster::Engine::TestMethods->method2), which does not really make sense for a reverse zone. method3 looks more appropriate in this case but I haven't tested.

[matsduf]

Thank you for reporting the problem. I agree that Zonemaster here fails to distinguish between delegation in parent zone and NS RRset in child zone. One thing that I think that Zonemaster stumbles on is the fact that the only working NS in the delegation, imag.imag.fr, is also a nameserver of the parent.

We do have shortcomings both of the specification and implementation of the methods. We will look into this.

Referral from parent zone:

; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> @ns1.renater.fr 1.0.3.5.0.6.6.0.1.0.0.2.ip6.arpa.
(...)
;; AUTHORITY SECTION:
1.0.3.5.0.6.6.0.1.0.0.2.ip6.arpa. 172800 IN NS	imag.imag.fr.
1.0.3.5.0.6.6.0.1.0.0.2.ip6.arpa. 172800 IN NS	brahma.imag.fr.
1.0.3.5.0.6.6.0.1.0.0.2.ip6.arpa. 172800 IN NS	cosmos.imag.fr.

NS RRset in child zone:

; <<>> DiG 9.11.3-1ubuntu1.14-Ubuntu <<>> 1.0.3.5.0.6.6.0.1.0.0.2.ip6.arpa. @imag.imag.fr ns
;; ANSWER SECTION:
1.0.3.5.0.6.6.0.1.0.0.2.ip6.arpa. 3600 IN NS	eip2.u-ga.fr.
1.0.3.5.0.6.6.0.1.0.0.2.ip6.arpa. 3600 IN NS	eip1.u-ga.fr.

Zonemaster says:

$ zonemaster-cli 1.0.3.5.0.6.6.0.1.0.0.2.ip6.arpa. --show_testcase --level INFO --save 1.0.3.5.0.6.6.0.1.0.0.2.ip6.arpa.savefile
Seconds Level     Testcase       Message
======= ========= ============== =======
   0.00 INFO      UNSPECIFIED    Using version v4.1.0 of the Zonemaster engine.
(...)
  33.93 INFO      DELEGATION07   All of the nameserver names are listed both at parent and child.
(...)

$ zonemaster-cli 1.0.3.5.0.6.6.0.1.0.0.2.ip6.arpa. --show_testcase --level INFO --raw --restore 1.0.3.5.0.6.6.0.1.0.0.2.ip6.arpa.savefile
   0.00 INFO      UNSPECIFIED    GLOBAL_VERSION   version=v4.1.0
(...)
   4.21 INFO      DELEGATION07   NAMES_MATCH   names=eip1.u-ga.fr;eip2.u-ga.fr
(...)

The save file 1.0.3.5.0.6.6.0.1.0.0.2.ip6.arpa.savefile.gz from the test is enclosed.

[matsduf]

Looking quickly at the code, it seems to be simply fetching glue records (Zonemaster::Engine::TestMethods->method2), which does not really make sense for a reverse zone. method3 looks more appropriate in this case but I haven't tested.

A zone is a zone. DNS does not make any difference between "normal" domains and reverse domains. There are some problems with the Methods. both the specification and its implementation. We have a specification for new methods, MethodsNT, that we have not had time to implement.