1.7.3 - stub-zone public domain

[Wouter Wijngaards]

Hi,


On 27/07/18 04:06, ѽ҉ᶬḳ℠ via Unbound-users wrote:
>> Hi,
>>
>> is stub-zone is only serving private domains but not public domains?
stub zones and forward zones are selected closest to the name of the
query.  That one is used.

If you run another (authoritative) server on the same host,
do-not-query-localhost: no is usually necessary to enable unbound to
query it.  Otherwise unbound attempts to not get into some sort of loop
by querying localhost (itself in many cases), hence it is off by default.

>>
>> 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

Unbound should prefer the closest of stub of forward zones that is
configured for that query.

For auth-zones, the read fails if there is no masters to fetch the
content from and the file does not exist.  Then it is a fatal error.  If
you also configure a master, it ignores the file and fetches data.  So,
it should work and ignore the non-existant file and fetch for you if
there is some config for that.

I think the file is not found because of the chroot enabled by default
that tripped you up earlier?  Or perhaps the directory: "...." somewhere
that is also enabled by default (usually the chroot location). 
Otherwise that file should work, I guess, it has the data in zone file
format.

Best regards, Wouter

>> 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
> [1532656875] unbound[7107:0] fatal error: auth_zones could not be setup"
>
>
>
>