Nice one! I ran both BIND and tinydns. I loved how tinydns only did authoritative DNS, whereas BIND mixed two different servers, with completely different risk profiles: authoritative and resolver.
I am just glad ISC gave up on 'the DNS server written in Python and C++, formerly know as "BIND 10"', now spun off as Bundy (like Ted), and in deep hibernation mode.
For the past 10 years, I’ve been happily using BIND to managing my two personal domains and haven’t encountered any problems. I run the primary (master) name server on my VPS while Gandi provide the secondary server.
If you are looking for an authoritative DNS server with a sane API try KnotDNS [1]. Really easy to automate dynamic updates using `knotc` [2] without worrying about manually updating zone files.
BIND has supported dynamic zones for like 15 years. Declare the zone dynamic, generate a key, apply the key to the zone as authorized to make changes, and then use nsupdate command to make changes
From outsiders point of view DNS is kinda weird and fascinating (and a bit scary). Conceptually simple key-value store, but then there is readily apparent so much complexity that is kinda surprising. So many extensions, edge cases, legacy leftovers, and all sorts of things. Also nice and interesting that there seems to be many high quality foss options to choose from with different flavors.
For a while BIND had a reputation as a Swiss-cheese DNS server.
I think they fixed those issues after a major rewrite. But at least from the security point of view it was considered really bad. Functionally it did the job, but considering that DNS servers are frequently used on the open web, they're still major attack vectors.
The reputation for BIND for a long time was that it was immensely complex because (as the reference implementation) it supported absolutely all the weird corner-case oddities that you could do with DNS. All that code complexity and flexibility came with a huge cost in terms of exploitable bugs and extra "oops, didn't know I had to turn that off" features.
I know coming up the recommendation was always "use something else if you can, use BIND if you have to". It's nice to hear they've improved things to the point that using it doesn't mean tons of extra labor for the security department! On the other hand, that reputation has allowed a lot of other good "supports 75% of everything and 100% of anything you're likely to need" implementations to flourish, which is also good.
Unfortunately, some of BIND's complexity is accidental. BIND took the controversial decision to act both as an authoritative DNS server and a resolver. Yes, they both talk DNS, but their role and risk profile is so different, it would have been better to have two development tracks.
In the old days (90's and earlier), nobody really looked at it that way. The early ISPs I'm familiar with typically ran open resolvers, which happened to also be authoritative DNS servers. I ran BIND as an open resolver for probably 15 years on my home network.
I gotta agree with you - I have been running services on the internet for 13 years now. I learned bind, I loved bind, I didn't think at all about separating what it did. If you knew its config file syntax, you could make it do it all, and easily.
related question - anyone have any nice view-aware ways to deal with zone data? (and ideally, have some API and manage DHCP as well?) hacking together some scripts to export from a database, but would be nicer to use someone elses already-maintained hacked up scripts :)
1) setup a list of views (named.views) and edit the acls to match views based on how your dns servers will see your clients (named.acls)
2) setup a list of ip networks that you are going to resolve (res/db/net_list.xml)
3) modify you hosts with potentially single or multiple networks as necessary (res/db/host_list.xml)
There are some helper scripts in the root of the repo that bring you through the workflow of updating host_list.xml and generating your views.
Some nice things about this: you can set a per-network preference for what networks you try to connect to a host first if the host is multi-homed. This is useful for hopping over local links first and then traversing external hops if necessary.
When I ran it (7 years ago), the model was starting to slow down with several thousand nodes and ~30 networks because I just use xsltproc (command line tool) instead of writing something a little more streamlined.
i kind of agree with you their. but managing zone files when you have a couple of thousand of domains just becomes nearly impossible.
also, lack of an api makes it even harder.
personally I have been very happy with powerdns for a very long time.
BIND works, but IMO is more of a legacy application compared to modern alternatives.
https://cr.yp.to/djbdns/blurb/unbind.html
[EDIT]: https://www.google.com/search?channel=fs&client=ubuntu&q=bin...