Gabor Gombas wrote: > On Wed, Dec 21, 2005 at 06:08:04PM +0100, Marco d'Itri wrote: > >>I find this reasoning very peculiar. If an algorithm is inefficient and >>this causes problems then it is obviously buggy. > > An algorithm is buggy if it does not match the specification. I see no > description about the lookup order wrt. multiple protocols, so the > behaviour is conformant to the documentation.
In this case, the algorithm does not match the specification. Therefore, it's a bug. Quoting the man page: "Resolver queries having fewer than ndots dots (default is 1) in them will be attempted using each component of the search path in turn until a match is found." IPv6 queries are not excluded from this description. The fact is that with this bug, resolver queries with MORE than ndots are ALWAYS attempted using each component of the search path. Yes, the queries are IPv6 but that does not matter. If you read further down the man page: "ndots:n sets a threshold for the number of dots which must appear in a name given to res_query() (see resolver(3)) before an initial absolute query will be made." There's no ambiguity in the term 'absolute query'. A lookup for the IPv6 address example.com.domain.in.search.path is NOT an initial absolute query no matter how you look at it. > Also note that resolv.conf(5) explicitely says that using search lines > "may be slow and will generate a lot of network traffic if the > servers for the listed domains are not local, and that queries will time > out if no server is available for one of the domains." The author of that man page did not have this bug in mind when he wrote that. If he did, the search functionality would have been removed. Yes, using the search line causes more network traffic than not using it. But this bug causes WAY more network traffic than a proper functioning search line. As I said in a previous e-mail, FreeBSD's resolver does it the correct way. Debian should follow suit, regardless of whether glibc developers consider this a bug (I'd be surprised if they thought it wasn't). Also, keep in mind that even if you DON'T use the search line at all and simply have 'domain example.com' in resolv.conf, which most users have by convention, then you're STILL having extraneous queries. I checked this too. Every resolver query your system ever makes will also look for an AAAA record of example.com.example.com even when example.com exists! How is that not a bug? Regards, Ed > > Gabor > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]