At Tue, 15 Aug 2017 13:40:00 +0200 (CEST), Mikael Abrahamsson <swm...@swm.pp.se> wrote:
> > If it's a commonly-used name, isn't this a one-time event, though? The > > happy eyeballs client asks for A and AAAA, gets A because it was in the > > cache, but AAAA also winds up in the cache, and then because it's a > > commonly used name, neither record ever goes stale again. > > That was the assumtion by a lot of people who aren't DNS experts > (including me). Mark Andrews brought up that this might be a more frequent > issue that people think. > > Also there is the issue that as the TTL becomes 0 and the RR is now no > longer in cache, next question will trigger a lookup and if the > authoritative nameserver is 400ms RTT away, then during these 400ms a lot > of clients might only use IPv4 with current RFC6555bis proposal. If it's a commonly-used name, I suspect the more straightforward "prefetching" should suffice in practice: https://datatracker.ietf.org/doc/draft-wkumari-dnsop-hammer/ Several popular recursive servers already implement the feature. Some of them even enable it by default. My impression on the rfc6555bis thread is that Mark wanted to make it "safer" (in that both AAAA and A responses are provided before trying to establish a TCP connection) even in some near-worst cases, not just "working in most cases in practice". In that sense I suspect tricks at the resolver won't help much, whether it's existing prefetch, opportunistic refresh or bundled AAAA/A queries, since there are worst cases where those don't work. Whether we need this level of perfection for rfc6555bis is a different question, though. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
