[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RES: Exploits start against flaw that could hamstring huge swaths of
- Subject: RES: Exploits start against flaw that could hamstring huge swaths of
- From: morrowc.lists at gmail.com (Christopher Morrow)
- Date: Tue, 4 Aug 2015 12:21:14 -0400
- In-reply-to: <CAMrdfRw1hbUh-qsQUQDZu=jYN-PB2+=3p=3Pp2pVYDa+fzjCcw@mail.gmail.com>
- References: <59E8C16E83D82B439E20698AAC790B5F01384CE23E@ma45> <[email protected]> <CAMrdfRwukydeJCMVALunG0CyqYFU5+7Qy-iXR2TVUvX4Bni9rA@mail.gmail.com> <CAL9jLaaqeQVnoqpKteAMWAWAhhaF7CQOkZvyfmAzy9fyW1=pdA@mail.gmail.com> <CAMrdfRw1hbUh-qsQUQDZu=jYN-PB2+=3p=3Pp2pVYDa+fzjCcw@mail.gmail.com>
On Tue, Aug 4, 2015 at 11:46 AM, Scott Helms <khelms at zcorum.com> wrote:
> Automation just means your mistake goes many more places more quickly.
>
and letting people keep poking at things that computers should be
doing is... much worse. people do not have reliability and
repeat-ability over time.
If you fear 'many more places' problems, improve your testing.
> On Aug 4, 2015 9:38 AM, "Christopher Morrow" <morrowc.lists at gmail.com>
> wrote:
>>
>> On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms <khelms at zcorum.com> wrote:
>> > With the (large) caveat that heterogenous networks are more subject to
>> > human error in many cases.
>>
>> <cough>automate!</cough>
>>
>> > On Aug 4, 2015 9:25 AM, "Joe Greco" <jgreco at ns.sol.net> wrote:
>> >
>> >> > 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.
>> >>