IssueTracker

I can confirm this happens for me as well.

This actually happens on Maemo as well. I simply added this line to the /etc/hosts
192.168.0.1 joynet

I don't know if you can do that on Android w/o "rooting" (or something else). It's not
really a good solution either since it should resolve automatically...

Yep, you'd need to "root" the device to gain access to /etc/hosts, and that would
void warranty and possibly give other problems too when you are out of support from
the manufacturer.

And with further testing it seems like it is not really restricted to domains,
Android seems to regard any single-name hostname to not being a valid hostname. I
guess this is related to the fact that Android devices do not seem to set themselves
a name either (you can see on DHCP daemon that the phone has no associated hostname).

So this seems to be a wider problem regarding local hostnames.

If this is fixed, make sure that if a VPN connection provides a domain name via DHCP,
do NOT overwrite the WiFi's domain name, just append it to the search path.

At least add domain name search path properly via DHCP attribute 119 or at LEAST attribute 15.

I would like to see this fixed as well.  My android based phone is nearly useless on our intranet because of their organic nature the FQDN isn't often used (if ever) so me adding the domain to the server is always a pain.

Please implement DHCP Domain Search on Android!!

Similar problems in my company network. Please help..

I even have an internal dns defined for my wifi connection for my .local domain.  Using internal ips work just not the fqdn.  Seems strange as I have proper dns servers defined.

DHCP attribute 119 and attribute 15 are important on a corporate network, as not everything uses FQDN.

Please fix.

Yes, I run a .local domain, with proper dns servers running. Android devices will not resolve any .local address.

Same problem. Very annoying in a professional setting.

My device is a french Milestone, android version 2.1 update 1

The problem is accessing a local one-label web page which should be resolved with appended subdomain (DNS search suffix)
 tcpdump on the DNS : #
[root@mydnsserver htdocs]# tcpdump port 53 and host 192.168.0.123 -vv
#
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
#
10:08:33.537987 IP (tos 0x0, ttl  64, id 44233, offset 0, flags [DF], proto: UDP (17), length: 52) a123.mylan.mydomain.tld.11524 > mydnsserver.domain: [udp sum ok]  10982+ A? mywebserver.M-P^GM-^X. (24)
#
10:08:33.538971 IP (tos 0x0, ttl  64, id 41714, offset 0, flags [none], proto: UDP (17), length: 127) mydnsserver.domain > a123.mylan.mydomain.tld.11524:  10982 NXDomain q: A? rd.M-P^GM-^X. 0/1/0 ns: . SOA[|domain]

Note the "M-P^GM-^X." where there should be the DNS suffix mylan.mydomain.tld.

Of course I can't access my web intranet on its adress http://mywebserver

Please Google do something ! iPhones don't have this kind of problem !

I'm having the same problem.  On IOS I access my DHCP media server as audiobox.local.  Android insists on a numeric IP address.  What a pain.

It looks like android actually needs a FQDN

my machine name is jsharp01...ping jsharp01 yeilds nothing
pinging jsharp01.us.$$$$$$$$$.com yeilds results.  This happens with anything inside of DNS...if i try and ping a short name it fails, but if i ping a long FQDN it resolves just fine

Any idea's other than rooting

Again, see DHCP attribute 119 or and attribute 15

"Again, see DHCP attribute 119 or and attribute 15"

This option is defined on the DHCP server.  .local domains do not resolve.

Yes, I mean, the bug is that android IGNORES 119 and 15 IMO

FYI, this appears resolved in 2.2. My epic finally received an update and this was fixed for me.

FYI, this appears resolved in 2.2. My epic finally received an update and this was fixed for me.

As far as i know, both 2.2 and 2.3 still ignore DHCP attributes 119 and 15

my /etc/resolv.conf still only has nameservers, no search path. What did you do to tell your phone what domain it was in?

[Comment deleted]

This Bug still occurs.  I have the issue both on a Motorola Xoom and HTC Thunderbolt.  I cannot get the DNS Search Suffix populated via DHCP.  I have to browse internal Web Sites via FQDN only.
 

Confirmed here as well (froyo).  Added scope option 119 (15 was already set) and still no change.  Very disappointing.  Looks like the "other camp" just introduced this problem recently too:

http://discussions.apple.com/thread.jspa?messageID=13335754

Confirmed here also. We got a intranet and can't resolve any ip address in our network.

Please fix this...

Running the Motorola XOOM at work, and trying to show that its a 1+ above an 1Pad(flash support) but because of this.. its not looking so good :(

PLEEEEEEEEEASE FIX!

I can also confirm this.  Please fix.

Added to cyanogenmod bug tracker

http://code.google.com/p/cyanogenmod/issues/detail?id=3779

Obviously google won't fix this. Hopefully the CM guys will.

Good idea!  I sure hope the google folks tackle this though.  We're going to be investigating tablets for corporate apps.  Being mostly intranet, android based devices may be disqualified immediately.

In the same boat as everyone else.  Can't browse internal intranet site using the short hostname.  Have to use FQDN (which is not a solution...just a workaround). Trying to show senior management the pros for going Android Tablet vs iPad2 and this has just put a HUGE stop on the efforts since they cannot easily connect to our Intranet.
I unfortunately will have to report back to them that the iPad2 wins...

We're having the same problem here. This is ridiculous because the problem has been present for well over a year. Rooted devices have a solution, iPhones/iPads just work. While I think it's fair to say that most of us love Android, problems like this need to be addressed quickly.

Whats the solution for rooted phones?

same issue on honeycomb 3.1 - Acer Iconia - any workarounds other than fqdn?

This happens on my Nexus One running Gingerbread and my Motorola Xoom running Honeycomb 3.1.  FQDN is the only way to resolve internal DNS.

Android is based on Linux, Linux resolves DNS Suffix to local host names just fine, what is the big hold up to get Android doing this?  Seems like Android is aimed at consumer market, enterprise is not well represented when these (predominately enterprise) issues persist across versions.  Just another nail in the coffin holding us to iPhone/iPad and preventing real enterprise deployment of Android.

just got Desire z with android 2.3, can't believe this is not working.
Just look at the following case (example):
You have an email account on server "buzz".
This server is accessed via wireless corporate network and resolves to private lan by adding corporate.intra domain, the same when accessed via VPN.
When using other external connection, I would like to add corporate.com (because this resolves to public fw ip address) to access the same account.
Well, I think this is quite a common setup and can't believe it's impossible on Gingerbread! Or maybe there is some other net topology is unknown to me to solve the same kind of problem.

I would say modifying /etc/resolv.conf would work.

Of course, # vi /etc/resolv.conf is a pain through the virtual
keyboard... so pushing the file through adb might be _much_ easier.  :)

And requires a rooted device.

And requires editing files on a phone/tablet with _vi_!

Give vi editing instructions to your executive staff and see how far you get with it.

And.. its permanent, whether or not you are connected to that particular local internal network or not.

The whole point of DHCP is to allow dynamic configuration.

Absolutely agree - it is not an enterprise solution, but a workaround.  

Google should fix this.
on my project, users cannot login to the local server through their galaxy tab 7.
my nexus s 2.3.4 can not do it too

Without support for DHCP tags such as WINS or dns suffixes, the andriod platform is useless in a corporate environment.  For example, we use a transparent proxy to authenticate web browser traffic.  The android cannot resolve a short hostname, because it doesn't except the dhcp dns suffix being handed out to it.  It won't accept WINS either.  Having to root the phone and modify the host file isn't a corporate solution.

I suggest at least looking at the issue or responding to the user posts.  I'm running an LG revolution 2.2.2, and an acer android tablet.  Both have the same issues related to dns suffixes not appending properly.

I'm suffering from the same problem here. Please fix this.

I'm afraid they won't. Seems like it's not a bug, but a feature. At
least it seems to be done on purpose.

For those of you who need a workaround till this is fixed and are running bind, add "check-names master warn;" to the "options {};" section of your named.conf and restart named. This will cause named to allow the use of a "-" in the host name.

here is a lookup from my DNS server with this implemented:

# nslookup 10.0.1.194
Server:         127.0.0.1
Address:        127.0.0.1#53

194.1.0.10.in-addr.arpa name = android_d4b2fobfuscation.stjohn.home.

; The only change was the hex for privacy.

@mirhun...
I think you've either posted to the wrong thread or misunderstood the above.

@olivier...
I was wondering if this might be intentional, but I don't see what purpose this would have in improving device security.  That would be the only possible thing that would warrant this "feature."

Can't understand why there's been no response from Google to this point.  How do we escalate this?

It is really frustrating. I'm being tempted into rooting my device to edit the hosts file, but I don't wanna get into risks. Without any feedback from Google, I'm loosing hope on having it fixed anytime soon...

I cant believe Google aren't doing anything about this.
OK it might not be a big issue in the consumer space for Joe Public who doesn't have a private network, but it's a show stopper in the corporate arena.
I couldn't recommend adopting android phones or tablets within an organization purely on this one issue.

I really wanted to use an Android based solution, but will not be able to due to the DNS issues.

It seems like the /etc/dhcpdc.conf file is to blame here. It seems to be called android.conf in the source repo.

https://github.com/android/platform_external_dhcpcd/commits/master/android.conf

The configuration parameters domain_name(15) and domain_search(119) are missing from the option line. Seems to me dhcpcd supports those options but the android config file for dhcpcd ommits them.

[Comment deleted]

Does anybody know if there is any workaround on this? (without having to root the device). Is there any way to configure the device or browser to always interpret or modify a given address to its FQDN form? I use Sharepoint, and I can use the FQDN address with no problem, but as soon as the server redirect me, the browser stop finding the server.

Any third party application perhaps?

[Comment deleted]

I can't believe Google is ignoring this very simple issue...
I found out that simply adding the local domain name to system property net.dns.search solves the issue:
setprop net.dns.search "domain.local"
I changed dhcpcd.conf to request the domain_name and domain_search options and tried creating a dhcpc hook that would do that automatically but for some reason the property would not be added. Testing showed that the option domain_name was correctly obtained (${new_domain_name}) but the property would simply not be added. Any suggestions?

Have you dug around in the AOSP tree? setprop shouldn't fail... perhaps your hook is wrong?

On the current build of ICS / CM9 for my Galaxy Note, the problem is actually in permissions. dhcpcd is running as user dhcp which isn't allowed to change properties.
I'm trying to use su -s "setprop..." but I'm seeing errors in the log like this:
W/su      ( 5098): request rejected (1014->0 setprop net.dns.search domain.local)
The Superuser app doesn't bring up the box to confirm root access... Not sure how to go about this.

Come'on guys!! This is like more than a year old Bug!! And not just a bug, but a Major Bug!

My colleague has a BB and they don't have this problem!!

Please Google make this work. If not... a lot of company's will never gonna use a Android device.

My company is deploying a guest wireless network now using an https:// redirect to an internal guest logon page.  Android devices can't bring up the https:// web page due to this issue with Android devices not accepting DHCP option 119.  DHCP option 119 specifies the connection-specific DNS domain suffix to be used by the DHCP client.  The lack of a DNS suffix prevents the client from resolving the https certificate name and renders the https guest logon page useless.  This issue means our guest network will not be able to support android devices.  Please resolve this issue!!!

I bet Google won't be fixing this anytime soon. Here's why :

- http://forum.xda-developers.com/showthread.php?t=1107482
- http://seclists.org/fulldisclosure/2011/May/317

Summed up : Suffixes are evil. FQDN are good. Use FQDN or F... Y..

I can't believe this is still an open issue. Makes me think that either me or the company I work for is not configuring well its network resources, or there are few people out there that need the ability to connect to servers inside an intranet.

I can connect by using the FQDN or IP address, but the servers redirect me to other pages within the sites and the connection gets lost.

I have decided to root my device. Sorry if this post is more emotional than technical, but I'm really dissapointed with the level of attention that this bug is taking from Google and the lack of workarounds to resolve it.

[Comment deleted]

A (poor) work around I have found is to connect to your corporate network over VPN where the settings INCLUDE a search domain
e.g. following these steps: http://www.techrepublic.com/blog/smartphones/connect-to-a-pptp-vpn-from-your-android-phone/2145

frustrating but it works, plus user is prompted for VPN password every time they connect (unless they download a market vpn app). Clearly this isn't a work around which will help in every situation.

[edit: forgot about search domain]

Like many others not even a FQDN will bring up my local pages I have to use the IP address, everything fails.

I would be happy if the FQDN would work as that is what I use anyway so I can connect to my resource internally or externally, that is somewhat the point of being mobile.

@robway, if you cannot use FQDN then your DNS servers are broken.
Simply put, if you can use FQDN on your computer in the same network, you can use them on Android. I've never had any problem with FQDN.

@p..., following this thread it doesn't really sound like my DNS is broken as all other devices will resolve, everything except android devices, so it sounds like the 'bug' others are referring to.  I made sure i have attributes 119 and 15 included in my DNS.

Thanks

Robway, if FDQN does not work your problem has nothing to do with this bug.

Olivier:

Bull. You either trust your DNS server, or you don't. Both of those articles are naive.

If you don't trust the DCHP server to hand out a search path, why do you trust it to hand you the IP to a DNS server, which could also be compromised?

And if you don't trust the DNS or DHCP server, why do you trust your default gateway, which could also hijack DNS requests?

More importantly, claiming that everybody should exclusively use FDQNs is ridiculous. I use search paths all the time from the CLI ("ssh hostname". "scp hostname", "rsync hostname", fns/autofs hostname key namespace, etc. etc. etc.) Why not the browser too?

Bottom line, there is absolutely NO excuse for google to not support 15 and/or 119. If you are concerned about security, open a new bug making it adjustable per Wifi connection. But remember, you're going to want to override DNS server as well... which still doesn't solve the problem of a rogue default gateway.

[Comment deleted]

4.0.3 still has the problem. This means our company will NOT use android tablets on our wireless network …
You can not expect everyone to use FQDN or ip addresses everywhere!
Google, get this fixed!

Most certainly still an issue and one that will prevent our 19,000 employees from using any Android device on our intranet!

I'm starting to think we're barking up the wrong tree... maybe if we took the issue to someone who has a stake in selling enterprise devices?  (ASUS, Samsung, etc)

I know I've brought this up before, that rooted users can modify their hosts.  Well, now there's an app for that:
https://play.google.com/store/apps/details?id=com.treb.hosts&hl=en

Yes, I know... not an Enterprise solution...

This is a very frustrating issue that has been known for 2 years and is still not fixed.  How hard could it be to recognize options 15 from DHCP?  iOS does not seem to have this issue...  Please fix.

Same issue here, with Android 4.0.4, its really annoying.

"Robway, if FDQN does not work your problem has nothing to do with this bug."

Unfortunately not true at all. Corporate servers, like SharePoint, commonly redirect immediately to their hostname, even when you are connecting with FQDN (which is resolved properly). So it doesn't work and it is caused by this bug.

@mvasko: that sounds like a broken server.  I would think a redirect to a different server should always be an FQDN.  A server cannot assume anything about the client's resolver being able to figure out which domain it's redirecting an unqualified name to.

@brianjmnu
IMO
- server can assume it can be resolved - all clients are in domain network and expected to resolve unqualified names in that domain
- it is more future proof. Domains need sometimes to be renamed or migrated... and less things will be broken if you don't use FQDNs in links etc. Users often simply copy URLs and use them somewhere for instance.
In any case, why to go head against the wall, Android will hardly cause corporate infrastructure to be reconfigured, it simply won't be used.

FQDN for internal servers doesn't work for me either.  Works only by IP directly.  
Seems strange as on all other IOS/Windows OS, it just works.  

I'm also quite surprised that as a platform that is suppose to target more technical crowd, there is no simple way to even look at the advanced DNS/Gateway settings which IOS/Windows all have.  

Basic IP stack stuff (supporting DHCP option supplied domain suffix) and still not fixed? Come on guys, this is a basic requirement.

[Comment deleted]

I can confirm it's still broken in 4.1.

A google internal feature request has been entered (6799630) and we'll try to get to this when we can.

We also are facing this issue trying to test mobile websites in our development environments.

I can also confirm this is an issue on my corporate network. I need to use FQDN to access any internal sites.

also confirm for Android 4.1 (Jelly Bean) on Nexus 7. I can't believe this is still lingering after 2 years.

SIte development specific for the new Nexus 7 is at a stand-still because we can test across all iOS devices but not Android.

Ridiculous. Please address this.

[Comment deleted]

Nexus 7 has this issue. My tablet will be sold soon entirely because of this.

Sorry guys.  We're not idle but there are alot of issues to work on.  The code is opensourced, so if you want to try to fix this or know of an existing fix give a reference to the fix here and I can expedite its adoption.  No way the fix will be released in weeks either way - we don't get to do ad-hoc release cycles.

to fix you'll need to do 2 things:

1) determine the WINS server.  It should be obtainable during the DHCP exchange.

2) integrating nmblookup behavior to resolve netbios to IP.

http://www.samba.org/samba/docs/man/manpages-3/nmblookup.1.html

A proper DNS system does not require a wins server, let alone netbios resolution! That is hardly a fix. It isn't even a reasonable workaround.

I do not argue on the definition of a proper "Dns" system.  The bug/issue here is that android does not resolve wins names, Which creates a problem in corporate environments where wins is used.  The steps proposed makes it resolve wins names.  

This does not even have to be in the main dns module, but used as a fallback when main dns resolution fails. I fail to see how adding on domain suffix is a better solution as the main issue is wins resolution.  

No, the bug here has nothing to do with WINS.  The names we want to look up really are DNS names.  NetBIOS names, as used by WINS, are separate beasts and much more restrictive.  For instance, the name this-is-not-a-valid-netbios-name is not a valid NetBIOS name; however, it is perfectly valid for DNS.

We just want the basic and pretty ancient ability to automatically use the DNS domain suffixes as commonly distributed by DHCP servers when DNS fails to find an exact hostname of interest.  To you, this may appear to be the same thing as performing a NetBIOS lookup via a WINS server, but it is not.

I agree with the person above me: This bug is NOT about WINS at all. It is about Android respecting the DNS domain name search suffix list as given by the DHCP server on a network.

If you need WINS support/resolution, please open a separate issue and don't pollute this one.

Actual it has more to do with URI handling. If you put name.suffix in the address bar, bare, the browser will treat it as a search term instead of a browser request if "suffix" is not on the default list.

If you prepend http:// it works.

I have not found a way to add ".suffix" to the list.

[Comment deleted]

> It's not uri handling, it's not wins and it's not netbios. It's dhcp and dns.

I agree. The main issue here (in this bug report) is that Android ignores DNS search suffix provided by DHCP.

However, URI handling by browsers does enter into it as happyp... mentions. unfortunately (for us more technical users) the same behaviour can be observed in desktop browsers too (at least desktop Chrome and IE 9).

Hello again,

Could any of you more knowledgeable Android fans assist me with developing a fix for this issue - be it at least for rooted phones? I've been looking into this issue for quite some time and this is what I've found:

1) The DNS search suffix is stored in the system property "net.dns.search". When it's set DNS resolution of simple hostnames WORKS:

shell@android:/ # ping errorek
ping: unknown host errorek
2|shell@android:/ # setprop net.dns.search "fatsoft.co.uk"
shell@android:/ # ping errorek                                                
PING errorek.fatsoft.co.uk (10.10.10.10) 56(84) bytes of data.
64 bytes from errorek.fatsoft.co.uk (10.10.10.10): icmp_seq=1 ttl=64 time=88 ms

2) Android uses dhcpcd to obtain IP configuration from DHCP. The configuration is in /system/etc/dhcpcd. The folder /system/etc/dhcpcd/dhcpcd-hooks contains hooks that are executed on DHCP events - for example, file /system/etc/dhcpcd/dhcpcd-hooks/20-dns.conf sets properties "dhcp.<interface>.dnsX" to the DNS servers obtained from DHCP and exported by dhcpcd as environment variable $new_domain_name_servers

3) DHCP options that are exported by dhcpcd are specified in /system/etc/dhcpcd/dhcpcd.conf. By default, ICS and JB (I think GB is the same) uses these:

# dhcpcd-run-hooks uses these options.
option subnet_mask, routers, domain_name_servers

To get the domain name exported, domain_name needs to be added:

option subnet_mask, routers, domain_name_servers, domain_name

4) I then tried creating a new hook similar to 20-dns.conf; I called it 25-net.dns.search.conf:

# Set net.dns.search property to domain_name from DHCP

set_dns_props()
{
    setprop net.dns.search ${new_domain_name}
}

unset_dns_props()
{
    setprop net.dns.search ""
}

case "${reason}" in
BOUND|INFORM|REBIND|REBOOT|RENEW|TIMEOUT|IPV4LL)       set_dns_props;;
EXPIRE|FAIL|RELEASE|STOP)                unset_dns_props;;
esac

This unfortunately doesn't work - it fails because dhcpcd doesn't have permission to set the property "net.dns.search". I know the environment variable $new_domain_name was exported correctly - when I added

echo "${new_domain_name}" > /data/local/new_domain_name

to the hook, it contained the right domain name when I disconnected and re-connected to wifi.

5) I was unable to use "su" to set the property. Superuser pop-up window is not displayed and toaster notification simply shows something like "shell was denied root access".

--- To be continued in the following comment :)

6) I see that the DHCP hooks actually do not set the main "net.dnsX" properties that control DNS resolution. Instead, they set "dhcp.<interface>.dnsX" as shown above. The property "net.dnsX" must be set from some other script that naturally has permissions to set the property. That leads me to think that the correct way to handle this would be to set the property "dhcp.<interface>.search" in the DHCP hook and then set "net.dns.search" from the other script.

7) I do not know which script is it but I'm going to look into it now. Also, I'm going to confirm that I can set "dhcp.<interface>.search" from the dhcp hook.

Any testers welcome!

Pete

Right. I can confirm that the property "dhcp.<interface>.search" can be set from the new dhcpcd hook as expected. However, I haven't been able to find out where the "net.dnsX" properties are set.

After some more googling it looks like the net.dnsX properties are copied from other properties (like dhcp.<interface>.dnsX) by framework class ConnectivityManager. Duh.

Anybody have any idea how to persuade su to work properly in the dhcpcd hook? I'm getting following errors in the log (adb logcat):

E/su      (27108): select failed with 17: File exists
W/su      (27108): request rejected (1014->0 setprop net.dns.search fatsoft.co.uk)

Pete

I think we are talking about two issues.

1) in a *browser*, "http://" should be optional whenever the string entered *could* be parsed into a valid URI if it had been prefixed with it. Right now private DNS domains get sent right to search even if the FQDN is provided.

2) abbreviated host names are not being resolved with the provided search suffix.

It seems to me that these are really two separate issues, though they both impact people that use private DNS namespaces.

I am also looking for a fix for this issue, not for the reasons mentioned above but to get the domain name and contact a server in that domain.

I looked at the Android open source and ended up realizing that if we could have the Domain name exposed through the DhcpInfo class http://developer.android.com/reference/android/net/DhcpInfo.html, then applications could use it.

To do this, dhcp daemon will need to request the domain name and then the domain name has to be written to a system property (can not write to net.dns.search directly as pete mentioned) and be read and provided to the framework. I have this piece working and if required, I can try to make further modifications to set "net.dns.search" property with the domain name.

However, the bigger question is that does Domain name belong in the DhcpInfo class?

Any suggestions / comments?

Amol

Why bother if you can't modify DhcpInfo to do the right thing? May as well just have /etc/dhcpcd/dhcpcd-hooks do the right thing along the lines of what Pete is already doing.

It's best to pass it to the framework via the dhcpinfo object.  There may
be multiple networks in play and you should let the framework do its think
regarding them.  The LinkProperties object should also be modified.

While you're at it, you could make the DhcpInfo object use an array of dns
server addresses rather than just the pair..

[Comment deleted]

Gday everyone. Put me down too for being at a loss as to why local domain awareness  isn't supported.

As a workaround, there's a good trick involving running up an apache server to handle requests with no domain specified...

The thing that still sucks (and this is another android problem) is having to set the proxy manually.

Android really needs to add support for dhcp option 252 (wpad) and dns configured proxy settings...

We have customers that like Android enough to live with the workaround but I think Android marketshare would increase even more significantly in the tablet space if they can get these two issues sorted...

I can also confirm this on HTC EVO 4G and the Kindle Fire. Both fail on hostname resolution, requiring either hostname.domainname.local or IP address. Not going over very well for those at the company who have android devices.

I can confirm this on verizon galaxy s3. PLEASE FOR THE LOVE OF GOD FIX THIS. :) Thanks.

Bump, please fix

It's really hard to get my corporate environment to switch to Android devices when this problem has been occurring for some time now. Google, please, please, PLEASE get this fixed, and thanks!

@rgreenw : A fix is attempted and available for your review. Please see my email.
Please expedite the adoption as you commented above.

I can confirm that domain name issues exist on Galaxy S2 and also the new Enterprise ET1 tablet.......really really need this resolved as one of our new apps relies on the ET1 Enterprise Tablet

No

No

This is a basic feature of name resolution and really needs to be addressed.

It is embarrassing when IOS supports this. Failing to support this feature will make corporate Android adoption challenging.

Do the right thing and fix this.

To all those who are complaining here like me, please vote for this issues aka:"Star" it to it goes up in the list ;)

Unknowing of this tread, I created another one

https://code.google.com/p/android/issues/detail?id=38037

We see issue on www.greenecs.com

The issue is browser independent, device independent, android version independent (2.2, 2.3, 4.03).

I have tried with Asus Transformer prime with Jelly Belly and it is a no go. Also is it just me or is there not enough attention brought to this issue. I can't seem to find anything on Xda or any other sites, although it seems like SpiceWorks knows of these issue. Has anyone else found other sites talking about this?

http://community.spiceworks.com/topic/142450-we-need-google-s-help-to-make-the-spiceworks-mobile-for-android-better

I can reproduce this on my university network

This is occuring still on latest 4.1.2 :(

Another corporate adopter that can't really use android devices because of this issue.  Really need this fixed!

Still occurs on CM 10 /4.1.2..

Add me to this list, I have had to go down the route of setting up DNS on my homeserver to resolve the issue which is less than ideal. All my other devices are able to use this functionality OK.

Just received the 4.2 update for my Nexus7 and the problem persists.  :(

Wow, two years and the issue persists, way to go Google.
Guess the think "it's open source, fix it yourself, we're too busy with other things".

I was pretty disappointed when I tried to reach my pc over the browser to test a web interface I was working on just to find out it googles up my network name whenever I enter it.
If I wouldn't have had given it a static ip in the network I wouldn't even be able to find it.

Google, you're a failure. How is it that an issue like this goes unaddressed for sooooooo long?

Till this is fixed I can not recommend the use of Android Tablets in corporate use - BTW we are evaluating Tablets at the moment for display of clinical data.

The fix for this has gone in thanks to Kevin Tang.  It will be available in
the next major release.

Wow, in record time too.

4.2? 5.0?

Jeez.... It's about time !! Two year and a half for such an issue ! Please never again, Google.

Guys, it was a matter of prioritization and resources.  We don't have
people to put on every requested feature and we certainly were not idle
during this time.  I apologize it took so long.

I can't say what the next version will be (neither know it nor can discuss
it) but it will be after 4.2, which has already gone out.

[Comment deleted]

This isn't some "requested feature", this is a major functional defect that has been around since -Eclair-.

For god sakes, people, just be happy it's fixed.

Thank you for the status update.  Eagerly awaiting its actual availability.

And that means it'll never be fixed for the devices I have.  YAY! I get to buy new hardware. [/sarcasm]

Seriously though, I'm glad you are working on basic functionality of DNS.

@rgreenw... That's great to hear (although a fix must have been pretty simple, really). Could you please link to the code submitted to fix this issue?
Thanks!

Due to merge conflicts and API changes, the change was submitted internally
and will appear in the next release.  It was based on:
https://android-review.googlesource.com/#/c/42810/
https://android-review.googlesource.com/#/c/42755/
https://android-review.googlesource.com/#/c/42811/
https://android-review.googlesource.com/#/c/42739/

I dont see search path support in that patch,  only domainname.

As I said, that isn't the change that was submitted.  Internally we turned
on both domain_name and domain_search.

Quit emailing me I'm waiting for a nexus 4 and you get my hopes up for a
tracking number.

[Comment deleted]

I want to thank you for implementing the hook and API members for these DHCP options.

I think respecting these DHCP scope options is a great step. That said, I don't think this fixes the expected user behavior in the browser.

Will this fix the problem in the browser documented in #24571:  entering "www.local" or "www" in the address bar invokes Google Search with the entered host name as the keyword instead of performing the expected action of opening the web page at http://www.local .  [In this scenario, assume that .local is the private DNS domain name or appears in the domain search list and "www.local" resolves in DNS to an A record or CNAME to an A record running a web server.]

Too little too late, brought a surface and i'm loving it. Next up, Lumia 920.

No other company would take this long to fix a simple yet important bug, Make excuses all you like Google, but this sort of thing just shows how pathetic Android is.

[Comment deleted]

Not all android devices will be updated to 4.2, that means there is no hope for those devices if Google does not do something about it. I'm not sure if my galaxy s2 will be upgraded to android 4.2. Two and a half years to fix a simple bug? This is not good for the Google brand. Im switching to IOS

@146 fblue2
Worse yet, this isn't just a simple bug, it's *intentionally* breaking native Linux, (and integral DNS) functionality, which has existed for what-close to two decades?

It's inexcusable. Can you imagine the uproar if MS had broken this functionality? It's a core element of DNS!

Let the DNS server do it's job. I simply can't imagine why someone went out of their way to *remove* this.

<DOUBLE facepalm>

Better late than never. Hopefully Google will also be taking a look at the two years outstanding Wifi DHCP lease bug (Issue 36921335) which has been dragging Android's name through the mud in business/education: http://code.google.com/p/android/issues/detail?id=11236

That one seems even more dire since it still doesn't even have an owner.

Thx Zizagoo for the reference.

I'll take a look at it.

LG Nexus 4 with 4.2.1 still see this problem.

Please fix this with first priority.

I'm on Asus TF700t and Droid 4.1.. There is no dns search from dhcp.. I use option 15 and 135. i saw somthing about 119.?? no default MS dns option????

Well When will it be out?

In my opinion, this MUST be fixed for all versions of android 2.3 and upwards.

It is absurd that an open source network os does not honor the dhcp-provided search domain. Apple IOS does.

I'm experiencing this bug on a Nexus 7 I just bought and I'm pretty upset seeing all of this.  I saved for months to afford this tablet for grad school and there appears to be no fix - you have to be kidding me.

You can always type in the fully qualified path.

It has been fixed in future releases.

I'm sorry it took a while to get fixed.

Of course we can use the fully qualified path ("name" is the proper nomenclature, FWIW).  Everyone here knows that.  That a FQDN is *required* is the entire complaint of this ticket.

Can you report which release an Android user would expect to see it in?

I don't know what the next release will be called or labeled.

This is a major issue for using android in a serious business environment

I know the 5.0 development is under the way, but would it be possible to backport this change to 4.2?
Because many tablets and phones will not get updates to 5.0 soon, but instead will get (hopefully) updates to 4.2 in the next month.

I have the same problem for years now and it doesn't get solved. What a failure! If I run my local network with a local domain every device accepts it but not Android...

So google forces me to use an existing domain name which I will never visit for local addresses, this works, but it's terrible ugly!

We are facing the same problem at my work, but, an it seems that the Android 3 just dont like to honor the dns configuration received through dhcp, and still insists to use the Google ones :

Iptables log at the firewall, blocking outgoing dns queries:
Feb 11 17:11:36 hafw1 IN=vlanXXXX OUT=vlanXXXX MAC=XXXX SRC=10.0.0.107 DST=8.8.8.8 LEN=69 TOS=00 PREC=0x00 TTL=63 ID=35639 DF PROTO=UDP SPT=56219 DPT=53 LEN=49 MARK=0
Feb 11 17:11:37 hafw1 IN=vlanXXXX OUT=vlanXXXX MAC=XXXX SRC=10.0.0.107 DST=8.8.8.8 LEN=62 TOS=00 PREC=0x00 TTL=63 ID=35791 DF PROTO=UDP SPT=16060 DPT=53 LEN=42 MARK=0
Feb 11 17:11:41 hafw1 IN=vlanXXXX OUT=vlanXXXX MAC=XXXX SRC=10.0.0.107 DST=8.8.8.8 LEN=69 TOS=00 PREC=0x00 TTL=63 ID=36919 DF PROTO=UDP SPT=62492 DPT=53 LEN=49 MARK=0
Feb 11 17:11:42 hafw1 IN=vlanXXXX OUT=vlanXXXX MAC=XXXX SRC=10.0.0.107 DST=8.8.8.8 LEN=62 TOS=00 PREC=0x00 TTL=63 ID=37077 DF PROTO=UDP SPT=2582 DPT=53 LEN=42 MARK=0
Feb 11 17:11:46 hafw1 IN=vlanXXXX OUT=vlanXXXX MAC=XXXX SRC=10.0.0.107 DST=8.8.8.8 LEN=69 TOS=00 PREC=0x00 TTL=63 ID=36920 DF PROTO=UDP SPT=62492 DPT=53 LEN=49 MARK=0
Feb 11 17:11:47 hafw1 IN=vlanXXXX OUT=vlanXXXX MAC=XXXX SRC=10.0.0.107 DST=8.8.8.8 LEN=62 TOS=00 PREC=0x00 TTL=63 ID=37078 DF PROTO=UDP SPT=2582 DPT=53 LEN=42 MARK=0
Feb 11 17:11:51 hafw1 IN=vlanXXXX OUT=vlanXXXX MAC=XXXX SRC=10.0.0.107 DST=8.8.8.8 LEN=69 TOS=00 PREC=0x00 TTL=63 ID=38200 DF PROTO=UDP SPT=38443 DPT=53 LEN=49 MARK=0
Feb 11 17:11:56 hafw1 IN=vlanXXXX OUT=vlanXXXX MAC=XXXX SRC=10.0.0.107 DST=8.8.8.8 LEN=69 TOS=00 PREC=0x00 TTL=63 ID=38201 DF PROTO=UDP SPT=38443 DPT=53 LEN=49 MARK=0

If we fix the IP and DNS address works while resolving internal network names, but, will be such a waste of precious time fixing IP's on every tablet/smartphone...

Nicolas, the issue you describe (using 8.8.8.8 instead of the dns server addresses given by dhcp) is very different than this issue.  Can you create a new issue to discuss it?

Everyone here does understand that back-porting isn't an option, right? Once the code is released and sent to (eg. Samsung) it gets modified. Then it gets sent to (eg. AT&T) and gets modified again. By the time you get it, it isn't an option for Google to patch it. Really, the only way to get changes from Google is in the next release.

Of course, considering the way the above referenced pattern goes, unless you have a pure google device (Nexus) you are likely to be waiting years to see the next version. This only leaves a few options. 1) Wait. 2) Complain for no reason. 3) Get different device.

But I do agree with the frustration here. This never should have happend, or been ignored when pointed out. It is not a 'feature request' that there aren't enough developers to handle. This is core functionality which should have been addressed quickly with an appology.

Thanks, asmallwood0311.

I would like to point out a 4th option.  This is an opensourced project.
 Internally we are a small team, but externally there are many of us.  4)
Fix the problem and upload a solution.  Kevin Tang did just that (
https://android-review.googlesource.com/#/c/42810/ and others) and his fix
will go out in the very next release.

Hi,

I'm making tests for my company (mobile provider) for integrate tablets (Android and IOS) in VPN, and this issue is going to make me choose the IOS, while we all prefer the Android tablets.

I'm disappointed to make this choice (ios)

Hope this will be fixed soon.

Thanks

[Comment deleted]

For so many new features in Android over the years, problems like this totally eliminate Android from our enterprise usage unfortunately.
The sharepoint server here does not like FQDN on all pages and they dont want to bother changing a working system just for Android devices when they quite happily tell people to just get an iphone instead as they work with everything.
Why does something this important and far more simple than designing new Chrome browsers and graphics drivers for pretty graphics for games and Google+ apps etc gets totally left behind.
Its the little things that count sometimes and that needs to be realized in the Andriod team at some point.

Current issue is a showstopper in our both development and production(!) environment.
We can't use FQDN at all (first requests goes fine using FQDN, but afterwards the local resource makes forward to using short names...). Same with our partner's production environment.

I do hope it will be possible to include fix into 4.1.x release! Thanks!

I don't think there will be more 4.1.x releases - JB MR1 was 4.2 and we'll
be building on that.

Ok, I see. In such case maybe you could suggest a workaround? It would be really great!