Re: [DNSOP] Multi-QTYPES (was: unsolicited HTTPSSVC responses)

[Eric Orth <[e-mail]>]

I lead engineering for the stub resolver built into Chrome browser, so
while not an OS-level stub, maybe still prominent enough to count for the
"any communication" requested above.

My biggest concern with an approach like this is ossification from
middleboxes (especially some old home routers) that may not be ideally
engineered for the modern web.  Chrome has seen significant issues in the
past with such middleboxes creating pain (super slow responses mostly) for
a small number of our users on sending unusual queries or an increased
amount of queries.  As such, we're generally afraid of sending out anything
other than basic and rate-limited requests when it comes to Classic DNS.
Attempting new things and falling back to conservative behavior on an issue
is not necessarily a reasonable approach because the middlebox pain is not
always limited to the individual queries.  In some cases, probing or
experimenting with resolver capabilities can cause user pain for all
subsequent queries for a period of time on the order of minutes.

Since this specific multi-query proposal encodes it in EDNS, it might be
more reasonable.  I don't have any actual data to back this up, but I would
guess that unknown EDNS options are less likely to cause issues than
completely unknown queries.  So it might be safe enough to at least do
super cautious experimentation around it.

Note that none of these ossification issues are really a concern with DoH
(or DoT) where we can be reasonably sure we're talking to a modern
non-ossified resolver.  The usefulness of combining queries is a little
reduced since DoT and DoH often use connection sharing for multiple
requests anyway.  But there's still some potential value.  In ECH (ESNI)
discussions, it has come up a few times that an attacker could try to force
a downgrade from ECH by identifying and blocking the larger packets
containing HTTPSSVC responses that contain ECH keys but not address
resolves.  Much safer if A/AAAA and HTTPSSVC can be in the same
query/response to force an attacker to block everything or nothing.

Additional possible issues with this multi-query proposal:
*By combining A and AAAA, you might lose nice abilities to try to speed
things up using Happy Eyeballs v2 style algorithms to immediately start
using addresses as they come in, before all addresses are received.  Not
currently a huge issue for Chrome DNS because we don't currently support
Happy Eyeballs v2, but we'd be hesitant to lose the ability to make that
improvement.
*The current proposal seems to give the resolver a lot of leeway to only
sometimes include the additional results and includes a TODO note that
maybe there should be a way for clients to mark qtypes as mandatory.  I
don't think the client would get as much use out of multiple qtypes unless
it had reasonable confidence that it would at least usually get all the
responses.  Otherwise, the client is often going to have to make multiple
requests in parallel anyway to ensure it can get all the responses
reasonably quickly in parallel.  Then again, if it's something like
requesting an extra qtype that we would be afraid to send in Classic DNS
anyway (due to the ossification issues), eg HTTPSVC, I suppose there's more
value of just adding in the additional qtype and using the response
opportunistically when received.

On Thu, May 28, 2020 at 12:22 PM Vladimír Čunát <[e-mail]>
wrote:

> Hello.
>
> On 5/28/20 10:00 AM, Shane Kerr wrote:
> > As I have mentioned several times on microphone, I think this draft
> > has huge potential, potentially cutting the number of queries handled
> > by recursive resolvers almost in half - since they could ask for A and
> > AAAA records in a single query.
>
> I'm not sure if it would be a net benefit if we consider the added
> complexity (like the few unpleasant corner cases), the need to implement
> on both sides, and other ways that are available.  Is saving the number
> of IP-layer packets the only significant motivation?
>
> For resolver-to-auth case I do suspect some potential.  Plain UDP will
> probably still stay popular there for some time.  Though I'm afraid this
> might _sometimes_ push the answer sizes too large to fit into one packet
> (in signed zones), which in my eyes slightly reduces attractiveness of
> the technique, now that we know that UDP over 1.5 kB is no good.
>
> For non-auth cases, you typically communicate with just one upstream
> resolver (or very few), so if the number of packets is a concern, I'd go
> for a long-lived TCP or TLS connection (there's e.g. privacy motivation,
> too).  That's all standardized already, and it naturally avoids those
> extra corner cases.  Sure, it's probably possible to improve
> significantly on session timers and resuming, performance, usage of
> Nagle's algorithm, etc. but ATM to me that feels a more worthwhile
> investment than any of the multi-answer proposals.  One advantage is
> that many of the TCP/TLS improvements can be deployed one-sidedly with
> some effect but multi-QTYPEs can't.
>
> --Vladimir
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>