A love letter to ISC bind | Hacker News Reader

A love letter to ISC bind

ungleich.ch

49 pointstelmich23 comments

Open articleView on HN

djb would beg to differ:

https://cr.yp.to/djbdns/blurb/unbind.html

[EDIT]: https://www.google.com/search?channel=fs&client=ubuntu&q=bin...

Latest date in djb post is 2002.08.08, and latest bind version mentioned is 9.2.1

Current is 9.17:

https://downloads.isc.org/isc/bind9/cur/

Full history is here:

https://gitlab.isc.org/isc-projects/bind9/-/blob/main/HISTOR...

Anyone familiar with the interim changes, care to synopsize?

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.

For those who might be interested in learning more about using BIND and DNS administration, the ISC are currently running a series of monthly webinars on various aspects of BIND: https://www.isc.org/blogs/bind-management-webinar-series-202...

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.

[1] https://www.knot-dns.cz

[2] https://www.knot-dns.cz/docs/3.0/html/man_knotc.html

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

===

nsupdate -k your.keyfile

server ns.your.zone

update add foo.your.zone. 3600 IN A 1.2.3.4

send

===

You can script it too if you want

Indeed, it's the only way to fly is using DNSSEC

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.

Kept my own BIND 4 patchset and kept it running on the public internet until 2007. Even that version, with its well known flaws, served my needs well.

I wonder how the ratio between "thanks" vs "your software sucks" commentary on the BIND family has been, through the years.

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.

Mine was instrumented up to report what it saw. fun times. it still drew the occasional creative attempt til I shut it down.

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 :)

I wrote this some years ago for my previous job:

https://github.com/imoverclocked/xmdns

Basically, you:

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.

DNSControl (https://dnscontrol.org) supports split horizons as of a few days ago!

https://github.com/StackExchange/dnscontrol/releases/tag/v3....

(and if I do say-so myself... the way we implemented it is pretty darn elegant)

i have found BIND to be troublesome for running large(r) scale workloads.

Also, dealing with zone files just gets annoying, especially compared to DNS servers that support database backends.

I don't like managing a lot of zones, so I wrote a language that outputs zone files: https://dnscontrol.org

I haven't had to run large workloads, but for smaller workloads, having a zone file in version control is so much nicer than fiddling with a database.

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.

Reply on news.ycombinator.com