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

[Martin J. Dürst <[e-mail]>]

Hello Bert,

On 2018/06/07 18:36, bert hubert 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 think I agree with Patrick that it is a media type limitation. I might 
be wrong, but I don't see a way for a JSON-based format to be as 
efficient as the binary DNS format(s). Even if it were possible, a JSON 
format could contain lots of additional spaces without changing the 
meaning of the message at all.

So for a JSON message, there's not limit of 64K on the actual message 
length. But there is (or should be) an *indirect* limitation that can 
roughly be expressed as "a JSON message, when converted to a binary 
format, has to fit into 64K".

> 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.
> 
> The one reason you might like DNS to be able to do something new and large
> is because you might have no alternate way of getting large data.
> 
> So I ask, who wants to fundamentally extend the DNS protocol with messages
> of a size never seen or supported? Who is the customer?

Not me, at least not for now.

Regards,    Martin.