Questions[unbound](server)

According to https://nlnetlabs.nl/documentation/unbound/unbound.conf/ multiple forwarders can be configured with forward-addr

For the forward zone this list of nameservers is used to forward the queries to. The servers listed as forward-host: and forward-addr: have to handle further recursion for the query.

However there is no statement how these servers are used. Is only the first server queried? Are all simultaniously queried and fastes answer will be sent? Or are they queried in a round robin style? Or another option?

I am trying to use unbound to forward requests to a pair of dns servers, while answering a small hand full of queries locally. In testing this out, I have built the following configuration at /etc/unbound/conf.d/my.zone.com.conf

forward-zone:
    name: "my.zone.com"
    forward-addr: 1.2.3.4   # my DNS server
    forward-addr: 1.2.3.5   # my other DNS server

    local-data: "server1.my.zone.com. IN A 1.2.3.6"

    local-data-ptr: "1.2.3.6 server1.my.zone.com"

When running unbound-checkconf I get the following error:

$ unbound-checkconf
/etc/unbound.conf.d/my.zone.com.conf:8: error: syntax error
read /etc/unbound.conf.d/my.zone.com.conf failed: 1 errors in configuration file
$

My desired behavior is that unbound should forward all requests to the DNS servers 1.2.3.4, and 1.2.3.5, but should respond with local information for server1.my.zone.com.

I have looked through a number of lengthy config file examples on line, but I just don't see what I am doing wrong - though I suspect it has to do with local-data and local-data-ptr nested inside forward-zone.

The config file at /etc/unbound/unbound.conf remains unchanged from the default yum install in centos7.

Thanks in advance for your help

This is my unbound.conf

server:
interface: 0.0.0.0
access-control: 10.0.0.0/8 allow_snoop
access-control: 127.0.0.1 allow_snoop
access-control: 192.168.0.0/16 allow_snoop
...

Reading the documentation, it should be enough. And then in resolv.conf:

nameserver 127.0.0.1

However this does not work. dig gives me

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 41485
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
...
SERVER: 127.0.0.1#53(127.0.0.1)

The problem can be resolved if I add access-control: <internet-ip-address-of-eth0> allow to unbound configuration, but this requires me to put the address into the config file, and that address might change.

Why doesn't this configuration simply make dig query the local server on 127.0.0.1? (Even though it says it did!).

It looks like unbound receives queries on 127.0.0.1, but then tries to respond on the internet ip? (It's from the syslog:)

Jan 11 11:26:28 hostname unbound: [25567:0] info: send_udp over interface: 1 127.0.0.1 127.0.0.1
Jan 11 11:26:39 hostname unbound: [25567:0] info: receive_udp on interface: 1 127.0.0.1 127.0.0.1
Jan 11 11:26:39 hostname unbound: [25567:0] debug: refused query from ip4 35.63.78.210 port 48650 (len 16)

I am trying to configure NSD and Unbound to handle Internal DNS.

I have everything working for forward look ups but reverse looks ups are failing.

I am not sure what to do next, but looking at the dig (reverse) response, it has something to do with my specification of the reverse zone.

"10.in-addr.arpa" vs "57.142.10.in-addr.arpa"

please see the dig output and configuration files below

Dig forward(working):

dig pc01.example.com.au

; <<>> DiG 9.8.3-P1 <<>> pc01.example.com.au
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2821
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;pc01.example.com.au.         IN      A

;; ANSWER SECTION:
pc01.example.com.au. 79883    IN      A       10.142.57.50

;; AUTHORITY SECTION:
example.com.au.       79755   IN      NS      ns1.example.com.au.

;; ADDITIONAL SECTION:
ns1.example.com.au.   79755   IN      A       10.142.57.1

;; Query time: 0 msec
;; SERVER: 10.142.57.1#53(10.142.57.1)
;; WHEN: Tue Nov  1 12:36:38 2016
;; MSG SIZE  rcvd: 91

Dig reverse(not working):

dig -x 10.142.57.50

; <<>> DiG 9.8.3-P1 <<>> -x 10.142.57.50
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24368
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;50.57.142.10.in-addr.arpa.     IN      PTR

;; AUTHORITY SECTION:
10.in-addr.arpa.        10800   IN      SOA     localhost. nobody.invalid. 1 3600 1200 604800 10800

;; Query time: 1 msec
;; SERVER: 10.142.57.1#53(10.142.57.1)
;; WHEN: Tue Nov  1 12:38:25 2016
;; MSG SIZE  rcvd: 102

unbound.conf:

server:
        interface: 10.142.57.1
        interface: 127.0.0.1

        access-control: 0.0.0.0/0 refuse
        access-control: 10.142.57.0/24 allow
        access-control: 127.0.0.0/8 allow

        do-not-query-localhost: no
        hide-identity: yes
        hide-version: yes
        do-ip6: no

        auto-trust-anchor-file: "/var/unbound/etc/root.key"
        root-hints: "/var/unbound/etc/named.cache"

        local-zone: "57.142.10.in-addr.arpa." nodefault

        verbosity: 1

remote-control:
        control-enable: yes
        control-interface: 127.0.0.1

stub-zone:
        name: "example.com.au"
        stub-addr: 127.0.0.1@8053

stub-zone:
        name: "57.142.10.in-addr.arpa."
        stub-addr: 127.0.0.1@8053

nsd.conf:

server:

    server-count: 1 # use this number of cpu cores
    database: "/var/nsd/db/nsd.db"
    zonelistfile: "/var/nsd/db/zone.list"
    username: _nsd
    logfile: "/var/log/nsd.log"
    pidfile: "/var/nsd/run/nsd.pid"
    xfrdfile: "/var/nsd/run/xfrd.state"
    ip-address: 127.0.0.1
    port: 8053

remote-control:
    control-enable: yes

zone:
    name: example.com.au
    zonefile: example.com.au.forward

zone:
    name: 57.142.10.in-addr.arpa
    zonefile: example.com.au.reverse

example.com.au.forward:

$ORIGIN example.com.au.
$TTL 86400
;
@ IN SOA ns1.example.com.au. example.com.au. (
           2016110102  ; serial number
           28800       ; Refresh
           7200        ; Retry
           864000      ; Expire
           86400       ; Min TTL
           )
           IN     NS   ns1.example.com.au.
;
ns1      IN     A    10.142.57.1
pc01     IN     A    10.142.57.50
pc02     IN     A    10.142.57.51
server01 IN     A    10.142.57.254

example.com.au.reverse:

$ORIGIN 57.142.10.in-addr.arpa.
$TTL 86400
;
@ IN SOA ns1.example.com.au. admin.example.com.au. (
           2016110102  ; serial number
           28800       ; Refresh
           7200        ; Retry
           864000      ; Expire
           86400       ; Min TTL
           )
    IN NS ns1.example.com.au.
;
1   PTR ns1.example.com.au.
50  PTR pc01.example.com.au.
51  PTR pc02.example.com.au.
254 PTR server01.example.com.au.

Using BIND RPZs gives me exactly what I'm looking for to alter queries. However, my recursive DNS server is in use by hundreds of clients and I am looking for a way to allow each client some level of customization. There's possibly a couple hundred zones a client might want to enable making for thousands of different possible combinations.

It appears I am limited to 32 RPZ zones (of seemingly infinite length) but that alone won't work -- each user needs the ability to opt-in to specific zones. Even with massive zones for each client it will still hit the 32 limit.

I've looked briefly at Unbound which appears to have a similar sort of RPZ setup with local-data transparency, but the fun seems to have ended when looking for a way to separate things into views so I can only serve them to specific clients.

Surely there's a way to accomplish this without reinventing the wheel? I see commercial providers offering similar setups, like OpenDNS for example where thousands of customers can toggle various lists. What's the secret sauce?