Good Morning!

I can demonstrate this behavior in RHEL5, and demonstrate that it doesn't exist in RHEL6. Ergo, this is a known bug that's been fixed. Now, I need to document that fact!

Of course, for the life of me, I can't find the bug.

Basically, under certain circumstances, the RHEL5 resolver will ignore the ndots value when making AAAA queries. This leads to seeing queries with multiple q.d.n's attached. (And, of course, this won't show up with host, dig, nslookup, etc. I had to get one of the Java guys to whip up a little .jar that calls InetAddress.getByName).

For context, my /etc/resolv.conf contains a search line of "mid.top bot1.mid.top bot2.mid.top bot3.mid.top."

Search "host.bot1.mid.top" and bind receives these requests

query: host.bot1.mid.top IN AAAA +
query: host.bot1.mid.top.mid.top IN AAAA +
query: host.bot1.mid.top.mid.top IN AAAA -E
query: host.bot1.mid.top.mid.top IN AAAA -E
query: host.bot1.mid.top.mid.top IN AAAA +
query: host.bot1.mid.top.mid.top IN AAAA -E
query: host.bot1.mid.top.mid.top IN AAAA -E
query: host.bot1.mid.top.bot2.mid.top IN AAAA +
query: host.bot1.mid.top.bot1.mid.top IN AAAA +
query: host.bot1.mid.top.bot3.mid.top IN AAAA +
query: host.bot1.mid.top IN A +


Search "host:"

host.mid.top IN AAAA +
host.bot1.mid.top IN AAAA +
host.bot2.mid.top IN AAAA +
host.bot3.mid.top IN AAAA +
host.mid.top IN A +


Search "host.bot1.mid.top." with the dot on the end:

host.bot1.mid.top IN A +
host.bot1.mid.top IN AAAA +
host.bot1.mid.top IN A +


This only appears to apply to IPv6 requests handled directly by the resolver in RHEL5.

Does this look familiar to anyone? I need to track down any existing bug number for this behavior.

Thanks!
dafydd

When you're saying "handled directly by the resolver" do you mean that as in 'man 5 resolver'? If that's the case then look at Glibc first?