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

[Michael Tokarev]

27.06.2023 15:41, Tuomo Soini wrote:
> On Tue, 27 Jun 2023 13:56:45 +0300
> Michael Tokarev <mjt at tls.msk.ru> 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 :)
> 
> 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