
The Decline and Fall of BIND 10 [pdf] - ook
https://ripe68.ripe.net/presentations/208-The_Decline_and_Fall_of_BIND_10.pdf
======
ChuckMcM
Wow I feel that pain. I designed a replacement for Sun's yellow pages service
called NIS+ and with a couple of awesome engineers got it built and into
production. It changed _everything_ about the old YP. And if there is one
thing system administrators really hate, its change that isn't compatible with
simple mods to their shell scripts. That lead to an interesting effort to make
a NIS+ light which was more like YP.

The evolution of BIND had very similar sorts of challenges it seems. Earlier
version worked new version was all different. So different that their
customers (the system administrators) seem to have revolted. Ouch.

When you are building a part of the infrastructure that lots of people have to
manage to keep the infrastructure running, its a special kind of challenge.
Both in deployment, change management, and service evolution. Even after going
through the process with NIS+ I'm not sure if I could even chart a path for a
replacement BIND.

~~~
mzs
Just want to say thanks, the automounter, nfs, and nis were great in concert.

~~~
dredmorbius
Until they aren't.

Too many hours spent troubleshooting automounter / NFS failures through NIS
and LDAP.

------
sigil
Interesting view into the human elements of a software project.

BIND is one of those programs that scares the living crap out of me, both from
a security perspective and from a complexity perspective. (Gee, could those be
related?)

Just take a look at the list of BIND vulnerabilities. We're still finding em,
and I'm sure we'll continue to for years to come.

[http://www.cvedetails.com/vulnerability-
list/vendor_id-64/pr...](http://www.cvedetails.com/vulnerability-
list/vendor_id-64/product_id-144/ISC-Bind.html)

For a refreshingly simple and secure DNS serving experience, I highly
recommend djbdns / tinydns / dnscache:

[http://cr.yp.to/djbdns/blurb/security.html](http://cr.yp.to/djbdns/blurb/security.html)

~~~
darksim905
If BIND is fairly vulnerable, why does everyone say it's the best/de-facto
standard in Linux/DNS Servers? It's as if you use BIND & only BIND. Is it
really that bad underneath?

~~~
tptacek
I recommend djbdns.

~~~
CrLf
You recommend something that hasn't been maintained in over a decade.
Something that needs all sorts of random patches to still be useful? Random
patches that may or may not introduce random vulnerabilities?

BIND may have had a (really) bad run in the BIND 8 days, but BIND 9 was surely
an improvement.

And if you really want to stay away from BIND, you can go for something like
PowerDNS. Or a combination like PowerDNS+Unbound.

~~~
tptacek
I'm not sure what patches you're saying are required. Most startups don't need
much more than what comes in the box. What's crazy to me is the idea that
they'd opt into BIND 9 preemptively, not knowing what their extended needs
are.

This is, for what it's worth, the original objection to qmail as well ---
"it's not even maintained". It's not maintained because for the core job it
does, it's _correct_. There's not a lot of mail software (at least, not
software written in C) that can make a competing claim.

------
twic

      People Fear & Hate Change
    
      BIND 10 is quite different for administrators
    
      – Lots of dependencies, slow build
      – Lots of processes
      – Tool to configure, not configuration files
    
      People hate change.
    

Do they? Or do they hate things being worse?

Having lots of dependencies can actually be a huge pain. Yes, reusing existing
software is wise. And most of the time, these days, on a modern unix, you're
covered by the package manager. But not always. Someone is going to be
building or installing on some freaky system, or some old version of
something, and every additional dependency is going to be like a red-hot poker
up the fundament. More dependencies is wrose.

Having lots of processes generally does make things harder to manage. Yes,
there are advantages in terms of fault isolation and privilege separation. But
it means that you can't just throw off a quick pgrep to see if the service is
up, you have to worry about _some parts of it being up_. More processes is
worse.

Using a tool to configure something instead of using a file ... nah, i've got
nothing. There's nothing good about configuration tools. I have never come
across a situation where i used a specific tool to configure something and
didn't wish i was just editing a file. Tools for configuration is worse.

I'm sure there are lots of really awesome things about BIND 10. It clearly had
a huge amount of care and attention given to it. But it does sound a bit like
its developers were blind to the need of the system administrators who they
hoped would ultimately install it.

------
Jonanin
I'm curious about this quote on page 21: "Administrators really hate Python.
Really. HATE."

I hadn't heard anything like this before, what is the reasoning here?

~~~
mprovost
One reason is that versioning is really hard. Now that Python comes standard
with Linux distros, and in fact some of the built in tools are written in
Python, it becomes really hard to upgrade. So you can never touch the version
that your OS ships with or you'll break some part of the OS. But those are
usually years behind and developers generally want the new hotness so you end
up installing newer versions elsewhere. There are tools built around this like
virtualenv but you end up with a bunch of different versions of Python
installed in different places, and then installing modules becomes something
that happens outside of your system's package management software so you can't
track dependencies etc. And python itself has really weak package management,
or rather several competing and incompatible systems but you'll download
modules that use each of them so you end up with all of them. At least Ruby
and Perl were able to standardise on one each.

~~~
Aqwis
What are the "several competing and incompatible systems"? I haven't used
anything other than pip, ever. I know of easy_install, but as far as I know
pip is an outright total replacement for it.

~~~
crististm
The tools installed by pip won't usually work with the old versions of Python
found by default on some systems. They break because they want a new Python
feature, and that makes you want to upgrade and that... you can't do that
because it will break dependencies at system level.

And then you want to install a new Python side by side and you sort of do that
but /usr/bin/python still points to the old version and you have to be
explicit with /usr/bin/python2.6 in your scripts. But then some scripts will
work and some still don't and you make /usr/bin/python point to
/usr/bin/python2.6 and now you really broke yum.

And all you can do now is hate python because it gave you all these problems.

~~~
pekk
And I can't imagine what it is like to deploy Java apps if you have no actual
familiarity with the JVM ecosystem, either.

~~~
bronson
What is your point? That administrators really hate Java too?

~~~
thyrsus
This system administrator hates Java almost as much as Windows. I'm still
enraged at the old lie "compile once, run everywhere". Just look at what Java
does to the Red Hat "alternatives" system, although I can't imagine any
prettier body cast around that catastrophe.

~~~
dredmorbius
Reading your comment the irony occurs to me that the best solution to "compile
once" has been real VMs. Not Java VMs, but full god damned fucking virtual
machines running the OS and environment you determine should run in them.

You've _still_ got to provision those, but, well, they're individual and
isolated and tend not to go hammering into one another. Other than consuming
all available system resources.

Oddly: IBM got this right with VM ... 40 years ago?

[https://en.wikipedia.org/wiki/VM_(operating_system)](https://en.wikipedia.org/wiki/VM_\(operating_system\))

------
gjvc
djb is to be commended for his foresight. I always found it depressing that
people would slate him for doing things his own way. I'm reminded of this
quote:

    
    
      "Don't worry about people stealing your ideas.  If your ideas
       are any good, you'll have to ram them down people's throats."
    
            -- Howard Aiken

------
guard-of-terra
I still can't get in my head that writing DNS server is so hard.

Looks so easy on surface. Made me want to write a toy server just to prove
myself.

~~~
IgorPartola
You know, I did actually start writing one recently [1]. It's both more and
less complex than I imagined it. A basic caching resolver, especially in a
reasonably high-level language is not a bad time. I think the complexity
starts coming in when you start keeping a database of authoritative zones,
etc.

If you are writing it in C... things are more complex. All DNS records are
variable length, so you have be damn sure you don't have off by one errors,
etc. Also, proper DNS works over both TCP and UDP so you have to architect it
such that you can work with both. Not knowing anything about the code of BIND,
I can say this would take quite a bit of careful planning to not get wrong. I
can see a whole slew of buffer overflows happening in all these places.

[1]
[https://github.com/ipartola/pulpdns/blob/master/main.py](https://github.com/ipartola/pulpdns/blob/master/main.py)

My idea for this code was to have a DNS server that keeps track of which
domains are the most requested and in the background keeps a thread running to
always keep them in the cache. I noticed that even with a pretty fast
connection my DNS resolver on my LAN can take 100-300 ms to return a name not
in a cache.

~~~
Florin_Andrei
In part, this is due to the fact that features were added to the protocol as
needed - or as it seemed necessary at the moment. I don't think anyone is to
blame, the whole Internet grew like that.

------
nmc
Please note that RIPE archives _everything_ and, as a result, the video is
available:
[https://ripe68.ripe.net/archives/video/153/](https://ripe68.ripe.net/archives/video/153/)

