Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Vladimír Čunát]

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 would return  and A. 
>
> This is something I see value in being implemented. 

I can't see how that is relevant, really.  Either you ask two separate
queries or you might ask one for ANYA.

--Vladimir

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Brian Wellington]

> 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 QTYPE=.
>>> 
>>> given identical deployment curves along both the ANYA and
>>> additional-data timelines, we will get identical results.
>> 
>> +1, by far simpler/cleaner than adding a new RR type.
> 
> viktor, if you write this up and submit it as an i-d, i agree to review it.

I volunteer to review this, as well.

Brian

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Petr Špaček]

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:
 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.
>> From how I read the document and understand the implementations none of
>> those implements the actual draft, but instead they have implementations
>> that do some sort of prefetching. If that is the case you can add Nominum
>> Cacheserve to the list,

BTW you can count Knot Resolver in as well.

-- 
Petr Špaček  @  CZ.NIC

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Warren Kumari]

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:
>>> 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.
> From how I read the document and understand the implementations none of
> those implements the actual draft, but instead they have implementations
> that do some sort of prefetching. If that is the case you can add Nominum
> Cacheserve to the list,

Awesome!

> but I really think we should do some more general
> document describing prefetching as a concept and not just one way how to
> do it with a hammer ;-).

Yeah, we keep meaning to go back and fix up the document. I think that
it (and, even more so,  the discussions) has already served it's
primary purpose - it led to this being implemented. But, I think that
it would be good if we now update it to explain what is now
implemented, and how...

I must admit that I some of my hesitance has been because I'm still
entertained by the "joke", and know that I need to just get over this
:-)

W
>
> So long
> -Ralf



-- 
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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Ralf Weber]

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.
>> 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.
>From how I read the document and understand the implementations none of
those implements the actual draft, but instead they have implementations
that do some sort of prefetching. If that is the case you can add Nominum
Cacheserve to the list, but I really think we should do some more general
document describing prefetching as a concept and not just one way how to
do it with a hammer ;-).

So long
-Ralf

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Mukund Sivaraman]

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
> requests. If the server (auth or recursive) knows that a client
> (recursive or stub) might be able to use this into, it just shovels it
> in. This leads to larger responses, but I think that we lost the
> "small packets" battle long ago -- attackers who want to find big
> responses for reflections can easily do so...

There's a cost attached to how much information is in a reply
message. Lookup of data, rendering it to a DNS message, RR ordering,
name compression, etc. all consume CPU and the query performance of a
service is affected by how many RRsets it includes in a reply. This is
significant and should not be ignored when thinking about these
extensions.

I favour the draft where the client requests for things it needs
(including for TLSA as somebody pointed out) than the server adding what
it thinks a client may need (a lot of which may end up being thrown away
by the client).

I don't oppose bundling A/ though per this thread.

Mukund

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Warren Kumari]

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 it was in the
>> > cache, but  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  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 /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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Mark Andrews]

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 name but no associated  record.

In message <43be41d4-40fa-49da-8f8e-13651f9df...@nominum.com>, Bob Halley write
s:
> 
> > 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=.
> >>> 
> >>> given identical deployment curves along both the ANYA and
> >>> additional-data timelines, we will get identical results.
> >> 
> >> +1, by far simpler/cleaner than adding a new RR type.
> > 
> > viktor, if you write this up and submit it as an i-d, i agree to review it.
> 
> I am also willing to review such a draft.
> 
> /Bob
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Bob Halley]

> 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=.
>>> 
>>> given identical deployment curves along both the ANYA and
>>> additional-data timelines, we will get identical results.
>> 
>> +1, by far simpler/cleaner than adding a new RR type.
> 
> viktor, if you write this up and submit it as an i-d, i agree to review it.

I am also willing to review such a draft.

/Bob

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Paul Vixie]

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, we will get identical results.


+1, by far simpler/cleaner than adding a new RR type.


viktor, if you write this up and submit it as an i-d, i agree to review it.

--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Paul Vixie]

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 implementations support this?


of authorities, none.

of recursives as initiators, most.

of recursives as responders, none.

of stubs, some.

there are two measurable lobes here. one is now, where any authority who 
adopts this behaviour is likely to pre-seed the recursive initiator's 
cache with "the other answer" (among A and ), and any stub who makes 
two queries in series ( then A) will get a faster answer to the 
second query.


the other is the future, where stubs are taught to notice the additional 
data section and begin to avoid the second query, and where recursive 
responders both ensure that they do cache additional data whose owner is 
the same as the effective qname, and begin to send additional data to stubs.


so, the benefit begins immediately, but gets better over time, and there 
is no new signalling required, and nothing ever breaks, and it is never 
necessary to try-then-fallback (causing additional round trips.)


have no fear. every few years this topic comes up, and i say what i'm 
saying, and we don't do it, and then people ask for QDCOUNT>1 again. so 
we are right on track at this stage of the thread. had the response to 
"resimprove" been better, i would have written this up before now.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Viktor Dukhovni]

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 every few years when this proposal comes up, it's unnec'y.
> 
> 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.

+1, by far simpler/cleaner than adding a new RR type.

On Tue, Aug 15, 2017 at 11:28:41AM -0700, Paul Vixie 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, it will only be used
> opportunistically.
> 
> adding it to the answer section would be more problematic.
> 
> but no rfc is needed to give permission, and since these records could be
> signed and can in any case be cached, the impact would be immediate.

With no need to change stub or caching resolvers.  Just the
authoritative servers can be upgraded incrementally.  Though
multi-stage caches might benefit from similar logic in the upstream
cache.  This has a clear advantage over introducing new query types.

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Jared Mauch]

> 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 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 every few years when this proposal comes up, it's unnec'y.
> 
> 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 implementations support this?

- Jared

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Paul Vixie]

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 that the server will
return additional address records? How does it tell the difference
between no support, no records, or an empty cache? To what extent do
the additional records actually help clients to avoid double
queries?


the stub resolver as of today will most likely not look in the 
additional data section. i think the happy eyeballs community has enough 
cohesion around their client-side features that apple, microsoft, 
google, the bigger linux distros like ubunto and debian and redhat and 
suse, and bsd, would all modify their gethostby*() logic if this idea 
took off. and the getdnsapi people of course, likewise.


however, they would have to make a change to support ANYA, so that's not 
new work in the "a/ as additional" timeline vs. the ANYA timeline. 
what matters, then is the authority-to-cache side.



From the recursive server point of view, should it delay answers so
it can fill in the additional section?


no. it should answer with what it's got without fetching anything new, 
like all additional data other than the rare case of in-zone a/ 
referenced by NS.



What if a broken authority
doesn't answer to  queries?


n/a.


DNSSEC can help a bit because there would be a visible proof of
nonexistence to disambiguate some cases.


n/a.


given identical deployment curves along both the ANYA and
additional-data timelines, we will get identical results.


ANYA has the advantage of clear signalling that the server supports
it or not, though broken servers or middleboxes might make the
negative answer rather slow. But we would need some kind of modelling
or experimental evidence to see if it increases the query load by 50%
(the worst case) rather than reducing by 50% (the goal).


in the just-send-additional model, the recursive will more often have 
both A and  rrsets in cache (because it will indeed cache the 
additional data section, using cache precedence and credibility rules, 
under which same-owner should be at the ANSWER credibility level even 
though that's not the section it was found in).


this means the stub that makes two queries will get the second answer 
much faster. and that future stubs that make one query and get both 
answers and use both answers will not have to make a second query.




-- P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Tony Finch]

> 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 address records? How does it tell the difference between no 
>support, no records, or an empty cache? To what extent do the additional 
>records actually help clients to avoid double queries?

>From the recursive server point of view, should it delay answers so it can 
>fill in the additional section? What if a broken authority doesn't answer to 
> queries?

DNSSEC can help a bit because there would be a visible proof of nonexistence to 
disambiguate some cases.

> given identical deployment curves along both the ANYA and additional-data 
> timelines, we will get identical results.

ANYA has the advantage of clear signalling that the server supports it or not, 
though broken servers or middleboxes might make the negative answer rather 
slow. But we would need some kind of modelling or experimental evidence to see 
if it increases the query load by 50% (the worst case) rather than reducing by 
50% (the goal).

Tony.
-- 
f.anthony.n.finch    http://dotat.at
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Paul Vixie]

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, it will only be 
used opportunistically.


adding it to the answer section would be more problematic.

but no rfc is needed to give permission, and since these records could 
be signed and can in any case be cached, the impact would be immediate.


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Paul Vixie]

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 is something I see value in being implemented.


as i've said every few years when this proposal comes up, it's unnec'y.

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.

--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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 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  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 /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

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Mark Elkins]

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 sort out whether there is an
 if there is a valid answer to A, and visa versa.

"dig machine.domain.com a machine.domain.com " - actually works but
does this as two queries.

I think the cleanest way would be a new pseudo record (ANYA) as the
reply would have to be a single complete resource set of all the
possible answers (A's and 's), all with one covering signature if
DNSSEC is involved. One would then programmatically know then what was
available.


On 15/08/2017 14:00, fredrik danerklint 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 see value in being implemented.
>>
>>
> Would it be easier in this case to implement this behavior instead of
> creating a new type?
>
> If a authority DNS server is getting a question type of A and it has
> both A and  records, put both in the answer. The same for a
> question type of , if it has both A and  records put those in
> the answer.
>
> If it got a question type of A and it doesn't have the A record but it
> has the  record, what should the behavior be in this case? The
> same for other way around of course, question type  but it does
> not have the  record, only the A record. Should it add the known
> record or not at all?
>

-- 
Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[fredrik danerklint]

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 this behavior instead of 
creating a new type?


If a authority DNS server is getting a question type of A and it has 
both A and  records, put both in the answer. The same for a question 
type of , if it has both A and  records put those in the answer.


If it got a question type of A and it doesn't have the A record but it 
has the  record, what should the behavior be in this case? The same 
for other way around of course, question type  but it does not have 
the  record, only the A record. Should it add the known record or 
not at all?


--
//fda

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Mikael Abrahamsson]

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 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.


So there are two things here I see:

1. Opportunistically refresh RRs before they expire. I've been told some 
resolvers do this already.


2. Tie together A and  so that if one is asked for, make sure there is 
an up-to-date of the second one as well, at least make sure it doesn't 
expire even if it's infrequently used. I guess this means take into 
account A questions when deciding whether to refresh that  you might 
have?


--
Mikael Abrahamssonemail: swm...@swm.pp.se

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Ted Lemon]

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.

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 goes stale again.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

[Jared Mauch]

> 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 see value in being implemented. 

- jared 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] opportunistic refresh and Happy Eyeballs

[Mikael Abrahamsson]

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, 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  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  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  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 Abrahamssonemail: swm...@swm.pp.se

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop