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 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 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. Cheers, Simon. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
