<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>I've read through both the unbound.conf(5) man page and
unbound.conf.sample for unbound Version 1.7.0 many times and am
finding it hard to understand the logic behind how a specific
query is resolved against a view and global data alone, not to
mention my eventual desire to include stub/forwarded zones into
the mix. Most of what an Internet search on views in unbound
discusses Python-driven approaches, not the more recent, native
implementation. <br>
</p>
<p><br>
</p>
<p>First, are there any other resources on how the logic among the
various sources (view local data, view stub/forwarders, global
stub/forwarders, global local data, external authoritative DNS)
for getting an "answer" is intended to work? <br>
</p>
<p>Functional specs, design docs, or a pointer to the code would be
generally helpful. <br>
</p>
<p><br>
</p>
<p>In the minimal test case that returns unexpected results, the
goal is that there is "public" data that all subnets care resolve,
a "private" name that all subnets should get the same value for
(gld.example.com), and another name that a specific subnet should
get a different answer that the other subnets, overriding the
"public" value (maps.example.com). <br>
</p>
<p>(This can be tested by substituting example.com for an
appropriate domain that supports the "maps" host name.)<br>
</p>
<p>As I understand the view-first directive it is "use the view's
local data first, if not present, then check as if the request was
made at the global level". I would expect this to check the global
local data. <br>
</p>
<pre class="man" style="box-sizing: border-box; font-family: fira-mono, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 1rem; overflow: auto; display: block; color: rgb(33, 37, 41); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; background-color: rgb(255, 255, 255); text-decoration-style: initial; text-decoration-color: initial;"> <b style="box-sizing: border-box; font-weight: bolder;">view-first:</b> <i style="box-sizing: border-box;"><yes</i> <i style="box-sizing: border-box;">or</i> <i style="box-sizing: border-box;">no></i>
If enabled, it attempts to use the global local-zone and
local-data if there is no match in the view specific options.
The default is no.
</pre>
<p>Goals:</p>
<p>* most-anything.example.com resolved by public example.com DNS<br>
* gld.example.com resolved by "global, local" data in unbound
(local host names with no public DNS)<br>
* maps.example.com resolved by<br>
* global, local data for many subnets<br>
* view-specific data for some other subnets<br>
</p>
<p>However, when I configure</p>
<p><tt>local-zone: "example.com." typetransparent</tt><tt><br>
</tt><tt><br>
</tt><tt>local-data: "gld.example.com. A 10.0.0.1"</tt><tt><br>
</tt><tt>local-data: "maps.example.com. A 10.0.0.2"</tt><tt><br>
</tt><tt><br>
</tt><tt>access-control-view: 192.168.0.0/24 "classC"</tt><tt><br>
</tt><tt><br>
</tt><tt>view:</tt><tt><br>
</tt><tt> name: "classC"</tt><tt><br>
</tt><tt> view-first: yes</tt><tt><br>
</tt><tt> local-zone: "example.com." typetransparent</tt><tt><br>
</tt><tt> local-data: "maps.example.com. A 192.168.0.2"</tt><br>
</p>
<p><br>
</p>
<p>If I query from an address *not* on the 192.168.0.0/24 subnet,
the results are as expected:</p>
<p><tt><a class="moz-txt-link-abbreviated" href="http://www.example.com">www.example.com</a> (resolved by example.com's DNS)</tt><tt><br>
</tt><tt>gld.example.com 10.0.0.1<br>
maps.example.com 10.0.0.2<br>
</tt></p>
<p><br>
</p>
<p>If I query from an address in the 198.168.0.0/24 subnet ("in" the
view), it looks like the global data isn't consulted for
gld.example.com<br>
</p>
<p><tt><a class="moz-txt-link-abbreviated" href="http://www.example.com">www.example.com</a> (resolved by example.com's DNS)</tt><tt><br>
</tt><tt>gld.example.com NXDOMAIN from example.com's DNS (expected
10.0.0.1 from "global" data)<br>
maps.example.com 192.168.0.2 (as expected from the view)<br>
</tt></p>
<p><br>
</p>
<p>Changing to view-first: no (or omitting it completely) does not
change the behavior.</p>
<p>Changing the view's local-zone to static (thinking that the view
might have tried external resolution before deferring to the
global zone definition) ends up with an NXDOMAIN result for all
but maps.example.com from the unbound instance (no authority
section)..<br>
</p>
<p><tt>view:</tt><tt><br>
</tt><tt> name: "classC"</tt><tt><br>
</tt><tt> view-first: yes</tt><tt><br>
</tt><tt> local-zone: "example.com." static</tt><tt><br>
</tt><tt> local-data: "maps.example.com. A 192.168.0.2"</tt></p>
<p><br>
<tt><tt><a class="moz-txt-link-abbreviated" href="http://www.example.com">www.example.com</a> NXDOMAIN (expected to be resolved by
example.com's DNS)</tt><tt><br>
</tt><tt>gld.example.com NXDOMAIN (expected 10.0.0.1 from
"global" data)<br>
maps.example.com 192.168.0.2 (as expected from the view)</tt></tt></p>
<p><tt><br>
</tt></p>
<p>(Yes, this simple, two-name configuration could be replicated in
the view, but the target operational configuration involves many
more zones, names and views.)<br>
</p>
<p>What am I missing in my thinking, in my configuration?</p>
<p>TIA,</p>
<p>Jeff</p>
<p><br>
</p>
<p>FreeBSD 11.1-RELEASE-p13 #9<br>
</p>
<p>Version 1.7.0<br>
linked libs: libevent 2.1.8-stable (it uses kqueue), OpenSSL
1.0.2k-freebsd 26 Jan 2017<br>
linked modules: dns64 respip validator iterator<br>
<br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>