I can appreciate if you are tired of, and thus refrain from,
responding further in light of my continued ignorance.
What I am not understanding is that forward and recursing are
conflicting since I would have considered forwarding being part of
recursing.
The issue to me as simple user seems rather that the forward-zone
name is limited to . and therein somehow conflicting with auth-zone
name .
Or else forward-zone name being a domain name but it can hardly be
expected having to list every TLD there is such as .com .net .gov
and so forth ("Define them for other names, and that should work for
those subzones.")
Perhaps if there was instead a logic for forward-zone name: .* it
would solve the matter comprehensively for all TLD and subdomains.
I do appreciate all the effort being put into unbound and I am happy
with deploying the application just in this case of the “hyperlocal”
concept its usability does not appeal really.
Having to chose between complicating matters with stub-zone and DoT
I have opted for the latter and dropped the idea of hyperlocal
(auth-zone name: .).
On 28.11.2018 17:15, Wouter via Unbound-users wrote:
Hi,
So to summarize, another user also had this problem. And the
issue was he enabled both a forward-zone with the new DoT. And
RFC7706 local copy of the root. But that is both forward and do
full recursion at the same time, conflicting. You have to pick
one.
That query can get TLSed and sent to an upstream forwarder. Or
it can take a referral from an RFC7706 copy of the root and then
do full recursion. But not really both at the same time.
Hence, a bug, previously, and now it prints errors. But you ran
into that error.
Unbound can actually also do DoT with stub-zones too, if you
configured it in unbound.conf, but there are no upstreams or
method to find any. Anyway, that was not what you tried to do.
Best regards, Wouter
On 28/11/2018 16:56, Wouter
Wijngaards via Unbound-users wrote:
Hi,
Yes the RFC7706 functionality needs you to not have a
forward-zone clause and then an auth-zone for the root. With
for-downstream: no and for-upstream: yes (and the RFC
recommends the fallback enabled, I think). Unbound uses the
auth-zone as a repository of data that is accessed instead of
the upstream, this is why the forward-zone and stub-zone
definitions are still used, because they regulate how that
local-copy of the upstream is accessed.
If you want DoT upstreams, you can define them. Just not for
the "." zone whilst doing the auth-zone for the root. Define
them for other names, and that should work for those subzones.
There is an example in the example.conf for RFC7706
functionality for the root. You keep turning the options
wrong?
The servfail is because you instructed unbound to act as a
forwarder to a root server, whose content is locally cached in
an auth-zone. The root server has very little data, itself,
hence the servfails. It needs to not have that forwarder
clause. Then it uses the referrals from the local copy to
continue the full recursion. And you could have gotten non
SERVFAIL answers, if only you asked for the data that the
local copy actually has, the root SOA record. That would be
answered and then a forwarder configuration works, giving the
SOA record answer. But for RFC7706 it wants the referrals
followed, so not the forwarder configuration.
The auth zone, when configured as for-downstream:no and
for-upstream: yes is a quick method to get a reply from the
upstream. By having a local copy of the data to fill in the
upstream reply. Unbound then still needs to have the
configuration on how to contact upstreams. And for a local
root copy mirror that means a configuration where it will use
the referral answer. Using the referral answer needs a
stub-zone (or the absence of a forward-zone).
Looks like the architecture of the system and its
configuration settings is complicated, if you end up figureing
out where the understanding issue is, I mean how to fix
documentation that would be nice. Unbound is using both
stub/forward decls to feed into an upstream selection, using
auth-zone copies. With for-downstream: yes the auth-zone
moves closer and overtakes the stub/forward zones to provide
the answer directly, something that is useful for giving
authority answers to downstreams.
Best regards, Wouter
On 28/11/2018 16:01, ѽ҉ᶬḳ℠ via
Unbound-users wrote:
I am not sure where my understanding is going awry here. What
I want to achieve seems to be called “hyperlocal” concept - a
local copy (AXFR/IXFR) of the root zone (to be served) by
unbound to its clients. Something like:
Thus far my understanding is that is (zone transfer) best to
be achieved via auth-zone and sub-zone rather to be utilized
for company-local data or private zones (authoritative data
that cannot be accessed using the public internet servers),
which the root zone is not. And stub-zone does not provide for
zone transfer, as far as I understand.
If the forward-zone definition is removed than I cannot
utilise DoT with selected upstream resolvers.
What I not get is the servfail on the referrals/delegation
from the root zone. Is unbound not suited for this
“hyperlocal” concept thence?
On 28.11.2018 14:42, Wouter via
Unbound-users wrote:
Hi,
On 28/11/2018 13:46, ѽ҉ᶬḳ℠ via
Unbound-users wrote:
Hi Wouter,
thanks for looking into it and the response. Unfortunately
with the below setting the second-level domain does
not resolve
It is configured to forward to the root zone that you
have mirrored. The root zone only contains delegations,
so you get servfail or referrals out of that. What you
want is that it performs full recursion with the copy of
the root zone, that is the stub-zone behaviour. You
should change your config to have stub-zone for the name:
"." zone and not a forward-zone for that; or remove the
forward-zone definition.
These two log lines contained the info:
debug: forwarder, ignoring referral from auth zone
debug: auth zone lookup failed, no fallback, servfail
|
