Unbound was/is lenient on CNAMEs in NS records by design.
Since it will have to start a resolution attempt at that point, it does
not matter if it is for a CNAME or not.
Also the text in that section of the RFC 2181 could be interpreted as
targeting the auth side (servers, zone editors), at least by me now that
I read it again.
I believe Unbound was/is like that to try and resolve in such a case
that garbage-in was encountered.
I think bind9 has more reasons to block it, because it is also primary authoritative server quite often. I think similar checks should be done on authoritatives and refused there, if possible. It would be good to put such check into NSD server. Unbound can do authoritative zones only and it might want to refuse adding CNAME there.
But I think if resolver receives CNAME where it should not be, it should log some warning, but continue to work. Correct behaviour should be enforced on whatever authoritative side, resolvers should accept whatever it can process in my opinion.
Therefore I would not call it a bug in Unbound, if it continues. My that is only my personal opinion, I do not speak for Unbound team.
I think bind9 has more reasons to block it, because it is also
primary authoritative server quite often. I think similar
checks should be done on authoritatives and refused there, if
possible. It would be good to put such check into NSD
server. Unbound can do authoritative zones only and it might
want to refuse adding CNAME there.
This argument is akin to "nip it in the bud", and I agree that's
the appropriate place to do it. However, BIND is not the only
DNS publication software out there, and I'm sure there exists DNS
publication implementations which do not perform this check, and
therefore allows this mis-configuration. This means that the
effect of this type of configuration error will certainly be
encountered by recursive resolvers.
But I think if resolver receives CNAME where it should not be,
it should log some warning, but continue to work. Correct
behaviour should be enforced on whatever authoritative side,
resolvers should accept whatever it can process in my opinion.
This argument leads to increasing complexity in recursive
resolver implementations, papering over what is obviously an
operator error / protocol violation. I'll have to admit that I
am not convinced that is the correct approach. If my memory
doesn't fail me, the preivous instances of "DNS flag day" events
have been declared exactly to get rid of additional complexity in
recursive resolvers which previously were used to paper over
operator error / protocol violations, and going in the opposite
direction feels wrong to me.
Therefore I would not call it a bug in Unbound, if it continues. My
that is only my personal opinion, I do not speak for Unbound team.