> 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. As per the above, I'm not sure I agree. Best regards, - Håvard
