Date: Fri, 10 Aug 2007 17:29:41 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp> To: blue <susan.lan@zyxel.com.tw> Cc: Max Laier <max@love2party.net>, freebsd-net@freebsd.org Subject: Re: A and AAAA DNS query process in getaddrinfo()? Message-ID: <m1tzr723nu.wl%jinmei@isl.rdc.toshiba.co.jp> In-Reply-To: <46BBFB8A.1080509@zyxel.com.tw> References: <46BBE0E9.1070707@zyxel.com.tw> <m1vebo10ab.wl%jinmei@isl.rdc.toshiba.co.jp> <200708100648.51663.max@love2party.net> <46BBFB8A.1080509@zyxel.com.tw>
next in thread | previous in thread | raw e-mail | index | archive | help
At Fri, 10 Aug 2007 13:45:46 +0800, blue <susan.lan@zyxel.com.tw> wrote: > 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: (snip) > 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. I thought the v6fix document provided sufficient background to answer these questions, but in case it didn't I'm going to rephrase the points: - ideally, we'd not want to introduce the special behavior; as you indicated above, the ideal behavior for getaddrinfo() called with AF_UNSPEC would be to return all possible IPv4 and IPv6 addresses via A and AAAA queries. - unfortunately, however, a dual stack application running on IPv4-only node could suffer from various problems due to misbehaving DNS servers if the underlying resolver sends out AAAA queries. Note that the most typical behavior for such dual stack applications is to call getaddrinfo() with AF_UNSPEC. - the specific behavior of the KAME-snap version of getaddrinfo() is a workaround to mitigate the problem in the conflicting situation, yet still being compliant to the API specification. - since this is a workaround, we'd not want to do the same ugly hack for the less common case of getaddrinfo() called with AF_INET6. Also, in this case the node without an effective IPv6 address would not be able to make any IPv6 communication regardless of the getaddrinfo() results or how long it takes, and the application doesn't have any alternative network protocol unlike the case of AF_UNSPEC, so introducing the same hack doesn't actually help the application. - so, comparison between the AF_UNSPEC case and the AF_INET6/AF_INET case in terms of superficial consistency doesn't really make sense. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m1tzr723nu.wl%jinmei>