Tony Finch wrote:
On 15 Aug 2017, at 20:28, Paul Vixie<p...@redbarn.org> 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.
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 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
