If you don't have the appropriate facilities to handle biological materials the ATCC won't sell them to you. If our artist friend lied in order to trick the ATCC into thinking that he worked for a university that had biological facilities then that seems like mail fraud to me.
I use a browser launched VPN client.
And I in fact always have IE open for that and Firefox open for use as a web browser.... I have to restart Firefox at least twice a day to keep memory utilization reasonable and it's a pain to have to reauth.
I really don't care *what* causes such horrible memory leaks (but it must be either Live HTTP Headers or Web Developer in my case) but the thing sucks up 350-500mb after a few hours of use.
And maybe everyone will forget you invented the rules in the first place...
1996 "Let's make everyone pay each other for calls from their network to another network..." rule to keep CLECs from being a viable business (oh wait dialup ISPs are all inbound calls, D'OH!) followed by the 1999 "The Internet is not the telephone call so we don't have to pay those competitors the BILLIONS of reciprocal compensation for all our customers dialling up to d/l pr0n" rule which made 2004 "Packet based voice not subject to the same regulations as POTS" rule
Which means that now Verizon is rolling out a pure packet switched network that they don't have to share... Oh yeah and practicing a scorched-earth policy it seems.
Expounding upon this, what if you (gasp) don't use a firewall or anti-spyware software on your computer? The absense of any "security" software is NOT an indictment of a compromised system. What if you have it, but they're not able to detect it like (perhaps Vista would throw up a security alert?). What if you have it but they'd never be able to know, such as if build your own linux router and the firewall is on the router, not on your computer?
Then perhaps you are captcha'd, forced to enter your pin on a moving on screen keyboard, and, assuming this is because your an idiot running windows, get put into a protected workspace.
This appears to be limited to content scanning, and isn't really a vulnerability in itself. Relying on content scanning to prevent an exploit to reach an exploitable system is a pretty bad idea, much better to fix the system than the extra layer of defense on the outside.
While that is strictly (and inarguably) true, it really doesn't matter when you aren't the people who wrote/own the application. Lobbing problems over the cubicle wall to the 'other' group only tends to lead to least-common-denominator solutions that take forever to get in place.
Content scanning is mostly useful against filtering known exploits, and is hardly meant to be your primary defense. Being able to bypass this scanning won't buy you much. If the content scanner is aware of an exploit it scans for, chances are so are the systems being targeted and are patched to protect against it.
Without getting into the religion of Integrity/Availability/Confidentiality... This is why people use layered approaches to security like Firewall -> IDS/IDP -> WAF -> Secure Applications -> Secured Platforms -> Simple Obscurity. What you are pointing out is the need for a Web Application Firewall (WAF) that uses a positive security model- one that defines what is allowed, not what is bad. If your positive model is granular enough you should catch 'zero day' attacks, as well as prevent a hax0r from probing your application since their usage patterns will probably fall way outside of normal.
PS It's still better to catch an attack in an outer layer then get hacked...
I went ahead and read about this guy and his party also. Unlike you my first thought was 'the Christian Democratic Union'!? How f'd up is that !!!?!?!eleven!1!'
My second thought was, "at least I don't have to worry about that kind of crap here"
However we re-converge because my third thought was 'only in Germany could a man that sounds this boring be so controversial.' and my fourth was indeed "Oh wait, I'm in America, I've been desensitized."
I went to the website and have read through the Slashdot comments and still can't figure why this keyboard is supposed to be so great. Does it scratch your balls when you're typing an email? Does it protect from terrorism? Will it sing me a song so I can fall asleep at night? Or pour me a drink whenever I crave a martini?
Yes. You can also program it to make each key display pr0n.
At the point where you are doing site/site DR via BGP you are most likely going to be running both your edge routers and your DNS based GSLB servers.
When I mentioned robustness I was really thinking of two specific issues: -partial failures (where not all of your services are down) -routing instability directly following a major 'disaster'
I've seen people use iBGP w/ route health injection to move traffic internally between DC's, but AS-at-a-time is not particularly granular.
Users well outside of a disaster event are also much more likely to be able to get DNS resolution and a stable route to the DR network if it is in a wholly separate AS.
I still vote for the best solution being both your own AS + BGP as well as DNS based GSLB using ISP IP's...
Disclosure time: I deal with this stuff every day and I have a vested interested in commercial solutions to this issue. dnsmadeeasy doesn't solve the problem the OP is asking about. They simply monitor your services and start serving a different DNS record if your primary is down.
The OP is concerned with all the DNS servers that aren't yours that would then have a cached version already, and continue to serve up the dead DNS record until their (incorrectly configured) TTL expired.
As another poster already mentioned, BGP is really the only technical solution to this problem. All other "solutions" are going to be convincing people that they don't really need instant failover in the event of a major disaster.
The problem is that this is somewhat specious of a concern. It tends to be browser/os combos that don't honor TTLs, and there are very few of those around anymore. In that case all the client has to do is close and reopen their browser.
BGP is cumbersome but a valid solution (if you've got your own AS). You probably want to suppliment it with a DNS based solution though- far more of your outages will be less than whole site events. The more viable (and likely) scenario to keep in mind is a partial outage at a the primary DC where you can use DNS to send 99% of the users of affected applications to the DR site, and the 1% who are non RFC compliant can be handled via more draconian methods (either 302's, l3 backhaul, or even shared l2 if you have it between sites). A properly designed solution will be able to do all of this for you and also know what is really available without manual intervention.
I really want to address your comment about convincing people they "don't really need instant failover in the event of a major disaster." Well they probably don't [need 100% of users to have instant failover during a major disaster]. Metrics get wrapped around BC for a good reason. People often fail to grasp is that if your entire primary site goes 'poof' you, and likely most of the world, will not notice the time it takes either a DNS or BGP based solution to 'reconverge,' and you certainly won't care if a fractional percent of your users need to close their browsers (btw many users probably won't be able to get to your site because of route flapping mayhem et al. caused by said disaster...) Frankly it won't be anyone's biggest concern at that point.
Layered approaches are often needed, your particular requirements and bugdet determine how deep you go. A DNS based first layer will do 99%+ of the job.
[FYI for dealing with the bad boy superproxy types like AOL you could segment that traffic out and handle it differently than everyone who 'plays fair'... If you've got the money to play with the best of breed solutions then it's all been done before- but you probably wouldn't be asking/.]
Slashdot Mirror
FWIW the guy was a guest lecturer in a class I had and he was a harmless geek (and yes that is a compliment, this is
I use a browser launched VPN client. And I in fact always have IE open for that and Firefox open for use as a web browser.... I have to restart Firefox at least twice a day to keep memory utilization reasonable and it's a pain to have to reauth. I really don't care *what* causes such horrible memory leaks (but it must be either Live HTTP Headers or Web Developer in my case) but the thing sucks up 350-500mb after a few hours of use.
Alternatively you could just wait till she's dead. Bonus is that you pay less to lawyers. (Well unless you not so much 'wait' and get caught ;)
But only if it's unlocked and is tri or quad-band.
And maybe everyone will forget you invented the rules in the first place...
1996 "Let's make everyone pay each other for calls from their network to another network..." rule to keep CLECs from being a viable business (oh wait dialup ISPs are all inbound calls, D'OH!) followed by the
1999 "The Internet is not the telephone call so we don't have to pay those competitors the BILLIONS of reciprocal compensation for all our customers dialling up to d/l pr0n" rule which made
2004 "Packet based voice not subject to the same regulations as POTS" rule
Which means that now Verizon is rolling out a pure packet switched network that they don't have to share... Oh yeah and practicing a scorched-earth policy it seems.
And as another poster already mentioned- your ISP prolly isn't a common carrier.
PS It's still better to catch an attack in an outer layer then get hacked...
I went ahead and read about this guy and his party also. Unlike you my first thought was 'the Christian Democratic Union'!? How f'd up is that !!!?!?!eleven!1!'
My second thought was, "at least I don't have to worry about that kind of crap here"
However we re-converge because my third thought was 'only in Germany could a man that sounds this boring be so controversial.' and my fourth was indeed "Oh wait, I'm in America, I've been desensitized."
Alles klar Herr Komisar?
At the point where you are doing site/site DR via BGP you are most likely going to be running both your edge routers and your DNS based GSLB servers.
When I mentioned robustness I was really thinking of two specific issues:
-partial failures (where not all of your services are down)
-routing instability directly following a major 'disaster'
I've seen people use iBGP w/ route health injection to move traffic internally between DC's, but AS-at-a-time is not particularly granular.
Users well outside of a disaster event are also much more likely to be able to get DNS resolution and a stable route to the DR network if it is in a wholly separate AS.
I still vote for the best solution being both your own AS + BGP as well as DNS based GSLB using ISP IP's...
DNS doesn't do the job seemlessly 100% of the time but BGP isn't robust enough to do the job alone. Solution = do both.
Disclosure time: I deal with this stuff every day and I have a vested interested in commercial solutions to this issue.
/.]
dnsmadeeasy doesn't solve the problem the OP is asking about. They simply monitor your services and start serving a different DNS record if your primary is down.
The OP is concerned with all the DNS servers that aren't yours that would then have a cached version already, and continue to serve up the dead DNS record until their (incorrectly configured) TTL expired.
As another poster already mentioned, BGP is really the only technical solution to this problem. All other "solutions" are going to be convincing people that they don't really need instant failover in the event of a major disaster.
The problem is that this is somewhat specious of a concern. It tends to be browser/os combos that don't honor TTLs, and there are very few of those around anymore. In that case all the client has to do is close and reopen their browser.
BGP is cumbersome but a valid solution (if you've got your own AS). You probably want to suppliment it with a DNS based solution though- far more of your outages will be less than whole site events. The more viable (and likely) scenario to keep in mind is a partial outage at a the primary DC where you can use DNS to send 99% of the users of affected applications to the DR site, and the 1% who are non RFC compliant can be handled via more draconian methods (either 302's, l3 backhaul, or even shared l2 if you have it between sites). A properly designed solution will be able to do all of this for you and also know what is really available without manual intervention.
I really want to address your comment about convincing people they "don't really need instant failover in the event of a major disaster." Well they probably don't [need 100% of users to have instant failover during a major disaster]. Metrics get wrapped around BC for a good reason. People often fail to grasp is that if your entire primary site goes 'poof' you, and likely most of the world, will not notice the time it takes either a DNS or BGP based solution to 'reconverge,' and you certainly won't care if a fractional percent of your users need to close their browsers (btw many users probably won't be able to get to your site because of route flapping mayhem et al. caused by said disaster...) Frankly it won't be anyone's biggest concern at that point.
Layered approaches are often needed, your particular requirements and bugdet determine how deep you go. A DNS based first layer will do 99%+ of the job.
[FYI for dealing with the bad boy superproxy types like AOL you could segment that traffic out and handle it differently than everyone who 'plays fair'... If you've got the money to play with the best of breed solutions then it's all been done before- but you probably wouldn't be asking