90% of the times Bind is deployed then named.conf probably could have been:

  options {
      allow-recursion { localhost; localnets; };
  
      forwarders { 1.1.1.1; 8.8.8.8; 4.2.2.2 };
      forward only;
  };

And it would have done the same job the person was looking for. This binds to all interfaces, avoids explicitly respecifying the default paths as a lot of the config lines on the site do, logs what most people care to log to syslog, and forwards requests from any private subnet or the local machine. Alternatively, the distro probably comes with a default file with any distro specific customization you may wish to align to and just needs these 3 lines added.

For the next 8% where people operate "real" dns servers I agree the zone definition syntax is a bit verbose (especially if you're doing many domains or reverse lookup zones) but not necessarily that complicated. The last 2% probably care about all of the syntax that starts to look like mumbo-jumbo which bind documentation focuses on. Oh, I will complain about bind expecting you to manually increment serial numbers in your zonefiles though... but most deployments like this (or even ones acting as the nameserver for some domains) don't actually need that anyways.

No complaints about choosing PowerDNS though. Hard to go wrong with it for this either.

▲ immibis 4 days ago | parent [-]

Do you really want to do forwarding in 2025 when there's all kinds of DNS censorship going on? I'd think you want your DNS server to do the recursive lookup itself.

▲

zamadatix 3 days ago | parent [-]

If you're talking about "censorship from what the forwarder will resolve": You're free to pick any forwarders you'd like (in this case), not just ones that censor, and a forwarder is likely to perform better for most people's use.

If you're talking about "censorship of unencrypted DNS traffic in general": The censorship (or security/privacy risk or whatever your reason for caring it's unencrypted) doesn't care if you're sending traffic to a root nameserver for recursive resolution or traffic to a forwarder. What you need is something like encrypted DNS over another commonly encrypted channel that won't be blocked (e.g. DoH), which actually fits better with using a forwarder since most servers you'll recurse to don't support such transports.

Recursive resolution of public domains is really not as useful as it may sound for most people. The folks it perhaps helps the most are those interested in having the fewest external dependencies in their infrastructure. I have another comment about how to maximize that goal more than just resursing to the public root servers.

	▲	immibis 3 days ago \| parent [-]
		All public resolvers censor - some more than others. That's why you should run your own resolver. If you're already running unbound, just delete your forwarder configuration and it will be a resolver by default (I think).