1.7.3 - stub-zone public domain

Tue Jul 31 15:08:02 UTC 2018

Hi,

On 07/27/2018 06:19 PM, ѽ҉ᶬḳ℠ via Unbound-users wrote:
> 
>>>>>> 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).
> 
> Not the case here being an ubuntu box with a one unbound.conf with a
> separate [ include: "/etc/unbound/stub" ]. Latter is being loaded and
> foo.bar is a DelegationPoint (LOG [2] at the bottom) with the corect ip
> and port.
> 
> Looking then at LOG [1] (bottom) the query via stub is initiated indeed
> but then at some point leaps to the upstream resolver:
> 
> unbound[14331:0] debug: request has dependency depth of 1
> unbound[14331:0] debug: forwarding request

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.

Best regards, Wouter

> 
> 
>>
>> 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 ]
>>>
> 
> 
> LOG [1]
> unbound[14331:0] info: resolving foo.bar. A IN
> unbound[14331:0] debug: request has dependency depth of 0
> unbound[14331:0] info: use stub foo.bar. NS IN
> unbound[14331:0] debug: cache delegation returns delegpt
> unbound[14331:0] info: DelegationPoint<foo.bar.>: 1 names (1 missing), 1
> addrs (0 result, 1 avail) cacheNS
> unbound[14331:0] info:   dns.
> unbound[14331:0] debug:    ip4 172.24.120.10 port 42053 (len 16)
> unbound[14331:0] debug: iter_handle processing q with state INIT REQUEST
> STATE (stage 2)
> unbound[14331:0] info: resolving (init part 2):  foo.bar. A IN
> unbound[14331:0] info: use stub foo.bar. NS IN
> unbound[14331:0] debug: iter_handle processing q with state INIT REQUEST
> STATE (stage 3)
> unbound[14331:0] info: resolving (init part 3):  foo.bar. A IN
> unbound[14331:0] debug: iter_handle processing q with state QUERY
> TARGETS STATE
> unbound[14331:0] info: processQueryTargets: foo.bar. A IN
> unbound[14331:0] debug: processQueryTargets: targetqueries 0,
> currentqueries 0 sentcount 0
> unbound[14331:0] info: DelegationPoint<foo.bar.>: 1 names (1 missing), 1
> addrs (0 result, 1 avail) cacheNS
> unbound[14331:0] info:   dns.
> unbound[14331:0] debug:    ip4 172.24.120.10 port 42053 (len 16)
> unbound[14331:0] debug: attempt to get extra 3 targets
> unbound[14331:0] info: new target dns. A IN
> unbound[14331:0] debug: selrtt 376
> unbound[14331:0] info: sending query: foo.bar. A IN
> unbound[14331:0] debug: sending to target: <foo.bar.> 172.24.120.10#42053
> unbound[14331:0] debug: dnssec status: not expected
> unbound[14331:0] debug: EDNS lookup known=0 vs=0
> unbound[14331:0] debug: qname perturbed to foo.bar.
> unbound[14331:0] debug: serviced query UDP timeout=376 msec
> unbound[14331:0] debug: inserted new pending reply id=c71e
> unbound[14331:0] debug: opened UDP if=0 port=6899
> unbound[14331:0] debug: comm point start listening 58
> unbound[14331:0] debug: mesh_run: iterator module exit state is
> module_wait_reply
> unbound[14331:0] debug: iterator[module 1] operate:
> extstate:module_state_initial event:module_event_pass
> unbound[14331:0] info: iterator operate: query dns. A IN
> unbound[14331:0] debug: iter_handle processing q with state INIT REQUEST
> STATE
> unbound[14331:0] info: resolving dns. A IN
> unbound[14331:0] debug: request has dependency depth of 1
> unbound[14331:0] debug: forwarding request
> unbound[14331:0] debug: iter_handle processing q with state QUERY
> TARGETS STATE
> unbound[14331:0] info: processQueryTargets: dns. A IN
> unbound[14331:0] debug: processQueryTargets: targetqueries 0,
> currentqueries 0 sentcount 0
> unbound[14331:0] info: DelegationPoint<.>: 0 names (0 missing), 8 addrs
> (0 result, 8 avail) parentNS
> unbound[14331:0] debug: attempt to get extra 2 targets
> unbound[14331:0] debug: selrtt 376
> unbound[14331:0] info: sending query: dns. A IN
> unbound[14331:0] debug: sending to target: <.>
> 
> 
> 
> LOG [2]
> unbound[6400:0] debug: Forward zone server list:
> unbound[6400:0] info: DelegationPoint<.>: 0 names (0 missing), 8 addrs
> (0 result, 8 avail) parentNS
> unbound[6400:0] info: DelegationPoint<foo.bar.>: 1 names (1 missing), 1
> addrs (0 result, 1 avail) cacheNS
> unbound[6400:0] info:   dns.
> unbound[6400:0] debug:    ip4 172.24.120.10 port 42053 (len 16)
> unbound[6400:0] info: DelegationPoint<mail.>: 1 names (1 missing), 1
> addrs (0 result, 1 avail) parentNS
> unbound[6400:0] info:   mail.
> unbound[6400:0] debug:    ip4 172.24.120.10 port 42053 (len 16)
> unbound[6400:2] debug: Forward zone server list:
> unbound[6400:2] info: DelegationPoint<.>: 0 names (0 missing), 8 addrs
> (0 result, 8 avail) parentNS
> unbound[6400:2] info: DelegationPoint<foo.bar.>: 1 names (1 missing), 1
> addrs (0 result, 1 avail) cacheNS
> unbound[6400:2] info:   dns.
> unbound[6400:2] debug:    ip4 172.24.120.10 port 42053 (len 16)
> unbound[6400:2] info: DelegationPoint<mail.>: 1 names (1 missing), 1
> addrs (0 result, 1 avail) parentNS
> unbound[6400:2] info:   mail.
> unbound[6400:2] debug:    ip4 172.24.120.10 port 42053 (len 16)
> unbound[6400:1] debug: Forward zone server list:
> unbound[6400:1] info: DelegationPoint<.>: 0 names (0 missing), 8 addrs
> (0 result, 8 avail) parentNS
> unbound[6400:1] info: DelegationPoint<.>: 13 names (0 missing), 26 addrs
> (0 result, 26 avail) parentNS
> unbound[6400:4] debug: Forward zone server list:
> unbound[6400:4] info: DelegationPoint<.>: 0 names (0 missing), 8 addrs
> (0 result, 8 avail) parentNS
> unbound[6400:3] debug: Forward zone server list:
> unbound[6400:5] debug: Forward zone server list:
> unbound[6400:3] info: DelegationPoint<.>: 0 names (0 missing), 8 addrs
> (0 result, 8 avail) parentNS
> unbound[6400:5] info: DelegationPoint<.>: 0 names (0 missing), 8 addrs
> (0 result, 8 avail) parentNS
> unbound[6400:3] info: DelegationPoint<.>: 13 names (0 missing), 26 addrs
> (0 result, 26 avail) parentNS
> unbound[6400:1] info: DelegationPoint<foo.bar.>: 1 names (1 missing), 1
> addrs (0 result, 1 avail) cacheNS
> unbound[6400:5] info: DelegationPoint<.>: 13 names (0 missing), 26 addrs
> (0 result, 26 avail) parentNS
> unbound[6400:1] info:   dns.
> unbound[6400:1] debug:    ip4 172.24.120.10 port 42053 (len 16)
> unbound[6400:1] info: DelegationPoint<mail.>: 1 names (1 missing), 1
> addrs (0 result, 1 avail) parentNS
> unbound[6400:1] info:   mail.
> unbound[6400:4] info: DelegationPoint<.>: 13 names (0 missing), 26 addrs
> (0 result, 26 avail) parentNS
> unbound[6400:1] debug:    ip4 172.24.120.10 port 42053 (len 16)
> unbound[6400:3] info: DelegationPoint<foo.bar.>: 1 names (1 missing), 1
> addrs (0 result, 1 avail) cacheNS
> unbound[6400:3] info:   dns.
> unbound[6400:3] debug:    ip4 172.24.120.10 port 42053 (len 16)
> unbound[6400:3] info: DelegationPoint<mail.>: 1 names (1 missing), 1
> addrs (0 result, 1 avail) parentNS
> unbound[6400:3] info:   mail.
> unbound[6400:3] debug:    ip4 172.24.120.10 port 42053 (len 16)
> unbound[6400:4] info: DelegationPoint<foo.bar.>: 1 names (1 missing), 1
> addrs (0 result, 1 avail) cacheNS
> unbound[6400:4] info:   dns.
> unbound[6400:4] debug:    ip4 172.24.120.10 port 42053 (len 16)
> unbound[6400:4] info: DelegationPoint<mail.>: 1 names (1 missing), 1
> addrs (0 result, 1 avail) parentNS
> unbound[6400:4] info:   mail.
> unbound[6400:4] debug:    ip4 172.24.120.10 port 42053 (len 16)
> unbound[6400:5] info: DelegationPoint<foo.bar.>: 1 names (1 missing), 1
> addrs (0 result, 1 avail) cacheNS
> unbound[6400:5] info:   dns.
> unbound[6400:5] debug:    ip4 172.24.120.10 port 42053 (len 16)
> unbound[6400:5] info: DelegationPoint<mail.>: 1 names (1 missing), 1
> addrs (0 result, 1 avail) parentNS
> unbound[6400:5] info:   mail.
> unbound[6400:5] debug:    ip4 172.24.120.10 port 42053 (len 16)
> 