Date: Fri, 10 Aug 2007 13:45:46 +0800 From: blue <susan.lan@zyxel.com.tw> To: Max Laier <max@love2party.net> Cc: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlA==?=, freebsd-net@freebsd.org, =?UTF-8?B?5ZOJ?= <jinmei@isl.rdc.toshiba.co.jp> Subject: Re: A and AAAA DNS query process in getaddrinfo()? Message-ID: <46BBFB8A.1080509@zyxel.com.tw> In-Reply-To: <200708100648.51663.max@love2party.net> References: <46BBE0E9.1070707@zyxel.com.tw> <m1vebo10ab.wl%jinmei@isl.rdc.toshiba.co.jp> <200708100648.51663.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Max Laier wrote: >On Friday 10 August 2007, JINMEI Tatuya / 神明達哉 wrote: > > >>At Fri, 10 Aug 2007 11:52:09 +0800, >> >>blue <susan.lan@zyxel.com.tw> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46BBFB8A.1080509>