[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:
>>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.
>
> 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?


>>
>>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



More information about the Dnsmasq-discuss mailing list