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

Unbound
1

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

2

It only works like you want if you use cache between clients and your
zone like this. Important thing here is "for-downstream: no".

auth-zone:
        name: "example.com"
        fallback-enabled: yes
        for-downstream: no
        for-upstream: yes
        primary: 172.27.5.3
        zonefile: /var/lib/unbound/example.com.zone

stub-zone:
        name: "example.com"
        stub-address: 172.27.5.3

Hope this helps.

3

27.06.2023 01:25, Tuomo Soini wrote:

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.

It only works like you want if you use cache between clients and your
zone like this. Important thing here is "for-downstream: no".

auth-zone:
         name: "example.com"
         fallback-enabled: yes
         for-downstream: no
         for-upstream: yes
         primary: 172.27.5.3
         zonefile: /var/lib/unbound/example.com.zone

stub-zone:
         name: "example.com"
         stub-address: 172.27.5.3

Well. This - setting of for-downstream to "no" - effectively makes auth-zone
statement completely useless. Unbound has the zone but does not use it to
answer the queries. It is exactly the same as having no "auth-zone" at all,
and just use stub-address directly. And in turn, it means stub-address must
be reachable when this zone is queried - for any name, not just for this particular
record.

Hope this helps.

No, unfortunately it does not :slight_smile:

Thanks,

/mjt

4

27.06.2023 01:25, Tuomo Soini wrote:
> It only works like you want if you use cache between clients and
> your zone like this. Important thing here is "for-downstream: no".
>
> auth-zone:
> name: "example.com"
> fallback-enabled: yes
> for-downstream: no
> for-upstream: yes
> primary: 172.27.5.3
> zonefile: /var/lib/unbound/example.com.zone
>
> stub-zone:
> name: "example.com"
> stub-address: 172.27.5.3

Well. This - setting of for-downstream to "no" - effectively makes
auth-zone statement completely useless. Unbound has the zone but
does not use it to answer the queries. It is exactly the same as
having no "auth-zone" at all, and just use stub-address directly.
And in turn, it means stub-address must be reachable when this zone
is queried - for any name, not just for this particular record.

When there is for-downstream: no unbound queries auth-zone instead of
querying configured upstream server but responds from resolver, so
behaviour is not like authoritative server. So instead of querying
authoritative server unbound queries from local auth-zone file. The
difference is you get proper responses for CNAME. This is exactly same
as rfc8806 root dns cache config.

So unbound queries from auth-zone but answers are kept in cache until
they expire and then queries go to auth-zone again. I have testes this
and queries continue to work after stopping primary server and
restarting unbound (to make sure caches are clean).

> Hope this helps.

No, unfortunately it does not :slight_smile:

Yes, it does. Try it first before you say it doesn't.

5

27.06.2023 15:41, Tuomo Soini wrote:
..

Well. This - setting of for-downstream to "no" - effectively makes
auth-zone statement completely useless. Unbound has the zone but
does not use it to answer the queries. It is exactly the same as
having no "auth-zone" at all, and just use stub-address directly.
And in turn, it means stub-address must be reachable when this zone
is queried - for any name, not just for this particular record.

When there is for-downstream: no unbound queries auth-zone instead of
querying configured upstream server but responds from resolver, so
behaviour is not like authoritative server. So instead of querying
authoritative server unbound queries from local auth-zone file. The
difference is you get proper responses for CNAME. This is exactly same
as rfc8806 root dns cache config.

So unbound queries from auth-zone but answers are kept in cache until
they expire and then queries go to auth-zone again. I have testes this
and queries continue to work after stopping primary server and
restarting unbound (to make sure caches are clean).

Hope this helps.

No, unfortunately it does not :slight_smile:

Yes, it does. Try it first before you say it doesn't.

Now this is interesting.

A while back when I tried it, I had to turn it off again (and switch
nsd+unbound again for local domain), exactly because it diddn't work:
it resorted to resolving the queries the usual recursive way starting
from configured forwarders (or from root), just like there's no auth-
zone configured. This was the reason I switched to nsd again, and
sent another email about this matter. And this is the reason I
wrote the for-downstream:no in auth-zone makes it useless.
(I didn't use stub-zone at the same time, and didn-t have fallback:
yes, iirc anyway).

I gave it another try, and now it does reply from the fetched auth
zone directly, without querying anything else, including CNAME
resolution.

Now I wonder why it didn't work for me in the first place, why
it tried the recursive lookup, basically ignoring auth-zone
entirely.

It still feels.. unreliable at best, but now I can't say why
it didn't work for me when I had to switch back to unbound+nsd

(setting up the two is rather clumsy, since one needs two IP
addresses and "cross-configuration" for both, while just
unbound with auth-zone *supposed* to work with very simple
config)

Lemme run it for a while once again...

/mjt