<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 14, 2020, at 11:48 AM, Andrew Forgue via Unbound-users <<a href="mailto:unbound-users@lists.nlnetlabs.nl" class="">unbound-users@lists.nlnetlabs.nl</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><br class=""><blockquote type="cite" class="">On Jul 13, 2020, at 11:55 AM, Jan Komissar (jkomissa) <<a href="mailto:jkomissa@cisco.com" class="">jkomissa@cisco.com</a>> wrote:<br class=""><br class="">Hi Andrew,<br class=""><br class="">I believe that stub-zones will not work correctly for +norecurse (RD (recursion desired) flag unset) queries. Also, if your <a href="http://blah.example.com" class="">blah.example.com</a> has delegations to subzones (even on the same server) and you use a non-standard port, you would need a stub-zone for each sub-zone.<br class=""></blockquote><br class="">After restarting unbound, non-recursive queries work fine for several days, until they don't (not sure why). My understanding is that stub_zone presents as if it's local data, and the behavior you're describing would be more like the behavior of a forward zone.<br class=""><br class=""><blockquote type="cite" class="">I would follow Eric's advice to use an auth-zone, either as primary or secondary server (depending on your authoritative requirements).<br class=""></blockquote><br class="">Yeah, Thanks Eric & Jan I'll take a look at that, but I'm not sure the "proxied" dns server can do notifies, but seems to be a good lead.<br class=""></div></div></blockquote><div><br class=""></div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">Just to bump this again -- here's the progress so far. We've been able to reproduce this with auth_zones too.</span></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></span></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">With my limited knowledge of unbound code and gdb it *appears* that in answer_norec_from_cache:</span></div><div><br class=""></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">daemon/worker.c:492 (or so):</span></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br class=""></span></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">answer_norec_from_cache(...) {</span></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">...</span></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>dp = dns_cache_find_delegation(&worker->env, qinfo->qname,</span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><span class="Apple-tab-span" style="white-space:pre"> </span> qinfo->qname_len, qinfo->qtype, qinfo->qclass,</span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><span class="Apple-tab-span" style="white-space:pre"> </span> worker->scratchpad, &msg, timenow);</span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>if(!dp) { /* no delegation, need to reprime */</span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><span class="Apple-tab-span" style="white-space:pre"> </span> return 0;</span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">in the happy case, `dp` is NULL meaning there's no delegation (so it hits return 0), and the correct answer is returned.</span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">In the failure case: `dp` is a delegation point to what looks like the root zones:</span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">--</span></font></div><div><font color="#000000" class=""><div>(gdb) p *dp</div><div>$27 = {name = 0x7f66cc516d58 "", namelen = 1, namelabs = 1, nslist = 0x0, target_list = 0x0, usable_list = 0x0, result_list = 0x0, bogus = 0, has_parent_side_NS = 0 '\000', dp_type_mlc = 0 '\000', ssl_upstream = 0 '\000', auth_dp = 0 '\000', no_cache = 0}</div></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">-- </span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">broken node:</span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div><font color="#000000" class=""><div>dns1 :: ~ » sudo unbound-control lookup <a href="http://blah.example.com" class="">blah.example.com</a></div><div>The following name servers are used for lookup of <a href="http://blah.example.com" class="">blah.example.com</a></div><div>;rrset 17491 13 1 5 2</div><div>. 17491 IN NS <a href="http://c.root-servers.net" class="">c.root-servers.net</a>.</div><div>. 17491 IN NS <a href="http://d.root-servers.net" class="">d.root-servers.net</a>.</div><div>. 17491 IN NS <a href="http://j.root-servers.net" class="">j.root-servers.net</a>.</div><div>. 17491 IN NS <a href="http://e.root-servers.net" class="">e.root-servers.net</a>.</div><div>. 17491 IN NS <a href="http://l.root-servers.net" class="">l.root-servers.net</a>.</div><div>. 17491 IN NS <a href="http://h.root-servers.net" class="">h.root-servers.net</a>.</div><div>. 17491 IN NS <a href="http://f.root-servers.net" class="">f.root-servers.net</a>.</div><div>. 17491 IN NS <a href="http://k.root-servers.net" class="">k.root-servers.net</a>.</div><div>. 17491 IN NS <a href="http://m.root-servers.net" class="">m.root-servers.net</a>.</div><div>. 17491 IN NS <a href="http://i.root-servers.net" class="">i.root-servers.net</a>.</div><div>. 17491 IN NS <a href="http://a.root-servers.net" class="">a.root-servers.net</a>.</div><div>. 17491 IN NS <a href="http://g.root-servers.net" class="">g.root-servers.net</a>.</div><div>. 17491 IN NS <a href="http://b.root-servers.net" class="">b.root-servers.net</a>.</div><div>. 17491 IN RRSIG NS 8 0 518400 20200827170000 20200814160000 46594 . ZxJeYw7vVyjxZg8y7mtt5N3YtejDrho11npxtnjt7MMZm/MlbSErowznceyvXYhTkgF4dJOFGcrUkwFekcN86Zw0tN+cHYYb4lpV2o/pYtXIzo2w2OtA0WJURMB1pWcclhma9y648OiGUsEwImRXpCQS7Mgk+XKU05KFCg5yrFW+UC4faaQ1ZiisVnK9GF8CwsHCC82xT7HU/pAMFgF2vEovsomysMuDhBKE1QTP9MN/DqD6bitdqGmhQSC9GxxcRrNCCU8fSnW4UVIiOJ95kaEMDk0kdpTGowBcKx2WCbXN8oKGSYRpJjE+y77mc2mv3cBUBwK9jnqB86jXwZ7enA== ;{id = 46594}</div><div>Delegation with 13 names, of which 13 can be examined to query further addresses.</div><div>It provides 0 IP addresses.</div><div>cache delegation was useless (no IP addresses)</div></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">Any other help finding out how dns_cache_find_delegation returns the root delegations instead of the auth_zone (in this case <a href="http://example.com" class="">example.com</a> is the auth zone, with a proper zone file on disk)?</span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">-Andrew</span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font><blockquote type="cite" class=""><div class=""><div class=""><br class="">-Andrew<br class=""><br class=""><blockquote type="cite" class="">Regards,<br class=""><br class="">Jan.<br class=""><br class="">On 7/12/20, 12:00 PM, "Unbound-users on behalf of Eric Luehrsen via Unbound-users" <<a href="mailto:unbound-users-bounces@lists.nlnetlabs.nl" class="">unbound-users-bounces@lists.nlnetlabs.nl</a> on behalf of <a href="mailto:unbound-users@lists.nlnetlabs.nl" class="">unbound-users@lists.nlnetlabs.nl</a>> wrote:<br class=""><br class=""> On 7/11/20 11:49 AM, Andrew Forgue via Unbound-users wrote:<br class=""><blockquote type="cite" class="">I have an unbound server that acts as a recursive resolver for clients and also acts as a target for fully delegated DNS (i.e. unbound is the NS record). For the fully-delegated domain it is a simple stub zone with an upstream of localhost on a different port. Let's call it "<a href="http://blah.example.com" class="">blah.example.com</a>".<br class=""><br class="">Occasionally, unbound (has happened on versions 1.10.1 and 1.7.3) will start responding to non-recursive queries with the list of root zones instead of a response from the stub-zone. It seems that clients that use the `rd` flag are fine and continue to be able to resolve records in the stub-zone. Only recursive desired clients will receive correct records from unbound (using the stub server). All records in seemingly all stub zones have this behavior simultaneously.<br class=""><br class="">I don't know what triggers it, but a full restart of unbound is the only thing that fixes it. I've tried flushing cache, flushing infra, and everything, nothing seems to matter. I've seen only 2 things that may point to the issue.<br class=""><br class="">- With verbosity turned up to 10, there's an entry produced in strace (but not in the actual log - maybe a misconfig): "unbound[2213085:5] debug: answer from the cache failed"<br class=""><br class="">- stracing the "broken" unbound process is a very tight recvmsg() (of the request) and sendmsg() (with the root servers) with no syscalls in between.<br class=""><br class="">Again, Using dig with +recurse works all the time, even when unbound gets in this state. So seems like an unbound bug / cache corruption or something?<br class=""></blockquote><br class=""> If it is a bug, you may want to try a work around while waiting for a <br class=""> fix. You could try "auth-zone:" instead of "stub-zone:" or as a <br class=""> companion to "stub-zone:" You may need to give the authoritative server <br class=""> permission for a wholesale zone transfer to the Unbound instance. This <br class=""> may help avoid some undiscovered bug in piecemeal zone recursion.<br class=""> - Eric<br class=""><br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></body></html>