Child Item

Site Totals

61432 Questions Answered 270 Categories

Harmful DNS caching in Droid 4 and other recent Android phones.

I am a quality assurance manager in a software organization. As such, I'm gonna ask you to at least consider the possibility that i might know what I'm talking about.

My Droid 4 is caching dns records for things like email server addresses with the result that i have to reboot my phone before and after work each day if i wish to remain connected to my employer's Exchange server.

Basically, when I'm at work, I'm on the corporate wifi, and thus inside the corporate network. The DNS servers are configured such that the OWA server host name points to a 10.x.x.x non-routeable ip address when looked up from inside the corporate network. From outside the corporate network, i get a regular internet ip address.

This is a common and appropriate DNS server configuration, particularly for large companies with many offices such as the one i work for.

So, after using Corporate Sync while on the office wifi at work, when i then come home at the end of the day Corporate Sync is still trying to connect to the internal, non-routeable dns record which is now unreachable, and will persist in doing so even if i delete and re-create the account on the phone.

Unless i reboot the phone, then it looks up the ip address of the OWA server again, and it again works.

And then in the morning when i go to work and connect to the corporate wifi - and wouldn't you know it, i have NO verizon data signal in my office at all - it tries to connect to the external address, and fails because the corporate firewall prevents it. Until i reboot the phone.

I am not the only person to observe this behavior. See this thread:

>Link deleted to comply with Forum Terms of Use<

A well meaning person added some aggressive DNS caching to recent android distributions used by Verizon, and it has unintended consequences.

Please fix it.

Message was edited by: Moderator

Comments

demmo86rt

This needs to be directed to Verizon themselves and, more appropriately, to Motorola, possibly even Google. Verizon doesn't deal with the firmware on the phones, other than some QC testing for their network, though, if they feel this is a big enough issue, may have some pull in getting it fixed. Google writes the OS, and Motorola adjusts it to work for this particular phone. This site, however, is a peer-to-peer help forum and, other than moderation duties (as you can see by your edited post), and the occasional attempt at solving an unsolved thread. If your post was intended purely for information purposes for other users, that's fine (though that's not what I saw as the intent), but for a real fix, you would be better suited to copy and paste your post and email it to somebody from all three companies.

ej0rge

My experience trying to communicate with large faceless companies as an end user leaves much to be desired. I hoped that this post would serve as a sign post at best. Though i admit that it was late and i hadn't fully considered the probability that nobody who has access to anyone who can do anything has any idea what goes on here.

Verizon absolutely has quality control oversight with regard to android builds on phones they sell.

This was probably a stunt Motorola pulled. Caching DNS beyond the TTL included with the record is the sort of ignorant tomfoolery that i can't picture Google ever attempting.

if you search the interwebs, there are a few other mentions of this behavior, all attributed to recent gingerbread builds on motorola/verizon phones.

The long & short of it is that if a recent droid customer is on an internal corporate wifi when they set up Corporate Sync, and their internal dns points to a local (non-internet) address for their OWA server, Corporate Sync won't work as soon as they leave the range of their corporate wifi.

And it'll stay not working until they reboot, even if they delete the account and add it again.

Some subset of these uesrs will find that they have to reboot again when they get back to work.

Essentially, somebody made a design decision that suspendered old unix geeks ruled out as a bad idea 40 years ago, which offers a majority of users an imperceptible performance increase in return for breaking functionality for a minority of users.

It's one of those things that sounds like a good idea at first blush, until you start exploring use cases. And frankly, as someone who has worked in software QA since 1998, it's the sort of thing that makes my blood boil.

It's like deciding that your car is more secure if there is only one key in existence. This is entirely true until you discover that you've locked yourself out.

smashogre

I'm a little confused. Are you saying that your exchange box has the same name both internally(Private) and externally(Public)?
Name meaning CNAME, HOST or what have you...?

For example if I'm connected internally I would go to servername\OWA. If I'm outside however I would go to mail.servername.com\OWA.

ej0rge

Precisely.

The company i work for has dozens of offices in several countries, and a

very complex routing and firewall infrastructure. There are numerous

internal dns servers which provide internal dns addresses for various

services, which are selected to provide the shortest route to a given

service. It's even possible that there is more than one internal OWA

server, and if i were to visit an office in the UK or asia for example i

might get a completely different ip address for the same fully qualified

hostname.

To give you an idea, there are no less than 7 network hops - each a router

or firewall - between my work desktop and my gateway to the internet,

because much of my internet traffic is backhauled through corporate

headquarters for filtering, proxying, and firewalling.

This sort of thing is part of the reason why dns records are provided with

a time-to-live specified - meaning that the response should only be

considered cachable for a specified length of time. You can set the TTL to

a really high value, but it's generally considered inadvisable to do so

because caching dns servers and clients will hold onto the record until the

TTL expires, which might be some time after you tried to push out an update

to your dns table.

Caching a dns record longer than the TTL decreases the total number of dns

lookup requests that have to go across a network, which would decrease

latency in some applications - for example when you go to a new page at the

same website - but this comes with well known pitfalls. Specifically that

the cached data might be incorrect.

smashogre

Very well, I just wanted to clarify. We use separate and distinct DNS for obfuscation purposes(among others)

The issue you're describing isn't Verizon's fault however, seems to be a purely Android thing.
You need to flush the DNS cache manually - I haven't searched but I'm sure there is an app/method.
In your case - somewhat of a perfect storm - I can understand your frustration.

ej0rge

I have several android devices. Just this one has that problem.

like i said, Verizon does have quality control oversight of the android

builds on the phones they sell. Motorola does their QA, and then Verizon

does their own acceptance QA. Do you think Morotola would say "No" if

Verizon asked them to change something?

vzwmaxx525

I actually found this very helpful as I wasn't sure if what I was experiencing was limited to myself, my phone and my situation or if this DNS issue is wider in scope. I noticed the very same behavior from within a corporate environment with OWA, for the same reasons as the OP. I am running a RAZR Maxx with the 6.12.181 update.

I am very hopeful that this issue will be resolved in ICS but I really can't be sure. I have a coworker who is seeing the same behavior on at least one of two Honeycomb tablets. My DroidX running Gingerbread 2.3.4 worked just fine.

I haven't done testing to determine if this caching is unique to the Corporate Sync app or if it extends to the browser and other apps. An option to disable DNS caching within the OS or simply clearing the DNS cache when the network connection changes would seem to be a simple fix by Moto/Google. Has anyone contacted them? There might still be time before the ICS update is released. I have even considered installing a leaked ICS to confirm/deny that this issue has been resolved. We shall see...

vzwmaxx525

Greetings all:

This issue is resolved in ICS. Hopefully the Droid 4 gets the update soon. RAZR and RAZR MAXX working flawlessly.

Child Item