Subject: Re: [Doh] [Ext] Are we missing an architecture? (was Re: DNS Camel thoughts: TC and message size)

From: Puneet Sood <[email-masked]>
Date: Thu, 14 Jun 2018 16:00:43 -0400

New to the list, quoting the relevant message manually
(https://www.ietf.org/mail-archive/web/doh/current/msg00743.html).

Dave Lawrence wrote:
> I believe that makes not imposing a 64k limit on DNS fall within the
> bounds of the charter.  In fact, I could make a case that it goes
> right to the first paragraph:
>
>   This working group will standardize encodings for DNS queries and
>   responses that are suitable for use in HTTPS. This will enable the
>   domain name system to function over certain paths where existing DNS
>   methods (UDP, TLS [RFC 7857], and DTLS [RFC 8094]) experience
>   problems.
>
> ... in addressing cases where existing methods experience problems.
> I'm not going to get too hung up on rules-lawyering that argument
> though, it's a sideshow.
>
> Per our out-of-band conversation, I will later this week (new $dayjob
> intrudes) be offering text for the proposal I made in another message
> about using two mandatory-to-implement media types right out of the
> gate, differing only in that one has a Content-Length limit.
> Implementers can then choose to make it plainly explicit that they
> are sticking to legacy TCP limits.

Having two distinct media types (one with the limit, one without) will
allow a doh server to determine if a larger response is safe to send
and respond accordingly. So I am in favor of your proposal to define
two media types. The RFC should not mandate length limits for media
types other than the existing wire format media type. That should be
entirely up to the specification of the new media types. Barring a
clear indication in the client request, a doh server should
conservatively limit responses to 64K for the existing wire format
media type.

Reading draft 10 section 6.1, I do not see any text addressing
interaction of the message size with the cache behavior in a recursive
resolver.  This is mostly theoretical right now because the transports
(UDP, TCP) between recursive and authoritative servers are constrained
by the 64K limit. However when recursive resolvers start receiving >
64K responses, this will need to be addressed. Couple of points:
1. Will a caching resolver be expected to cache very large responses?
An implementation may decide to put an upper limit on the size of a
message it will cache.
2. Will a caching resolver need to cache different answers
corresponding to the 64K limit and the "unlimited" case?

-Puneet

---

From: Mukund Sivaraman <[email-masked]>
Date: Fri, 15 Jun 2018 01:41:55 +0530

> corresponding to the 64K limit and the "unlimited" case?

There's no use-case for any such caching. There's no data that DNS
carries that needs such large answers to be cached today. That "640k
ought to be enough for anybody" thing keeps coming up, but this is
over-engineering. It's like computing everything with bignums instead of
64-bit ints because.. who knows.. a larger number may come and we should
not restrict it because it's 2018.

		Mukund