Closed BenBE closed 1 year ago
Yeah, this seems to be an unsigned sub-zone served by the same nameserver. n3map relied on the RRSet type bits in the NSEC record to detect when it is descending into a sub-zone, which doesn't work of course if it is not signed (it also would have failed if the sub-zone used NSEC3 though...).
I've made this more robust now (by also looking for a SOA
RR in the reply) , but there are undoubtedly still things that can go wrong.
Enumeration of the TLD
ax.
fails after a few records are found.To reproduce:
Given that
4h.ax.
seems to b served also by the same nameservers asax.
itself, querying for the A DNS RR does not produce a NSEC record:Instead to produce the next NSEC record, we need to manually increment the left-most label from our previous response; similar to what NSEC White Lies does, e.g.
4h0.ax.
. This gives the following (proper) reply:Would be nice, if this approach would be tried before declaring a nameserver to be misbehaving.
NB: I'm not yet sure, why this kills all four nameservers for this domain, but likely because the zone is authoritive there too, but not published in the NS RRset in the parent zone we are iterating.
FWIW: Using
--query-mode=NSEC
produces the same problem.