incompatibility between dnsmasq and uClibc resolver

[Mathias Kresin]

Hello,

querying dnsmasq from a system which uses uClibc can result in a
partly not working name resolution.

I'm using dnsmasq 2.71 and uClibc 0.9.33.2 on openWRT 14.07
(mips/x86). The openwrt version of uClibc includes already a lot of
fixes from HEAD. I've checked the commits between $version and HEAD of
both programs and couldn't spot any related change.

To hit this incompatibility the requested hostname must not a dnsmasq
dhcp client and not mentioned in any hosts file.

When querying for a _non_ FQDN the uClibc resolver sends first a query
for the hostname only. If the server response code is NXDOMAIN (3) or
SERVERFAIL (2) it resends the query as FQDN using the search value
from /etc/resolv.conf[1].

Unfortunately dnsmasqs response code to the query for the hostname is
NOERROR (0). As this isn't s.th. that uClibc does expect in case of a
none existing hostname, the query for the FQDN is never send.

For reference I checked what other DNS resolvers are doing when
querying for non existent hosts with a search value in resolv.conf
using 'nslookup host':

linux + uclibc:
    1. query for host

linux + glibc:
    1. query for host.domain.tld
    2. query for host

windows7:
    1. query: host.domain.tld

macos 10.9:
    1. query for host.domain.tld
    2. query for host

And even what other DNS Servers[2] are returning on 'nslookup host':

microsoft dns: SERVERFAIL (2)
google public dns: NXDOMAIN (3)
bind 9.10.0-P2 : NOERROR (0)
powerdns: NOERROR (0)

Due lack of a deeper knowledge of the DNS RFCs I can't say who behaves
wrong here. According to [3],[4] and [5] I'm not the only one who
found the oddity.

Regards
Mathias Kresin

[1] http://git.uclibc.org/uClibc/tree/libc/inet/resolv.c?id=a9bdc5d28e692c04f51bcea1bb8e87f9c72ad09f#n1463
[2] http://www.ungefiltert-surfen.de/nameserver/de.html
[3] https://dev.openwrt.org/ticket/13685
[4] http://freetz.org/ticket/1560
[5] https://bugs.alpinelinux.org/issues/469