Re: [DNSOP] unsolicited HTTPSSVC responses

[Eric Orth <[e-mail]>]

On Tue, May 26, 2020 at 7:05 PM Paul Vixie <[e-mail]> wrote:

> On Tuesday, 26 May 2020 19:43:27 UTC Eric Orth wrote:
> > One of my colleagues recently brought up the idea of suggesting
> recursives
> > add additional HTTPSSVC records into responses for A/AAAA queries as a
> way
> > to make HTTPSSVC more available for cases where a stub is hesitant to
> make
> > additional queries out of concern for bad behavior from bad middleboxes
> (a
> > frequent concern for Chrome when not using DoH).  My initial impression
> is
> > that it's not a reasonable idea, but I wanted to bring it here to DNSOP
> in
> > case anybody has further ideas to make it workable.  So any relevant
> > thoughts or concerns from anybody here?
>
> proposals exist going way back to add AAAA to additional data for answers
> of
> type A, and to add A to additional data for answers of type AAAA. this is
> not
> different from adding A and AAAA to additional data for answers of MX and
> SRV,
> which already happens. your proposal fits the same mold, which is that the
> spec neither requires nor prohibits it. however, the client API likely
> does
> not have a way to benefit from the additional data in a stub response.


Not a blocking concern for Chrome because in many cases it uses a built-in
stub resolver that could easily read anything it wants out of the
responses.  But it certainly limits whether or not we would try to convince
recursive operators to do this if it is likely to only be of benefit to
Chrome.  Also exacerbates all the concerns around things not being ideal if
the stub is not going to use the HTTPSSVC if even less stubs are able to
use it.


> see
> getdnsapi.net for a representative example of something that can only
> tell you
> answers to the question you asked, even if it knows more, and won't keep
> the
> response in state just in case your next question could also be answered
> by
> it. getdnsapi has a return_both_v4_and_v6 extension but would need another
> API
> change to support HTTPSSVC.
>
> for SMTP senders to benefit from the additional AAAA/A data in MX answers,
> they have to call a lower level API such as res_nsend() and then walk
> through
> the response to see what they actually got, in hopes of not needing to
> make a
> second query for addresses (or a second and third, if V6 and V4 are
> available.)
>
> so, this way lies madness, and the solution we see most often is a
> host-level
> cache of DNS results. the old INN (usenet net news) server had one of
> these,
> and all modern browsers have one. many of us simply run a validating
> iterative
> caching recursive resolver on our hosts, since it's not much code by
> modern
> standards. but in all such cases we don't have a good way to retrieve more
> than one kind of data in a single upstream DNS round trip. QDCOUNT>1 is
> not
> well defined and is broadly unimplemented. various other
> multiple-questions
> proposals have been made but nothing gets traction.
>
> > The obvious problems I could think of (all basically along the theme of
> it
> > not being ideal when the stub might not even care about HTTPSSVC):
> >
> >    - Performance implications if the recursive has to retrieve HTTPSSVC
> or
> >    follow alias chains.  Maybe not as bad if only done opportunistically
> > when the recursive happens to already have everything in cache.
> >    - Polluting DNS for non-browsers.  Maybe not as bad if SVCB instead of
> >    HTTPSSVC, but this would likely only be of use for web browsers which
> are
> > obviously not the only queryers of A/AAAA.
> >    - Could lead to lots of unnecessary truncation, especially for large
> >    records containing ESNI data.
>
> your self-criticisms are all valid in my opinion. however, i think it
> would be
> fine to recommend in the HTTPSSVC draft that the necessary subsidiary data
> like AAAA or A or SVCB all be sent, both in authoritative and non-
> authoritative responses, when the qtype is HTTPSSVC and the responder
> knows
> the additional data (that is, it should not make extra queries to find it
> just
> for additional data reasons.) this will push UDP/53 DNS into either TCP/53
> DNS
> (via truncation) or TCP/853 DNS (therefore incenting adoption of DoT) or
> even
> TCP/443 DNS (DoH) or UDP/443 DNS (DoHoQ).
>
> long answers are our future. if this data is going to be nec'y to make the
> primary answer useful, then pre-seeding it is a net good. some day our
> descendants will break the tyranny of MTU 1500, and thank us for any
> prework
> that brought the data their apps needed closer and with fewer round trips.
>
> --
> Paul
>
>
>