Re: DNS & IPv6

On 05/22/2010 05:37 PM, Amos Jeffries wrote:
> On Sat, 22 May 2010 17:04:49 -0600, Alex Rousskov
> <rousskov_at_measurement-factory.com> wrote:
>> On 05/14/2010 01:38 PM, Henrik Nordström wrote:
>>> As you may have noticed I have been looking at the IPv6 support in the
>>> last days, and now I am looking at how we perform DNS queries.
>>>
>>> Today we first do an AAAA query, followed by an A query. As we anyway
> do
>>> both queries it would be better if we ran both in parallell. The
>
> Except when configured with dns_v4_fallback == off. In which case the A
> look starting requires a NXDOMAIN result from the AAAA query.

NXDOMAIN implies the A query will return NXDOMAIN as well because the
domain does not exist. Unless we are trying to be compatible with
misconfigured or broken DNS servers, we should only try A (or should
keep waiting for A if Henrik implements concurrent lookups) if AAAA
results in a NOERROR response with no answer records.

>>> benefits of this is twofold:
>>>
>>> a) Lower latency.
>>>
>>> b) Easier policy on re-transmission
>>>
>>> But needs a bit of reshuffling to get done unfortunately, separating
> the
>>> actual queries a bit from the lookup.
>> Is there an RFC or somesuch that recommends parallel lookups over
>> sequential ones or vice versa?
>>
>> Thank you,
>>
>> Alex.
>
> No RFCs that I'm aware of (though I have not been following the newest
> ones). Just whitepapers about methods of encouraging and helping the
> world-wide v6 transition.
>
> For comparison the OS resolver does them sequentially with A first unless
> the options "inet6" entry is set. That default encourages non-v6 traffic
> which we want to reverse.

BIND starts with A as well, AFAIK.

Cheers,

Alex.

> Doing them in parallel I think is a good idea from the speed viewpoint. We
> will need to be careful over which lookup uses, such as forwarding, can go
> ahead with just ONE set and want the fastest path; versus lookups like
> config and ACL which require BOTH to be completed before it is reliably
> answered.
>
> Amos
Received on Sat May 22 2010 - 23:49:30 MDT