DNS Cache Poisoning Risks - Case Study

Third party providers bring a lot of benefits to a website including lower operational cost (CDNs), revenue generation (Ads), and better insights (Analytics). Just like any component of a system, they also bring risks, which both providers and sites try to manage by various means.

The most talked risk is the performance impact they introduce on the website or application via a JavaScript tag on the page, poorly written code, or slow API calls. A second widely publicized risk is end user privacy – providers gathering user information across sites without site or user knowledge (on purpose or not).

Recently, we came across a third risk that can have a major impact on site operations that is not in the spotlight. While working with a large ecommerce company we noticed DNS errors every so often while monitoring their mobile site. After hours of troubleshooting and experimenting we discovered that the mobile site provider, Usablenet, was inadvertently poisoning the DNS cache.

What is DNS Cache Poisoning?

DNS cache poisoning refers to data breach, whereby new DNS records are introduced in the DNS Cache of a resolver or computer and divert traffic to a different IP address. The cache poisoning can be caused by hackers trying to divert traffic to a phishing/malware sites or it could be a configuration mistake. In either case the end result is not good for end users – they will end up accessing the wrong site or not access your site at all.

How It Can Happen?

Usablenet is a leader in mobile transformation and its platform powers the mobile websites of major brands like Expedia, Dell, Fedex, etc. Its platform allows companies to quickly transform existing websites into mobile websites that match the capabilities of the end users device.

One key requirement of their mobile platform is that the DNS record for the mobile site is handled by Usablenet. For example Expedia’s web address is www.expedia.com and points to Expedia’s servers; however, for their mobile site they created a new DNS record “m.expedia.com” and delegated it to the Usablenet authoritative DNS servers.

Using Dig (DNS query tool), I queried where is m.expedia.com using one of the OpenDNS servers:

dig +norec +trace @208.67.222.222 m.expedia.com

here is the Dig output:

The problem occurs when the mobile DNS entry is resolved. When Usablenet authoritative servers are queried they not only provide the A Record for “m.expedia.com” (twice), but also provide a new NS record for “expedia.com”. Essentially they promote their DNS “system balancer.ky.4usable.net” to be an authoritative server for the entire “.EXPEDIA.COM” zone and setting a TTL of 38,400 seconds or 10 hours.

DNS CACHE – LAST RESPONSE

This is one way of causing CACHE POISONING and it is BAD practice. You can try these domains which have the same problem:

• m.chanel.com
• m.asos.com
• mobile2.macys.com

Why Is It A Bad Practice?

If an end-user accesses “m.expedia.com” and then tries to access any of the Expedia domains like “www.expedia.com” or “mail.expedia.com”, their ISPs DNS resolver can end up querying DNS records from the Usablenet, since their servers are one of the authoritative records. The end result will be a DNS failure, the user will not be able to access the site. The issue will be amplified as the data is cached by the DNS server and utilized for other end users configured to use it.

Luckily, the majority of the end users access these domains on mobile devices and the DNS servers these devices rely on are not the same as the one configured for the desktops. Still the risk is there and its impact is not easily measured. Real user monitoring and web analytics solutions cannot track such failures (if DNS fails the website server never receives the HTTP request, does not log it, and the analtyics/rum tags never get served to the end user).

There are other 3rd party providers that rely on clients delegating a DNS entry to their systems to provide mobile experiences, ad serving, vanity domains, etc. If your company is required to perform such DNS delegation follow-up and ensure that the provider is not inadvertently poisoning your DNS. Remember DNS is the first encounter a user has with your brand, protect it and demand that your partners do the same!

Mehdi Daoudi – CEO of Catchpoint Systems.

Note: The issue detailed in this blog post was resolved by the vendor as of March 15 2012 as noted in the comments.