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.
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?
Functional specs, design docs, or a pointer to the code would be
generally helpful.
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).
(This can be tested by substituting example.com for an appropriate
domain that supports the "maps" host name.)
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.
*view-first:* /<yes/ /or/ /no>/
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.
Goals:
* most-anything.example.com resolved by public example.com DNS
* gld.example.com resolved by "global, local" data in unbound (local
host names with no public DNS)
* maps.example.com resolved by
* global, local data for many subnets
* view-specific data for some other subnets
However, when I configure
local-zone: "example.com." typetransparent
local-data: "gld.example.com. A 10.0.0.1"
local-data: "maps.example.com. A 10.0.0.2"
access-control-view: 192.168.0.0/24 "classC"
view:
name: "classC"
view-first: yes
local-zone: "example.com." typetransparent
local-data: "maps.example.com. A 192.168.0.2"
If I query from an address *not* on the 192.168.0.0/24 subnet, the
results are as expected:
www.example.com (resolved by example.com's DNS)
gld.example.com 10.0.0.1
maps.example.com 10.0.0.2
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
www.example.com (resolved by example.com's DNS)
gld.example.com NXDOMAIN from example.com's DNS (expected 10.0.0.1
from "global" data)
maps.example.com 192.168.0.2 (as expected from the view)
Changing to view-first: no (or omitting it completely) does not change
the behavior.
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)..
view:
name: "classC"
view-first: yes
local-zone: "example.com." static
local-data: "maps.example.com. A 192.168.0.2"
www.example.com NXDOMAIN (expected to be resolved by example.com's DNS)
gld.example.com NXDOMAIN (expected 10.0.0.1 from "global" data)
maps.example.com 192.168.0.2 (as expected from the view)
(Yes, this simple, two-name configuration could be replicated in the
view, but the target operational configuration involves many more zones,
names and views.)
What am I missing in my thinking, in my configuration?
TIA,
Jeff
FreeBSD 11.1-RELEASE-p13 #9
Version 1.7.0
linked libs: libevent 2.1.8-stable (it uses kqueue), OpenSSL
1.0.2k-freebsd 26 Jan 2017
linked modules: dns64 respip validator iterator
