consider the following output, generated by running zonemaster on le-fay.org (using zonemaster.net, running 2024.2.1 as of today), which returns 3 results for Zone01:

 Zone01
    Warning SOA MNAME name server "hemlock.eden.le-fay.org/81.2.96.162" does not respond to an SOA query.
    Warning SOA MNAME name server "hemlock.eden.le-fay.org/2001:8b0:aab5:c401::1:5" does not respond to an SOA query.
    Info SOA MNAME name server "hemlock.eden.le-fay.org" is not listed as NS record for the zone.

the "Info" result is fine: the MNAME server not being listed as an NS is something that's worth flagging at Info level, but since it's not wrong, it's raised at Info rather than Warning.

in my opinion, the MNAME server not responding to queries is also worth flagging at Info level, but it's also not wrong, so it should also be raised at Info level, not Warning. my argument here is:

• the MNAME server is not normally queried during DNS resolution, so not responding to queries does not affect availability of the zone
• the MNAME server is often an internal server that, for security reasons, should not response to queries from the Internet

in my case, i have three servers listed in NS that run on Internet-facing servers running Knot and serve my zones to Internet users. the MNAME host (hemlock.eden.le-fay.org) runs BIND with a complicated configuration including Kerberos authentication for nsupdate, and for security reasons, this host does not respond to Internet queries. i believe this type of setup is very common on the Internet.

a workaround in this situation is to use a "hidden master" setup, where MNAME is set to one of the servers listed in NS rather than the real master. however, because of the way Kerberos authentication works for DNS, i cannot do this -- the MNAME must contain the real hostname of the master server.