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