Subject: Re: CNAME ordering in ares_parse_a_reply()

Re: CNAME ordering in ares_parse_a_reply()

From: James deBoer <deboer_at_google.com>
Date: Mon, 8 Sep 2008 13:04:54 -0700

On Thu, Sep 4, 2008 at 8:06 PM, William Ahern
<william_at_25thandclement.com> wrote:
> On Thu, Sep 04, 2008 at 07:05:54PM -0700, James deBoer wrote:
>> Hello,
>>
>> I am using c-ares to resolve host names from a server which returns
>> CNAME records after A records.
>>
>> For example, a request for lion.domain would return:
>>
>> cat.domain. IN A 1.2.3.4
>> lion.domain. IN CNAME cat.domain.
>>
>> This order is opposite to BIND, which always returns CNAME records
>> first. I haven't found any documentation that specifies a record
>> order, but I haven't read all the RFCs closely either.
>>
>> Currently, ares_parse_a_reply() makes a single pass over the DNS
>> reply. By the time it follows the CNAME pointer, it has missed the
>> relevant A record.
>>
>> I have a patch that adds an additional pass to ares_parse_a_reply()
>> which resolves the CNAME chain before examining the A records. This
>> change allows c-ares to resolve lion.domain. Is this the correct
>> approach, or are these upside-down replies invalid?
>>
>
> I don't understand. Maybe I haven't used Ares recently enough to understand
> that API, but if the CNAME wasn't in-bailiwick (i.e. lion.domain's CNAME was
> cat.otherdomain), a resolver would have to query again to get an answer. So,
> this patch would still leave things broken, if indeed I understand what's
> happening.

That is correct. c-ares doesn't attempt to resolve dangling CNAMEs
either. In order to query authoritative servers, it should be able to
do that as well. The patch I am proposing doesn't fix everything, but
it does make ares_parse_a_reply() less broken.
Received on 2008-09-08