> 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@42053 >>>> >>>> Doing a [ dig foo.bar ] unbound is neglecting [ stub-addr: >>>> 172.24.120.10@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 ] >>>> >>