Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica
Everyone got BIND updated? http://arstechnica.com/security/2015/08/exploits-start-against-flaw-that-could-hamstring-huge-swaths-of-internet/ -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica
On Tue, Aug 04, 2015 at 10:03:33AM -0400, Jay Ashworth wrote a message of 6 lines which said: > Everyone got BIND updated? For instance by replacing it with NSD or Unbound?
Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica
On Tue, Aug 4, 2015 at 10:17 AM, Stephane Bortzmeyer wrote: > On Tue, Aug 04, 2015 at 10:03:33AM -0400, > Jay Ashworth wrote > a message of 6 lines which said: > >> Everyone got BIND updated? > > For instance by replacing it with NSD or Unbound? always great to jump ship from one platform to another ... under stress and without knowing scaling, management, etc properties. Also, it's not like the alternatives have clean shorts when it comes to code mistakes, right?
Re: Exploits start against flaw that could hamstring huge swaths of
> On Tue, Aug 04, 2015 at 10:03:33AM -0400, > Jay Ashworth wrote > a message of 6 lines which said: > > > Everyone got BIND updated? > > For instance by replacing it with NSD or Unbound? Or doing something better like not just replacing one evil with another, and instead moving to a heterogeneous environment where possible. ... 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.
RES: Exploits start against flaw that could hamstring huge swaths of
So, you guys recommend replace Bind for another option ? -Mensagem original- De: NANOG [mailto:nanog-boun...@nanog.org] Em nome de Joe Greco Enviada em: terça-feira, 4 de agosto de 2015 12:01 Para: Stephane Bortzmeyer Cc: nanog@nanog.org Assunto: Re: Exploits start against flaw that could hamstring huge swaths of > On Tue, Aug 04, 2015 at 10:03:33AM -0400, Jay Ashworth > wrote a message of 6 lines which said: > > > Everyone got BIND updated? > > For instance by replacing it with NSD or Unbound? Or doing something better like not just replacing one evil with another, and instead moving to a heterogeneous environment where possible. ... 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.
Re: Exploits start against flaw that could hamstring huge swaths of
On Tue, Aug 4, 2015 at 11:06 AM, Leonardo Oliveira Ortiz wrote: > So, you guys recommend replace Bind for another option ? The humorous thing is that the security researcher who showed the recent bind9 error (note: it isn't a vulnerability or a hack, it's just a way to remotely crash named), well, he criticized bind9 for doing more than simple basic name services. So, it's very easy to find bind9 alternatives if you are only looking for basic minimal DNS functionality. But once you start looking for features... well there aren't many options. -Jim P.
Re: RES: Exploits start against flaw that could hamstring huge swaths of
> 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.
Re: RES: Exploits start against flaw that could hamstring huge swaths of
With the (large) caveat that heterogenous networks are more subject to human error in many cases. On Aug 4, 2015 9:25 AM, "Joe Greco" 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. >
Re: RES: Exploits start against flaw that could hamstring huge swaths of
On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms wrote: > With the (large) caveat that heterogenous networks are more subject to > human error in many cases. automate! > On Aug 4, 2015 9:25 AM, "Joe Greco" 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. >>
Re: RES: Exploits start against flaw that could hamstring huge swaths of
On Tue, 04 Aug 2015 15:06:36 -, Leonardo Oliveira Ortiz said: > So, you guys recommend replace Bind for another option ? The *good* recommendation is to get some onboard security clue, and learn procedures to mitigate the inevitable exploits against flaws in infrastructure software. pgproCq1JbkNP.pgp Description: PGP signature
Re: RES: Exploits start against flaw that could hamstring huge swaths of
Automation just means your mistake goes many more places more quickly. On Aug 4, 2015 9:38 AM, "Christopher Morrow" wrote: > On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms wrote: > > With the (large) caveat that heterogenous networks are more subject to > > human error in many cases. > > automate! > > > On Aug 4, 2015 9:25 AM, "Joe Greco" 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. > >> >
Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica
I recommend using DNSDIST to balance traffic at a protocol level as you can have implementation diversity on the backside. I can send an example config out later for people. You can balance to bind NSD and others all at the same time :-) just move your SPoF Jared Mauch > On Aug 4, 2015, at 10:03 AM, Jay Ashworth wrote: > > Everyone got BIND updated? > > http://arstechnica.com/security/2015/08/exploits-start-against-flaw-that-could-hamstring-huge-swaths-of-internet/ > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: RES: Exploits start against flaw that could hamstring huge swaths of
On Tue, Aug 4, 2015 at 11:46 AM, Scott Helms 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" > wrote: >> >> On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms wrote: >> > With the (large) caveat that heterogenous networks are more subject to >> > human error in many cases. >> >> automate! >> >> > On Aug 4, 2015 9:25 AM, "Joe Greco" 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. >> >>
Re: RES: Exploits start against flaw that could hamstring huge swaths
> With the (large) caveat that heterogenous networks are more subject to > human error in many cases. Indeed. Everything comes with tradeoffs. More intimate familiarity with the product and a uniformity of deployment strategy has made it more practical here to stick with BIND; an update is a simple matter of a tarball and running a script that manages the dirty work. However, the original point was that switching from BIND to Unbound or other options is silly, because you're just trading one codebase for another, and they all have bugs. However, collectively, two different products cooperatively providing a service are likely to have a higher uptime in a well-designed environment. ... 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.
Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica
In message <9c2aca5a-755d-4fcf-8491-745a1f911...@puck.nether.net>, Jared Mauch writes: > I recommend using DNSDIST to balance traffic at a protocol level as you can h= > ave implementation diversity on the backside.=20 > > I can send an example config out later for people. You can balance to bind N= > SD and others all at the same time :-) just move your SPoF > > Jared Mauch Unless the same client hits the same server all the time this is a bad idea. Resolvers actually track capabilities of servers as it is the only way to get answers due to firewalls dropping legitimate packet and protocol misimplementations. Add to that different vendors / versions supporting different extensions randomly flipping between vendors / versions is frought with danger unless you take extreme care. > > On Aug 4, 2015, at 10:03 AM, Jay Ashworth wrote: > > > > Everyone got BIND updated? > > > > > http://arstechnica.com/security/2015/08/exploits-start-against-flaw-that-c > ould-hamstring-huge-swaths-of-internet/ > > -- > > Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica
On Tue, Aug 4, 2015 at 9:39 AM, Mark Andrews wrote: > In message <9c2aca5a-755d-4fcf-8491-745a1f911...@puck.nether.net>, Jared > Mauch writes: > > I recommend using DNSDIST to balance traffic at a protocol level as you > can h= > > ave implementation diversity on the backside.=20 > > > > I can send an example config out later for people. You can balance to > bind N= > > SD and others all at the same time :-) just move your SPoF > > Unless the same client hits the same server all the time this is a > bad idea. > But tying a set of clients to the same backend puts them all in the same failure domain Resolvers actually track capabilities of servers as it is the only > way to get answers due to firewalls dropping legitimate packet and > protocol misimplementations. Add to that different vendors / > versions supporting different extensions randomly flipping between > vendors / versions is frought with danger unless you take extreme > care. Out of curiosity, do any resolvers other than BIND do this? I ask because BIND has a reputation for having "too many" features, and I wonder if this is one of them. Damian > > On Aug 4, 2015, at 10:03 AM, Jay Ashworth wrote: > > > > > > Everyone got BIND updated? > > > > > > > > > http://arstechnica.com/security/2015/08/exploits-start-against-flaw-that-c > > ould-hamstring-huge-swaths-of-internet/ > > > -- > > > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >
Re: RES: Exploits start against flaw that could hamstring huge swaths
On 4 August 2015 at 18:48, Joe Greco wrote: > However, the original point was that switching from BIND to Unbound > or other options is silly, because you're just trading one codebase > for another, and they all have bugs. It is equally silly to assume that all codebase are the same quality and have equally many bugs. Maybe we should be looking at the track record of those two products and maybe we should let someone do a code review. And then choose based on that. Regards, Baldur
Re: RES: Exploits start against flaw that could hamstring huge swaths of
- Original Message - > From: "Scott Helms" > On Aug 4, 2015 9:38 AM, "Christopher Morrow" > wrote: > > > On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms > > wrote: > > > With the (large) caveat that heterogenous networks are more > > > subject to human error in many cases. > > > > automate! > Automation just means your mistake goes many more places more quickly. Not necessarily. The sort of failure you're talking about, Scott, is "user did the wrong thing", and sure, automation makes it easier for that to spread. Chris was, though, I think, suggesting automating around "user tries to do the right thing on disjoint devices, and fails *because they're disjoint*"; that is, clearly, a problem automation can help with. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: RES: Exploits start against flaw that could hamstring huge swaths of
I don't disagree, but automation usually protects against typing errors, it doesn't protect against incorrect configurations. Using multiple vendors or server software means that your people have to know all of the systems. There are many cases where, for example, a Cisco like CLI will make a network engineer think that a command works exactly the same way on another vendors system when in fact the under the hood implementation is very different. It's not always feasible to have the people with the needed skill levels and automation does not help that at all. On Aug 4, 2015 10:21 AM, "Christopher Morrow" wrote: > On Tue, Aug 4, 2015 at 11:46 AM, Scott Helms 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" > > wrote: > >> > >> On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms wrote: > >> > With the (large) caveat that heterogenous networks are more subject to > >> > human error in many cases. > >> > >> automate! > >> > >> > On Aug 4, 2015 9:25 AM, "Joe Greco" 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. > >> >> >
Re: [BULK] Verizon exiting California
> On Aug 3, 2015, at 10:09, Matthew Black wrote: > > I ran a few Google searches and came across a trove of complaints against > Frontier. Seems they are far worse than GTE/Verizon. On the few occasions I > have called for FIOS support, always reached someone knowledgeable and > helpful. Not looking forward to the changeover, as the new owners have to pay > off debts from their acquisition. That can only be accomplished through rate > increases. I see a Verizon tech outside my kitchen window every two to three > days as he replaces two nitrogen tanks keeping copper trunks pressurized > against water intrusion. Cutting expenses is another (well, and selling more too). Properly engineered/maintained cable should not require that level of constant attention.
Re: Exploits start against flaw that could hamstring huge swaths of
On 4 Aug 2015, at 23:21, Christopher Morrow wrote: 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. I've personally never come across an accidental route hijack (of the subset of which I learned the actual details of what happened) that wasn't the result of someone manually typing at the enable prompt. --- Roland Dobbins
Re: RES: Exploits start against flaw that could hamstring huge swaths
On Tue, Aug 4, 2015 at 12:51 PM, Baldur Norddahl wrote: > On 4 August 2015 at 18:48, Joe Greco wrote: > >> However, the original point was that switching from BIND to Unbound >> or other options is silly, because you're just trading one codebase >> for another, and they all have bugs. > > > It is equally silly to assume that all codebase are the same quality and > have equally many bugs. Maybe we should be looking at the track record of > those two products and maybe we should let someone do a code review. And > then choose based on that. because: 1) historical results matter here? (who looked at which products over what period of time, with what attention to detail(s) and which sets of goals?) 2) the single person doing a code review is likely to see all of the problems in each of the products selected? nothing against any of the software in question here, but really this is all quite a crapshoot and past transgression research doesn't make for a great tool to plan for the future. Joe's right: "all software has bugs, find the software and strategy that makes sense for your organization" that MIGHT mean 2 platforms (seems sensible to me!) and it might mean automation for management of configs (from an abstraction so you can generate the right data to each target implementation) or it might mean more monkeys on keyboards if you don't believe in automation. -chris
Re: RES: Exploits start against flaw that could hamstring huge swaths of
hi ya > >> On Tue, Aug 4, 2015 at 11:29 AM, Scott Helms wrote: > >> > With the (large) caveat that heterogenous networks are more subject to > >> > human error in many cases. > >> > >> automate! > >> ... On 08/04/15 at 12:21pm, Christopher Morrow wrote: > On Tue, Aug 4, 2015 at 11:46 AM, Scott Helms 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. ditto ... computers are experts at listening and repeatatively doing what it's told to do .. > If you fear 'many more places' problems, improve your testing. i prefer automation .. even if it's wrong, you can look at the script and see what bad things it did and you should know what to do to fix the problem and fix the script to prevent it from spreading that mistake again if you ask a person(s), what did you do to create this mess, "duh... i donno" btw, it's my kids birthday, i needed to be home an hr ago with the cake :-) hummm... :-) - for automation to work: - folks updating the scripts should be required to know all platforms being used and how its different from each other - folks testing the scripts/updates process/proceedures should be paid bonuses, even free pizza/beer for finding bugs before release to the your internal world of automated-machines - always have 3 co-developments boxes for the script develpment and to backup each other - always have 2 or more test bed boxes for initial releases of new scripts where those boxes can also be downgraded back to the previous release before the new patches was applied - if nothing went wrong, there should be minimal issue with release a patch where it doesn't propagate "problems automatically to everywhere" the trick is "how good are the eyes/brains" that is looking for potential problems of the new releases/patches/updates/etc - i also say always let clients pull down patches vs pushing it to systems that seems un-responsive to avoid having to wait for dead boxes - all appps, not just bind, has occasional problems .. changing to something else doesn't necessarily solve the original "bug" problem pixie dust alvin # ddos-mitigator.net
Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica
Hi Jared, On 4 Aug 2015, at 12:00, Jared Mauch wrote: I recommend using DNSDIST to balance traffic at a protocol level as you can have implementation diversity on the backside. I can send an example config out later for people. You can balance to bind NSD and others all at the same time :-) just move your SPoF As someone who once hosted TLD zones in a way that a query to a particular nameserver could be answered by either NSD or BIND9, my advice would be "don't do that". You're setting yourself up for troubleshooting hell. You can include different nameservers in the set for a single zone. Using different software for different nameservers can be sensible. Using different software for the same nameserver can be a nightmare. Joe
Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica
On Wed, Aug 05, 2015 at 02:39:18AM +1000, Mark Andrews wrote: > > In message <9c2aca5a-755d-4fcf-8491-745a1f911...@puck.nether.net>, Jared > Mauch writes: > > I recommend using DNSDIST to balance traffic at a protocol level as you can > > h= > > ave implementation diversity on the backside.=20 > > > > I can send an example config out later for people. You can balance to bind > > N= > > SD and others all at the same time :-) just move your SPoF > > > > Jared Mauch > > Unless the same client hits the same server all the time this is a > bad idea. Software that can't handle the remote side having a upgrade/downgrade/capability change is broken. > Resolvers actually track capabilities of servers as it is the only > way to get answers due to firewalls dropping legitimate packet and > protocol misimplementations. Add to that different vendors / > versions supporting different extensions randomly flipping between > vendors / versions is frought with danger unless you take extreme > care. I've come to use DNSDist to workaround the problems that BIND has with outstanding queries which don't get a response. You might be surprised how poorly BIND performs if you use something else to take a look at it from the exterior. http://puck.nether.net/~jared/dnsdist.png The first two are BIND the 3rd is not and the 4th is BIND. The last 3 get the same types of queries, notice how BIND drops lots of queries. I don't have time to report all the DNS related issues on bind-users/dev but you may find it helpful to use a tool like this to at least identify what is going on. The last 3 servers get only domains like arpa and a few well known domains, eg: gmail. - Jared > > > On Aug 4, 2015, at 10:03 AM, Jay Ashworth wrote: > > > > > > Everyone got BIND updated? > > > > > > > > http://arstechnica.com/security/2015/08/exploits-start-against-flaw-that-c > > ould-hamstring-huge-swaths-of-internet/ > > > -- > > > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica
On Tue, Aug 04, 2015 at 01:48:56PM -0400, Joe Abley wrote: > Hi Jared, > > On 4 Aug 2015, at 12:00, Jared Mauch wrote: > > >I recommend using DNSDIST to balance traffic at a protocol level as you > >can have implementation diversity on the backside. > > > >I can send an example config out later for people. You can balance to bind > >NSD and others all at the same time :-) just move your SPoF > > As someone who once hosted TLD zones in a way that a query to a particular > nameserver could be answered by either NSD or BIND9, my advice would be > "don't do that". You're setting yourself up for troubleshooting hell. I'm not suggesting you have an unpredictable set of things you route queries to. I have a very simple config I'll share with you off-list. One should route things in a predictable manner. This is why people want operators who can code and operate a service vs just operate it, or just code. Those are the people in the highest demand in my narrow experience. > You can include different nameservers in the set for a single zone. Using > different software for different nameservers can be sensible. Using > different software for the same nameserver can be a nightmare. Proper logging and instrumentation is essential. DNSDIST can be configured to fail over to something else while one server or daemon is offline and being serviced or restarted. This can also be done with other tools like "stupid routing tricks" aka anycast. For a resolver I want to "just work" for servers that need to do e-mail etc this works well for me. The fact I can have it point to a BIND process on localhost on a different port, or nsd, etc.. provides flexability that others don't do as easily. - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: RES: Exploits start against flaw that could hamstring huge swaths of
Wow this thread went off-track in nanoseconds. So which bind versions are ok? -b
Re: RES: Exploits start against flaw that could hamstring huge swaths of
On Tue, 04 Aug 2015 15:54:53 -0400, Barry Shein said: > > Wow this thread went off-track in nanoseconds. > > So which bind versions are ok? This week's. pgpakL0r72_lt.pgp Description: PGP signature
RE: multipath tcp now in production use for linux based mobile devices
So, obviously, MPTCP can cause problems with Stateful Firewalls (as in asymmetric routing, out of state packets, etc.). Cisco's take on how to deal with MPTCP is just as interesting as MPTCP itself is. http://www.cisco.com/c/en/us/support/docs/ip/transmission-control-protocol-tcp/116519-technote-mptcp-00.html Yep, for regular ASAs they advise you to let everything with option 30 set in the header have a free pass to your network (turn off NOOP replacement of option 30 in TCP headers via a tcp-map)... and btw, turn off packet inspection. For ASA-X "next generation" firewalls with modern code levels, this behavior seems to be default, although it looks like you can have your packet inspection as well. --p -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Colin Johnston Sent: Saturday, August 01, 2015 1:45 AM To: nanog@nanog.org list Subject: [EXTERNAL]multipath tcp now in production use for linux based mobile devices http://blog.multipath-tcp.org/blog/html/2015/07/24/korea.html
Re: Exploits start against flaw that could hamstring huge swaths of
On 4 Aug 2015, at 15:54, Barry Shein wrote: Wow this thread went off-track in nanoseconds. So which bind versions are ok? 9.10.2-P3 is marked "current stable", and 9.9.7-P2 is marked "current-stable ESV" at: https://www.isc.org/downloads/ The bind-users is probably a place where this kind of thread would at least go off-track in a different set of ways: https://lists.isc.org/mailman/listinfo/bind-users Joe
Re: multipath tcp now in production use for linux based mobile devices
"Darden, Patrick" writes: > So, obviously, MPTCP can cause problems with Stateful Firewalls (as > in asymmetric routing, out of state packets, etc.). Cisco's take on > how to deal with MPTCP is just as interesting as MPTCP itself is. ... It's not so much the statefulness of the firewall that's the problem, it's that if the firewall wants to work at higher layers than TCP, in particular at the TLS layer, it can't because it doesn't have all the data. Operators should probably consider that if they block or disable MPTCP, the device using it might decide that network is broken or not currently available to it for that service, and prefer its other interface bypassing the firewall entirely.
Re: RES: Exploits start against flaw that could hamstring huge swaths
Den 04/08/2015 19.18 skrev "Christopher Morrow" : > > On Tue, Aug 4, 2015 at 12:51 PM, Baldur Norddahl > wrote: > > On 4 August 2015 at 18:48, Joe Greco wrote: > > > >> However, the original point was that switching from BIND to Unbound > >> or other options is silly, because you're just trading one codebase > >> for another, and they all have bugs. > > > > > > It is equally silly to assume that all codebase are the same quality and > > have equally many bugs. Maybe we should be looking at the track record of > > those two products and maybe we should let someone do a code review. And > > then choose based on that. > > because: > 1) historical results matter here? (who looked at which products > over what period of time, with what attention to detail(s) and which > sets of goals?) > 2) the single person doing a code review is likely to see all of the > problems in each of the products selected? > Maybe not but a code review can tell what methods are used to safe guard against security bugs, the general quality of the code, the level of automated testing etc. History can give hints to the same. If it had a lot of bugs discovered it is likely it is not good quality in a security perspective and more bugs can be expected. It is called due diligence. The aim is not to find the bugs but to evaluate the product. Regards Baldur
Re: Mac compatible SFP+/XFP programmer
I can attest to the quality of the Flexbox. It is fantastic! All of our employees have Mac's and they work great. Originally you had to use Java in FireFox to make it work, but they now have a "Chrome app" that works in Chrome which is even easier (don't have to get the right Java version loaded and click through a million security warnings). The workflow for how the box works is fantastic- You just go to their website and plug in the box and the UI is fully web based. The benefit here is that they are constantly updating different programming profiles for different manufacturer quirks. As soon as they make a change, it is available to you from the UI. If you run into any issues with optic compatibility, they can whip up a new profile and have it available immediately (not that I have actually had any issues, but I did have them add some XFP MRV profiles for me). It will also show you the history of any optic you have programmed which is nice I guess. The down side is naturally that I think it only works with their branded optics and also they are in control (i.e. if they decide to discontinue the service, or if you have no net access you are out of luck, but come on, we are all network engineers - finding Internet is not exactly hard). ;-) -Eric On Fri, Jul 31, 2015 at 8:57 AM, Eriks Rugelis wrote: > A couple of months ago I purchased a Flexbox V3 and a pile of SFP and SFP+ > for $dayjob. The parts arrived in less than a week and the Flexbox V3 > (and webapp) works well with our Macs. > > We are a satisfied customer. > > Eriks > --- > Eriks Rugelis > Sr. Consultant > Netidea Inc. > T: +1.416.876.0740 > > > On Jul 30, 2015, at 14:48, Youssef Bengelloun-Zahr > wrote: > > > > Hi, > > > > Flexoptics seems to do the trick but via a Web browser : > > > > https://www.flexoptix.net/en/flexbox-v3-transceiver-programmer.html > > > > From what I've heard, this thing does the Job. > > > > Best regards. > > > > > > > >> Le 30 juil. 2015 à 20:28, Jason Lixfeld a écrit : > >> > >> Does anyone know where I might find a SFP+/XFP programmer with a Mac > compatible programmer application? > >> > >> Thanks! > > > -- *Eric Rosenberry* Principal Infrastructure Architect // Chief Bit Plumber
DropBox peering issue in SF bay area ? Rare and Odd
Anyone from dropbox please contact n...@fiberinternetcenter.com Multiple peering session - peering sessions are up/established - prefixes are received - but no website and customers complaining to us. Thank You Bob Evans CTO
RE: [BULK] Verizon exiting California
I don't live in a new suburban community with modern utilities. Well, the 50 year-old water main on my street was replaced about 10 years ago. We haven't suffered major flooding like UCLA experienced last year. My house was built in 1930. Much of that telco copper is pushing 70 years old or more. Some is above ground and some is underground. Until recently, the underground vault would flood whenever it rained. The b-box uses screw-type terminals, not even 66 or BIX. Thank you GTE. matthew black california state university, long beach -Original Message- From: Andrew Carey [mailto:ca...@ar-ballbat.org] Sent: Tuesday, August 04, 2015 10:02 AM To: Matthew Black Cc: nanog@nanog.org Subject: Re: [BULK] Verizon exiting California > On Aug 3, 2015, at 10:09, Matthew Black wrote: > > I ran a few Google searches and came across a trove of complaints against > Frontier. Seems they are far worse than GTE/Verizon. On the few occasions I > have called for FIOS support, always reached someone knowledgeable and > helpful. Not looking forward to the changeover, as the new owners have to pay > off debts from their acquisition. That can only be accomplished through rate > increases. I see a Verizon tech outside my kitchen window every two to three > days as he replaces two nitrogen tanks keeping copper trunks pressurized > against water intrusion. Cutting expenses is another (well, and selling more too). Properly engineered/maintained cable should not require that level of constant attention.
AW: Mac compatible SFP+/XFP programmer
I can also suggest you the Multi-Fiber-Tool from Solid Optics: http://www.solid-optics.com/tools/multi-fiber-tool/so-multi-fiber-tool-id1768.html Works great but I've never tested it with an Mac ... MacOS is at least listed as supported. Best regards Jürgen Jaritsch Head of Network & Infrastructure ANEXIA Internetdienstleistungs GmbH Telefon: +43-5-0556-300 Telefax: +43-5-0556-500 E-Mail: j...@anexia.at Web: http://www.anexia.at Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601 -Ursprüngliche Nachricht- Von: NANOG [mailto:nanog-boun...@nanog.org] Im Auftrag von Eric Rosenberry Gesendet: Dienstag, 04. August 2015 23:49 An: Eriks Rugelis Cc: NANOG Betreff: Re: Mac compatible SFP+/XFP programmer I can attest to the quality of the Flexbox. It is fantastic! All of our employees have Mac's and they work great. Originally you had to use Java in FireFox to make it work, but they now have a "Chrome app" that works in Chrome which is even easier (don't have to get the right Java version loaded and click through a million security warnings). The workflow for how the box works is fantastic- You just go to their website and plug in the box and the UI is fully web based. The benefit here is that they are constantly updating different programming profiles for different manufacturer quirks. As soon as they make a change, it is available to you from the UI. If you run into any issues with optic compatibility, they can whip up a new profile and have it available immediately (not that I have actually had any issues, but I did have them add some XFP MRV profiles for me). It will also show you the history of any optic you have programmed which is nice I guess. The down side is naturally that I think it only works with their branded optics and also they are in control (i.e. if they decide to discontinue the service, or if you have no net access you are out of luck, but come on, we are all network engineers - finding Internet is not exactly hard). ;-) -Eric On Fri, Jul 31, 2015 at 8:57 AM, Eriks Rugelis wrote: > A couple of months ago I purchased a Flexbox V3 and a pile of SFP and SFP+ > for $dayjob. The parts arrived in less than a week and the Flexbox V3 > (and webapp) works well with our Macs. > > We are a satisfied customer. > > Eriks > --- > Eriks Rugelis > Sr. Consultant > Netidea Inc. > T: +1.416.876.0740 > > > On Jul 30, 2015, at 14:48, Youssef Bengelloun-Zahr > wrote: > > > > Hi, > > > > Flexoptics seems to do the trick but via a Web browser : > > > > https://www.flexoptix.net/en/flexbox-v3-transceiver-programmer.html > > > > From what I've heard, this thing does the Job. > > > > Best regards. > > > > > > > >> Le 30 juil. 2015 à 20:28, Jason Lixfeld a écrit : > >> > >> Does anyone know where I might find a SFP+/XFP programmer with a Mac > compatible programmer application? > >> > >> Thanks! > > > -- *Eric Rosenberry* Principal Infrastructure Architect // Chief Bit Plumber
Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica
> As someone who once hosted TLD zones in a way that a query to a > particular nameserver could be answered by either NSD or BIND9, my > advice would be "don't do that". You're setting yourself up for > troubleshooting hell. for some folk, complexity is a career. i worked for circuitzilla for 15 months; it's embedded in their culture. randy
Re: RES: Exploits start against flaw that could hamstring huge swaths of
>> 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. i love the devops movement; operators discover that those computers can be programmed. wowzers! maybe in a decade or two, we will discover mathematics. nah. randy
Re: RES: Exploits start against flaw that could hamstring huge swaths of
On Tue, Aug 4, 2015 at 4:53 PM, Randy Bush wrote: > i love the devops movement; operators discover that those computers can > be programmed. wowzers! > Maybe we can give them a new title. I'm thinking, "System Programmer."
Re: Exploits start against flaw that could hamstring huge swaths of Internet | Ars Technica
On Tue, Aug 04, 2015 at 12:00:32PM -0400, Jared Mauch wrote:
> I recommend using DNSDIST to balance traffic at a protocol level as you can
> have implementation diversity on the backside.
>
Here's an example dnsdist config you might find helpful:
This sends queries to the first two servers unless
they are for domains in the "nether" pool list. They go to
other servers.
You can restrict access based on the Acl.
newServer("x.x.223.10")
newServer("x.x.223.20")
;setServerPolicy(firstAvailable) -- first server within its QPS limit
setServerPolicy(leastOutstanding)
webserver("0.0.0.0:8083", "AskMe")
addACL("192.168.0.0/22")
addACL("10.0.0.0/16")
addACL("172.16.22.0/24")
setKey("AskMe")
controlSocket("127.0.0.1:1099")
newServer{address="129.250.35.250", pool="nether"}
newServer{address="129.250.35.251", pool="nether"}
newServer{address="8.8.8.8", pool="nether"}
addPoolRule({"ntt.net.", "nether.net."}, "nether")
addPoolRule({"arpa.", "google.", "gmail.com.", "google.com.",
"googlemail.com."}, "nether")
--
Jared Mauch | pgp key available via finger from ja...@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.
