[Dnsmasq-discuss] incompatibility between dnsmasq and uClibc resolver

Simon Kelley simon at thekelleys.org.uk
Mon Oct 13 22:10:51 BST 2014

On 11/10/14 12:16, Mathias Kresin 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 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 host7de060b08dc8f7ea9fd1f972e3c55beab2df51b1
> 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.

My guess is that your dnsmasq is configured with the --domain-needed
flag, which tells dnsmasq not to forward queries with simple names: if
the name isn't known locally (as in this case) then dnsmasq returns NOERROR.

Strangely, before dnsmasq-2.58, it used to return NXDOMAIN, and this old
behaviour would fix your problem, but has other bad consequences.

Consider doing a query for "com". If dnsmasq returns NXDOMAIN then
whatever gets that answer can assume the nothing that ends on ".com"
exists, which is clearly wrong, and breaks a lot of stuff. Simple
resolvers won't break, but anything more complex will, so reverting the
behaviour is no possible.

The best I can offer is to remove --domain-needed as a workaround, but
really the uclibc resolver needs to be modified to accept NOERROR as reply.



More information about the Dnsmasq-discuss mailing list