[Dnsmasq-discuss] incompatibility between dnsmasq and uClibc resolver

Mathias Kresin openwrt at kresin.me
Mon Oct 13 14:44:31 BST 2014

2014-10-12 22:38 GMT+02:00 Bernhard Reutner-Fischer <rep.dot.nop at gmail.com>:
> On 11 October 2014 13:16:34 CEST, Mathias Kresin <openwrt at kresin.me> wrote:
>>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 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
>>    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.
> http://lists.uclibc.org/pipermail/uclibc/2014-March/048288.html
> Was the alternative that I did not apply back then in favour of a more conservative fix (IIRC).
> Can you check if that alternative would work for dnsmasq, please?
> TIA,

Thanks for your feedback Bernhard.

I think this patch will not change anything. With the patch applied,
the search domain gets appended if a non zero code is returned. But
dnsmasq returns zero in the described situation.

I can imagine of two possible approaches to fix the issue on the uclibc side :

a. Query for the search domain expanded hostname (FQDN) at first and
fall back to the hostname as last effort. That is similar to what I've
observed with the glibc/macos resolver implementation.
b. If a hostname was send, don't rely on the return code only. Check
the number of received records as well in case of a NOERROR return
code. Basically something like (h.rcode == NXDOMAIN || h.rcode ==
SERVFAIL || (h.rcode == 0 && variant == -1 && h.ancount == 0))

Personally I prefer b. as the impact on existing code is minimal.

Any thought on this?

>>Mathias Kresin
>>[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

More information about the Dnsmasq-discuss mailing list