BIND’s views are a feature some people like using because they allow a single server instance to respond distinctly depending on, say, the source address used to query the instance. I actually quite dislike BIND views because they complicate configuration, and as such I typically advise against using them. (If you’re ever really bored, try configuring AXFR from one view to the other; it’s possible, and it’s horrid. ;-)
Hidden in the depths of the Unbound version 1.6.0 Changelog which I’ve only just looked at, I find the word view. I actually groaned, but I thought I’d give it a peek even so.
Unbound’s views can be used to serve local data depending on the source address a query is received on. Let’s look at a small example:
server:
...
access-control-view: 127.0.0.0/8 intview
local-zone: "aa." static
local-data: "my.aa. IN A 1.1.1.1"
view:
name: "intview"
local-zone: "aa." static
local-data: "my.aa. 90 IN A 2.2.2.2"I define local-zone and local-data globally, so queries to this instance should return the following for my.aa/A:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6565
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
my.aa. 3600 IN A 1.1.1.1
;; Query time: 8 msec
;; SERVER: 192.168.1.130#53(192.168.1.130)The view named intview defines an alternative response, which is used when a query comes in to 127/8, as defined in the access-control-view statement:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14806
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
my.aa. 90 IN A 2.2.2.2
;; Query time: 0 msec
;; SERVER: 127.0.0.2#53(127.0.0.2)There may be multiple view clauses, and options from views matching an access control statement will be used and override global options. On the other hand, global options are used if no matching view is found.
It doesn’t appear to be possible to use views other than for local data, which is fine, if you ask me. :-)
Further reading: