In my experience with unbound, it tends to return expired records in the hope that they are still valid, causing issues with services hosted in the cloud, where IP addresses rotate regularly. What I did was update the serve-expired-ttl setting in unbound's configuration to 3 hours (down from the default 24h)
this post was submitted on 11 Aug 2025
29 points (93.9% liked)
Selfhosted
50456 readers
342 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
Thanks. I think I might rebuild the pihole-unbound server and try again with this setting.
Any other DNS server I might be able to try?
I use and warmly recommend Technitium DNS. Unlike most other solutions, it uses the root servers by default while still providing an ad blocker, DoH, DoQ etc. - and it does not even require any command-line kung-fu for that (except for the installation, which is one command).
I absolutely second Technitium as well. That thing is rock solid, can be used for basically everything, has blocking with a multitude of options and does provide a nice graphical GUI.
I have it running in a dual DNS setup (main server+a Zimablade nowadays) and that shit just works - it's the container that has caused the least amount of problems in the last 3 years.
The API is fairly handy and quite easy - I have it integrated into HomeAssistant so I have a "Disable DNS Blocking" button in my "Network control" tab in the app.
The only downside is the fact that initially it can be quite overwhelming, especially if you are not an DNS guru and just did the step from AdGuard/PiHole - but soon you realise that you actually only need a few fields for basic operations.
The only downside is the fact that initially it can be quite overwhelming
On the other hand, Technitium comes with a fairly useful configuration straight out of the box. If you only want to use it on your home LAN (and therefore don't necessarily need SSL), the only thing you really need to change is the block list field.
Yeah, absolutely - nevertheless it can inspire that reaction - which is a shame, because it's indeed fairly easy.
I definitely bounced off of it as it had so much configuration I had no idea where to start. Adguard home was so much easier to set up, particularly because I also had to use it via DHCP as my router doesn't have a dns option.
I have it integrated into HomeAssistant so I have a "Disable DNS Blocking" button
I need that. I already have a bunch of physical buttons on my desk, which do things via Home Assistant, so that'd be an obvious one for me to add next.
Just saw that my way of doing this isn't actually needed anymore, there is an integration now:
Works great for me, thanks.
Added a button on my Stream Deck too, which disables blocking on my two Technitium instances for 5 minutes.
When I set up opnsense with unbound I switched on detailed logs, just for checking what's going on and if course I forgot to turn it off, which resulted in horrible overall performance, in particular when the drive filled up and everything broke.
My 2c.
Changing "DNS" won't fix it. There are two DNS: dnsmasq and unbound (and bind, ok). What else you use doesn't matter (pihole, adguard, opnSense) at the end of the day it's always them inside.
In my experience ISPs will block your direct DNS queries overtime, so it might be that. I set up my unbound as caching and forwarding, not as a pure resolver. This fixed all my issues with DNS self hosted. You can forward to 9.9.9.9 if you like it.
Another issue might be with your blocklists of course, your azure might have been temporary listed maybe.
Over time I ended up choosing a very lax blocklist setup due to this reason
In my experience ISPs will block your direct DNS queries overtime,
I have no idea what ISP you're using, but that's probably not true. Lots of devices have hard-coded DNS servers and nothing would work if ISPs stated blocking dns upstream queries.
Above some threshold, the one you will cross when filtering port 53 in your network and setup a custom full resolver, it can happen.
I experienced it, it seems they filter excess dns traffic from inside. Probably more a malware/anti spam measure than an actually DNS blocking.
Even if your ISP did have something in place to try and prevent abuse I find it unlikely it would trigger over normal traffic. Do you have a huge network/many hosts/exposed services?
Just a normal 4 people home, two teenagers tough. Enabling a DNS resolver indeed stop working after a few days while setting it up as forwarder to 1.1.1.1 or 8.8.8.8 or pick yours works just fine.
Maybe it's something else, but when it happens, that's the feel
Not trying to go down a rabbit hole, nor invade your teen's privacy, but have you done any kind of packet inspection on what's going out/in? Teens can surprise you with the kind of stuff they're up to sometimes.
I'm not sure why your resolver started acting up but what you're describing doesn't sound like normal cause/effect. Four people on a residential connection, even if you throw in a ton of electronic devices and iot/crap that calls home constantly shouldn't cause any kind of ISP engagement.
Not like it really matters, for 99.9% of people having a forwarder is easy and just fine and there isn't good reason to troubleshoot it if there's a working solution. I'm pretty privacy conscious and I don't even think having my own forwarder is worth the hassle, I am just choosy about my upstream.
I use pihole with DNS over https (my ISP intercepts my non encrypted DNS queries) works great for me. Both in LXC and Raspberry pi.
What issue are you trying to solve?
I use pfsense as my router os and run pfblockerng for my filter. Anytime I have some problem I can log in to the router and look at what is being blocked and if necessary whitelist the entry that is being blocked.
I also redirect all dns to my router at the firewall and block dns over https. This means that all dns no matter the settings on the client machine are redirected to the router. Its not fool proof but so far so good.
What's the use-case for pihole and unbound together?
Aren't they both DNS servers?
Pi-hole forwards the requests to another DNS server. Unbound can ask the root servers and go down the DNS chain.
Guess I'm not following, both still have to request from other (upstream) DNS servers, so what does unbound add?
Thanks!
Forwarding: just passes the DNS query to another DNS server (e.g. your ISP's). Home routers use forwarding to pass DNS queries from your home network's clients to your ISP's DNS servers. For example, for foo.example.com, a forwarding DNS server would first check its cache (did it already ask this question before), and if the answer is not in its cache, it would ask its forwarder (your ISP's DNS server) for the answer, which would respond with either a cached response, or would perform recursion until it figured out the answer.
Recursion: the DNS server receiving the query takes it upon itself to figure out the answer to that query by recursively querying authoritative DNS servers for that domain. For example, for foo.example.com, a recursor would first query the root servers for what DNS servers are responsible for the .com TLD, then it would ask those servers for example.com, then it would query the servers for example.com for foo.example.com, finally getting the answer to the original query.
Copy-pate from here.
Basically, it remove one middle man from the DNS resolving.
Cool, thanks for the clarification. This is good info to have in here in general.
So unbound by default discovers other DNS servers, if I'm understanding that correctly. I've never used it, does it not use your ISP's DNS by default, or does that depend on user config?
What if your PiHole is configured to use other than your ISP's DNS?
There are 13 root name servers, they container info about which DNS is authorative (can tell you about) a given TLD (like .com or .de) then that repeats for every part of your query with that given server.
Something
^ most of the time the same as.
Foo.
^ DNS for baz or bar dns again.
Bar.
^ DNS for Bar.
Com.
^ DNS server for the .com tld
^ the one unbound asks first, not part of the domain
Giving us the IP of something.foo.bar.com
Though the DNS name would be something.foo.bar.com.
The root server ips are known to unbound and static.
Then it will ask that server? Like I said unbound remove the middle man and somewhat increases privacy (debatable if only you use it but anyway)
Ah, unbound has the root DNS servers hard coded. That's a significant point.
Any reason you couldn't do the same with any other DNS server such as PiHole?
I'm really trying to understand why I'd run two DNS servers in serial, instead of one. All this sounds like it's just a different config that (in the case of unbound) has been built in - is there something else I'm missing that unbound does differently?
Why couldn't you just config the TLD's as your upstream DNS in whatever local DNS server? Isn't that what enterprises do?
Because pi-hole asks the configured DNS the whole domain, the root server will promptly because that's not how DNS is supposed to work.
There's a difference between asking about the individual domain parts of the domain to the corresponding authorative DNS server and just sending the whole thing to a root server. If you did that then the root server would get ddosed to death.
Pi-hole can't ask the root servers, it can only forward. Unbound can forward or be authorative or ask using the root servers and go down the chain or do all of those at once.
If pi hole is configured to use another DNS it will still forward your request, just not to your ISP DNS server. Essentially you're providing your DNS requests to a 3rd party, for a slight boost to performance (because they'll have tons of stuff cached and can do recursive queries faster if you're requesting a site not in their cache.) Your web pages will load faster because you don't have an SBC trying to manually figure out what's the IP for bigfuckdaddyhairbrushemporium.net
The downside is you're exposing your DNS queries to a 3rd party and it's a bit of a privacy hit, as the upstream DNS server you select has your public IP correlated with your DNS requests. Doesn't really matter to most, but it does for some.
Thanks for the clarification.
How is that different than unbound? Isn't it also forwarding requests?
I use Pi-hole, except that I originally retrofitted after setting up DNScrypt years ago to connect to Cisco OpenDNS. That's not the only DNS server you can use with it, though, and it's added more features since.
To use DNScrypt with Pi-hole on the same device, set DNScrypt to listen on 127.0.0.1:54 and point Pi-hole to that as the DNS server.
The only time I have ever had any trouble with this setup and DNS resolution is when the network is recovering from a power outage; there's a race condition somewhere between the Pi and my modem/router that I've never found the time to pin down (given outages are so infrequent I just haven't gotten around to it) and it's easily resolved by rebooting the Pi.
I have tried quite a few and found blocky to be very easy and reliable.
I use multiple DoH servers upstream, it sorts out which ones better response times and uses it more often, but splits them still. I have over 20 devices using it and its been running well.
It also can prefetch common domains and caches them per config. I got A 40% cache rate with running 3 of them for redundancy.
Just normal dnsmasq without fancy web-ui.