为什么Android拒绝解析指向内部IP地址的DNS记录？

尝试访问本地网络应用程序时，我在Android设备（Nexus 7）上有一个非常奇怪的行为。Android设备没有获取局域网上计算机的实际IP，而是获取了公共 IP，这意味着Chrome，Firefox或任何其他浏览器仅显示了路由器的网页。

我有一个处理本地网络的内部DNS服务器。这样做ping从PC正常工作：

$ ping s.pelicandd.com

PING pelicandd.com (192.168.1.15) 56(84) bytes of data.
64 bytes from front.pelicandd.com (192.168.1.15): icmp_seq=1 ttl=64 time=0.524 ms
64 bytes from front.pelicandd.com (192.168.1.15): icmp_seq=2 ttl=64 time=0.578 ms
^C

在HTC One设备（通过访问adb shell）上，它也可以正常工作：

shell@m7:/ $ ping s.pelicandd.com

PING pelicandd.com (192.168.1.15) 56(84) bytes of data.
64 bytes from front.pelicandd.com (192.168.1.15): icmp_seq=1 ttl=64 time=2.56 ms
64 bytes from front.pelicandd.com (192.168.1.15): icmp_seq=2 ttl=64 time=27.8 ms
^C

但是，这是我ping从Nexus 7进行的操作所得到的：

shell@flo:/ $ ping s.pelicandd.com

PING pelicandd.com (90.78.26.42) 56(84) bytes of data.
64 bytes from LFbn-1-2441-42.w90-78.abo.wanadoo.fr (90.78.26.42): icmp_seq=1 ttl=64 time=2.56 ms
64 bytes from LFbn-1-2441-42.w90-78.abo.wanadoo.fr (90.78.26.42): icmp_seq=2 ttl=64 time=8.63 ms
^C

它不是解析内部IP，而是解析为公共IP。

除设备的IP地址外，网络配置在两个设备上都完全相同：IP设置为Static，而DNS服务器为内部服务器。两个Android设备都通过Wi-Fi连接（与PC不同）。但是，主要区别在于Nexus 7使用的是Android 6.0.1，而HTC One使用的是Android 5.0.2。

没有nm-tool，dig或者nslookup在Nexus 7上没有。设备没有植根。

自几周前我购买设备以来，就一直存在该问题，因此这几乎不是DNS缓存的问题。

我该怎么做才能进一步检查这个问题？

我们最近遇到了此问题，并将其范围缩小为仅在运行Android v5及更高版本的设备上发生。Android v4和所有其他操作系统都没有问题。

有了这个小窍门，我们确定Android v5及更高版本坚持使用IPv6进行DNS名称解析。（由于我们已经完全禁用了网络上的IPv6，这与问题有关。）如果Android v5（+）无法从本地DNS获得IPv6响应，则它会到达Google的公共名称主机（8.8.8.8） 。因此，没有内部DNS，只有外部DNS。

我们通过在面向公众的DNS服务器上为选定的内部名称和IP创建DNS记录来解决此问题。完成此操作后，Google的公共DNS可以使用内部IP解析这些内部名称，然后设备可以访问我们的内部主机。

我们将在内部DNS服务器（域控制器）上完全启用IPv6作为永久解决方案。

========================================

更新-好吧，事实证明这可能是完全的红鲱鱼……或者不是。我的家庭网络是Win2008R2，具有DHCP和DNS且没有IPv6绑定的单域。从那里测试了Android v5设备，但没有问题。有问题的Office网络是Win2012（非R2）单域。

问题仍然存在，并通过独立的Linksys WAP和独立的SSID绕过了当前的办公室WAP。

办公室和家庭网络之间的差异（我能想到）：-Windows版本-2012与2008 R2-路由器模型（思科与Linksys）-WAP模型（戴尔品牌的Aruba Networks与Linksys）

我可以考虑进行进一步的测试以缩小问题的范围。任何建议或意见都非常感谢！

========================================

问题消失了（？！）

在我认为不相关的网络拓扑更改之后，我们的问题似乎消失了，但是这里提供了一些信息。

（关于这个冗长而冗长的故事的巨大歉意，但这是我们的Android问题消失的时候，因此，如果可以的话，请尝试解决。我在这里可能会提供太多详细信息，但是由于看不到直接的联系，我正按照实际情况进行全部布置。）

我们的ISP是康卡斯特（Commcast）商业级—有线调制解调器，带有五个地址的静态IP块（奇怪的数字，但这就是康卡斯特出售它们的方式）。Comcast的电缆调制解调器本质上是调制解调器/防火墙/路由器/交换机的组合，我们的静态IP模块可以远程编程到其中。

十多年来，几乎所有雇主，我一直以相同的方式构建办公网络：
为ISP调制解调器/路由器配置LAN IP，NAT互联网的流量通过该IP进行访问。再简单不过了，这就是我目前的办公室网络已经配置了四年的方式。

最近我们办公室的互联网服务中断了。通常情况下，调制解调器重启会纠正它，但是如果没有重启，我们会打电话给Comcast派遣技术，然后他会更换电缆调制解调器以恢复服务。

几天后，同样的事情再次发生。我们再次打电话，现场技术（与以前不同的技术）试图再次更换调制解调器，这次是使用较新的型号。令人惊讶的是，较新的电缆调制解调器不支持更改LAN子网地址。默认子网为10.1.10.0/24，无法更改。（仅第四个八位位组是可配置的。）由于我们的办公室子网是192.168.100.0/24，我让技术人员知道，如果不更改LAN子网，我们将无法使用它。他了解，但没有任何有关为何电缆调制解调器会阻止更改的信息。因此，他安装了与以前相同型号的替换调制解调器，我们对其进行了相同配置，并恢复了互联网访问。

又过了一两天，服务再次中断。这次，当我致电Comcast时，我与之交谈的最初技术询问了有关我们网络配置的详细和知识渊博的问题。当我解释说电缆调制解调器在我们的子网中配置了LAN IP时，他似乎对此感到困惑。他说，大多数Comcast客户在电缆调制解调器和LAN之间连接NAT'ing路由器，而不是使用电缆调制解调器的NAT'ing。实际上，他说他并不知道电缆调制解调器支持NAT'ing。

康卡斯特（Comcast）推出了另一项技术，该技术采用了全新的电缆调制解调器（不支持更改LAN子网的最新型号）。他在现有的调制解调器上进行了广泛的测试，最后确定它仅通过IPv6流量，而没有IPv4。他还证实了电话技术人员所说的话–建议使用单独的路由器进行NAT，并且不要更改电缆调制解调器上的LAN子网（无论如何我们现在不能在新的调制解调器上进行此操作）。

现在，我们终于可以进行网络更改了。我在电缆调制解调器和我们的核心路由器之间安装了一个简单的LinkSys路由器，在调制解调器侧配置了我们的静态IP，在内部配置了LAN IP。然后恢复了Internet服务，并在一段时间内保持稳定。

恢复互联网服务后，我想到了电缆调制解调器的IPv6问题，这反而使我想起了Android v5问题。然后，我在办公室测试了我们的Android设备，并惊讶地发现DNS问题不再发生。

添加LinkSys路由器进行NAT'ing是我们所做的唯一网络更改。巧合？？可能，但是两者都与IPv6有关似乎有点奇怪。

无论如何，再次为长话难过，但我们的Android问题不见了。尽您所能。

Dimarc67

我在尝试让我的Android 6.0设备使用本地配置的DNS服务器解析本地主机名时遇到了这篇文章。上面的一个答案表明，Android 5.0及更高版本坚持使用IPv6 DNS服务器。这就是引导我找到解决方案的线索。

我的路由器正在使用DHCP-PD通告由ISP提供的IPv6 DNS服务器。我将路由器重新配置为停止发布IPv6 DNS服务器，现在Android 6.0设备正在使用DHCP（IPv4）提供的IPv4 DNS服务器解析本地主机名。

我还有一个DNAT，可将所有DNS查询（TCP / UDP端口53）重定向到我的本地DNS服务器。这是在使用IPv6 DNS服务器禁用路由器播发之前就位的，所以我不知道Android 5.0+是否会退回到Google DNS服务器（如上一个答案中所述），我用DNAT规则捕获了它们，或者我的Android是否捕获了它们6.0设备仅使用了DHCP分配的IPv4 DNS服务器。无论哪种方式，本地主机名解析现在都可以正常工作。

我终于可以通过在同一网络上自己设置DHCP服务器来解决此问题，该服务器配置正确的Search Domain来发送给客户端。

一旦有了dhcp服务器，在我的情况下为dhcp.conf中的配置为isc-dhcpd：

option domain-name "myrealdomain.tld";

Android能够解析我的DNS服务器中设置的本地A记录。