How does Android OS do DNS name resolution?

I am learning about how Windows does name resolution and need to know how Android does it so an app will work on my Windows laptop and from my Android Phone.

Borrowing from a post on superuser.com, the normal resolution method on windows is as follows:

1. The client checks to see if the name queried is its own.



2. The client then searches a local Hosts file, a list of IP address and names stored on the local computer.


3. Domain Name System (DNS) servers are queried.


4. If the name is still not resolved, NetBIOS name resolution sequence is used as a backup. This order can be changed by configuring the NetBIOS node type of the client.

I use dnsmasq to provide local DNS resolution so I can map my own made up hostnames to local LAN IP addresses. This also allows me to see, in the dnsmasq log file, the DNS query that goes from the client to the DNS server. While testing the website from my phone I could swear using the URL address http://mywebsite in a Chrome browser on the phone was loading the website and the dnsmasq log showed just that unqualified name - mywebsite - resolving to the desired local IP address the web server is at.

However that was a few days ago, now the dnsmasq log always shows that the DHCP server DNS suffix [home] has been appended. So I see mywebsite.home in the dnsmasq log even though I used the URL address http://mywebsite in the phones Chrome browser. I didn't change anything with the phone. It is still set up to get its IP address via DHCP, in practice it never changes.

So my questions are:

1. How does Android OS resolve domain names to IP addresses - what things does it try and in what order?



2. Any feedback on why Android seemed to be resolving the unqualified hostname in my browser originally without any DNS suffix being appended. But now the [home] suffix is always appended as reported in the dnsmasq log file.

Update 1

After some more testing I have again seen the scenario where the webpage http://mymovies loads from the Android phone but the dnsmasq log appears to show the name resolution happening on an unqualified domain name (bare hostname: mymovies).

The x's are my redacted routers public IP address.

Can anyone explain what dnsmasq is doing here?

Starting from 02:07:22 it initially seems to try resolving the name mymovies.home. This makes sense because the phones IP is dynamically allocated by the DHCP server and I can see on my laptop that the DHCP server sends the DNS suffix [home] as the connection-specific DNS suffix so it must be doing the same to the phone I guess?

The reason why it fails here is because I do not have an entry for mymovies.home in dnsmasq.conf - I commented it out. I DO have an address entry for mymovies in dnsmasq.conf and that seems to be why it can resolve mymovies to an IP address.
Is this a difference of name resolution in Android compared with Windows - that eventually Android OS WILL try to resolve an unqualified domain name (bare hostname) to an IP address?

Answer

How DNS queries made by a program are being resolved isn't specific to an OS, but depends on the resolver library the program is using. DNS resolvers have traditionally been part of OS's standard C library e.g. Bionic on Android, libcmt on Windows, glibc, musl, dietlibc, uClibc and others on Linux. Not all C libraries use the same approach to resolve host/domain names. While glibc and alike provide complicated but highly configurable mechanisms like Name Service Switch, others just rely on hosts and DNS queries to upstream nameserver as configured in /etc/resolv.conf. Android's resolver ^{(1, 2)} looks up cache, hosts and DNS:

"DNS lookups are centralized in the netd daemon to allow for system-wide caching, while apps call functions (such as getaddrinfo) in Bionic. The query is sent over a UNIX socket to /dev/socket/dnsproxyd to the netd daemon, which parses the request and calls getaddrinfo again to issue DNS lookups, then caches the results so that other apps can use them."

DNS server address is either received through PDP context on Mobile Data or through DHCP on Wi-Fi (also possibly to set manually) or the hard-coded value 8.8.8.8 is used. Since Android 9 Private DNS (DNS over TLS) may also be configured in Settings. It's also possible to set DNS and domain name using ndc resolver setnetdns command. See more details in How to configure DNS properly?.

dnsmasq log always shows that the DHCP server DNS suffix [home] has been appended

.home suffix is being provided by your DHCP server (router?) to Android as part of DHCP request (code 15). Android's DHCP client asks server for option 6 (domain name server) and option 15 (domain name), which are then forwarded to C library (_resolv_set_nameservers_for_net) through DnsManager, NetworkManagementService and netd.

On Linux DHCP client (e.g. dhcpcd) modifies resolv.conf itself or uses a program like resolvconf which is dedicated to manage resolv.conf. nameserver keyword defines DNS server and search defines search list for host-name lookup (DHCP option 119 or 15). Android uses default values hard-coded in different header files other than those received from DHCP or set manually.

Windows's DHCP client and DNS resolver support option 15. Additional configurations which are honored by DNS Client service (dnscache) and library can be made through Network Connections or Group Policy Editor or Registry Editor.

Is this a difference of name resolution in Android compared with Windows - that eventually Android OS WILL try to resolve an unqualified domain name (bare hostname) to an IP address?

As far as I have seen this is almost standard behavior for Linux libc's. Android's DNS resolver code is also based on NetBSD - a Linux distro. A single-label unqualified name is first tried with DNS suffix appended, then tried without suffix 4 times (see "options attempts:n" for resolv.conf). For multi-label name the order is reversed while a FQDN (with trailing .) is never tried with suffix. On Windows you can append dot to unqualified name so that it's treated as FQDN. It's possible to set it as default behavior by adding dot (.) to "DNS suffix for this connection". See also for Multi-Label Name Queries.

I am learning about how Windows does name resolution and need to know how Android does it

As stated in the start, name resolution might not be persistent across whole OS. On Android, for instance, Firefox or Chrome will be depending on Bionic resolver while some busybox ping (or even some native libraries included with GUI apps) will be trying to read resolv.conf and make DNS queries directly.

Also network troubleshooting tools like ping and getent rely on OS's internal resolver libraries like NSS, while DNS diagnostic tools like nslookup, dig and host act as independent DNS clients - they don't read hosts file and may not honor resolv.conf in its entirety. dig provides commandline arguments to (not) use options set in resolv.conf, and similarly Windows nslookup has its own built-in resolver.

So even on same OS you can't expect same DNS resolution behavior when using different GUI/CLI programs because they could be using different libc and/or different resolver and/or different configuration.

---

RELATED: