Android - Why is Android refusing to resolve DNS records pointing to internal IP addresses?
We recently encountered this issue, and we narrowed it to occurring ONLY on devices running Android v5 and newer. Android v4 and all other OS's have no issue.
With that tidbit, we determined that Android v5 and newer insists on using IPv6 for DNS name resolution. (Since we've completely disabled IPv6 on our network, this jibes with the issue.) If Android v5(+) can't get an IPv6 response from local DNS, then it reaches out to Google's public name host (8.8.8.8). Hence, no internal DNS, just external.
We worked around the issue by creating DNS records on our public-facing DNS servers for select internal names and IPs. With that done, Google's public DNS could resolve these internal names with internal IPs, and the devices could then reach our internal hosts.
We're proceeding with fully enabling IPv6 on our internal DNS servers (domain controllers) as a permanent fix.
=========================================
UPDATE-- Well, it turns out this may be a total red herring...or not. My home network is Win2008R2, single-domain with DHCP and DNS and no IPv6 binding. Tested an Android v5 device from there and had NO ISSUE. Office network with issue is Win2012 (non-R2), single-domain.
Bypassed current office WAPs with stand-alone Linksys WAP and separate SSID for testing, issue persists.
Differences between office and home networks (that I can think of): - Windows version - 2012 vs. 2008 R2 - router model (Cisco vs. Linksys) - WAP model (Dell-branded Aruba Networks vs. Linksys)
Proceeding with whatever further testing I can think of for narrowing the issue. Any suggestions or input is extremely appreciated!
=========================================
PROBLEM GONE (?!)
Our issue seemed to disappear on its own following a network topology change that I wouldn't think was related, but here's the info in case.
(HUGE APOLOGIES for this long, drawn out story, but this is when our Android issues disappeared, so ride this out if you can. I'm probably providing WAY too much detail here, but because I can't see a direct connection, I'm laying it all out exactly as it happened.)
Our ISP is Comcast Business Class—a cable modem with a static IP block of five addresses (weird number but that's how Comcast sells them). Comcast's cable modem is essentially a combination modem/firewall/router/switch, with our static IP block remotely programmed into it.
For 10+ years and almost as many employers, I've always built office networks the same way:
Configure a LAN IP for the ISP modem/router, which NAT's traffic from the internet. Couldn't be simpler, and that's how my current office network has been configured for four years.
Recently our office internet service went down. Usually a modem restart corrects it, but when it didn't we called Comcast who sent a tech, who replaced the cable modem to restore service.
A few days later, the same thing happened again. We called again, and the onsite tech (different tech than before) attempted to replace the modem again, this time with a newer model. Surprisingly, the newer cable modem did not support changing the LAN subnet address. The default subnet is 10.1.10.0/24, and it cannot be changed. (Only the 4th octet was configurable.) As our office subnet is 192.168.100.0/24, I let the tech know we couldn't use it without being able to change the LAN subnet. He understood, but had no info as to why the cable modem would prevent the change. So he installed a replacement modem of the same model as before, which we configured identically, and internet access was restored.
Another day or two passes, and the service goes down again. This time when I called Comcast, the initial tech I spoke with asked detailed and knowledgeable questions about our network configuration. When I explained that the cable modem was configured with a LAN IP on our subnet, he seemed puzzled by this. He said that most Comcast customers connect a NAT'ing router between the cable modem and LAN rather than use the cable modem's NAT'ing. In fact, he said he wasn't aware that the cable modem supported NAT'ing.
Comcast sent out another tech with a brand new cable modem (latest model that doesn't support changing the LAN subnet). He did extensive testing on the existing modem, and finally determined that it was only passing IPv6 traffic—no IPv4. He also confirmed what the phone tech had said--that it's recommended to use a separate router for NAT'ing, and to not change the LAN subnet on the cable modem (which we can't do on the newer modems now anyway).
And now we finally come to the network change we made. I installed a simple LinkSys router between the cable modem and our core router, configured with our static IP on the modem side, and a LAN IP on the inside. Internet service was then restored, and has remained stable for some time now.
After internet service was restored, I thought about the oddness of the IPv6 issue with the cable modem, which in turn reminded me of the Android v5 issue. I then tested our Android devices in the office, and was stunned to see that the DNS issue was no longer occurring.
Adding the LinkSys router for NAT'ing is the ONLY NETWORK CHANGE WE MADE. Coincidence?? Possibly, but it just seemed a little peculiar that both were related to IPv6.
Anyway, sorry again for the long story, but our Android issue is gone. Make what you can out of it.
Dimarc67
I came across this post while trying to get my Android 6.0 device to use the locally configured DNS server to resolve local hostnames. One answer above indicated that Android 5.0 and newer insists on using IPv6 DNS servers. This was the clue that lead me to my solution.
My router was advertising the IPv6 DNS servers provided by my ISP using DHCP-PD. I reconfigured my router to stop advertising the IPv6 DNS servers and now the Android 6.0 device is resolving the local hostname using the IPv4 DNS server provided by DHCP (IPv4).
I also have a DNAT to redirect all DNS queries (TCP/UDP port 53) to my local DNS server. This was in place before disabling the router advertisement with IPv6 DNS servers so I don't know if Android 5.0+ falls back to the Google DNS servers (as claimed in the previous answer) and I caught them with my DNAT rule or whether my Android 6.0 device just used the DHCP assigned IPv4 DNS server. Either way, the local hostname resolution is working now.
I was finally able to solve this by setting up a DHCP server myself on the same network, which configures the correct Search Domain to send to the clients.
Once I had a dhcp server, in my case isc-dhcpd with the configuration in dhcp.conf:
option domain-name "myrealdomain.tld";
Android was able to resolve local A-records set in my DNS server.