Unbound domain overrides stop resolving periodically. They only resume after the service has been restarted.

Raffi_

This may not be the solution you're looking for, but if DNSBLs are what want, that could also be done with a pi hole server. That way you don't have to break a working DNS setup. https://pi-hole.net/

chamilton_ccn

@Raffi_ I may do that, but honestly I'm more intrigued about the behavior of unbound in this scenario. I'd really like an explanation as it doesn't make any sense to me, given my current understanding of how it works.

gtech1

@chamilton_ccn

sorry for bumping an older thread, but I am facing the same exact, daunting issue.
I went through the same steps as you and what I discovered is that if I keep my queries limited just to my own .local domains, unbound keeps on working fine.

The moment I process some other .local domains, unbound appears to break and stops forwarding my own .local domains to my name server.

I tried with both stub and forward, same behavior.

Have you made any other headway ? I'm on version 1.10 by the way

gtech1

@chamilton_ccn
I have found a working fix for the moment.

forward-zone:
name: "local"
forward-addr: 192.168.1.41

I am forwarding all of local tld to my NS which serves my other .local domains and this keeps it from breaking.

chamilton_ccn

@gtech1 Don't apologize! We never found a solution to this. There's a bug report filed here. Also, I want to say we tried that (using just "local" as the domain) but I can't say for certain. I'll take another look.

This:

The moment I process some other .local domains, unbound appears to break and stops forwarding my own .local domains to my name server.

Is highly interesting. Out of more than 10 pfSense deployments, I have three working with unbound and I haven't yet found the difference between those and the other ones that don't work correctly. Maybe this is it. Again, I'll have another look. Thanks for replying to this thread btw. I'll reply back with my findings.

gtech1

It's only when someone tries to resolve another '.local' domain that it breaks. Otherwise I was seeing the same as you, multiple unbound locations, all work fine but one would break at random. The factor was someone resolving another '.local' that I wasn't hosting.

And by the way, you need to add both entries to unbound. yourdomain.local and local itself, both going to your main NS.

Good luck!

Gertjan

Wasn't it some where said that you shouldn't call you domain 'local' ?

Like

chamilton_ccn

@Gertjan Only if you care about mDNS/Avahi/etc. Unfortunately using .local for Active Directory domains is a long established practice and Microsoft is at least partially to blame for this (one example ... there are others). In any case, this fact should not matter with regards to the problem described in this discussion. If anything, it reinforces the idea that the behavior of unbound in this scenario is truly odd -- after all, if .local is never a public TLD, why would any resolver try to resolve a .local domain using public DNS?

gtech1

@chamilton_ccn

indeed, and not only that, why would it forget that it's supposed to resolve the defined domain locally, once it resolves another .local domain. That's the bug we've uncovered

captain calamity

@chamilton_ccn
I know this is a somewhat old thread now, but I think I bumped into the same problem with my architecture which, although different from yours, displayed similar problems. It worked fine for a while and then the resolver would go to the root servers for the forwarded zones.

What worked for me was to mark the forwarded zones as local zones with the "transparent" zone type. So to emulate this you'd be adding something like the following lines to your custom options box:-

server:
local-zone: "domain1.local" transparent
local-zone: "domain2.local" transparent

Since the zones are local, my (limited) understanding is that they get processed before other zone types. In the transparent case, since you have no local entries in the zones anyway, resolution proceeds as it normally should.

I'm on pfSense 2.4.5-p1, unbound 1.10.1.

I do not believe these entries should be at all necessary, but it works for me. I hope that's useful.