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

[Patrick McManus <[e-mail]>]

On Thu, Jun 7, 2018 at 11:36 AM, bert hubert <[e-mail]>
wrote:

> On Thu, Jun 07, 2018 at 09:19:06AM +0200, Patrick McManus wrote:
> > it seems possible that this is a property of the default media type not
> of
> > DoH. e.g. a negotiated json response wouldn't have this kind of
> limitation.
> > Does that make sense?
>
> Firstly, it is not a media type limitation. It is a question of if we want
> to extend DNS into a territory where it has never been before. The moment
> 100 kilobyte DNS answers become possible, we need to redo a ton of
> software.
> This is true if the end transport is JSON or a DNS message wrapped into an
> HTTP response.
>
>
I still think that your argument only applies to the *wireformat media
types.

New types mean new parsers. It seems your concerns are about existing
parsers that, by definition, can't parse the new types. So I'm not
concerned about them with new types.


> Before typing a lot more characters on this, can I ask who is actually
> arguing that we need bigger DNS messages?  Who is hurting under the 65536
> byte constraint?  DNS over HTTPS implies that we have access to HTTPS.
> This
> protocol supports messages as large as you want.
>
>
I don't want to constrain what those new types might do based on our
current understanding. For instance some media types might be very space
inefficient but super efficient to access.. and we might fix that on the
wire with a http compression encoding. heck maybe they come back as jpeg
visualizations; I'm not here to judge.

If we buy my argument then we don't so much as restrict DoH as note that
the wireformat media types effectively have this limitation already that
needs to be respected.