Is it by design that Unbound supports NS records pointing to CNAME records?

[Petr Menšík]

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