[DNSOP] opportunistic refresh and Happy Eyeballs

[Mikael Abrahamsson <[e-mail]>]

Hi,

we've had a discussion on V6OPS 
(https://www.ietf.org/mail-archive/web/v6ops/current/msg27337.html) where 
Mark Andrews has brought up the topic of caching DNS resolvers not being 
populated with A and AAAA information at the same time, or the TTL might 
expire at different points in time, thus causing the Happy Eyeballs 
algorithm to use IPv4 more than IPv6 because of the 50ms total timer of 
DNS lookup+TCP initation.

I had a look into this, and there are some drafts regarding opportunistic 
refresh of information to try to avoid records expiring, and instead 
refreshing them before they expire.

One I have found is 
https://tools.ietf.org/html/draft-muks-dnsop-dns-opportunistic-refresh-00

There was another opinion in the discussion 
(https://www.ietf.org/mail-archive/web/v6ops/current/msg27356.html) that 
caching resolvers should try to keep AAAA and A cached as long as one of 
them is being asked for. Currently I believe there is no such "coupling" 
between RR types?

What is the opinion of this wg on that topic? I believe the best solution 
for the problem statement in Happy Eyeballs is a solution that needs to 
change behaviour both in the client (DNS lookups and TCP session 
initiation) but also in the resolver.

If we can have a reasonable expectation that the caching resolver is 
always "hot" when it comes to frequently used A and AAAA records, that 
would mean we'd need less DNS lookup delay, waiting for both lookups to 
complete before deciding what to do regarding IPv6 and IPv4 TCP session 
initiation.

Right now RFC6555bis proposes a 50ms head start for IPv6 (DNS lookup+TCP 
init), which IPv6 will lose if the DNS resolver AAAA is expired and the A 
is cached, and the authoritative DNS server is far away TTL-wise.

However, introducing a really high head start for IPv6 in this setup is 
not desireable either, let's say 500ms head start to handle that the 
authoritative DNS server is 400ms RTT away. This would give a bad user 
experience in some other cases.

Thoughts?

-- 
Mikael Abrahamsson    email: [e-mail]