701–710 of 721 posts
Earlier quoted context omitted.
I know a lot about some things, but almost nothing about networking, so excuse me if this is a really dumb question but - would your physical location determine what hosts you returned from that query? Like if you were in Asia would you get different ones back?
Yes because DNS typically uses ANYCAST networking. The DNS request routes to the nearest location.
USA cyber defenses are NOT up to the task of defending our critical electronic infrastructure. Letting every company that runs critical services decide their own security posture is not scalable and has left us vulnerable. While no one is getting hurt, we are taking cyber missile hits from our enemies and eventually the damage will be worse. Other countries with more central controls will be less vulnerable than we a…
No. What we need are new techniques for creating back-pressure to all the routers which are forwarding on this type of attack. The issue is that our Routing technology does not give downstream nodes any way to push back on the flood of packets. Cisco could step up to the plate here. And no, I'm not talking about firewalls. We need newer ICMP type packets to create this back-pressure, so that we can stop floods like t…
What is this type of attack? TCP/UDP/ICMP has no notion of of a compromised host. Or even that it was crafted packet.
Back pressure already exists in TCP, see slow-start and window sizes, flow control is part of the "control part". When a router's porst buffers are full the router drops the packets on the floor. It does not do further processing of those packets.
What would ICMP do here? If I have a million compromised hosts and each sends a single SYN packet towards a destination host, how would ICMP help?
">Cisco could step up to the plate here" What would Cisco do? Cisco doesn't control the ICMP protocol.
I think you are not understanding ICMP. The job of ICMP is to report error conditions. ICMP serves as a helper to IP which is itself unreliable and has no form of error control or checking. A router or host being overrun is not a network error condition it is a resource condition. No ICMP type is ever going to be able to stop a host from originating UDP/TCP/ICMP towards a destination. Even if it could you would just overwhelm it in the outbound direction by replying to potentially millions of hosts.
Earlier quoted context omitted.
Nope, just point your machine or router's DNS to use opendns resolvers instead of your regular ones: 208.67.222.222 and 208.67.220.220
Be aware that some things (Netflix, Comcast, Youtube) expect you to use your local DNS server so that they can route you to the nearest media server. Using a central IP Address like what is mentioned here can result in unsatisfactory video streaming....at least that's what I found with our Apple TV.
https://www.opendns.com/enterprise-security/technology/globa...
Relevant (or at least a-propos) post by Bruce Schneier, from a month ago: "Someone Is Learning How to Take Down the Internet" https://www.schneier.com/blog/archives/2016/09/someone_is_le... Edit: And to be clear: I don't mean to imply there's any connection :)
If I had to guess, though, I don't think it's China. I think it's more likely related to the DDoS attacks against Brian Krebs than the probing attacks against the Internet infrastructure, despite how prescient that essay seems right now. And, no, I don't think China is going to launch a preemptive attack on the Internet."
[1] https://www.schneier.com/blog/archives/2016/10/ddos_attacks_...
Earlier quoted context omitted.
That's good to know - the ads are the reason I reluctantly switched from OpenDNS to google. (Reluctantly in that Google already has enough of my data, thanks, through gmail, search, maps, docs and other services, not because it doesn't work well.)
Google DNS doesn't store any identifiable/private data, as far as I understand? https://developers.google.com/speed/public-dns/privacy
Still, I prefer it to isps snooping.
Earlier quoted context omitted.
It's not illegal to have TTL that short but it certainly feels like violation of some implicit contract between users and provides. Of course the root cause of this is the horrendous hack of using DNS for CDN routing. It doesn't have to be that way... I wrote a recent article about this very issue here http://www.infoworld.com/article/3133104/mobile-technology/w...
I haven't heard of packetzoom before, I'll definitely take time over the weekend or next week to dig into your approach. I wouldn't call DNS based IP mapping "horrendous" simply because it doesn't work as well for mobile,I understand you have your own pitch but lets go easy on the hyperbole :) The fact is that it is still very effective. The major CDNs are quite aware of the mobile shortcoming of DNS based mapping an…
OK I'll take back the word "horrendous" but it's a hack alright.
> The fact is that it is still very effective. The major CDNs are quite aware of the mobile shortcoming of DNS based mapping and I am pretty sure it is something they are working to address.
No not really. They're certainly trying to patch DNS to pass through enriched information in DNS requests through recursive calls... but it's such a long shot to work consistently across tens of thousands of networks around the world, and requires coordination from so many different entities, that it's clearly a desperation move more than than a serious effort. Regardless, there's no real solution in sight for the web platform.
For mobile (native) apps though, the right way to discover nearby servers is to directly build in that functionality using mobile specific techniques. There's no reason to keep limiting mobile apps to old, restrictive web technologies considering that apps have taken over as majority of traffic around the world. That's the root idea behind a lot of what we're doing at PacketZoom. Not just in service discovery, but also in more intelligent transport for mobile with built-in knowledge of carriers and network technologies etc, automatic load-balancing/failover of servers and many other things. Here's my older article on the topic
http://www.infoworld.com/article/3016733/application-develop...
Earlier quoted context omitted.
I'm not sure what metric you use to judge it as terrible. I thought it was great. 10,000 companies pay for my service today. 65 million people use my infrastructure today. Cisco bought the company for more than $650m. It continues to innovate on the decades old DNS in secure and useful ways. So let me know what part is terrible.
The part where you repeated Verisign's mistake in breaking a fundamental protocol. NXDOMAIN. Kind of a thing, and important to protocols other than HTTP.
Can someone explain why this is so bad? I think the internet handled the downtime of Dyn pretty great, not reaching github wasn't exactly pleasing, but i added the ip temporary to /etc/hosts and the problem was solved. Isn't the best strategy to accept that attacks will continue and systems may go down and design for resilience? If so this attack can serve as a warning and as a check that we can handle these types of…
You're assuming we'll build immunity fast enough. What if we don't? Attacks at this scale can bring a significant part of Internet down. The economic affect can be just as bad as a war.
Earlier quoted context omitted.
To be perfectly honest, a "feature" like this has no business being in a safe and secure DNS server. You should fail-safe, rather than serving stale data of unknown safety. Serving data you cannot verify is a dangerous failure state.
Perhaps. In this case the web was down. I definitely understand the point, stale data with TTLs which have expired, especially on RRSIG records is dangerous. But I have to wonder about situations like this where DNS has been taken down, what the better good is. If the records can be proven to have been cached as authentic data at some point within some period of time. In this case hours, is it for the better good tha…
As another user put it, we have these standards for good reason.