Unbound w/ split dns and adguardhome

Unbound
1

I have what I imagine is an unusual setup I’m trying to get to work. Here’s what I’m looking for:

Request → Unbound [Split DNS] → adguardhome [Ad Block] → Unbound [final resolution].

I have step 1 and 2 working, but having issues with step 3.

server:
  access-control: 127.0.0.1 allow
  access-control: 192.168.8.0/24 allow
  access-control: 10.0.0.0/24 allow
  auto-trust-anchor-file: /var/lib/unbound/root.key
  chroot: ""
  directory: /var/lib/unbound
  do-daemonize: no
  edns-buffer-size: 1232
  harden-dnssec-stripped: yes
  harden-glue: yes
  hide-identity: yes
  hide-version: yes
  interface: 127.0.0.1
  interface: 192.168.8.198
  interface: 10.0.0.5
  ip-freebind: yes
  pidfile: ""
  port: 53
  prefer-ip4: yes
  prefetch: yes
  tls-cert-bundle: /nix/store/cgkz4l4c6l4d76apcjfa8ylvcbixz3py-nss-cacert-3.121/etc/ssl/certs/ca-bundle.crt
  use-caps-for-id: no
  username: ""
access-control-view: 192.168.8.0/24 local
access-control-view: 10.0.0.0/24 wg
forward-zone:
	name: "."
    forward-addr: "127.0.0.1:5335"
view:
  local-data: "mydomain.com. IN A 192.168.8.198"
  local-data: "*.mydomain.com. IN A 192.168.8.198"
  local-zone: "mydomain.com." transparent
  name: local
  view-first: yes
view:
  local-data: "mydomain.com. IN A 10.0.0.5"
  local-data: "*.mydomain.com. IN A 10.0.0.5"
  local-zone: "mydomain.com." transparent
  name: wg
  view-first: yes

What I want to be able to do is set up a third zone that doesn’t forward requests.

I know that I could run a second unbound instance, but due to my usage of NixOS, this is difficult to do and I’d like to avoid it if possible.

Any help would be greatly appreciated. Thanks :slight_smile:

2

Hi @sbrow, not sure I understand what the different steps are.
Also not sure how you could combine the two different Unbounds shown before and after adguardhome.

Another thing, you think you are using wildcard for the local-data but that is not something supported in local data. In this case it is literally <star>.mydomain.com. .

3

Thank you for the note about * not being resolved, I’ll have to update that.

The goal is to have split DNS for my home websites and have adguard.

ATM, unbound is creating views based on the interface the dns request came in on. The problem is, if I configure unbound to forward to adguard, then adguard needs somewhere to resolve from. I want to loop it back to unbound to a view that doesn’t forward and does all its recursion itself.

I could do this by running a second instance of unbound that has no forward zone, but that is a pain. Let me show some examples:

dig mydomain.com @192.168.8.198
  → [unbound@192.168.8.198:53]
  A 192.168.8.198

dig @10.0.0.5 mydomain.com @10.0.0.5
  → [unbound@10.0.0.5:53]
  A 10.0.0.5

# With not ideal setup
dig example.com @192.168.8.198
  → [unbound@192.168.8.198:53]
  → [adguard@127.0.0.1:5335]
  → [unbound2@127.0.0.1:5555]
  A 104.18.27.120

# with ideal setup
dig example.com @192.168.8.198
  → [unbound@192.168.8.198:53]
  → [adguard@127.0.0.1:5335]
  → [unbound@127.0.0.1:53]
  A 104.18.27.120

Hopefully that’s clearer. Sorry if there’s a standard format for displaying DNS traces, I am not a dns wiz :confused:

4

I might be wrong, but I think unbound does not support using views with different data for forwarders. Bind9 can do such thing, but I think unbound can use views only on authoritative data. It has only one shared cache, and therefore it cannot forward one source IP but do not forward another one.

5

Indeed, this is not possible. Views currently only have local data configuration on them.

But regardless of the forwarder issue where you want it enabled/disabled based on view (which is not possible as I replied on the other topic, there are more issues with caching and queries in flight.
There is a single global cache in Unbound, if something is found there adguard will not be contacted to begin with, not sure if this is desired or not.
There would be a weird cyclic dependency on a single query that passes through adguard, for a hypothetical example with a single Unbound for the same query:

client -> unbound -> adguard
adguard -> unbound -> maybe internet?

Unbound would get the incoming query from adguard and see that the same query is already under resolution (from the client) and aggregate the two together. So the second query would wait for the first to complete.
When/If the query would have been resolved, Unbound would reply to both the client and the adguard since the tuple (qname, type, class) would be the same as I understand it. Not a desired behavior as I understand it.

Having two separate Unbounds with clearly distinct roles is the better solution here in my opinion. Also troubleshooting-wise.

There are talks to incorporate more functionality in views but this is something for the future and not a trivial feature request which touches a lot of functionality.

1 Like