1.7.3 - stub-zone public domain

[ѽ҉ᶬḳ℠]

> You have a name set for the forward zone, and it looks up the name
> "dns." that you set.  It does not exist, so won't do anything.  Just
> remove that from the config if you do not want it to look that up.
> forward-host is meant to be able to give the name string that unbound
> looks up (recursively making a new lookup to get the IP -address to use
> for the current lookup).  But you already have an IP-address, so it is
> not needed.
>

That local QDN dns is not the cause and gets resolved locally, no issue.
It is the public FQDN foo.bar.

But I have been thinking about it and in a way it makes sense that
unbound at some point leaps (basically just  doing the job is set to) to
a public resolver:

1. foo.bar has DNSSEC enabled and thus also the parent zone(s) need
validation that cannot be catered for by the local authoritative server
2. the default target-fetch-policy: "3 2 1 0 0", which to my
understanding would be 3 for ".",  2 for ".bar" and 1 for "foo.bar",
which can neither be satisfied from the local authoritative server


>
>
>>
>>> Set verbosity: 4 and see what goes wrong here.  At startup it should
>>> straight away log the stubs and forwards that it read in.
>>>
>>> Best regards, Wouter
>>>
>>>> stub-zone:
>>>>   name: foo.bar
>>>>   stub-host: dns
>>>>   stub-addr: 172.24.120.10 at 42053
>>>>
>>>> Doing a [ dig foo.bar ] unbound is neglecting [ stub-addr:
>>>> 172.24.120.10 at 42053 ] and heads straight for the upstream resolver. And
>>>> that does not make sense to me as the dig query is matching the [
>>>> stub-zone name ]
>>>>
>>