RES: Exploits start against flaw that could hamstring huge swaths of

Tue Aug 4 15:46:34 UTC 2015

> So, you guys recommend replace Bind for another option ?

No.  Replacing one occasionally faulty product with another occasionally
faulty product is foolish.  There's no particular reason to think that
another product will be impervious to code bugs.  What I was suggesting
was to use several different devices, much as some networks prefer to
buy some Cisco gear and some Juniper gear and make them redundant, or
as a well-built ZFS storage array consists of drives from different
manufacturers.

Heterogeneous environments tend to be more resilient because they are
less likely to all suffer the same defect at once.  Problems still result
in some pain and trouble, but it usually doesn't result in a service
outage.

This doesn't seem like a horribly catastrophic bug in any case.  Anyone 
who is reliant on a critical bit like a DNS server probably has it set 
up to automatically restart if it doesn't exit cleanly.  If you don't,
you should!

So if it matters to you, I suggest that you instead use a combination
of different products, and you'll be more resilient.  If you have two
recursers for your customers, one can be BIND and one can be Unbound. 
And when some critical vuln comes along and knocks out Unbound, you'll 
still be resolving names.  Ditto BIND.  You're not likely to see both
happen at the same time.

However, at least here, we actually *use* TSIG updates, and other 
functionality that'd be hard to replace (BIND9 is pretty much THE only
option for some functionality).

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.