<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<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>
<p><br>
</p>
<p>Best regards, Wouter<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:e570cf6e-18d8-9724-6d20-49134e671214@gmx.net"> <br>
<blockquote type="cite">auth-zone:<br>
name: .<br>
zonefile: /etc/unbound/root<br>
for-downstream: no<br>
for-upstream: 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>
The debug log (unbound 1.7.3):<br>
<br>
<blockquote type="cite">info: validator operate: query
bbc.com. A IN<br>
debug: validator: pass to next module<br>
debug: mesh_run: validator module exit state is
module_wait_module<br>
debug: iterator[module 1] operate:
extstate:module_state_initial event:module_event_pass<br>
debug: process_request: new external request event<br>
debug: iter_handle processing q with state INIT REQUEST
STATE<br>
info: resolving bbc.com. A IN<br>
debug: request has dependency depth of 0<br>
debug: forwarding request<br>
debug: iter_handle processing q with state QUERY TARGETS
STATE<br>
info: processQueryTargets: bbc.com. A IN<br>
debug: processQueryTargets: targetqueries 0, currentqueries
0 sentcount 0<br>
info: DelegationPoint<.>: 0 names (0 missing), 10
addrs (0 result, 10 avail) parentNS<br>
info: auth_zone . query bbc.com. A, domain
ns.amarshallinc.com. notexact notexist, ce com., rrset NS<br>
info: msg from auth zone ;; ->>HEADER<<- opcode:
QUERY, rcode: NOERROR, id: 0<br>
;; flags: qr ; QUERY: 1, ANSWER: 0, AUTHORITY: 15,
ADDITIONAL: 26 <br>
;; QUESTION SECTION:<br>
bbc.com. IN A<br>
<br>
;; ANSWER SECTION:<br>
<br>
;; AUTHORITY SECTION:<br>
com. 172800 IN NS a.gtld-servers.net.<br>
com. 172800 IN NS b.gtld-servers.net.<br>
com. 172800 IN NS c.gtld-servers.net.<br>
com. 172800 IN NS d.gtld-servers.net.<br>
com. 172800 IN NS e.gtld-servers.net.<br>
com. 172800 IN NS f.gtld-servers.net.<br>
com. 172800 IN NS g.gtld-servers.net.<br>
com. 172800 IN NS h.gtld-servers.net.<br>
com. 172800 IN NS i.gtld-servers.net.<br>
com. 172800 IN NS j.gtld-servers.net.<br>
com. 172800 IN NS k.gtld-servers.net.<br>
com. 172800 IN NS l.gtld-servers.net.<br>
com. 172800 IN NS m.gtld-servers.net.<br>
com. 86400 IN DS 30909 8 2
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CFC41A5766<br>
com. 86400 IN RRSIG DS 8 1 86400 20181211050000
20181128040000 2134 .
FeSgJRqqq/LY82e1pAM38Eiu07pepp53zIY23OlA65VDqA4ynhKWb8OvOKiWzHhWbM6KSs/4oXoTPMKn9x3EiWR0L170uKLloALiqbiVi9hJf/fYyRQB9QQPgxUqkkUnDdU7+zfK78BjBlEXgjd+5SfNiE32WKU9i5bP8crQg7J7tC/9FQwcn+eh/kz6pUJ5NVBG6YKkG2Y8YYCsOusOpa67WiRk3bf7DwJUAV6zD6v16TLr0GZesXokZbiwdIqPeJVjLumzLFxVHa+agDb3G2kv2qIjpFw7VPl1Nh/nADyJLdk6tvH5V9xu3MbkUgNcQeAoQG+BrEoRr7xfjKJhTA==
;{id = 2134}<br>
<br>
;; ADDITIONAL SECTION:<br>
a.gtld-servers.net. 172800 IN A 192.5.6.30<br>
a.gtld-servers.net. 172800 IN AAAA
2001:503:a83e::2:30<br>
b.gtld-servers.net. 172800 IN A 192.33.14.30<br>
b.gtld-servers.net. 172800 IN AAAA
2001:503:231d::2:30<br>
c.gtld-servers.net. 172800 IN A 192.26.92.30<br>
c.gtld-servers.net. 172800 IN AAAA
2001:503:83eb::30<br>
d.gtld-servers.net. 172800 IN A 192.31.80.30<br>
d.gtld-servers.net. 172800 IN AAAA
2001:500:856e::30<br>
e.gtld-servers.net. 172800 IN A 192.12.94.30<br>
e.gtld-servers.net. 172800 IN AAAA
2001:502:1ca1::30<br>
f.gtld-servers.net. 172800 IN A 192.35.51.30<br>
f.gtld-servers.net. 172800 IN AAAA
2001:503:d414::30<br>
g.gtld-servers.net. 172800 IN A 192.42.93.30<br>
g.gtld-servers.net. 172800 IN AAAA
2001:503:eea3::30<br>
h.gtld-servers.net. 172800 IN A 192.54.112.30<br>
h.gtld-servers.net. 172800 IN AAAA
2001:502:8cc::30<br>
i.gtld-servers.net. 172800 IN A 192.43.172.30<br>
i.gtld-servers.net. 172800 IN AAAA
2001:503:39c1::30<br>
j.gtld-servers.net. 172800 IN A 192.48.79.30<br>
j.gtld-servers.net. 172800 IN AAAA
2001:502:7094::30<br>
k.gtld-servers.net. 172800 IN A 192.52.178.30<br>
k.gtld-servers.net. 172800 IN AAAA
2001:503:d2d::30<br>
l.gtld-servers.net. 172800 IN A 192.41.162.30<br>
l.gtld-servers.net. 172800 IN AAAA
2001:500:d937::30<br>
m.gtld-servers.net. 172800 IN A 192.55.83.30<br>
m.gtld-servers.net. 172800 IN AAAA
2001:501:b1f9::30<br>
;; MSG SIZE rcvd: 1156<br>
<br>
debug: forwarder, ignoring referral from auth zone<br>
debug: auth zone lookup failed, no fallback, servfail<br>
debug: return error response SERVFAIL<br>
debug: mesh_run: iterator module exit state is
module_finished<br>
debug: validator[module 0] operate:
extstate:module_wait_module event:module_event_moddone<br>
info: validator operate: query bbc.com. A IN<br>
debug: validator: nextmodule returned<br>
debug: cannot validate non-answer, rcode SERVFAIL<br>
debug: mesh_run: validator module exit state is
module_finished<br>
debug: query took 0.000000 sec<br>
info: mesh_run: end 0 recursion states (0 with reply, 0
detached), 0 waiting replies, 13 recursion replies sent, 0
replies dropped, 0 states jostled out</blockquote>
<br>
Tried on another node with unbound 1.8.1<br>
<br>
<blockquote type="cite">info: subnet operate: query cnn.com. A
IN<br>
debug: subnet: not found in cache. pass to next module<br>
debug: mesh_run: subnet module exit state is
module_wait_module<br>
debug: validator[module 1] operate:
extstate:module_state_initial event:module_event_pass<br>
info: validator operate: query cnn.com. A IN<br>
debug: validator: pass to next module<br>
debug: mesh_run: validator module exit state is
module_wait_module<br>
debug: iterator[module 2] operate:
extstate:module_state_initial event:module_event_pass<br>
debug: process_request: new external request event<br>
debug: iter_handle processing q with state INIT REQUEST
STATE<br>
info: resolving cnn.com. A IN<br>
debug: request has dependency depth of 0<br>
debug: forwarding request<br>
debug: iter_handle processing q with state QUERY TARGETS
STATE<br>
info: processQueryTargets: cnn.com. A IN<br>
debug: processQueryTargets: targetqueries 0, currentqueries
0 sentcount 0<br>
info: DelegationPoint<.>: 0 names (0 missing), 10
addrs (0 result, 10 avail) parentNS<br>
info: auth_zone . query cnn.com. A, domain
ns-tld5.charlestonroadregistry.com. notexact notexist, ce
com., rrset NS<br>
[1543408434] unbound[28177:2] info: msg from auth zone ;;
->>HEADER<<- opcode: QUERY, rcode: NOERROR, id:
0<br>
;; flags: qr ; QUERY: 1, ANSWER: 0, AUTHORITY: 15,
ADDITIONAL: 26 <br>
;; QUESTION SECTION:<br>
cnn.com. IN A<br>
<br>
;; ANSWER SECTION:<br>
<br>
;; AUTHORITY SECTION:<br>
com. 172800 IN NS a.gtld-servers.net.<br>
com. 172800 IN NS b.gtld-servers.net.<br>
com. 172800 IN NS c.gtld-servers.net.<br>
com. 172800 IN NS d.gtld-servers.net.<br>
com. 172800 IN NS e.gtld-servers.net.<br>
com. 172800 IN NS f.gtld-servers.net.<br>
com. 172800 IN NS g.gtld-servers.net.<br>
com. 172800 IN NS h.gtld-servers.net.<br>
com. 172800 IN NS i.gtld-servers.net.<br>
com. 172800 IN NS j.gtld-servers.net.<br>
com. 172800 IN NS k.gtld-servers.net.<br>
com. 172800 IN NS l.gtld-servers.net.<br>
com. 172800 IN NS m.gtld-servers.net.<br>
com. 86400 IN DS 30909 8 2
E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CFC41A5766<br>
com. 86400 IN RRSIG DS 8 1 86400 20181211050000
20181128040000 2134 .
FeSgJRqqq/LY82e1pAM38Eiu07pepp53zIY23OlA65VDqA4ynhKWb8OvOKiWzHhWbM6KSs/4oXoTPMKn9x3EiWR0L170uKLloALiqbiVi9hJf/fYyRQB9QQPgxUqkkUnDdU7+zfK78BjBlEXgjd+5SfNiE32WKU9i5bP8crQg7J7tC/9FQwcn+eh/kz6pUJ5NVBG6YKkG2Y8YYCsOusOpa67WiRk3bf7DwJUAV6zD6v16TLr0GZesXokZbiwdIqPeJVjLumzLFxVHa+agDb3G2kv2qIjpFw7VPl1Nh/nADyJLdk6tvH5V9xu3MbkUgNcQeAoQG+BrEoRr7xfjKJhTA==
;{id = 2134}<br>
<br>
;; ADDITIONAL SECTION:<br>
a.gtld-servers.net. 172800 IN A 192.5.6.30<br>
a.gtld-servers.net. 172800 IN AAAA
2001:503:a83e::2:30<br>
b.gtld-servers.net. 172800 IN A 192.33.14.30<br>
b.gtld-servers.net. 172800 IN AAAA
2001:503:231d::2:30<br>
c.gtld-servers.net. 172800 IN A 192.26.92.30<br>
c.gtld-servers.net. 172800 IN AAAA
2001:503:83eb::30<br>
d.gtld-servers.net. 172800 IN A 192.31.80.30<br>
d.gtld-servers.net. 172800 IN AAAA
2001:500:856e::30<br>
e.gtld-servers.net. 172800 IN A 192.12.94.30<br>
e.gtld-servers.net. 172800 IN AAAA
2001:502:1ca1::30<br>
f.gtld-servers.net. 172800 IN A 192.35.51.30<br>
f.gtld-servers.net. 172800 IN AAAA
2001:503:d414::30<br>
g.gtld-servers.net. 172800 IN A 192.42.93.30<br>
g.gtld-servers.net. 172800 IN AAAA
2001:503:eea3::30<br>
h.gtld-servers.net. 172800 IN A 192.54.112.30<br>
h.gtld-servers.net. 172800 IN AAAA
2001:502:8cc::30<br>
i.gtld-servers.net. 172800 IN A 192.43.172.30<br>
i.gtld-servers.net. 172800 IN AAAA
2001:503:39c1::30<br>
j.gtld-servers.net. 172800 IN A 192.48.79.30<br>
j.gtld-servers.net. 172800 IN AAAA
2001:502:7094::30<br>
k.gtld-servers.net. 172800 IN A 192.52.178.30<br>
k.gtld-servers.net. 172800 IN AAAA
2001:503:d2d::30<br>
l.gtld-servers.net. 172800 IN A 192.41.162.30<br>
l.gtld-servers.net. 172800 IN AAAA
2001:500:d937::30<br>
m.gtld-servers.net. 172800 IN A 192.55.83.30<br>
m.gtld-servers.net. 172800 IN AAAA
2001:501:b1f9::30<br>
;; MSG SIZE rcvd: 1156<br>
<br>
debug: forwarder, ignoring referral from auth zone<br>
debug: auth zone lookup failed, no fallback, servfail<br>
debug: return error response SERVFAIL<br>
debug: mesh_run: iterator module exit state is
module_finished<br>
debug: validator[module 1] operate:
extstate:module_wait_module event:module_event_moddone<br>
info: validator operate: query cnn.com. A IN<br>
debug: validator: nextmodule returned<br>
debug: cannot validate non-answer, rcode SERVFAIL<br>
debug: mesh_run: validator module exit state is
module_finished<br>
debug: subnet[module 0] operate: extstate:module_wait_module
event:module_event_moddone<br>
info: subnet operate: query cnn.com. A IN<br>
debug: mesh_run: subnet module exit state is module_finished<br>
debug: query took 0.000000 sec<br>
info: mesh_run: end 0 recursion states (0 with reply, 0
detached), 0 waiting replies, 21 recursion replies sent, 0
replies dropped, 0 states jostled out</blockquote>
<br>
<div class="moz-cite-prefix">On 26.11.2018 09:57, Wouter via
Unbound-users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5cc65b2b-48d0-ab3f-763d-ccc869582047@nlnetlabs.nl">
<pre class="moz-quote-pre" wrap="">Hi,
On 10/28/18 7:08 PM, ѽ҉ᶬḳ℠ via Unbound-users wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">the following configuration is known to work with unbound 1.8.x
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Seems it does not make a difference whether it is 1.7.3 or 1.8.x
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">auth-zone:
name: "."
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">The syntax *""* for *name: *is not stipulated in the online
documentation, that is for *auth-zone:*. Why is it being used then?
unbound-checkconf does not report an error either way, i.e. whether it
reads *name: "."* or *name: .*, and the outcome of the query is the same.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> for-downstream: no
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">That does not make sense to me considering the purpose of transferring
the root zone-> "If enabled, unbound serves authority responses to
downstream clients for this zone. This option /makes unbound
behave/, for the queries with names in this zone,/like one of the
authority servers for that zone/."
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">You need the for-downstream: no setting. Because unbound has to be a
mirror for looking up root zone information in the contents. It has the
information, but is not a copy of a root server to its clients, but uses
the information as a copy of the root server information for its own
purposes. Subtly different in wording, but very different in responses.
With for-downstream: yes, you got a referral for .com when queries for
somename.com. And that is exactly what that option does, serve a copy
of that zone.
With for-downstream: no (and for-upstream: yes), unbound should use the
information when recursing to answer user queries. It uses it in
preference to making internet queries, and this means it uses the local
copy to speed up the look ups. That seems to be the option you wanted.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Setting it to *no* is defeating that purpose as a query does not resolve
the SLD either:
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">This does not work either? Is that because you turned off for-upstream
with for-upstream: no? It should be working, with for-downstream: no
and for-upstream: yes, I wonder what went wrong. If the config fixes do
not work for you could you tell me the verbose log of that lookup? The
first result (the .com referral answer you got) tells me that mostly
things a fine, the zone is loaded and data is looked up correctly. But
I thought this would have worked?
Best regards, Wouter
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""># dig bbc.com
; <<>> DiG 9.11.2-P1 <<>> bbc.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34029
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bbc.com. IN A
;; Query time: 5 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Oct 28 18:40:37 CET 2018
;; MSG SIZE rcvd: 36
</pre>
</blockquote>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> for-upstream: yes
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">According to the online documentation this is a default setting and thus
redundant to my understanding.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> fallback-enabled: yes
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Only then the SLD resolves but that renders the transfer of the root
zone redundant, i.e. means there is no apparent benefit/advantage of
having a local the root zone with its delegated TLDs.
The purpose of featuring a local copy of the root zone was that TLD
queries are served locally rather than generating upstream queries to
the NS of the TLD and thus mitigating the amount of upstream queries to
authoritative servers and speed up lookups but also to enhance privacy
for client queries.
</pre>
</blockquote>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</body>
</html>