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

[Ólafur Guðmundsson <[e-mail]>]

On Fri, Jun 8, 2018 at 5:46 AM, Mark Nottingham <[e-mail]> wrote:

> AFAICT there are two of situations that might be relevant here:
>
> 1. A DOH request is gatewayed to "normal" DNS
> 2. A DOH response is gatewayed to "normal" DNS
>
> Could the folks who are concerned about this explain if there are any
> others (with detail)?

Actually I think what DNS people are concerned about is
 Query over DNS ==> DoH ==> Auth server generates big answer ==> Doh Reply
=> Answer over DNS  fails due to size limit.
so the fundamental problem is when different transports have different size
"limitations"
In my mind 64K is fine size and if any entity is STUPID enough to give out
888K answer on DNS port they will learn quickly.

The issue with encoding formats is that 1K DNS wire format is not 1K Jason
or 1K compressed Jason (not saying which one is going to be the biggest)
So if there is any rule needed it that answer should fit in 64K DNS
wireformat with Name compression enabled.
===> from this my assertion is that any given transport format can have its
own limit that reflects the "compactness" of the encoding and compression
but a general rule is not possible
The guiding light is "do not be stupid" but that does not work in practice
.......

so we are stuck with artificial limits.

>


> For #1, the DOH gateway should know the limitations of the protocol it's
> gatewaying (in this case, DNS over UDP), and can generate a 413 or 414
> status code as appropriate (see <https://httpwg.org/specs/
> rfc7231.html#status.413>). That's the correct way to express "that
> request is too big" in HTTP. Some non-normative advice in the spec about
> DOH servers generating appropriate status codes and clients understanding
> them might help here.
>
+1


>
> For #2, it seems like people are claiming that a client library is going
> to implement DOH but *not* update itself to take arbitrary-sized responses.
> Is anyone actually saying that's their implementation strategy, or is this
> just "what if"-ism?
>

+1


>
> If it's necessary to support those clients, it would be easy enough to
> define a preference <https://tools.ietf.org/html/rfc7240> that allows
> them to say "please give me small* responses", and require DOH servers to
> honour that preference.
>
> +1

Olafur

Cheers,
>
> * Where "small" is defined as "able to be expressed in less than N bytes
> in the UDP wire format" or similar. Limiting *all* DOH messages using
> Content-Length is not what we want to do here.
>
>
> > On 8 Jun 2018, at 11:34 am, Patrick McManus <[e-mail]>
> wrote:
> >
> > I'm not on board with limiting a 2018 protocol to 64KB variants because
> some parser of some some format might have a bug. At the very least we need
> to be more specific so we can assess the scope of the interoperability
> issue. DoH opens up new things - that's a good property. Not everything
> will be gatewayed back and forth into wireformat, and the wireformat isn't
> inherently limited to 16bit either. AXFR is an especially interesting case
> for DoH because it supports multiplexing and priority between streams, it
> might actually be the best way to carry it.
> >
> > as for other formats they are coming. Paul has an informational draft
> that has been sent to the IESG: https://datatracker.ietf.org/
> doc/draft-hoffman-dns-in-json/ and I've heard rumors of others in the
> works - even from the dns community :)
> >
> > If there is a known problem with gatewaying between formats, that's
> worth some non normative text to mention - but the notion that 64KB is
> enough for anybody is one I want to push back on. Even for that I would
> appreciate a citation of where the problem lays - there isn't agreement
> that wireformat actually has such a limit (though its existing transports
> do and maybe that's what should be noted), and no particular implementation
> choices, much less widely deployed and hard to upgrade implementations,
> have been cited (again - I'm not saying they don't exist.).
> >
> > -Patrick
> >
> > On Thu, Jun 7, 2018 at 11:58 PM, bert hubert <[e-mail]>
> wrote:
> > On Thu, Jun 07, 2018 at 11:39:16PM +0200, Patrick McManus wrote:
> > > > "Sort of".  Wire format itself does not have the limitation.  Its use
> > > > on certain transports does.  This distinction needs to keep being
> > > > made.
> > > tale has convinced me of this point.
> >
> > In the interest of reaching consensus, can we park this discussion until
> > another message type is invented and standardised that is not a DNS
> message
> > in "wire format"?
> >
> > Whenever we make life harder on the whole DNS implementation community,
> we
> > had better have a very good reason for that.
> >
> > To put it bluntly, a significant part of the DNS implementation community
> > (ISC, NLNetLabs, CZNIC, PowerDNS) has voiced that the 2^16 byte limit is
> > here to stay for now, so I don't see a viable consensus for expanding
> DNS -
> > especially given the lack of concrete usecases.
> >
> > Finally, I note that the DOH charter contains the following:
> >
> > "The working group will coordinate with the DNSOP and INTAREA working
> groups
> > for input on DNS-over-HTTPS's impact on DNS operations and DNS semantics,
> > respectvely.
> >
> > In particular, DNSOP will be consulted for guidance on the operational
> > impacts that result from traditional host behaviors (i.e., stub-resolver
> to
> > recursive-resolver interaction) being replaced with the specified
> mechanism..
> >
> > Specification of how DNS-formatted data may be used for use cases beyond
> > normal DNS queries is out of scope for the working group."
> >
> > It may be good to point out that 'normal DNS queries' have never involved
> > getting >64KB responses. We might also have to consult DNSOP about
> changing
> > DNS semantics, an activity they aren't stimulated to explore.
> >
> > Finally, I do really understand how much fun it would be to liberate DNS
> > from its pedestrian 64KB shackles. It is an arbitrary limitation, and
> > perhaps one day we'd love to put gigantic post-quantum cryptographical
> keys
> > in DNS. But given the amount of developer cycles in DNS, please also
> > understand my (our) reticence in overhauling this ancient protocol.
> >
> >         Bert
> >
> > _______________________________________________
> > Doh mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/doh
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>



-- 
Ólafur Gudmundsson | Engineering Director
www.cloudflare.com blog.cloudflare.com