Re: [DNSOP] opportunistic refresh and Happy Eyeballs

On 08/15/2017 01:27 PM, Jared Mauch wrote: >> On Aug 15, 2017, at 3:25 AM, Mikael Abrahamsson wrote: >> >> What is the opinion of this wg on that topic? > There has been much discussion about doing away with any/255 and I seem to > recall some discussion of a ANYA type which

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

> On Aug 15, 2017, at 2:25 PM, Paul Vixie wrote: > > > > Viktor Dukhovni wrote: >> On Tue, Aug 15, 2017 at 10:28:15AM -0700, Paul Vixie wrote: >> ... >>> >>> We can specify that be sent as additional data for QTYPE=A, and >>> that A be sent as additional data when

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

On 16.8.2017 23:59, Warren Kumari wrote: > On Wed, Aug 16, 2017 at 4:05 AM, Ralf Weber wrote: >> Moin! >> >> On 16 Aug 2017, at 2:44, Warren Kumari wrote: If it's a commonly-used name, I suspect the more straightforward "prefetching" should suffice in practice:

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

On Wed, Aug 16, 2017 at 4:05 AM, Ralf Weber wrote: > Moin! > > On 16 Aug 2017, at 2:44, Warren Kumari wrote: >>> If it's a commonly-used name, I suspect the more straightforward >>> "prefetching" should suffice in practice: >>>

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

Moin! On 16 Aug 2017, at 2:44, Warren Kumari wrote: >> 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.

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

Hi Warren On Tue, Aug 15, 2017 at 08:33:30PM -0400, Warren Kumari wrote: > multiple-responses allows servers to opportunistically include this > info. We still need to do some analysis to figure out just how much of > an improvement this generates, but it doesn't require any additional >

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

On Tue, Aug 15, 2017 at 1:08 PM, 神明達哉 wrote: > At Tue, 15 Aug 2017 13:40:00 +0200 (CEST), > Mikael Abrahamsson wrote: > >> > If it's a commonly-used name, isn't this a one-time event, though? The >> > happy eyeballs client asks for A and , gets A because

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

Or we could just say that mapped IPv4 addresses MUST be published in records and that A records are no longer required to be published after January 1, 2028 (now + ~10 years). Additionally that master nameservers and signers MUST synthesis mapped record if there are A records at the

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

> On Aug 15, 2017, at 14:25, Paul Vixie wrote: > > Viktor Dukhovni wrote: >> On Tue, Aug 15, 2017 at 10:28:15AM -0700, Paul Vixie wrote: >> ... >>> >>> We can specify that be sent as additional data for QTYPE=A, and >>> that A be sent as additional data when QTYPE=.

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

Viktor Dukhovni wrote: On Tue, Aug 15, 2017 at 10:28:15AM -0700, Paul Vixie wrote: ... We can specify that be sent as additional data for QTYPE=A, and that A be sent as additional data when QTYPE=. given identical deployment curves along both the ANYA and additional-data timelines,

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

Jared Mauch wrote: we can specify that be sent as additional data for QTYPE=A, and that A be sent as additional data when QTYPE=. given identical deployment curves along both the ANYA and additional-data timelines, we will get identical results. As this is DNSOP, what

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

On Tue, Aug 15, 2017 at 10:28:15AM -0700, Paul Vixie wrote: > > There has been much discussion about doing away with any/255 and I > > seem to recall some discussion of a ANYA type which would return > > and A. > > > > This is something I see value in being implemented. > > as i've said

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

> On Aug 15, 2017, at 1:28 PM, Paul Vixie wrote: > > > > Jared Mauch wrote: >> >>> On Aug 15, 2017, at 3:25 AM, Mikael Abrahamsson >>> wrote: >>> >>> What is the opinion of this wg on that topic? >> >> There has been much discussion about doing away with

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

Tony Finch wrote: On 15 Aug 2017, at 20:28, Paul Vixie wrote: we can specify that be sent as additional data for QTYPE=A, and that A be sent as additional data when QTYPE=. It's awkward. it seems so, but is not. From the stub point of view, how does it know

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

> On 15 Aug 2017, at 20:28, Paul Vixie wrote: > > we can specify that be sent as additional data for QTYPE=A, and that A > be sent as additional data when QTYPE=. It's awkward. >From the stub point of view, how does it know that the server will return >additional

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

Paul Hoffman wrote: ... This WG has already spent years trying to rearchitect the A/ lookup. that goal has been sought since longer than this wg has existed. however, adding the other kind of address record to the additional data section is something anyone can do, it breaks nothing,

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

Jared Mauch wrote: On Aug 15, 2017, at 3:25 AM, Mikael Abrahamsson wrote: What is the opinion of this wg on that topic? There has been much discussion about doing away with any/255 and I seem to recall some discussion of a ANYA type which would return and A. This

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

At Tue, 15 Aug 2017 13:40:00 +0200 (CEST), Mikael Abrahamsson wrote: > > If it's a commonly-used name, isn't this a one-time event, though? The > > happy eyeballs client asks for A and , gets A because it was in the > > cache, but also winds up in the cache, and then

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

The Query portion of the DNS protocol can probably ask more than one question at a time. (I think I've only ever seen "QUERY: 1" in all the digs I've ever done - but might be wrong). Of course - if one were to ask for both an A and at the same time - one gets the same problem - how does one

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

What is the opinion of this wg on that topic? There has been much discussion about doing away with any/255 and I seem to recall some discussion of a ANYA type which would return and A. This is something I see value in being implemented. Would it be easier in this case to implement

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

On Tue, 15 Aug 2017, Ted Lemon wrote: If it's a commonly-used name, isn't this a one-time event, though? The happy eyeballs client asks for A and , gets A because it was in the cache, but also winds up in the cache, and then because it's a commonly used name, neither record ever

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

El 15 ag 2017, a les 3:25, Mikael Abrahamsson va escriure: > Right now RFC6555bis proposes a 50ms head start for IPv6 (DNS lookup+TCP > init), which IPv6 will lose if the DNS resolver is expired and the A is > cached, and the authoritative DNS server is far away TTL-wise.

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

> On Aug 15, 2017, at 3:25 AM, Mikael Abrahamsson wrote: > > What is the opinion of this wg on that topic? There has been much discussion about doing away with any/255 and I seem to recall some discussion of a ANYA type which would return and A. This is something I

[DNSOP] opportunistic refresh and Happy Eyeballs

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 information at the same time, or the TTL might expire at different points in time,