On 05/22/2010 05:37 PM, Amos Jeffries wrote: > On Sat, 22 May 2010 17:04:49 -0600, Alex Rousskov > <rouss...@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
