[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(usagi-users 03695) Re: glibc getaddrinfo can resolve addresses of different hosts in case of search domains are used in /etc/resolv.conf - bug or feature?

Peter Bieringer wrote: 
Hi,

after some discussions with people from Red Hat I'm still not able to
convince them that the behavior of getaddrinfo in glibc is buggy, if
search domains in /etc/resolv.conf are specified.

Currently, it can return IPv6 and IPv4 addresses of different hosts,
depending what happen during AAAA lookups while appending a search
domain. If successful, application gets back e.g.

 AAAA fec0::1 (www.redhat.com.intranet.domain.example)
 A 66.187.224.150 (www.redhat.com)

Not good, if application prefers IPv6...it connects unexpected to the
wrong host.


Me was told inbetween (and a short look into the source code shows like
that), that getaddrinfo uses DNS lookups more abstract and it can't be
fixed in an easy manner.

Last note I get was I should provide more information or a whitepaper,
that current behavior is more a bug than a feature...and support/request
of the community is required.

Therefore my next (last) try is to inform the IPv6 community about this
issue. Please read details below and perhaps vote for

( ) bug, should be fixed in
	[ ] newer releases
	[ ] current release
	[ ] older releases, too
( ) feature, no need to fix it
( ) ...

I agree that this behaviour is bad. So I might vote for bug, fix in current. There are possible security problems with this.

It might be interesting to look at bottom of p9 in RFC 1536, it doesn't say much though.

My thinking is that you should follow search path until you find an DNS entry (not NXDOMAIN). If you find a match then you should stop, even if there are no addresses.

E.g. if getaddrinfo() is called with "www", and there is a match in the
beginning of my search path, e.g. www.domain.example that has only e.g. a TXT RR, then I don't think it should continue.

Even if getaddrinfo internally first looks for AAAA going through the search path if needed, and then repeats the process for A, you would then get the same results. E.g. when you look for AAAA for www.redhat.com, you would find that www.redhat.com exists and stop. Even if no AAAA records. That is, the internal lookup must distinguish between NXDOMAIN and no records of the requested type. I haven't looked at the code, but don't understand why this is hard to implement...

Stig