Hi,
On 27/07/18 17:07, ѽ҉ᶬḳ℠ 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. > That does not seems to be an issue. BIND-9 as authoritative server is > not bound on lo/127.0.0.1 but eth0/172.24.120.10 and port 42053. That looks fine to me. > > The local QDN set in a stub-zone gets resolved just fine by unbound. > However, for the public FQDN set in a stub-zone it does not and unbound > is querying upstream resolvers instead and I do not see why it should. > Is there a hard-coded logic in unbound for FQDN to always (or first) be > resolved from upstream servers? The sub-zone is configured as follows: No, that should work fine and the stub should be used once configured. All I can think of is that some people report that on FreeBSD there is at some times confusion and they edit the wrong unbound.conf file, their edits are ignored because a different config file is used by unbound. (I think because there are separate configs for different instances; also Debian has an alternatives mechanism that puts the files in some other location or was that Ubuntu). 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 ] >