Re: [Doh] [Ext] DNS Camel thoughts: TC and message size

[Mukund Sivaraman <[e-mail]>]

On Fri, Jun 08, 2018 at 05:31:24PM -0400, Dave Lawrence wrote:
> Any software that is taking a DoH answer from an HTTPS channel is
> brand new software, not some legacy problem that we have to worry
> about.  If it imposes size limits before passing it on to whatever
> legacy code it wants to pass it on to, so be it.  The new software
> shouldn't be just blindly passing whatever data it gets into some
> legacy parser anyway, especially if the draft comes with an
> admonishment to be wary of that very thing.

Dave, I don't understand all the ways DoH will be used yet.

I have concerns about use of messages that come via this transport into
traditional DNS software [let's not call it legacy yet ;)].

There are current implementations that will parse a single message as a
"whole" in memory (i.e., not as a stream, in parts). With a 64k message
limit, there is an upper limit on derived objects from a single message.
Such code will have to be reviewed and rewritten when messages are
several megabytes or even gigabytes in size (such as a whole AXFR).

I understand that the >64kB message sizes need not apply to traditional
DNS software, but if we're retrofitting support for DoH into such
products, programmers are going to try to re-use a lot of the existing
code. This code is written with assumptions for traditional DNS, and it
may be very hard to do this based on the design.

On retrofitting, I'll give you an example - take pipelining (and out of
order processing) of queries over TCP. It is a *simple* concept to
describe, requiring not more than a page of text.  But if you wanted to
fit it into existing designs of resolvers (their client-side to auth
code) and authoritative servers, it takes a large amount of effort due
to the design. E.g., I know of a popular resolver that even now doesn't
implement pipelining completely.

Sometimes the benefits outweigh the effort, but as you say for the
opposing opinion, we should not hand wave it in as the effort has a
cost.

A DoH intermediate may not be able to split up a single large message
into multiple pieces, esp. when things like TSIG are involved, e.g., for
a large single AXFR message. It may also not be able to combine several
small ones into a large message. Do you envision such a large-message
AXFR to travel exclusively over DoH?

I'm all for a new protocol if the goal is to not worry about backwards
compatibility and work on something for the current age. Is this the
goal? If so, why even bother with the suboptimal DNS message format?

		Mukund