Re: [DNSOP] opportunistic refresh and Happy Eyeballs

On Tue, Aug 15, 2017 at 1:08 PM, 神明達哉 <jinmei@wide.ad.jp> wrote:
> At Tue, 15 Aug 2017 13:40:00 +0200 (CEST),
> Mikael Abrahamsson <swmike@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.
>

One of the main outstanding items on the "Stop! Hammer Time!" document
that we need to clean up the implementation section (Appendix A), but
it does note that at least Unbound (NLNet Labs), OpenDNS, and ISC BIND
9.10 implement this.

Unbound's documentation says that the default for prefetch is disabled
(https://www.unbound.net/documentation/unbound.conf.html), and, BIND
enables it by default (
https://kb.isc.org/article/AA-01122/204/Early-refresh-of-cache-records-cache-prefetch-in-BIND-9.10.html
)

W

> 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

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf