A and AAAA DNS query process in getaddrinfo()?

blue susan.lan at zyxel.com.tw
Fri Aug 10 05:54:36 UTC 2007


Max Laier wrote:

>On Friday 10 August 2007, JINMEI Tatuya / 神明達哉 wrote:
>  
>
>>At Fri, 10 Aug 2007 11:52:09 +0800,
>>
>>blue <susan.lan at 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 at 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


More information about the freebsd-net mailing list