Amid Major Internet Outages, Affected Websites Have Lessons To Learn (zdnet.com) 135
Earlier today, Dyn, an internet infrastructure company, was hit by several DDoS attacks, which interestingly affected several popular websites including The New York Times, Reddit, Spotify, and Twitter that were directly or indirectly using Dyn's services. The attack is mostly visible across the US eastern seaboard with rest of the world noticing a few things broken here and there. Dyn says it's currently investigating a second round of DDoS attacks, though the severity of the outage is understandably less now. In the meantime, the Homeland Security said that it is aware of the attack and is investigating "all potential causes." Much of who is behind these attacks is unknown for now, and it is unlikely that we will know all the details until at least a few days. The attacks however have revealed how unprepared many websites are when their primary DNS provider goes down. ZDNet adds: The elephant in the room is that this probably shouldn't have happened. At very least there's a lot to learn already about the frailty of the internet DNS system, and the lack of failsafes and backups for websites and tech companies that rely on outsourced DNS service providers. "It's also a reminder of one risk of relying on multi-tenant service providers, be they DNS, or a variety of many other managed cloud service providers," said Steve Grobman, chief technology officer at Intel Security. Grobman warned that because this attack worked, it can be exploited again. "Given how much of our connected world must increasingly rely upon such cloud service providers, we should expect more such disruptions," he said. "We must place a premium of service providers that can present backup, failover, and enhance security capabilities allowing them to sustain and deflect such attacks." And that's key, because even though Dyn is under attack, it's the sites and services that rely on its infrastructure who should rethink their own "in case of emergency" failsafes. It may only be the east coast affected but lost traffic means lost revenue. Carl Levine, senior technical evangelist for NS1, another major managed DNS provider, said that the size and scale of recent attacks "has far exceeded what the industry thought was the upper end of the spectrum." "Large companies need to constantly upgrade their flood defenses. Some approaches that worked just a few years ago are now basically useless," said Kevin Curran, senior member with IEEE.We also recommend reading security reporter Brian Krebs's take on this.
First lesson (Score:5, Interesting)
Re: (Score:1)
IPV6 actually makes things worse.
-Matt
Re: (Score:2)
You can't just say that, please explain your reasoning.
Re:First lesson (Score:4, Interesting)
I have two major beefs with IPV6. The first is that the end-point 2^48 switch address space wasn't well thought-through. Hey, wouldn't it be great if we didn't have to use NAT and give all of those IOT devices their own IPV6 address? Well... no actually, NAT does a pretty good job of obscuring the internal topology of the end-point network. Just having a statefull firewall and no NAT exposes the internal topology. Not such a good idea.
The second is that all the discovery protocols were left unencrypted and made complex enough to virtually guarantee a plethora of possible exploits. Some have been discovered and fixed, I guarantee there are many more in the wings. IPV4 security is a well known problem with well known solutions. IPV6 security is a different beast entirely.
Other problems including the excessively flexible protocol layering allowing for all sorts of encapsulation tricks (some of which have already been demonstrated), pasting on a 'mandatory' IPSEC without integration with a mandatory secure validation framework (making it worthless w/regards to generic applications being able to assert a packet-level secure connection), assumptions that the address space would be too big to scan (yah right... the hackers didn't get that memo my tcpdump tells me), not making use of MAC-layer features that would have improved local LAN security, if only a little. Also idiotically and arbitrarily blocking off a switch subspace, eating 48 bits for no good reason and trying to disallow routing within that space (which will soon have to be changed considering that number of people who want to have stateful *routers* to break up their sub-48-bit traffic and who have no desire whatsoever to treat those 48 bits as one big switched sub-space).
The list goes on. But now we are saddled with this pile, so we have to deal with it.
-Matt
Re:First lesson (Score:4, Interesting)
NAT may do a good job obscuring internal topology, but it does saw at considerable cost; breaking the end to end concept of the original ARPANET structure, requiring more resources, and creating far greater complexity for routers. Yes, a flat address space that sits in the public address space might, on the surface, expose more devices, but this is where firewalls come into play. I can still have a rather complex topology, but now I have to worry less about routing and connection tables, and can use less resource expensive techniques like tagging.
It was never IPv6's intention to be more secure, and you're right that many existing issues will remain with IPv6, and there will likely be new ones, but one thing is certain, if the solution is NAT, then that solution is worse than the disease it purports to cure. And it isn't as if NAT can't be vulnerable in its own way, and the only way to make it less vulnerable is, you guessed it, firewalls, authentication, and other security measures which are also needed in an IPv6 world.
Re: (Score:2)
+1 There is so much undeserved hate for IPv6 because people haven't taken the time to understand it.
NAT is not a security solution. If you would put a NAT device between your network and the Internet you can put a firewall between your network and the Internet. Yes, someone could potentially learn a small amount about your internal topology, well if you call being able to identify possible subnets withing your network learning about the topology, but the little they can learn is of dubious use. You still ha
Dunning-Kruger Effect? (Score:2)
FWIW, the GP poster is Matt Dillon. He's a well known FreeBSD/Linux kernel hacker and the founder/maintainer of DragonFly BSD and his list of Nerd Cred is legit and long. I'm sure he's forgotten more about network protocols than I ever knew in spite of my kernel patches and Samba contributions. I'd wager he's painfully aware of the ins-and-outs of NAT and IPv6 at a low level.
Don't get me wrong; that doesn't mean he might not be wrong in his evaluation of the protocol. He'd just be wrong on a much more
Re: (Score:2)
I have two major beefs with IPV6. The first is that the end-point 2^48 switch address space wasn't well thought-through. Hey, wouldn't it be great if we didn't have to use NAT and give all of those IOT devices their own IPV6 address? Well... no actually, NAT does a pretty good job of obscuring the internal topology of the end-point network. Just having a statefull firewall and no NAT exposes the internal topology. Not such a good idea.
The second is that all the discovery protocols were left unencrypted and made complex enough to virtually guarantee a plethora of possible exploits. Some have been discovered and fixed, I guarantee there are many more in the wings. IPV4 security is a well known problem with well known solutions. IPV6 security is a different beast entirely.
Other problems including the excessively flexible protocol layering allowing for all sorts of encapsulation tricks (some of which have already been demonstrated), pasting on a 'mandatory' IPSEC without integration with a mandatory secure validation framework (making it worthless w/regards to generic applications being able to assert a packet-level secure connection), assumptions that the address space would be too big to scan (yah right... the hackers didn't get that memo my tcpdump tells me), not making use of MAC-layer features that would have improved local LAN security, if only a little. Also idiotically and arbitrarily blocking off a switch subspace, eating 48 bits for no good reason and trying to disallow routing within that space (which will soon have to be changed considering that number of people who want to have stateful *routers* to break up their sub-48-bit traffic and who have no desire whatsoever to treat those 48 bits as one big switched sub-space).
The list goes on. But now we are saddled with this pile, so we have to deal with it.
-Matt
The first point about NAT - while that used to be a shortcoming in terms of topology masking and load balancing, the IETF did explicitly define Network Prefix Translation, which is a 1:1 NAT mechanism that would do what you want, but avoid the pitfalls associated w/ the 1:many mapping in IPv4 NAT. Also, IPv4 NAT consumes several port addresses, and also often several NAT layers, reducing the networking to layer 2. As for IPSEC, I didn't exactly get your point on why that is a bad thing. As for the subnet
Re: (Score:2)
Re: (Score:2)
IPV6 can make some things worse, especially spam.
For example, it makes banning or classifying an IP address as a spam source nearly impossible. There's so much address space that spammers will be able to use an IP to send 1000 emails and then discard it, never to be used again. The incredibly huge address space makes this quite practical. Banning by IP address will become meaningless because there are so many useable (and therefore discardable) IPs.
How much address space is there? Well....
Let's assume every
Re: (Score:2)
Except that in reality the way it works is that each customer of an ISP is assigned a network block of IPs. If you find that customer is spamming you could block the entire network block. This is effectively the same thing as blocking the single IPv4 address assigned to a customer. The spammer would either need a new block of addresses from the ISP or a new ISP, effectively the same situation you have now with IPv4.
Re: (Score:3)
Except that in reality the way it works...
Except that in reality some ISPs are owned by the Russian Business Network (RBN), and they'll be given 100 million IPs to play with, and then another 100 million, and so on. The RBN owns lots of ISPs that are known for their friendliness towards "bulletproof" hosting companies and for working hand-in-hand with spammers.
-
The spammer would either need a new block of addresses from the ISP or a new ISP, effectively the same situation you have now with IPv4.
No, it's not the same situation because the address space that will be available to these criminal ISPs will be magnitudes of order larger than with IPV4. An ISP now may have a hundred thou
Re: (Score:2)
Re: (Score:2)
They'll have more address space available, but it'll still be in contiguous blocks. If an ISP as a whole is being a problem then all you have to do is block their v6 allocations, which is no harder than blocking their v4 allocations. (Or possibly easier since the ISP is likely to have a single v6 allocation vs dozens of v4 ones.)
Re: (Score:2)
If an ISP as a whole is being a problem then all you have to do is block their v6 allocations, which is no harder than blocking their v4 allocations.
You're talking about blocking 10 million or maybe 100 million IP addresses, and in that range are going to be some (or even many) legitimate users. Also, there's no guarantee that the address space will be contiguous, it may be broken up into various blocks. If they have their way then it will almost certainly be spread across many, many different blocks of IP addresses.
And finally, in addition to being spread out over many ISPs and many blocks, they'll almost certainly be using IP-shifting, fast-flux, or o
Re: (Score:2)
Re: (Score:3)
How exactly would being on a /64 prevent such an attack against a publicly facing entity? These attacks are not address space scanning attacks at all, they are known and publicly published IP addresses (in this case, DNS servers). Flood the public facing IP (the DNS server) would be exactly the same if IPv4 or IPv6. The only thing this would temporarily mitigate is the fact there are far fewer devices/users on the IPv6 network, so less of a botnet to control currently.
Re: (Score:2)
Re: First lesson (Score:2)
"But on the IPv6 network, you have the potential to have thousands of DNS servers, or even multicast/anycast addresses for DNS servers."
Most large DNS deployments already use IP Anycast on IPv4.
For example, Google's public recursive DNS (8.8.4.4, 8.8.8.8) uses IP Anycast. Most DNS root servers use IP Anycast.
There are two main benefits to IP Anycast, but the most relevant is allowing the distribution of an IP address over multiple geographic location, which allows lower latency, but also limits the number o
Re: (Score:3)
go back to the whiteboard
APK was right all along! C:\WINDOWS\HOSTS is the solution ;)
*goes to hide under a rock*
APK is pure (Score:2)
Re: (Score:2)
Re: (Score:1)
Wrong. This type of attack targets known IPs of public servers, directly or indirectly.
A bigger subnet doesn't help.
Re: (Score:2)
Re: First lesson (Score:1)
The servers were just fine, the DNS was the problem.
Process:
0. user enters xyz.com
1. lookup Ip address
2. connect to ip
3. serve content
step 1 was the problem. all else was fine. you 'solution' addresses step 2 which however was not the problem here.
No. Step 1 was the problem. Stop whining alright.
Re: First lesson (Score:3)
If your app can find the right server for the service, so can the attacking software.
Re: First lesson (Score:1)
Re: (Score:2)
What's the Solution? (Score:4, Insightful)
I've heard a lot of people today saying there's a problem. Several of the commenters (on Brian Krebs' blog for example, on the NANOG list for another, and probably soon here on ./) say we should do something to fix this so it doesn't happen again. What I haven't heard is a real proposal about what to do about stopping DDoS attacks.
dare I say it? APK APK APK! (Score:2, Funny)
Can't DDOS that.
Lameness filter encountered. Post aborted! Filter error: Please use fewer 'junk' characters.
Proof the system is rigged...
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Since my ISP stopped allowing me to access the admin console of my modem and started exposing a remote management interface to the internet, I don't trust anymore the DNS information provided via DHCP. Probably using a VPN service would be more practical, but for now, I use the hosts file for the sites that require authentication.
Re: (Score:3)
HOSTS file
sshhh... If you say H***** file 3 times in a mirror you'll summon APK... DO NOT ATTEMPT!
Re:What's the Solution? (Score:5, Insightful)
I've seen it a million times, in no small part because I've posted it myself:
ISPs need to start egress filtering to block spoofed packets coming from end users with forged source addresses. If a packet comes from joe blow's cable modem with a source IP from some other country, it should just be dropped.
Re: (Score:2)
Yes, this is effective against some subset of attacks. There was a good reminder/discussion of this on the NANOG list this morning. The problem is 1) probably pretty much every ISP which can be convinced to do this is already doing it at this point, the others are probably a lost cause and 2) this only prevents attacks where the address actually is spoofed. If a large number of compromised devices are running malware they can just make an overwhelming number of legitimate service requests en masse...
Re: (Score:2)
( 2) this only prevents attacks where the address actually is spoofed. If a large number of compromised devices are running malware they can just make an overwhelming number of legitimate service requests en masse...
Why would an ISP allow me to make "an overwhelming number of legitimate service requests"? Oh, that's right, you answered that question in point #1 -- most ISPs don't give a shit.
Re: (Score:3)
It is worse than that.The problem with DDOS is that the real victim probably doesn't know about it.
The proper way to thwart these kinds of attacks is to have a method of detecting them and then cutting off people who are making an inordinate amount of those kinds of packets aimed at that address. The solution to a coordinated attack is a coordinated response.
Re: (Score:2)
I would maintain that's not possible. Attackers will just write software that mirrors normal user traffic accessing a site. It's simply the fact that millions of devices will be accessing the site at the same time that takes the site/service down. Just like ye olden days when nearly every site mentioned in a ./ summary went down. The fundamental problem is that a truly distributed denial of service attack is just a coordinated accessing of a site from a large number of hosts. The only difference between tha
Re: (Score:1)
It would make life very difficult for the attackers.
Attackers would have to reduce the rate at which they access the site from any single bot in their botnet, otherwise the bot sticks out, can be identified and cut of the internet. That means they need more bots.
At the same time, if ISP's finally start to follow up on abuse notices, the number of bots would actually be reduced.
Together these would greatly reduce any botnets power.
At the same time we only need someone to maintain a list of ISP's who refuse t
Re: (Score:2)
"The proper way to thwart these kinds of attacks is to have a method of detecting them and then cutting off people who are making an inordinate amount of those kinds of packets"
Unless there're no inordinate amount of those kinds of packets but an inordinate amount of clients requesting usual amounts of packets each. That's the first D on DDoS, after all. How can you distinguish a malicious DDoS from the Slashdot-effect of yold?
On the other hand, this was not a DDoS attack targeted against the servers them
Re: (Score:2)
...and #2 is going to become a *lot* more common, thanks to growth in IoT. :/
Wish they'd have paid more attention to crap like this back in the late 90's when the whole idea first surfaced on a serious note (e.g. JINI).
Re: (Score:3)
Not how the Internet works. Yes that's true on the edges but once you enter into the public Internet, packets could be routed from anywhere to anywhere. The only solution here is to shut down ISPs that are participants but you're talking about getting participation from people that often are themselves involved in the criminal enterprise (that's true for US, Europese, Chinese etc providers) and are profiting from these attacks through overage fees etc.
You wouldn't imagine but even providers like Verizon won
Re: What's the Solution? (Score:1)
A good start would be to criminalize the manufacture and sale of iot devices with little or no security.
Re: (Score:3)
1) Yes, poorly designed IoT devices make the problem worse but it's existed long before IoT came along. 2) What qualifies as an IoT device, every Arduino with an Ethernet/WiFi port? The code isn't on them until you program them... 3) If mass regulation of all network connected products is the only way we have a problem because you're never going to get global agreement on that and it's going to be nearly impossible to enforce.
Re: What's the Solution? (Score:1)
Re: (Score:2)
An Arduino is just an AVR microcontroller, the same chip found in many electroinc/IoT devices. Point being when does it become an IoT device? If I sell it? How about if I just sell it to a few friends? Maybe I make and sell a small quantity on etsy? etc. It's hard to draw a line about when it's an IoT device and when it's just me playing around with electronics.
Re: (Score:3)
A) Avoid a single point of failure (the cause of downtime across all these providers)
B) avoid using a single point of failure
C) stop using public DNS (or DNS at all) for self-configuration and discovery of your hosted servers
D) stop using a single provider for all your stuff
Re: (Score:2)
Re: (Score:2)
How many different ways can you say the same thing?
A) Several ways
B) A lot of ways
C) Nearly infinite ways
D) About four, it seems
November 1987, RFC 1034. Secondary DNS servers (Score:5, Insightful)
For this specific attack, set up a secondary name server, using a secondary provider.
In November 1987, RFC 1034 was published. It describes how secondary DNS servers automatically sync from the primary. For about twelve years, people took that seriously. The used ar least two name servers that were unlikely to be affected by the same problem - separated geographically far apart and using two (or more) different network providers. Nowadays it's likely their two name servers are sitting right on top of each other in the same rack.
If both your DNS servers are with the same provider, wherher that be Amazon, DynDNS, or any other single provider, they are subject to fail due to the same cause, at the same time.
Btw ona different, but related topic - there's also an RFC for exactly how to build CDNs (reverse proxies) that actually work right. We've known how to do that correctly for decades, so everybody can read the damn RFC and stop inventing new ways to completely screw it up. First hint - the protocol for reverse proxies has been around far longer than the buzzword "CDN" that's now used to sell them.
Re: (Score:1)
These attacks cause service outages because legitimate DNS lookups can't be handled by the servers that are under attack (which I'm assuming here to be the authoritative name servers for the domains that are experiencing service outages). Most users don't ever query the authoritative servers directly; the legitimate queries come from their ISPs' resolvers, and those resolvers only query the authoritative servers if they don't already have the answer in their local cache. And that only happens (in respect of
Look at the Bright Side (Score:2)
At least the hackers didn't bother shutting down Slashd...
Re: (Score:3)
Well, we all know that Slashdot uses the mighty APK HOSTS engine to protect it!
Just hang around here long enough, you'll see everything you've ever wanted to know about it.
Re: (Score:2)
Well, we all know that Slashdot uses the mighty APK HOSTS engine to protect it!
Just hang around here long enough, you'll see everything you've ever wanted to know about it.
Actually, it's been weeks or months since I've seen APK. Can we get a wellness check on that fella?
Re: (Score:2)
Flood defenses? (Score:5, Informative)
There is no flood defense possible for most businesses at the tail-end of the pipe. When an attacker pushes a terrabit/s at you and at all the routers in the path leading to you as well as other leafs that terminate at those routers, from 3 million different IP addresses from compromised IOT devices, your internet pipes are dead, no matter how much redundancy you have.
Only the biggest companies out there can handle these kinds of attacks. The backbone providers have some defenses, but it isn't as simple as just blocking a few IPs.
-Matt
Re:Flood defenses? (Score:4, Insightful)
And this is why people need to be fined, if a device on their home network is found to be part of a botnet. Individuals need to be responsible for their networks, because the authorities are virtually powerless against botnets, Unless it costs them money, people just won't care.
Re:Flood defenses? (Score:4, Interesting)
And then what?
They buy a device that's horribly insecure, the manufacturer sends out one security update, then abandons it, and it becomes part of a botnet. And you fine the person who bought it?
Actually, you're right. That's a great idea, because it will kill the whole 'Internet of Things' idiocy overnight. No-one will risk attaching anything to their network if they can't verify it's secure.
Re: (Score:2)
Well, that's one potential side-effect - and not necessarily a bad one, in my opinion. Either they learn how to manage their devices, or don't connect them to the Internet.
Tackling Mirai (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
reuse infecting part, replace bot part with firmware updater flashing data straight from /dev/urandom
brisk every single alliexpress special $20 web camera out there, repeat every 3-5 months when new hardware comes out until Public learns NOT TO PUT GARBAGE on the public internet
DNS Replication Service Suggestions? (Score:1)
Anyone have recommendations for a good DNS replication service?
Would prefer to be able to replicate rather than maintain two sets of data.
A search turned up www.buddyns.com, but I've not yet dug into their details yet.
Re: (Score:3)
How about http://dyn.com/secondary-dns/ [dyn.com] ?
Re: (Score:1)
Dyn is who I want to replicate.
Re: (Score:2)
Why do you need a replication service? If your stuff is automated, just point it to two providers.
Re: (Score:2)
I think EasyDNS has a product but it's as simple as maintaining two sets of DNS records and pointing your domain to two different providers (e.g. powerDns and easydns).
This "attack" could've been easily prevented if they had a single SysAdmin with 15-20y experience in Internet hosting. Having multiple DNS providers used to be standard practice for any medium to large organization.
Imagine dyndns CEO or disgruntled employees simply pulling the plug out. Same result and a reason to avoid SPOF even if you're "i
This is a test. This is ONLY a test. (Score:3)
If this had been an actual attack, all internet services would be rendered inoperative for long enough for whomever the fuck is doing this to have accomplished whatever the fuck awfulness they desire.
Is it really a war? (Score:5, Interesting)
I've been looking at the mainstream media outlets and they are reporting on this attack as if we were just invaded by Russia.
This was an attack against DNS... at worst this type of attack stops people from "doing something". That "something" could be playing Pokemon... or banking... or working. But it doesn't "take down" the internet.
The internet is just fine. To take down the "whole internet" you'd have to attack routers. And the numbers of routers exceed the ability of anyone to saturate them. So why does the media get all hyped up when Twitter goes down?
It irks me so badly that the media and the general public get so completely flustered when some third world country, or a group of kids, decide to play games with the system. And that is all it is.
Certainly we should defend against disruptions like this. How they are done should be researched. Perhaps in the future the system can be hardened so it's incredibly difficult to attack it.
But it's a pretty minor league attack against the "internet". Twitter is down? The NYT?
I just turned 50 last year. Still up to date on tech. Still as sharp as I was at 25 when I lugged a Compaq suitcase around. This seems like such a small issue to me. When the real issue should be router security, the idiotic idea of tying SSL certs to domain names, or the sad security of home routers.
Re: (Score:2)
That's because you just handwave away the issue, mostly by pedantically nitpicking the terminology.
Re: (Score:2)
Yes I do handwave the issue- because it's a small one.
If you want to talk about big ones, I can go there as well. The US could deploy an alternative DNS system in days. Either with the current tech or something truly distributed.
That's the real issue. The press thinks this current attack is important. And what does the public do with this information? Are they going to revise the system?
If I had my druthers the whole DNS system would have been trashed around 2005 and replaced with a blockchain that would ha
Circular logic (Score:2)
Thereby creating a circular chain of logic.
Re: (Score:2)
So why does the media get all hyped up when Twitter goes down?
The media thinks Twitter is The Internet.
The real point of these attacks is that DNS, like any other centralized service on the Internet, is broken by design.
Re: (Score:2)
It doesn't have to be centralized. Hierarchical, yes, centralized no. Putting all your eggs in one basket (Dyn) is just not a good idea. People outsource stuff and then stop thinking. People assume that if they outsource to a company, nothing can go wrong. But big companies are bigger targets and when they fall over, the mess is much bigger. So yes, decentralize.
Re: (Score:2)
I was just reading a Facebook comment from a friend about a hospital basically shutting down... presumably they had a dependency on something "in the cloud".
Now, I'll certainly grant that said hospital fucked up beyond belief by having that dependency, and I'd hope that heads will roll over it, but the impact seems to go beyond mere entertainment.
Re: (Score:2)
"I was just reading a Facebook comment from a friend about a hospital basically shutting down... presumably they had a dependency on something "in the cloud".
Now, I'll certainly grant that said hospital fucked up beyond belief by having that dependency, and I'd hope that heads will roll over it, but the impact seems to go beyond mere entertainment."
Wont' happen. Executives *love* "the cloud" because, among other things, it can very effectively deflect blame. It was not me, it's been DynDNS, a reputable ac
Re: (Score:2)
I believe it's a Canadian hospital, so its executives might have a different sort of accountability. I hope.
Re: (Score:2)
"I believe it's a Canadian hospital, so its executives might have a different sort of accountability. I hope."
They most probably don't. And even if they do, that won't be the case for long. The nice thing about globalization is that it is a race to the bottom. In this case it translates to -how we Canadians can be competitive if our executives have higher accountability than their USA counterparts?
Re: (Score:2)
"The Internet" hasn't meant the physical network for at least 2 decades. Since at least the early '90s and the "internet superhighway", average people have used "The Internet" to refer to the collective set of interactive services and activities made possible by the network, rather than the underlying network hardware itself.
What good is the physical link if nothing intended to run on it is actually functioning?
Re: (Score:2)
But it doesn't "take down" the internet. The internet is just fine.
Sorry but this very serious and you ignore the realities of the modern internet which is as much dependent on DNS as it is those routers. DNS isn't just a name lookup service anymore. You can't fall back to something else when DNS is down. Many devices and programs come with hardcoded domain entries. Much of the internet is now wholly dependent on DNS to correctly localise services or even know what content to serve you. www.siteofinterest.com may resolve to a specific IP address, but good luck typing in th
Yet more proof and confirmation that... (Score:5, Insightful)
Re: (Score:2)
I so totally agree.... I'd mod you up but I posted and can't.
Russians! (Score:1)
17 intelligence agencies agree: Russia is behind the attack because it wants Trump to win. Or something...
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
Real Business Implications of Internet 3 (Score:2)
Look, when we built the Internet (back in the ARPA days), it was restricted to trusted players at military and research universities.
Then we let in the unwashed masses.
Then some morons decided to give Internet capability to every single device in the Internet of Things.
First principles, people:
Build one Internet based on IPv6sec for the trusted peers. The backbone.
Build a second Internet for the identified non-object computers based on IPv6sec. The unwashed masses. If parts misbehave, turn off their feeds u
Re: (Score:1)
Solution? (Score:2)
Is it time for blockchain DNS?
Re: (Score:3)
No, just DNS the way it was intended. DNS and all early Internet services were designed to withstand nuclear war and attacks by state-sized actors, actually specifically designed to withstand an attack from Russia.
The problem is the cloud has aggregated all that diversity of everyone running their own services into a handful of really big corporations. Today's just a reminder that any one of those corporations has a significant amount of control if it were a truly bad actor. Imagine Dyn intentionally pointi
Re: (Score:2)
Just turning off or filtering DNS UDP packets would be a start.
DNS over UDP works fine on an intranet. Just block it on the way out onto the rest of the net.
Re: (Score:2)
Actually, in cases like this it would make it worse. This is not the DoS of your youth with spoofed IP addresses. This is millions of bots making seemingly legitimate requests simultaneously. With UDP DNS requests are a single packet. With TCP you get a SYN, SYN ACK, and SYN before you even get to the part where you're making the query...that would dramatically multiply the number of packets for each query from each bot, or for that matter on a regular day from a legitimate user meaning the connections woul
Reddit, Spotify, and the New York Times were down? (Score:2)
There's only one answer: Activate Homeland Security!
You know, the department established to thwart terrorists who plan on mass murdering people in spectacular displays like knocking down skyscrapers? The one plenty of us told you was going to be used for every crime in the book in addition to terrorism?
Nah, that kind of scope creep would never happen I was told...
OpenDNS SmartCache (Score:3)
I was reading elsewhere that users utilizing OpenDNS' SmartCache feature were unaffected. Basically, in the event that a domain's authoritative servers all become unavailable, smartcache uses the last known good resource records, regardless of whether their TTL has expired. Are any of the other DNS providers and ISPs utilizing anything similar?
Luddites (Score:2)
They should get with the times and move from the olde worlde internet to the all new shiny shiny cloud!