freebsd stable - May 2006 - resolver behaviour regarding searchlist and A/AAAA query replies

Hi,

I was debugging some connection lag and I encountered some query
behavior which seems unnecessairy in my eyes.  The system in
question is running one of the FreeBSD 6.1 prereleases, I've not
verified this on any other version yet.

The queries I see are these:

22:15:29.657232 IP 172.16.21.2.57672 > 172.16.1.22.53:  54355+ A?
images.slashdot.org. (37)
22:15:29.658189 IP 172.16.21.2.64080 > 172.16.1.22.53:  46066+ AAAA?
images.slashdot.org. (37)
22:15:29.659407 IP 172.16.1.22.53 > 172.16.21.2.57672:  54355 1/13/1 A
66.35.250.55 (280)
22:15:29.659674 IP 172.16.1.22.53 > 172.16.21.2.64080:  46066 0/1/0 (96)
22:15:29.660514 IP 172.16.21.2.55636 > 172.16.1.22.53:  46067+ AAAA?
images.slashdot.org.b0rken.net. (48)
22:15:29.661438 IP 172.16.1.22.53 > 172.16.21.2.55636:  46067 NXDomain* 0/1/0
(99)
22:15:29.661847 IP 172.16.21.2.58524 > 172.16.1.22.53:  46068+ AAAA?
images.slashdot.org.bureau.b0rken.net. (55)
22:15:29.662720 IP 172.16.1.22.53 > 172.16.21.2.58524:  46068 NXDomain* 0/1/0
(106)

So it sends out A and AAAA queries, so far so good.  It gets an answer
for the A record query, however the AAAA query retuns an empty answer.
What I find strange though, is the fact it's now applying the searchlist
to get an answer on the AAAA query.  Other than the fact this could
potentially give unpredictable results in specific situations, I find
this rather illogical.  Since one of the queries (A or AAAA) succeeded
we _know_ the host in question exists (and the searchlist is there to
make non-fqdn queries work for 'local' hosts, by applying the searchlist
if the host does not seem to exist).  So, in short, isn't this a bug?

Regards


Jan Gyselinck

> Hi,
> 
> I was debugging some connection lag and I encountered some query
> behavior which seems unnecessairy in my eyes.  The system in
> question is running one of the FreeBSD 6.1 prereleases, I've not
> verified this on any other version yet.
> 
> The queries I see are these:
> 
> 22:15:29.657232 IP 172.16.21.2.57672 > 172.16.1.22.53:  54355+ A?
images.slashdot.org. (37)
> 22:15:29.658189 IP 172.16.21.2.64080 > 172.16.1.22.53:  46066+ AAAA?
images.slashdot.org. (37)
> 22:15:29.659407 IP 172.16.1.22.53 > 172.16.21.2.57672:  54355 1/13/1 A
66.35.250.55 (280)
> 22:15:29.659674 IP 172.16.1.22.53 > 172.16.21.2.64080:  46066 0/1/0 (96)
> 22:15:29.660514 IP 172.16.21.2.55636 > 172.16.1.22.53:  46067+ AAAA?
images.slashdot.org.b0rken.net. (48
> )
> 22:15:29.661438 IP 172.16.1.22.53 > 172.16.21.2.55636:  46067 NXDomain*
0/1/0 (99)
> 22:15:29.661847 IP 172.16.21.2.58524 > 172.16.1.22.53:  46068+ AAAA?
images.slashdot.org.bureau.b0rken.n
> et. (55)
> 22:15:29.662720 IP 172.16.1.22.53 > 172.16.21.2.58524:  46068 NXDomain*
0/1/0 (106)
> 
> So it sends out A and AAAA queries, so far so good.  It gets an answer
> for the A record query, however the AAAA query retuns an empty answer.
> What I find strange though, is the fact it's now applying the
searchlist
> to get an answer on the AAAA query.  Other than the fact this could
> potentially give unpredictable results in specific situations, I find
> this rather illogical.  Since one of the queries (A or AAAA) succeeded
> we _know_ the host in question exists (and the searchlist is there to
> make non-fqdn queries work for 'local' hosts, by applying the
searchlist
> if the host does not seem to exist).  So, in short, isn't this a bug?
> 
> Regards
	A lot of this behaviour follows from having to support pre
	RFC 1535 resolvers which walked the search list first and
	handling wildcard records with such a resolver.

	Such resolvers needed to continue on a nodata response as
	the wildcard would almost always be matched while walking
	the search list independent of query type.

	search a.example b.example
 
	and you have *.a.example A 1.2.3.4

	With a pre RFC 1535 resolver and uu.net mx record query you
	would get

	uu.net.a.example (nodata) uu.net.b.example (nxdomain)
	uu.net (data).

	A pre RFC 1535 could not stop on nodata and people started
	depending apon that behavior.  Even post RFC 1535 they still
	depend upon that behavior for host.subdomain queries.

	I suggest that you raise the issue on the ipv6 IETF working
	group mailing list as that was where getaddrinfo() behaviour
	was specified and it really does not cover search lists.

	The current getaddrinfo() specification handles the non
	search list case well.

	Mark
> Jan Gyselinck
> 
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
"freebsd-stable-unsubscribe@freebsd.org"
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

Hi,
>>>>> On Mon, 1 May 2006 20:46:40 +0200
>>>>> Jan Gyselinck <freebsd-stable@b0rken.net> said:
Jan> What I find strange though, is the fact it's now applying the
searchlist
Jan> to get an answer on the AAAA query.  Other than the fact this could
Jan> potentially give unpredictable results in specific situations, I find
Jan> this rather illogical.  Since one of the queries (A or AAAA) succeeded
Jan> we _know_ the host in question exists (and the searchlist is there to
Jan> make non-fqdn queries work for 'local' hosts, by applying the
searchlist
Jan> if the host does not seem to exist).  So, in short, isn't this a
bug?

Which application did you use?  The application which doesn't use
getaddrinfo(3) has this issue, and it cannot be fixed without
re-writing the application to use getaddrinfo(3).

Sincerely,

--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
ume@mahoroba.org  ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/