"view" Behavior Seems Inconsistent With Documentation

[Jeff Kletsky]

TL;DR - Appears resolved in 1.8.0rc1

On 8/30/18 2:08 AM, Wouter Wijngaards via Unbound-users wrote:

> Hi Jeff,
>
> On 08/25/2018 11:53 PM, Jeff Kletsky via Unbound-users wrote:
>> 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.
> It seems what you found it a problem in the code, where this feature
> check is simply missing.  I added such a check, so that zones that are
> transparent have their queries check for content defined outside of
> views with view-first is enabled.  This makes your test cases work.
> Thanks for the report.  It should work with zones that are transparent,
> typetransparent, always-transparent and type inform.
>
> Best regards, Wouter
>
>>
>> [...]
>>
>> 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)
>>
>>
>> [...]
>>
>>
>> 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
>>

Thanks!

I've just tweaked the FreeBSD port to use the 1.8.0rc1 source and new 
library versions and it appears to work as expected.

Version 1.8.0rc1
linked libs: libevent 2.1.8-stable (it uses kqueue), OpenSSL 
1.0.2k-freebsd  26 Jan 2017
linked modules: dns64 respip validator iterator


Jeff