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

[bert hubert <[e-mail]>]

On Fri, Jun 08, 2018 at 05:31:24PM -0400, Dave Lawrence wrote:
> Ólafur Guðmundsson writes:
> > 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.
> 
> I'm a DNS person and I don't have a concern about this.  The software

First, we should be clear no one has identified a usecase for "megabyte size
DNS messages" that can't be solved today already.  So the question is, for
no identified upside, what is the downside?

The downside is that if we do this, "large DNS messages" are a thing.  They
can happen over DOH transport.  Please realize nothing in the draft says
anything about this being restricted to resolvers.  Authoritative Servers
can start talking DOH, and they well might.  Resolvers can then speak it to
them. DNS has fundamentally changed.

And legally, auths can emit these 32 bit sized DNS messages now, so we'll
have to be able to store them in resolvers, and also serve them up when
requested. 

Next up, someone writes a testsuite for this and complains to all resolvers
and authoritative servers that they are not compliant.  Anyone implementing
a DOH-proxy (which seems to be common) is now also stymied since resolvers
can't communicate 32 bit sized DNS messages over any transport they do
support.

Whenever someone creates a new DNS feature, it turns into a requirement. And
it starts showing up in RFPs and mandatory feature lists. And we all have to
do it, or spend valuable time arguing with users and customers why they
don't actually need this. 

So with one sentence in a draft about a new transport format, for a feature
no one has yet found a usecase for, all DNS implementations will eventually
have to change or spend time arguing with their users.

Next up, we will have standards action work to determine the semantics of TC
on TCP/IP, because this will start to happen once authoritative servers
emit megabyte sized answers. This requires another new RFC and all resolvers
and stubs will have to learn how to deal with this. We may also have to
write a 32-bit TCP protocol perhaps so we at least have a lightweight way of
sharing large DNS answers.

Dave, you mention you aren't worried over this change. I assume this means a
strong commitment to implementing the changes in your software and working
on the drafts that specify the TC behaviour on TCP? 

Finally, I want to echo the remarks of Andrew that if we are going to change
30 years of DNS, it is a big thing.  And it should not come out of a privacy
enhancing transport format that is being rushed into service.

And frankly, for the people that do want to see a DOH RFC in 2018, I would
strongly suggest sticking to being a transport format that does not change
the rest of DNS.  Because I expect we'll be working on this well into 2019
if this WG wants to overhaul DNS as part of DOH.

	Bert