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.)<p>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.<p>---<p>> 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.<p>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.<p>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?<p>I didn't like starting off the article with a complaint against bind9 that's really not its fault.<p>Later,<p>> 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:<p>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.<p>> 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?<p>> The general answer for the year 2025 is: NO, you shouldn't.<p>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.<p>---<p>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.<p>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.<p>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.