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.

https://jpmens.net/2016/12/20/unbound-supports-views-for-local-data/

https://medium.com/nlnetlabs/response-policy-zones-in-unbound-5d453de75f26