Can we finally agree unbound does not work with local data or zones?
Tuomo Soini
tis at foobar.fi
Tue Jun 27 12:41:55 UTC 2023
On Tue, 27 Jun 2023 13:56:45 +0300
Michael Tokarev <mjt at tls.msk.ru> wrote:
> 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 :)
Yes, it does. Try it first before you say it doesn't.
--
Tuomo Soini <tis at foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <https://foobar.fi/>
More information about the Unbound-users
mailing list