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: swm...@swm.pp.se _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
