1.7.3 - stub-zone public domain

Unbound
1

Hi,

is stub-zone is only serving private domains but not public domains?

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

2

Hi,

is stub-zone is only serving private domains but not public domains?

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

3

Hi,

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

4

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.

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:

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 ]

5

Hi,

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

6

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

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 ]

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)

7

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

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

8

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