2014-10-12 22:38 GMT+02:00 Bernhard Reutner-Fischer <[email protected]>: > On 11 October 2014 13:16:34 CEST, Mathias Kresin <[email protected]> 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 _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
