Table of Contents

Networking - DNS - Unbound - Views

Unbound’s views can be used to serve local data depending on the source address a query is received on.

views were introduced in Unbound 1.6.0.

Different Views

view:
    name: "viewname"
    local-zone: "example.com" redirect
    local-data: "example.com A 192.0.2.3"
    local-data-ptr: "192.0.2.3 www.example.com"
    view-first: no
view:
    name: "anotherview"
    local-zone: "example.com" refuse
view:
    name: "evenanotherview"
    local-zone: example.com inform
    local-data: 'example.com TXT "this is an example"'
    local-zone: refused.example.co.uk refuse

NOTE:

  • name must be unique.
  • local-zone configures a local zone.
    • The type determines the answer to give if there is no match from local-data.
      • deny serves local data (if any), else, drops queries.
      • refuse serves local data (if any), else, replies with error.
      • static serves local data, else, nxdomain or nodata answer.
      • transparent gives local data, but resolves normally for other names.
      • redirect serves the zone data for any subdomain in the zone.
      • nodefault can be used to normally resolve AS112 zones.
      • typetransparent resolves normally for other types and other names.
      • inform acts like transparent, but logs client IP address.
      • inform_deny drops queries and logs client IP address.
      • inform_redirect redirects queries and logs client IP address.
      • always_transparent, always_refuse, always_nxdomain, resolve in that way but ignore local data for that name.
      • noview breaks out of that view towards global local-zones.
    • See https://nlnetlabs.nl/documentation/unbound/unbound.conf/.
  • local-data configures local data.
    • The query has to match exactly unless you configure the local-zone as redirect. If not matched exactly, the local-zone type determines further processing.
  • local-data-ptr configures local data shorthand for a PTR record with the reversed IPv4 or IPv6 address and the host name.
  • view-first specifies whether to use Global options if no matching view is found.
    • With view-first yes, it will try to answer using the global local-zone and local-data elements if there is no view specific match.

Override DNS queries for specific clients

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"

NOTE: Here the local-zone and local-data that is defined globally, pointing to 1.1.1.1, would be used for most DNS queries by default.

However, when a query comes in to 127/8, as defined in the access-control-view statement, that would be handled by the intview view, so would point to 2.2.2.2.

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.

NOTE: It does not appear to be possible to use views other than for local data.

References

Bypass pfBlockerNG for specific clients

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

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

https://blog.nlnetlabs.nl/client-based-filtering-in-unbound/