Is it by design that Unbound supports NS records pointing to CNAME records?
Havard Eidnes
he at uninett.no
Mon Jan 26 12:20:52 UTC 2026
> 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
More information about the Unbound-users
mailing list