<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Reckon I got it (hyperlocal) working now that is unless
misinterpreting the log and the shorter response times.<br>
It was mentioned in this thread earlier twice already (and I
dismissed it) to have fallback-enabled: yes.<br>
Finally that amounts to:<br>
<br>
<blockquote type="cite">auth-zone:<br>
name: .<br>
for-downstream: no<br>
fallback-enabled: yes<br>
master: 198.41.0.4<br>
master: 199.9.14.201<br>
master: 192.33.4.12<br>
master: 199.7.91.13<br>
master: 192.203.230.10<br>
master: 192.5.5.241<br>
master: 192.112.36.4<br>
master: 198.97.190.53<br>
master: 192.36.148.17<br>
master: 192.58.128.30<br>
master: 193.0.14.129<br>
master: 199.7.83.42<br>
master: 202.12.27.33</blockquote>
<br>
<div class="moz-cite-prefix">On 29.11.2018 12:18, ѽ҉ᶬḳ℠ via
Unbound-users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6f44ae76-828e-6e2a-5692-58efdd2ac849@gmx.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<br>
<div class="moz-cite-prefix">On 29.11.2018 09:42, via
Unbound-users wrote: </div>
<blockquote type="cite"
cite="mid:6e166fd6-c4ad-3d2b-8211-5456f98e80ac@nlnetlabs.nl">
<pre class="moz-quote-pre" wrap="">We make our tools for knowledgeable users, also because the education
part is very hard.</pre>
</blockquote>
<br>
I am trying hard with the education to become a knowledgeable user
but I am afraid that my pea sized brain is perhaps impeding the
process a bit ;)<br>
<br>
<blockquote type="cite"
cite="mid:6e166fd6-c4ad-3d2b-8211-5456f98e80ac@nlnetlabs.nl">
<pre class="moz-quote-pre" wrap=""> There are other places, and people, to get
information about how it all really works.</pre>
</blockquote>
<br>
Since you stated earlier: "There is an example in the example.conf
for RFC7706 functionality for the root." and thus I just looked
into unbound-1.8.2rc1\doc\example.conf.in and the only 3 RFC
references I could trace are unrelated to 7706. Also looked for
such file at <a class="moz-txt-link-freetext"
href="https://nlnetlabs.nl/documentation/unbound/"
moz-do-not-send="true">https://nlnetlabs.nl/documentation/unbound/</a>
but without success. <br>
The configuration examples listed in RFC7706/7706bis-00 are for
Unbound 1.4 in conjunction with NSD 4 and thus not applicable to
running only unbound.<br>
Am I missing something about that example.conf?<br>
<br>
<blockquote type="cite"
cite="mid:6e166fd6-c4ad-3d2b-8211-5456f98e80ac@nlnetlabs.nl">
<pre class="moz-quote-pre" wrap=""> But let me still try to
answer the questions. Probably in ways that make you ask more ... :-)</pre>
</blockquote>
<br>
Sure it does, and appreciate your continued patience and support!<br>
<br>
<blockquote type="cite"
cite="mid:6e166fd6-c4ad-3d2b-8211-5456f98e80ac@nlnetlabs.nl">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">What I am not understanding is that forward and recursing are
conflicting since I would have considered forwarding being part of
recursing.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">The difference is that forward is: send full query, get the answer.
For full-recursion: send parts, get referrals to other authoritative
servers, ask again there, until there is an answer.
If you enabled both, and unbound would perform full lookups to its
internal copy of the root zone. This then results in a list of TLD
servers to contact. But then it ignores that list, because, for TLDs,
it sends the full query to your configured DoT upstream forward server.
Then that upstream forward query would be the full query. Just like it
would have sent without the local copy of the root.</pre>
</blockquote>
<br>
I reckon that last bit is what confusing me - why the resolver
would issue a full query upstream (forward DoT) and not just for
the bits that are missing instead?<br>
Plus reading from 7706bis-00#section-1 - "recursive resolver
software such as Unbound will need to be able to talk to an
authoritative server (such as NSD) running on the same host. " It
was my impression that Unbound handles the part with auth-zone or
is that where stub-zone comes in?<br>
<br>
<blockquote type="cite"
cite="mid:6e166fd6-c4ad-3d2b-8211-5456f98e80ac@nlnetlabs.nl">
<pre class="moz-quote-pre" wrap="">So your solution to turn off the local copy of the root, seems to have
resulted in the behaviour you want from enabling both. Unbound sends
the full query to the upstream DoT server. And then uses that answer.
The local copy of the root is useful for full recursion, not forwarding,
setups, where the first referral lookups to the root servers are omitted
with a local copy. This is both faster and has privacy benefits.</pre>
</blockquote>
<br>
The speed and privacy benefits of the hyperlocal concept is what
caused me to start this thread and I still would like very much
deploy it but without having to give up on DoT and a curated list
of upstream resolver.<br>
<br>
<blockquote type="cite"
cite="mid:6e166fd6-c4ad-3d2b-8211-5456f98e80ac@nlnetlabs.nl">
<pre class="moz-quote-pre" wrap="">Best regards, Wouter
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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:
* <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>
* <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>
* <a class="moz-txt-link-freetext" href="https://localroot.isi.edu/about/" moz-do-not-send="true">https://localroot.isi.edu/about/</a>
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:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi,
On 28/11/2018 13:46, ѽ҉ᶬḳ℠ via Unbound-users wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi Wouter,
thanks for looking into it and the response. Unfortunately with
the below setting the /second-level domain does not resolve/
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>