[dns-operations] CVE 2015-8000 actively exploited yesterday

[Jared Mauch]

> On Dec 16, 2015, at 6:50 PM, Nick Urbanik <nick.urbanik at optusnet.com.au> wrote:
> 
> BIND really needs to have a better strategy to dealing with unexpected
> input other than by dying.  Perhaps the assumption is that everyone is
> using some kind of script that checks it's running, and if not,
> restarts it.  If that is the case, that should be explicitly stated,
> and made policy for packagers, such as Red Hat.

I’ve seen a lot of ways to deal with software development in this regard,
the nice thing about an ASSERT or REQUIRE is you know exactly where/why
things failed vs “phantom issue”.

The last one of these I encountered turned out to be an oddity in how
libc worked on a particular OS/release.  Tracking this back took some
extra time, but also was instructive for all involved.

You can always take something like dnsdist and stick it in front of a cluster
of servers, or ask RedHat to package a better init.d/systemd script to respawn
the daemon.  There’s lots of tools out there to handle process watching
so I won’t recommend any specific one.

Leaving it unwatched is something people may consider a serious problem these
days.  I personally like the approach of using dnsdist as you can have it
route queries to a responsive host or port and you can run a diverse set
of daemons, not just BIND.

I generate my config out of a database, so having something output another
format is fairly painless. Maybe that is PowerDNS or NSD or knot.  Lots of
people use BIND because it’s considered the ‘reference implementation’ by
the community.  this is also why when using NTP people use the ntp.org one
vs chrony, OpenNTPD or something else.  (Me, I recommend chrony).

Either way, diversity creates options and building a solution to restart
the daemon is as easy as:

#/bin/bash
while true; do
	/usr/sbin/named -f $OTHER_ARGS
done

- Jared