Can we finally agree unbound does not work with local data or zones?

Michael Tokarev mjt at tls.msk.ru
Mon Jun 26 15:35:50 UTC 2023


Hello!

I asked this question maybe 3 times in the past but the answer has always been
about something else.

The problem is that unbound does not work with any local data which contains
CNAME records, no matter if it is local-data: or auth-zone: or anything else
like this: once unbound hits CNAME, it does not expand it, so the client
receives an answer which it can't handle.

Replies which I got so far about this matter are:

1) unbound is not authoritative nameserver.

Okay, but how this is relevant to the question at hand?  I don't see why, in
order to not be authoritative NS, unbound should be buggy and return useless
replies.  To me, it is better to fix the bug than to declare itself being
authoritative or not.

2) use auth-zone with for-downstream: no.  This becomes non-sentical entirely,
and again, I haven't received any reply to my question about this one.  With
for-downstream: no, auth-zone becomes useless, it is not used when answering
queries, so keeping it makes no sense.


Can we just declare that unbound is buggy and does not work with any sort of
local data which contains CNAMEs, so that other, non-buggy nameservers should
be used in cases where local data is important? (and yes, I say any local data,
because it costs quite some resources to discover that it doesn't work and to
understand the only way to fix this is to move away from unbound).


I don't really understand what the problem is to resolve a CNAME which happen
to be in a local data or auth zone, - just recurse the same way it is done in
all other places, everything needed is already there for a long time, working
just fine.

The way it works now makes it unfit for scenarios where else it fits perfectly
and is much more superior than other alternatives.  For example, a small home
network with a .local "tld" for local names and single unbound run on router
acting as recursive resolver and nameserver for this local zone, - it makes
no sense at all to require it to pair, say, with nsd just to keep a few
foo.local names one of which happens to be a CNAME to something else. Ditto for
a small office network and many similar examples.

So.. is it buggy and we can declare it as such in the docs and move to some
other solution, or can it be fixed?


Thanks,

/mjt


More information about the Unbound-users mailing list