Patch DNS Servers Faster

51mon writes "Austrian CERT used data from one of their authoritative DNS server to measure the rate at which the latest DNS patch (source port randomization) is being rolled out to larger recursive name servers. While about half the traffic (PDF) they receive is now using source port randomization, their data suggest that this is due to ISPs who roll out such fixes immediately. The rate of patching has fallen to disappointingly low levels since. If your ISP isn't patched, perhaps it is time to switch." After details of the DNS vulnerability leaked, researchers |)ruid and HD Moore released attack code; ZDNet's security blog has an analysis.

Comments

Switch DNS Servers, NOT ISPs

[masdog]

You don't need to switch to a new ISP if they haven't patched yet - just switch to a new DNS server such as OpenDNS.

Re:Switch DNS Servers, NOT ISPs

[Jellybob]

It'll either be a setting on your router, or if your directly connected to the modem, you'll need to change it on the network settings on your computer.

Re:Switch DNS Servers, NOT ISPs

[masdog]

You can change this in your DHCP or IP configuration settings on your home router or PC. On my home network, for instance, my DD-WRT router isn't running a DNS server on it, and the DHCP static DNS settings are set for my Server 2008 box and the two OpenDNS resolvers. My Server 2008 box also has its forwarders set to OpenDNS.

That's probably more complicated than it needs to be, but better safe than sorry.

On Windows XP, 2000, and I think Vista, you can tell Windows to ignore the DNS server settings provided by DHCP by going into the IP properties for the connection and hard coding in the IP addresses under Local Area Connection Properties > Internet Protocol Properties > Use the Following DNS Server Addresses.

This can also be done under linux, but I don't know the particular commands for it.

Re:Switch DNS Servers, NOT ISPs

[A beautiful mind]

I digress. If an ISP didn't patch yet, it means they are incompetent. When the Debian SSL vulnerability was discovered, I sent two emails out, one to my server hosting company and one to my phone company. The server hosting company replaced their ssl cert within a day, the phone company took 4 months, meanwhile their online user gateway was open to sniffing.

I ditched the phone company when my email didn't get a reply in a week.

Re:Switch DNS Servers, NOT ISPs

[Anonymous Coward]

I had been using OpenDNS. I stopped when I realized they were monitoring my traffic. When I go to Google, they were returning their own Google-like page, to which my browser would submit the query, and then redirect me to Google.

I stopped using them after that discovery.

Re:Switch DNS Servers, NOT ISPs

[gunnk]

In Ubuntu, the network icon in the upper-right corner of your screen will take you to your network settings. You can change the DNS servers there.

I put OpenDNS right in my router configuration so it applies to my whole house. The other big benefit is that I block doubleclick whose ads always seem to make pages so slow to load. You also get some scam and phishing protection.

Re:Switch DNS Servers, NOT ISPs

[Woy]

I used OpenDNS and gave it up because it replaced firefox's feature to search google with what you type on the address bar with its own crappy search.

Re:Switch DNS Servers, NOT ISPs

[Ciarang]

It always surprises me how much love there seems to be for OpenDNS on /.

A DNS server returns you a result, or tells you that it can't resolve the domain. Instead of doing the latter, OpenDNS redirects you somewhere you didn't intend to go and attempts to hit you with some advertising. That seems more like typosquatting to me, although admittedly it's with your permission.

Re:Switch DNS Servers, NOT ISPs

[DavidSev]

I have no idea what netconfig is meant to do, but it doesn't exist on my computer. /etc/resolv.conf is the standard way of doing it.

Re:Switch DNS Servers, NOT ISPs

[Ciarang]

It's completely different, otherwise they wouldn't be my ISP.

Re:Switch DNS Servers, NOT ISPs

[eln]

resolv.conf will be written over by DHCP unless you set PEERDNS=no in the /etc/sysconfig/network-scripts/ifcfg-ethX file.

Re:Switch DNS Servers, NOT ISPs

[maztuhblastah]

You don't need to switch to a new ISP if they haven't patched yet - just switch to a new DNS server such as OpenDNS.

Please don't do that.

I don't think OpenDNS is a terribly good idea, and here's why:

They actively screw with the records and return incorrect information. Now you can argue that they do it for "OK" reasons, and indeed, OpenDNS does exactly this in their marketing materials, but the fact remains: they answer some queries with information that is in conflict with the authoritative nameservers.

Personally, I don't trust any DNS provider that does this, and I don't think it's a good idea for anyone to do so.

Use 4.2.2.1 - 4.2.2.6. They're fast, free, don't mess with records (such as altering NXDOMAIN), and are anycast to local servers, so response times are minimal.

Re:Switch DNS Servers, NOT ISPs

[the JoshMeister]

I had been using OpenDNS. I stopped when I realized they were monitoring my traffic. When I go to Google, they were returning their own Google-like page, to which my browser would submit the query, and then redirect me to Google.

I stopped using them after that discovery.

Your claim that OpenDNS is "monitoring your traffic" is misleading.

If you ping www.google.com it pings google.navigation.opendns.com (208.67.219.231). You still get the standard Google homepage and search results when you go to http://www.google.com/ however. The odd DNS resolution for www.google.com is apparently because some software such as the Google Toolbar bypasses DNS requests, which breaks some of OpenDNS's features. (More on this below.) One apparent advantage of OpenDNS doing this is that it help users avoid Dell affiliate adware so that affected Dell systems will get actual search results instead of a page full of Dell's affiliate ads.

But guess what? It's trivial to turn this feature off if you don't like it. Just go to https://www.opendns.com/dashboard/settings/ and sign in if necessary. Click on Advanced Settings. Scroll down and uncheck Enable OpenDNS proxy, then click Apply. Wait a few minutes, or try running "ipconfig /flushdns" from the command line if you're using Windows, or restart your computer, and then your settings should take effect. The downside to disabling the proxy is that it will break some of OpenDNS's features.

From an OpenDNS support article:

Is OpenDNS running a proxy?
Yes. Some software, including your (and our) beloved Google Toolbar, intercepts requests made via the address bar so that DNS requests never occur. This creates some usability issues, including making shortcuts - which require DNS requests to be made from the address bar - unreliable. We've designed a simple proxy that ensures the best of Google and OpenDNS work without causing problems.

When enabled, we route certain requests to a simple proxy which checks for the origin of the request. Shortcut-related traffic gets handled (and redirected) while all other traffic goes to the intended destination untouched. We are not storing or mining any of the data that passes through the proxy. The proxy does nothing malicious - it's designed to make your shortcuts work seamlessly with the Google Toolbar and similar services, giving you the best of both worlds.

Like all OpenDNS services, the proxy is respectful of your privacy. We do not track any of the searches made through the proxy. In fact, since so many people use Google we automatically rotate and delete the logs frequently. We do not store any of those logs, nor do we perform any non-operational-related analysis of the traffic sent through the proxy at any time. Protecting your privacy and delivering a fantastic navigational experience will always be two of our main goals at OpenDNS. We believe that this solution provides just that, and continues our tradition of innovative services that make your Internet experience with OpenDNS faster, safer and more reliable.

Ultimately, this proxy serves to enhance the OpenDNS experience and we recommend you leave it enabled.

Also, from the OpenDNS FAQ regarding the workaround for Dell adware:

Will this make Google slower?
No. We are doing this URL redirection on all of our servers in all of our locations. Loading Google should take no longer than it took before we made this change. Also, all of Google's other domains like like gmail.com and even subdomains like reader.google.com still work as they did before. We don't re-route any of those.

Are you tracking or keeping a log of my searches?
No way. Absolutely not. We don't keep cop

Monopoly

[Anonymous Coward]

If your ISP isn't patched, perhaps it is time to switch.

My ISP has a monopoly over internet services in my area you insensitive clod.

Re:Monopoly

[martin_henry]

Clearly your only option is to just unplug & turn in your geek card. Sorry.

Re:Am I safe?

[masdog]

Dan Kaminski's website has a DNS checker on it.

Re:how do I check?

[A beautiful mind]

Click here.

Re:Am I safe?

[MankyD]

http://www.doxpara.com/ They have a dns checker on the right hand side. This is linked from the original /. article on this topic.

Re:how do I check?

[masdog]

Dan Kaminski's website has a DNS checker on it.

time to switch?

[Dunbal]

If your ISP isn't patched, perhaps it is time to switch.

      Thanks to the "free market economy" in my capitalist country I can't switch, you insensitive clod!

DNS became slower

[sucker_muts]

Here in Belgium, I use Scarlet as my ISP.

It seems that dns queries have become much slower. With opera I can see what urls are being requested (main page, images/flash or ads).I can see that for every new page the first thing opera does is doing the dns queries for all the urls. And this has become very slow from time to time.

I've read somewhere that the randomization really slows down bind, but that the team is working on a patch to solve that.
(I also don't understand why opera need to execute dns queries every time I click a link, why can't opera have a tiny cache for the ip addresses? They don't chance that often, do they? I'm not very paranoid about the security implication, either.)

Re:DNS became slower

[Lennie]

If it has become slower, they are probably using bind9, because it's quick fix. After they've known for 6 months, all they could release was a quick fix. Even though the author/organsation that created/maintainces bind knew about possible problems somewhere in the preview century. I'm sorry, but I've stopped using their software as much as possible.

AT&T Southeast way behind the curve

[BDaniels]

We use AT&T (formerly Bellsouth) and their servers are not fixed according to the 'dig +short porttest.dns-oarc.net TXT' test.
I contacted their NOC about the problem yesterday and got the following reply:

"Patching for these servers are scheduled to begin next week."

So, major vulnerability, two weeks advance notice, exploit code released - we'll get around to it later.

Re:Am I safe?

[Nos.]

There's a couple issues with the one Dan created. First, its slashdotted. Secondly, some ISPs don't allow querying from just anywhere, only from its own customers (IPs). Here's a test you can run from any machine with dig on it:
https://www.dns-oarc.net/oarc/services/porttest

Re:Am I safe?

[Lennie]

dig +short porttest.dns-oarc.net TXT

Oops.

[Chameleon Man]

I tried to RTFA, but upon clicking the link I was directed to a porn site.

Easier Said Than Done

[foo fighter]

These kind of systems are really hard for security guys to get changed.

It's like updating switch and routing firmware. Most network engineers who know what they're doing and that have been around for awhile have been burned by "simple" or "easy" patches and config changes going tits up.

When your core network infrastructure goes tits up your phone tends to light up like a christmas tree. (Granted, when your web presence is redirected to porn or a copy that hides an iframe exploiting customers with unpatched browsers, well, you'll maybe get some phone calls.)

This DNS patch is a case-in-point: Microsoft's fix is rather ham-fisted and broke stuff; the BIND-Users list is full of people troubleshooting ISC's patch.

Also, many organizations (like mine) are taking this as an opportunity to reengineer their DNS architecture. This is the perfect time to reevaluate using TSIG and DNSSEC if you don't already.

It has only been just over two weeks since the initial "announcement". The progress so far is really amazing when you consider how big a ship the Internet is.

Re:Easier Said Than Done

[Lennie]

It's a perfect time to start using PowerDNS, djbdns or Unbound/NSD as well. :-)

Re:Easier Said Than Done

[prandal]

When your core network infrastructure goes tits up your phone tends to light up like a christmas tree.

Not if it is an IP phone!

Rediculious requirements

[Coolhand2120]

Maybe if the patch didn't require that open up all incoming and outgoing UDP ports on the DNS interface I could implement it faster. Seeing how most people use firewalls it makes it really quite a bit more difficult than just "apply the patch".

NOTE WELL: This update causes BIND to choose a new, random UDP port for each new query; this may cause problems for some network configurations, particularly if firewall(s) block incoming UDP packets on particular ports.

I'll get this patch applied as soon as I reconfigure my entire network topology.

Re:Rediculious requirements

[billcopc]

You can restrict it to a port range... even giving it access to 2048 ports gives you 2^11 randomness, which is still better than 2^0.

The issue I'm facing, which I find terribly frustrating, is in upgrading older distros. I'm now looking at completely reinstalling a bunch of older BSD servers just to get this idiotic vulnerability resolved, because the maintainers aren't backporting the patch and upgrading BIND itself would be a royal pain. Given how DNS servers tend to run unattended for eons, I suspect this near-sightedness is respnosible to a large degree for the slow patching. It's not that I don't want to patch my servers, it's that I now have to waste a day at the colo doing physical reinstalls. If it weren't for that hitch, I'd be done already!

Re:Rediculious requirements

[molo]

Maybe if the patch didn't require that open up all incoming and outgoing UDP ports [securitytracker.com] on the DNS interface I could implement it faster.

That is not the case at all. First off, on outbound requests, the destination port is still 53. The _source_ port is what gets randomized. On inbound replies to the randomized port, your stateful firewall will see this as an ESTABLISHED connection and you can safely let it in without blindly opening up the entire UDP port space.

You _are_ running a stateful firewall, right? Its not 1998 anymore.

-molo

OpenDNS is not the best answer

[rfunk]

OpenDNS returns their own search page for bad lookups, rather than NXDOMAIN, breaking various things. They also send queries for www.google.com to their own server. (I wrote about this recently.)

Re:Error 404: Page not found.

[deraj123]

First, it's not a 404. A 404 is a http server response that says I don't have the resource you're requesting.

OpenDNS however, hijacks the DNS protocol when you attempt to lookup the address for a server. And so yes, a dns response that says that no addresses are found is more useful than a fake address that, if you connect using http, will provide an html response with search results on it. Note that this breaks any other use of DNS where you now connect to the server and get garbage rather than simply being told that the server address doesn't map to an IP address. If I wanted to do a search, I would do a search.

That being said, you can turn off all of the "enhancement" options in OpenDNS, and it works great as a DNS server.

Re:Error 404: Page not found.

[drinkypoo]

"404 error: File not found" is more useful then the OpenDNS search result page?

Yes, yes it is. Because many, many things depend on getting a proper 404 error, like all those http-download automatic updates for example.

Of course, it's not the 404 error that's missing. It's a name resolution failure. This is also very important. You need to know when a domain has gone missing, and it needs to be available in an automated fashion. The proper, per-specification behavior is to return NXDOMAIN when there is no domain found, not to return a bullshit, erroneous result.

This WOULD be LESS offensive if all internet traffic were HTTP, but it is not. If you make a request to a time server and the FQDN doesn't resolve, you're not supposed to get the address to your ISP's webserver instead. So even if they serve a 404 error with their search content which would satisfy web clients, they'd still be hosing every other application on the internet.

So, are you trolling, or just utterly unqualified to have this conversation

OpenSuSe 10.2 RPMs miss the point?

[the_olo]

I have an OpenSuSe 10.2 x86_64 machine and have manually upgrade-installed the x86_64 RPMs from the security announcement (http://lists.opensuse.org/opensuse-security-announce/2008-07/msg00003.html). Yast2 has some problems due to this release being old and mirrors not available so I did a manual "rpm -Uhv".

Still, from a traffic dump it seems that on SuSe 10.2 the caching Bind nameserver sends out queries with predictable source ports (incrementing by 1).

Fedora's patched Bind sends from random ports (didn't run statistical randomness test on them, though).