IPv6 only domains should emit warning and not error

[sandoche2k]

https://www.zonemaster.net/result/698f292054b0dd1e

Also it should be discussed what messages to emit when the IPv4 option is turned off

[vlevigneron]

Could you ellaborate on the issue. The 2 nameservers are IPv6 only. What did you expect ?

[matsduf]

Yes, we must make a distinction between testing over IPv4 and testing for IPv4 resources. I agree with @vlevigneron.

[sandoche2k]

I do not expect the RED Colour in this case. If I consider this as a GUI issue, the RED colour is because there is an ERROR message emitted by the engine

[matsduf]

@sandoche2k, in Delegation01 you can see that NO_IPV4_NS_CHILD is classified as an ERROR, i.e. red in gui.

[sandoche2k]

@matsduf then we should update the test case specification saying that if there are less than least two distinct IP addresses (either two IPv4 or two IPv6 or one IPv4 and one IPv6, then), it is ERROR, otherwise just a NOTICE

[vlevigneron]

@matsduf @sandoche2k What are your conclusions on this issue fix ?

[matsduf]

Best practice says that there should be two name servers per protocol, so the test should not accept one IPv4 and one IPv6. Such a configuration has not redundancy for those parts of Internet with only one protocol stack. That should still be seen as an ERROR, one per protocol.

IPv4 is still more important than IPv6. The test case sees no IPv4 as an ERROR. I could accept to downgrade that to a WARNING, but it would be to go too far to downgrade that to a NOTICE.

The test cases sees no IPv6 as a NOTICE. I do not think we should upgrade that to a WARNING.

From RFC 3901:

3.  Policy Based Avoidance of Name Space Fragmentation

(...)

   Having those zones served only by IPv6-only name server would not be
   a good development, since this will fragment the previously
   unfragmented IPv4 name space and there are strong reasons to find a
   mechanism to avoid it.

From RFC 4472:

1.3.  Avoiding IPv4/IPv6 Name Space Fragmentation

   To avoid the DNS name space from fragmenting into parts where some
   parts of DNS are only visible using IPv4 (or IPv6) transport, the
   recommendation is to always keep at least one authoritative server
   IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
   See DNS IPv6 transport guidelines [RFC3901] for more information.

[mdavids]

Thank you for this good discussion. In my mind it is as follows:

My somewhat more principle, philosophical rationale for a more relaxed result, is that perhaps the real problem lies in the fact that there are still resolvers out there without IPv6 connectivity. Returning a red result, is not an incentive for them to fix their issue. It gives them the tools to dismiss the result as 'not being their problem to fix', even though they are a major part of the problem.

That is why I propose changing red to orange, with the following reasoning and justification:

An RFC8174 'MUST'-violation is what I associate with an ERROR (= red message).
But not following a 'recommendation' (RFC4472, 1.3) or a SHOULD (RFC3901, 4) is not an error per se. It could very well be shown as a WARNING (= orange message) or even a NOTICE (= blue message), something I would not recommend in this particular scenario by the way.

Orange seems as being the best of both worlds. But those are just my two cents.

Maybe I should write an RFC, stating explicitly that 'nowadays resolvers SHOULD have IPv6 connectivity'? 😉

PS:
I also wouldn't mind if not having and IPv6-reachable authoritative would yield an orange WARNING, instead of the blue NOTICE is has currently.

[matsduf]

I think that, in the default profile, it makes sense to lower the level on missing IPv4 nameservers from ERROR to WARNING. I hope I will see the day when this discussion is irrelevant, i.e. when we have IPv6 everywhere.

[matsduf]

PR zonemaster/zonemaster#758 addresses this issue.

[matsduf]

Specification has been updated (onemaster/zonemaster#758) and a new issue to implement that has been created (#569).