1.7.3 - stub-zone public domain
vtol at gmx.net
Fri Jul 27 02:06:18 UTC 2018
> is stub-zone is only serving private domains but not public domains?
> Running a local authoritative server for the public domain and having a
> stub-zone set in unbound for that public domain I noticed that unbound
> is not querying the local authoritative server for that public domain
> but querying upstream resolvers instead, which serve either from their
> cache or querying the local authoritative server eventually.
> That seems sort of redundant traffic and increasing the response time
> since that public domain could be resolved straight from the local local
> authoritative server instead?
Reading from the unbound online documentation for stub-zone:
"The servers should be authority servers, not recursors; unbound
performs the recursive processing itself for stub zones.
The stub zone can be used to configure authoritative data to be used by
the resolver that cannot be accessed using the public internet servers."
It does not say however that a public zone served by a local
authoritative server cannot be recursed locally but only through public
servers. Is it thus a misconception I fell victim to?
Tried then [ auth-zone: ] with [ zonefile: "/var/named/vtol.me.db" ]
being a BIND-9 zone file since the online documentation is not specific
on the format of such zone file. But that produces only:
"error: cannot open zonefile /var/named/foo.bar.db for foo.bar.: No such
file or directory
fatal error: auth_zones could not be setup"
So, then altered [ zonefile: "/etc/unbound/dummy.zone" ] and considering
"If the file does not exist or is empty, unbound will attempt to
fetch zone data (eg. from the master servers)." I would have
expected it to work now but unbound just reports:
"error: cannot open zonefile /etc/unbound/dummy.zone for foo.bar.: No
such file or directory
 unbound[7107:0] fatal error: auth_zones could not be setup"
More information about the Unbound-users