Subject: [DNSOP] opportunistic refresh and Happy Eyeballs

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Aug 2017 09:25:55 +0200 (CEST)

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: [email-masked]

---

From: Jared Mauch <[email-masked]>
Date: Tue, 15 Aug 2017 07:27:27 -0400

> On Aug 15, 2017, at 3:25 AM, Mikael Abrahamsson <[email-masked]> 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 AAAA and A. 

This is something I see value in being implemented. 

- jared

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Aug 2017 07:29:18 -0400

El 15 ag 2017, a les 3:25, Mikael Abrahamsson <[email-masked]> va escriure:
> 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.

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.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Aug 2017 13:40:00 +0200 (CEST)

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

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 AAAA 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 AAAA you might 
have?

---

From: fredrik danerklint <[email-masked]>
Date: Tue, 15 Aug 2017 14:00:21 +0200

> 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 AAAA records, put both in the answer. The same for a question 
type of AAAA, if it has both A and AAAA 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 AAAA record, what should the behavior be in this case? The same 
for other way around of course, question type AAAA but it does not have 
the AAAA record, only the A record. Should it add the known record or 
not at all?

-- 
//fda

---

From: Mark Elkins <[email-masked]>
Date: Tue, 15 Aug 2017 14:29:45 +0200

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 AAAA at the same time
- one gets the same problem - how does one sort out whether there is an
AAAA if there is a valid answer to A, and visa versa.

"dig machine.domain.com a machine.domain.com aaaa" - 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 AAAA'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:
>> 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 AAAA
>> and A.
>>
> both A and AAAA records, put both in the answer. The same for a
> question type of AAAA, if it has both A and AAAA records put those in
> the answer.
>
> has the AAAA record, what should the behavior be in this case? The
> same for other way around of course, question type AAAA but it does
> not have the AAAA record, only the A record. Should it add the known
> record or not at all?
>

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

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 15 Aug 2017 14:53:15 +0200

Hello, I can't bear to watch this anymore.

On 08/15/2017 02:29 PM, Mark Elkins wrote:
> [...]

Such changes would *not* help, really.  You can ask both A and AAAA in
separate parallel queries easily.  If something like ANYA was asked
instead, you would run into the risk of the server not implementing it
and introducing yet another round trip (in the better not-implemented
cases).

The main question on client side is how long to wait if one answer comes
and the other doesn't, but that does seem better decided by the client
(with separate queries) than by intermediate resolvers (with a single
query).  On resolver side, one could recommend some prefetching
strategies, as mentioned, and I can imagine having some such
recommendations in rfc6555bis (non-mandatory).

--Vladimir

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 15 Aug 2017 09:33:37 -0700

On 15 Aug 2017, at 4:29, 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 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.

+1 to this question. Happy eyeballs might tend to v4 for the first 
lookup, but then hopefully not after that.

This WG has already spent years trying to rearchitect the A/AAAA lookup.

--Paul Hoffman

---

From: 神明達哉 <[email-masked]>
Date: Tue, 15 Aug 2017 10:08:57 -0700

At Tue, 15 Aug 2017 13:40:00 +0200 (CEST),

> 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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Aug 2017 10:28:15 -0700

Jared Mauch wrote:
>
>> On Aug 15, 2017, at 3:25 AM, Mikael Abrahamsson<[email-masked]>
>> wrote:
>>

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

we can specify that AAAA be sent as additional data for QTYPE=A, and
that A be sent as additional data when QTYPE=AAAA.

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

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Aug 2017 11:28:41 -0700

Paul Hoffman wrote:
> ...

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

---

From: Tony Finch <[email-masked]>
Date: Tue, 15 Aug 2017 22:05:35 +0300

> On 15 Aug 2017, at 20:28, Paul Vixie <[email-masked]> wrote:
> 
> we can specify that AAAA be sent as additional data for QTYPE=A, and that A be sent as additional data when QTYPE=AAAA.

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 AAAA 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  <[email-masked]>  http://dotat.at

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Aug 2017 12:41:18 -0700

Tony Finch wrote:
>> On 15 Aug 2017, at 20:28, Paul Vixie<[email-masked]> wrote:
>>
>> we can specify that AAAA be sent as additional data for QTYPE=A,
>> and that A be sent as additional data when QTYPE=AAAA.
>
> 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/aaaa 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/aaaa 
referenced by NS.

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

n/a.

> nonexistence to disambiguate some cases.

n/a.

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

---

From: Jared Mauch <[email-masked]>
Date: Tue, 15 Aug 2017 15:45:20 -0400

> On Aug 15, 2017, at 1:28 PM, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> Jared Mauch wrote:
>> 

As this is DNSOP, what implementations support this?

- Jared

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Aug 2017 19:46:07 +0000

On Tue, Aug 15, 2017 at 10:28:15AM -0700, Paul Vixie wrote:

> We can specify that AAAA be sent as additional data for QTYPE=A, and

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

On Tue, Aug 15, 2017 at 11:28:41AM -0700, Paul Vixie wrote:

> section is something anyone can do, it breaks nothing, it will only be used
> opportunistically.
> 
> 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.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Aug 2017 12:50:57 -0700

> 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 AAAA), and any stub who makes 
two queries in series (AAAA 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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Aug 2017 14:25:34 -0700

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

---

From: Bob Halley <[email-masked]>
Date: Tue, 15 Aug 2017 22:57:27 +0000

> On Aug 15, 2017, at 14:25, Paul Vixie <[email-masked]> wrote:
> 
> Viktor Dukhovni wrote:

I am also willing to review such a draft.

/Bob

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Aug 2017 09:42:54 +1000

Or we could just say that mapped IPv4 addresses MUST be published
in AAAA 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 AAAA record
if there are A records at the name but no associated AAAA record.

In message <[email-masked]>, Bob Halley write
s:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 Aug 2017 17:00:35 -0700

> if there are A records at the name but no associated AAAA record.

that proposal is in a different echelon of both complexity and 
controversy, and should not be considered as an alternative.

-- 
P Vixie

---

From: Warren Kumari <[email-masked]>
Date: Tue, 15 Aug 2017 20:33:30 -0400

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

This is a subset of draft-wkumari-dnsop-multiple-responses-05
("Returning extra answers in DNS responses."):
"Other examples where this technique may be useful include SMTP (by
   including mail server addresses, SPF and DKIM records when serving
   the MX record), SRV (by providing the target information in addition
   to the SRV response) and TLSA (by providing any TLSA records
   associated with a name).  This same technique can also be used to
   include both the IPv4 (A) and IPv6 (AAAA) addresses for any singular
   address query."
The above document does require DNSSEC, and is clearly an
optimization, but if the auth-> recursive or recursive -> stub
includes an AAAA with an A (or the other way round), it means that
you'll have it handy.

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

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

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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 15 Aug 2017 20:44:48 -0400

> 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

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 16 Aug 2017 06:35:14 +0530

Hi Warren

> 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/AAAA though per this thread.

		Mukund

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 16 Aug 2017 10:05:50 +0200

Moin!

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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 16 Aug 2017 17:59:45 -0400

On Wed, Aug 16, 2017 at 4:05 AM, Ralf Weber <[email-masked]> wrote:
> Cacheserve to the list,

Awesome!

> but I really think we should do some more general

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

---

From: Petr Špaček <[email-masked]>
Date: Thu, 17 Aug 2017 15:41:04 +0200

>> that do some sort of prefetching. If that is the case you can add Nominum

BTW you can count Knot Resolver in as well.

-- 
Petr Špaček  @  CZ.NIC

---

From: Brian Wellington <[email-masked]>
Date: Thu, 17 Aug 2017 09:57:14 -0700

> On Aug 15, 2017, at 2:25 PM, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> Viktor Dukhovni wrote:

I volunteer to review this, as well.

Brian

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 15 Aug 2017 13:43:18 +0200

> 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