From owner-freebsd-net@FreeBSD.ORG Fri Aug 10 05:54:36 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BBD216A418 for ; Fri, 10 Aug 2007 05:54:36 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zyfb01-66.zyxel.com.tw (zyfb01-66.zyxel.com.tw [59.124.183.66]) by mx1.freebsd.org (Postfix) with ESMTP id C87A713C457 for ; Fri, 10 Aug 2007 05:54:35 +0000 (UTC) (envelope-from Susan.Lan@zyxel.com.tw) Received: from zytwbe01.zyxel.com ([172.23.5.10]) by zyfb01-66.zyxel.com.tw with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 13:54:34 +0800 Received: from zytwfe01.ZyXEL.com ([172.23.5.5]) by zytwbe01.zyxel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 13:54:31 +0800 Received: from [172.23.17.155] ([172.23.17.155]) by zytwfe01.ZyXEL.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 13:45:29 +0800 Message-ID: <46BBFB8A.1080509@zyxel.com.tw> Date: Fri, 10 Aug 2007 13:45:46 +0800 From: blue User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Max Laier References: <46BBE0E9.1070707@zyxel.com.tw> <200708100648.51663.max@love2party.net> In-Reply-To: <200708100648.51663.max@love2party.net> X-OriginalArrivalTime: 10 Aug 2007 05:45:29.0325 (UTC) FILETIME=[A89EB9D0:01C7DB11] Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlA==?=, freebsd-net@freebsd.org, =?UTF-8?B?5ZOJ?= Subject: Re: A and AAAA DNS query process in getaddrinfo()? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2007 05:54:36 -0000 Max Laier wrote: >On Friday 10 August 2007, JINMEI Tatuya / 神明達哉 wrote: > > >>At Fri, 10 Aug 2007 11:52:09 +0800, >> >>blue wrote: >> >> >>>When looking into kame-20070801-freebsd54-snap, the function, >>>_dns_getaddrinfo(), defined in getaddrinfo.c, will check if the >>>device gets any IPv4/global IPv6 address before sending out any >>>A/AAAA query by calling addrconfig() if the user does not specify the >>>family type (AF_UNSPEC). However, FreeBSD-CURRENT (known is going to >>>be FreeBSD7.0), does not do the process. >>> >>>Do we need to do the same check before sending out the A/AAAA query? >>> >>> >>I'm afraid just asking this question without providing a context could >>be misleading. I guess this is a continuation of a thread of the >>snap-users@kame list: >> >>ftp://ftp.kame.net/pub/mail-list/snap-users/9541 >>ftp://ftp.kame.net/pub/mail-list/snap-users/9544 >> >>If so, we should discuss this with the understanding of why KAME-snap >>version behaves that way, specifically referring to Section 3 >>(especially 3.4.1) of this document: >>http://v6fix.net/docs/wide-draft-v6fix.en >> >>We (KAME) thought the behavior was reasonable but we were also afraid >>this might be too experimental to incorporate to *BSD release >>versions at that time. That's why it's not in the FreeBSD repository. >>I'm interested in what others think on this. If others think this >>feature is reasonable, too, and want it, I'm happy to commit the >>change to the FreeBSD repository. >> >> > >I agree with the reasoning in the document you reference above. >getaddrinfo is a convenience resolver and thus it's a good thing to >return reasonable defaults. Not returning AAAA when there are no IPv6 >addresses around seems reasonable to me. I'm not sure it's a good idea >to go the other way (i.e. not sending A queries when there are no IPv4 >addresses), however. > > > Although DNS resolver may lead to some delay or misbehavior of the upper application, I think that would be caller's resposibility to decide which result it would like to use. I am not so sure about the check in KAME implementation, in getaddrinfo.c: _dns_getaddrinfo( void *rv, void *cb_data, va_list ap ){ ..... switch (pai->ai_family) { case AF_UNSPEC: qp = &q; buf_current = buf; /* * Since queries for AAAA can cause unexpected misbehavior, * we first send A queries. Note that the query ordering * is independent from the ordering of the resulting addresses * returned by getaddrinfo(). */ if (addrconfig(AF_INET, ac)) { qp->name = hostname; qp->qclass = C_IN; qp->qtype = T_A; qp->answer = buf_current->buf; qp->anslen = sizeof(buf_current->buf); if (addrconfig(AF_INET6, ac)) { qp->next = &q2; buf_current = buf2; qp = &q2; } } if (addrconfig(AF_INET6, ac)) { qp->name = hostname; qp->qclass = C_IN; qp->qtype = T_AAAA; qp->answer = buf_current->buf; qp->anslen = sizeof(buf_current->buf); } break; case AF_INET: q.name = hostname; q.qclass = C_IN; q.qtype = T_A; q.answer = buf->buf; q.anslen = sizeof(buf->buf); break; case AF_INET6: q.name = hostname; q.qclass = C_IN; q.qtype = T_AAAA; q.answer = buf->buf; q.anslen = sizeof(buf->buf); break; default: free(buf); free(buf2); return NS_UNAVAIL; } ..... } Why the check for avilable IPv4/IPv6 address, addrconfig(), only applies when the hints' family type is AF_UNSPEC? I think if delaying the upper application is a concern, the check should be applied no matter what family type it is. Thanks. Best regards, Yi-Wen