<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi,</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p><br>
</p>
<p>Best regards, Wouter</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 28/11/2018 16:56, Wouter Wijngaards
via Unbound-users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:ba8005df-7e26-2520-e534-0f23b922f97f@nlnetlabs.nl">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi,</p>
<p>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.<br>
</p>
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.
<p>There is an example in the example.conf for RFC7706
functionality for the root. You keep turning the options wrong?<br>
</p>
<p>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.</p>
<p>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).</p>
<p>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.<br>
</p>
<p>Best regards, Wouter<br>
</p>
<div class="moz-cite-prefix">On 28/11/2018 16:01, ѽ҉ᶬḳ℠ via
Unbound-users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c707cb50-c0d2-0692-09f7-6c9efe99ec80@gmx.net">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
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:<br>
<ul>
<li><a class="moz-txt-link-freetext"
href="https://tools.ietf.org/html/rfc7706"
moz-do-not-send="true">https://tools.ietf.org/html/rfc7706</a></li>
<li><a class="moz-txt-link-freetext"
href="https://tools.ietf.org/html/draft-ietf-dnsop-7706bis-00"
moz-do-not-send="true">https://tools.ietf.org/html/draft-ietf-dnsop-7706bis-00</a></li>
<li><a class="moz-txt-link-freetext"
href="https://localroot.isi.edu/about/"
moz-do-not-send="true">https://localroot.isi.edu/about/</a></li>
</ul>
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.<br>
<br>
If the forward-zone definition is removed than I cannot utilise
DoT with selected upstream resolvers.<br>
<br>
What I not get is the servfail on the referrals/delegation from
the root zone. Is unbound not suited for this “hyperlocal”
concept thence?<br>
<div class="moz-signature"><br>
</div>
<div class="moz-cite-prefix">On 28.11.2018 14:42, Wouter via
Unbound-users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2d40b260-8779-0e17-81fa-121347825d95@nlnetlabs.nl">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>Hi,<br>
</p>
<div class="moz-cite-prefix">On 28/11/2018 13:46, ѽ҉ᶬḳ℠ via
Unbound-users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e570cf6e-18d8-9724-6d20-49134e671214@gmx.net">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
Hi Wouter,<br>
<br>
thanks for looking into it and the response. Unfortunately
with the below setting the <i>second-level domain does not
resolve</i><br>
</blockquote>
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<p>These two log lines contained the info:</p>
<p> debug: forwarder, ignoring referral from auth zone<br>
debug: auth zone lookup failed, no fallback, servfail</p>
<br>
</blockquote>
<br>
</blockquote>
</blockquote>
</body>
</html>