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.
Cheers,
Petr
On 19/01/2026 18:15, Jaime Hablutzel via Unbound-users wrote:
In
https://unbound.docs.nlnetlabs.nl/en/latest/reference/rfc-compliance.html you
indicate compliance with RFC 2181, which forbids NS records to point
to CNAME records:
10.3. MX and NS records
The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias.
But Unbound is currently supporting NS records pointing to CNAME
records, following them in the regular way.
Is this by design or is it a bug?
For reference, BIND9 generates a SERVFAIL in such cases
(https://groups.google.com/g/comp.protocols.dns.bind/c/MGJHdh7TSS4).
--
Petr Menšík
Senior Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
