Is BIND9 suitable as a recursive resolver in 2025?(szafka.net)
szafka.net
Is BIND9 suitable as a recursive resolver in 2025?
https://szafka.net/blog/bind9-as-resolver.html
5 comments
BIND9 used to also be the basis for a lot of DNS appliances back in the day, so unless you are running your own recursive server, you might still be running bind, just with a GUI front end.
"Should you ever operate your recursive resolver on only one network? Specifically, should it be limited to the IPv4 or IPv6 network? The general answer for the year 2025 is: NO, you shouldn't."
I wholeheartedly disagree. When given the choice between our ISP's DNS, DNS served by a for-profit company that wants to be a monopoly (such as Cloudflare or Google), or running your own DNSSEC enabled, fully recursive DNS server, you should absolutely run your own, if you're even slightly technical.
If your network is only IPv6, then you already have plenty of issues with general Internet use and should know your caveats. If you're using only IPv4, then you know to run BIND with "-4".
Either way, if you only have one or the other, then you have much more control over what happens when you run your own recursive resolver, regardless of whether it's BIND, Unbound or something else.
The author may've made some money being slightly passive aggressive about running BIND and pretending to not know about "-4", but that's more a self own than a slight on BIND, in my opinion.
I wholeheartedly disagree. When given the choice between our ISP's DNS, DNS served by a for-profit company that wants to be a monopoly (such as Cloudflare or Google), or running your own DNSSEC enabled, fully recursive DNS server, you should absolutely run your own, if you're even slightly technical.
If your network is only IPv6, then you already have plenty of issues with general Internet use and should know your caveats. If you're using only IPv4, then you know to run BIND with "-4".
Either way, if you only have one or the other, then you have much more control over what happens when you run your own recursive resolver, regardless of whether it's BIND, Unbound or something else.
The author may've made some money being slightly passive aggressive about running BIND and pretending to not know about "-4", but that's more a self own than a slight on BIND, in my opinion.
I wholeheartedly disagree.
Same. There are plenty of example configurations for less technical people to stand up their own server. As a bonus they can learn from it with time and also help family members block some malicious sites.
My Unbound daemon talks to the root servers. I keep some DoT I also run on standby and various VPS and rental server providers just in case. Having my own daemon I can log to a ramdisk all the responses and see when apps are doing something dodgy. Despite popular belief here on HN it is trivial to block all the DoH servers despite being on HTTPS 443. Another perk of running my own server is I have full control over caching and blocking of domains. For most sites my response time is sub 0ms.
Sending all the DNS traffic to the big corporate capture servers is bonkers in my view. That allows both the ISP via SNI and the big government created sites to capture everything. ECH support is still very limited outside of Cloudflare. People claim that ISP's tamper with DNS but very few do in first world countries. I empathize with the people that have crap ISP's but mine will behave properly. I also only use IPv4 on my ISP. Even on VPS and rental servers the only role I also use IPv6 is my public authoritative DNS servers. Web and others are just IPv4. It's much easier to block bots having to only deal with one version.
For completeness sake I should also add that Unbound has options to mimick the BIND 8, BIND 9 or Unbound prefetch and retry algorithms.
Same. There are plenty of example configurations for less technical people to stand up their own server. As a bonus they can learn from it with time and also help family members block some malicious sites.
My Unbound daemon talks to the root servers. I keep some DoT I also run on standby and various VPS and rental server providers just in case. Having my own daemon I can log to a ramdisk all the responses and see when apps are doing something dodgy. Despite popular belief here on HN it is trivial to block all the DoH servers despite being on HTTPS 443. Another perk of running my own server is I have full control over caching and blocking of domains. For most sites my response time is sub 0ms.
Sending all the DNS traffic to the big corporate capture servers is bonkers in my view. That allows both the ISP via SNI and the big government created sites to capture everything. ECH support is still very limited outside of Cloudflare. People claim that ISP's tamper with DNS but very few do in first world countries. I empathize with the people that have crap ISP's but mine will behave properly. I also only use IPv4 on my ISP. Even on VPS and rental servers the only role I also use IPv6 is my public authoritative DNS servers. Web and others are just IPv4. It's much easier to block bots having to only deal with one version.
For completeness sake I should also add that Unbound has options to mimick the BIND 8, BIND 9 or Unbound prefetch and retry algorithms.
This article summarize my findings on what I believe to be a buggy recursive algorithm. Main actors: BIND-9.18, BIND-9.20 and wireshark.
I felt this article didn't do a good job of diving into the whys of what was going on. It makes statements without qualification and then blames bind for them. It draws conclusions, then the subsequent sections don't really seem to follow from those conclusions. It also drops pieces of information that end up not having a role in the article at large and that is jarring. (For instance, while the link to Geoff Huston's article is neat, they almost immediately say that nothing in the article was useful to the issue at hand. This would've been better provided as an errata or some other footer style note.)
I know the author found some issues with defaults in bind and definitely some logging bugs, but not everything levied at bind was really its fault. And I didn't feel the tone was fair much of the time.
---
> If you forget to set `forward only;` and relies on the default value, which is `forward first;`, you will fail to meet the requirement of forwarding all queries to the designated forwarders. In such a scenario, BIND9 may intermittently act as a fully recursive resolver for certain queries, and if the firewall is not configured to permit UDP/53 and TCP/53 traffic to the entire internet, then you are out of luck.
I wish the author had expanded a bit more on this. I guess we take it for granted that their previous firewall configuration had allowed outbound UDP connections on port 53 to the targeted upstreams. And that they tried one or the other instead of both simultaneously. I would've like to seem them use tcpdump to analyze why TCP is necessary.
I'm assuming the wide UDP purview is because the target nameservers they query return other DNS servers which bind then recursively queries. So, this requirement doesn't surprise me at all as it does need to talk to more that just the specified IPs. Even the product they recommend, Unbound, would have to be doing something like this. Perhaps maintaining an ongoing allowlist automatically?
I didn't like starting off the article with a complaint against bind9 that's really not its fault.
Later,
> Fortunately, we're witnessing some progress in this regard, with the elimination of annoying lame-servers warnings for the IPv6 network address space, so let's test it again:
Annoying, I feel, is not a good word to use here. The stack doesn't really support IPv6 but it definitely looks like it does. So of course it's going to complain that it can't reach servers you asked it to. This is an example of where I found the tone of the article to be unfair.
> The question is simple: Should you ever operate your recursive resolver on only one network? Specifically, should it be limited to the IPv4 or IPv6 network?
> The general answer for the year 2025 is: NO, you shouldn't.
But up to this point, that's what the author has been doing. They've setup bind to run on IPv4 and IPv6 but not really the latter, instead blackholing all such requests.
---
As the author discovers, their issue revolved around the fact that blackholing counts against request limits and hence the discrepancy between requests and configured limits. I do feel blackholing counting against those metrics is up for discussion, but I can see why some people would expect and want them to count. Perhaps it too needs a configuration flag.
As for the request for separate counters, I think they need separate configuration options with distinct names and not blanket configure both counters identically. I wouldn't expect up to double the requests I specify to be made. But I otherwise think this is a fantastic idea.
bind is a very barebones DNS resolver. It doesn't have the bells and whistles other resolvers have. It's the core technology that more featureful resolvers can build upon. And there's room for improvement and I hope the author's requests get traction.
I know the author found some issues with defaults in bind and definitely some logging bugs, but not everything levied at bind was really its fault. And I didn't feel the tone was fair much of the time.
---
> If you forget to set `forward only;` and relies on the default value, which is `forward first;`, you will fail to meet the requirement of forwarding all queries to the designated forwarders. In such a scenario, BIND9 may intermittently act as a fully recursive resolver for certain queries, and if the firewall is not configured to permit UDP/53 and TCP/53 traffic to the entire internet, then you are out of luck.
I wish the author had expanded a bit more on this. I guess we take it for granted that their previous firewall configuration had allowed outbound UDP connections on port 53 to the targeted upstreams. And that they tried one or the other instead of both simultaneously. I would've like to seem them use tcpdump to analyze why TCP is necessary.
I'm assuming the wide UDP purview is because the target nameservers they query return other DNS servers which bind then recursively queries. So, this requirement doesn't surprise me at all as it does need to talk to more that just the specified IPs. Even the product they recommend, Unbound, would have to be doing something like this. Perhaps maintaining an ongoing allowlist automatically?
I didn't like starting off the article with a complaint against bind9 that's really not its fault.
Later,
> Fortunately, we're witnessing some progress in this regard, with the elimination of annoying lame-servers warnings for the IPv6 network address space, so let's test it again:
Annoying, I feel, is not a good word to use here. The stack doesn't really support IPv6 but it definitely looks like it does. So of course it's going to complain that it can't reach servers you asked it to. This is an example of where I found the tone of the article to be unfair.
> The question is simple: Should you ever operate your recursive resolver on only one network? Specifically, should it be limited to the IPv4 or IPv6 network?
> The general answer for the year 2025 is: NO, you shouldn't.
But up to this point, that's what the author has been doing. They've setup bind to run on IPv4 and IPv6 but not really the latter, instead blackholing all such requests.
---
As the author discovers, their issue revolved around the fact that blackholing counts against request limits and hence the discrepancy between requests and configured limits. I do feel blackholing counting against those metrics is up for discussion, but I can see why some people would expect and want them to count. Perhaps it too needs a configuration flag.
As for the request for separate counters, I think they need separate configuration options with distinct names and not blanket configure both counters identically. I wouldn't expect up to double the requests I specify to be made. But I otherwise think this is a fantastic idea.
bind is a very barebones DNS resolver. It doesn't have the bells and whistles other resolvers have. It's the core technology that more featureful resolvers can build upon. And there's room for improvement and I hope the author's requests get traction.
> But up to this point, that's what the author has been doing. They've setup bind to run on IPv4 and IPv6 but not really the latter, instead blackholing all such requests.
Well, Linux kernel is dual-stacked for more than 30 years now. Every linux VM is dual-stacked unless you deliberatelly disable IPv6 with a kernel boot parameter. And while Linux, and every other modern OS today, is dual-stack, it does not mean that the network you boot Linux with, is dual-stacked. The main criticism is that the algorithm fails to notice that entirely. It is not the "lame-delegation", it is bind9 not being aware of the fact that certain network family is not available, due to outage or just as a starting point.
So while my advice stands, that you should not run any recursive resolver on IPv4 or IPv6 only - sometimes, you have no choice but to do so, as this is the network you are working on. In such cases, this article may help engineers to correctly run bind with either -4 or -6, or abandon it altogether.
Well, Linux kernel is dual-stacked for more than 30 years now. Every linux VM is dual-stacked unless you deliberatelly disable IPv6 with a kernel boot parameter. And while Linux, and every other modern OS today, is dual-stack, it does not mean that the network you boot Linux with, is dual-stacked. The main criticism is that the algorithm fails to notice that entirely. It is not the "lame-delegation", it is bind9 not being aware of the fact that certain network family is not available, due to outage or just as a starting point.
So while my advice stands, that you should not run any recursive resolver on IPv4 or IPv6 only - sometimes, you have no choice but to do so, as this is the network you are working on. In such cases, this article may help engineers to correctly run bind with either -4 or -6, or abandon it altogether.
No