A and AAAA DNS query process in getaddrinfo()?

[blue]

JINMEI Tatuya / ???? wrote:

>At Fri, 10 Aug 2007 13:45:46 +0800,
>blue <susan.lan at 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 at isl.rdc.toshiba.co.jp
>
>  
>
Dear Jinmei:

Thanks for your detailed explanation, and I have a deeper insight into 
the problem that IPv4/IPv6 dual stack may introduce to current applications.

Best regards,

Yi-Wen