Implementation is done in zonemaster/zonemaster-engine#1373. Current implementation details to note:

* The method returns `Zonemaster::Engine::Nameserver` objects, not just IP addresses as the specification describes. It is necessary to have such objects in Engine to be able to perform queries. The method could then be renamed as simply `get_parent_ns`, or a disclaimer can be added (just like with the new test case specifications).

Currently the test case specifications only use the parent name server IP addresses, not the names, so the method only needs to find the addresses. There is no issue if the implementation must have a name as long as we do not start using the name as such. I see no need of update of the specification.

* The method will return `undef` if there are more than one parent found (I assume this should not be possible from this new algorithm but still, it is a precaution)

There are still situations when there is more than one parent. Let us say that cc.xa has two NS. One has a delegation to bb.cc.xa and the other to aa.bb.cc.xa. And parent.grandparent.xa has two NS and both has a delegation aa.bb.cc.xa. The NS for aa.bb.cc.xa are the same in both delegations. Which is the parent of aa.bb.cc.xa? Except DNSSEC aa.bb.cc.xa will work. The two delegations could be different and it could still work if the zone data is the same, or at least relevant data is the same.

I just saw some errors in the specification, and then I again thought about the NXDOMAIN and NODATA situations. Since they do not give any delegation they could be ignored for the method (but not for Basic01). Now NXDOMAIN and NODATA are handled inconsistently by error. I will do an update where both are ignored (not considered to be a parent).

* A loop protection mechanism (currently set to 1000) is in place for the loop processing at step 5.11.

I am not sure how you count, but if there are many NS (both v4 and v6) and many levels (like IPv6 reverse) do you see a risk of reaching the limit? Will there be a message (DEBUG) if the loop protection breaks?

It would be interesting to see how many loops the code will do in the normal case. Have you checked?

I will adjust the expected parent data from some of the scenarios (remove server outputting NXDOMAIN or NODATA).

I just saw some errors in the specification, and then I again thought about the NXDOMAIN and NODATA situations. Since they do not give any delegation they could be ignored for the method (but not for Basic01). Now NXDOMAIN and NODATA are handled inconsistently by error. I will do an update where both are ignored (not considered to be a parent).

I will adjust the expected parent data from some of the scenarios (remove server outputting NXDOMAIN or NODATA).

Ah great, I was about to write a comment about that, as I'm currently testing zonemaster/zonemaster-engine#1351 with the changes in zonemaster/zonemaster-engine#1373. While troubleshooting scenario CHLD-FOUND-INCONSIST-1, I stumbled upon this issue.

I am not sure how you count, but if there are many NS (both v4 and v6) and many levels (like IPv6 reverse) do you see a risk of reaching the limit? Will there be a message (DEBUG) if the loop protection breaks?
It would be interesting to see how many loops the code will do in the normal case. Have you checked?

I will check now, and adjusts the break counter if needed (1000 seemed reasonable enough at first glance). There is a DEBUG2 message in place when that happens yes.

There are still situations when there is more than one parent. Let us say that cc.xa has two NS. One has a delegation to bb.cc.xa and the other to aa.bb.cc.xa. And parent.grandparent.xa has two NS and both has a delegation aa.bb.cc.xa. The NS for aa.bb.cc.xa are the same in both delegations. Which is the parent of aa.bb.cc.xa? Except DNSSEC aa.bb.cc.xa will work. The two delegations could be different and it could still work if the zone data is the same, or at least relevant data is the same.

Ok, I'll make the necessary changes in the implementation. But maybe the specification needs to be more explicit then? i.e., step 6.

Ok, I'll make the necessary changes in the implementation. But maybe the specification needs to be more explicit then? i.e., step 6.

Is it this step 6 you mean?

6. If the *Parent Found* set is non-empty then do:
   1. Extract the name server IP list.
   2. Return the following from the Method:
      1. The extracted list of name server IP addresses (parent zone name servers).
   3. Exit these procedures.

It just refers to parent name server IP addresses, not parent zone.

I am not sure how you count, but if there are many NS (both v4 and v6) and many levels (like IPv6 reverse) do you see a risk of reaching the limit? Will there be a message (DEBUG) if the loop protection breaks?
It would be interesting to see how many loops the code will do in the normal case. Have you checked?

I will check now, and adjusts the break counter if needed (1000 seemed reasonable enough at first glance). There is a DEBUG2 message in place when that happens yes.

For Basic01, using the test zones in t/Test-basic01.t (on current develop), the counter is either 0 or 1 (it starts at 0).
For MethodsV2, using the test zones in t/methodsv2.t (on current develop), the counter is always 0 (it starts at 0).