Subject: [Doh] DNS Camel thoughts: TC and message size

From: bert hubert <[email-masked]>
Date: Wed, 6 Jun 2018 11:32:12 +0200

Dear WG,

Briefly, the idea behind the 'DNS Camel' is that DNS is already very
complicated and that every new draft/RFC that touches it makes it even more
complex.  A summary of these thoughts can be found on
https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/
and was presented at IETF 101.

A key insight is that every new feature is guaranteed to interact with many
existing features. This leads to an eventual combinatoric explosion because
"everything has to think about everything". This is often unintentional and
only apparent after a draft has turned into an RFC.

Notably BGP and C++ have recently reached similar conclusions in https://mailarchive.ietf.org/arch/msg/idr/z0L79p9WJkv3F6GgJ8J5LtiCpIQ
and http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf 

Version -05 of the DOH draft introduced this small sentence:

	Also note that while [RFC1035] says "Messages carried by UDP are
	restricted to 512 bytes", that was later updated by [RFC6891], and
	this protocol allows DNS on-the-wire format payloads of any size.

This is of course a laudable '640KB ought to be enough for everyone'-effort
based on our current 64KB limit imposed by TCP envelope size. 

However, with this single sentence, almost every DNS parser in existence has
become obsolete or at least untested!

No DNS message larger than 64KB has ever been possible.  The offset pointers
within a message are 14 bits long.  The EDNS payload receive size is 16 bits
long.  The TCP envelope size is 16 bit.  People can be forgiven therefore
for assuming 65536 bytes is the absolute limit.

Implementors of DOH will now have to find "32 bit safe" DNS message
parsers/generators, which may be in short supply.  Implementors of DOH
proxies will have to standardise alternate means of talking to TCP
nameservers so they can retrieve DNS messages larger than 64KB.  In effect
this means you can't write DOH proxies that sit in front of 'bare' TCP/IP
nameservers.

Where previously 64KB was the absolute limit, and there was therefore little
need to discuss the semantics of the TC bit on a response sent over TCP,
this has now become a real possibility if authoritative servers ever start
offering DOH.

Incidentally, all of a sudden we now have a big thread on the meaning of TC
within DOH.

So, the DNS Camel has a suggestion. Specify that DNS messages carried over
DOH can be up to 65536 bytes large and note that truncation should be
handled as if the response was carried over TCP/53.

Effectively this means that a TC response over DOH is almost always useless,
but this is no loss of functionality since it did not work over TCP/IP
either. We've not made anything worse here.

And in general this is what I hope that DOH will restrict itself to: provide
access to the DNS protocol over HTTPS and not change DNS itself.

Because based on the lack of clamor for >64KB DNS responses, I can not see
consensus being reached for extending the core DNS protocol for a new
transport protocol.  

Or to put it more strongly, I will not be part of that consensus, and I
suspect, neither will many implementors who have better things to do
already, like for example spending time on implementing quality DOH servers.

    Bert

---

From: Tony Finch <[email-masked]>
Date: Wed, 6 Jun 2018 15:18:32 +0100

> access to the DNS protocol over HTTPS and not change DNS itself.

Full agreement, and with the rest of your message. Thanks for writing it
so that I didn't have to!

I think the semantics of a DNS message transported over HTTPS should be
the same as for DNS-over-TCP, wrt truncation, EDNS buffer sizes, and so
forth.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher, German Bight: Variable 3 or 4. Moderate at first in west Fisher,
otherwise slight. Fair. Moderate or good, occasionally poor.

---

From: Petr Špaček <[email-masked]>
Date: Wed, 6 Jun 2018 16:21:35 +0200

> the same as for DNS-over-TCP, wrt truncation, EDNS buffer sizes, and so

I totally agree with Bert and Tony, thank you for an excelent summary!

-- 
Petr Špaček  @  CZ.NIC

---

From: "Hewitt, Rory" <[email-masked]>
Date: Wed, 6 Jun 2018 16:06:58 +0000

+1 from me also. Thanks Tony & Bert (and Star!) for narrowing in on an elegant solution, wording-wise.

Thanks,

Rory

-----Original Message-----
From: Petr Špaček [mailto:[email-masked]] 
Sent: Wednesday, June 6, 2018 7:22 AM
To: [email-masked]
Subject: Re: [Doh] DNS Camel thoughts: TC and message size

On 6.6.2018 16:18, Tony Finch wrote:
>> So, the DNS Camel has a suggestion. Specify that DNS messages carried 
>> over DOH can be up to 65536 bytes large and note that truncation 
>> should be handled as if the response was carried over TCP/53.
>>
>> Effectively this means that a TC response over DOH is almost always 
>> useless, but this is no loss of functionality since it did not work 
>> over TCP/IP either. We've not made anything worse here.
>>
>> And in general this is what I hope that DOH will restrict itself to: 
>> provide access to the DNS protocol over HTTPS and not change DNS itself.
> 
> Full agreement, and with the rest of your message. Thanks for writing 
> it so that I didn't have to!
> 
> I think the semantics of a DNS message transported over HTTPS should 
> be the same as for DNS-over-TCP, wrt truncation, EDNS buffer sizes, 
> and so forth.

--
Petr Špaček  @  CZ.NIC

_______________________________________________
Doh mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/doh

---

From: Benno Overeinder <[email-masked]>
Date: Wed, 6 Jun 2018 23:22:43 +0200

On 06/06/2018 16:21, Petr Špaček wrote:
>>> over
>>> useless,
>>> provide

Thank you for the clear write-up Bert.  Like Tony and Petr, I fully
agree with your message.

-- Benno

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 6 Jun 2018 22:42:08 +0000

I hear a lot of support for Bert's wording:
   Specify that DNS messages carried over
   DOH can be up to 65536 bytes large and note that truncation should be
   handled as if the response was carried over TCP/53.

This thread has brought up a significant concern that I hope those supporting the language can clear up.

> the same as for DNS-over-TCP, wrt truncation, EDNS buffer sizes, and so

Three people agreed with this statement. DNS-over-TCP is defined in RFC 1035 and significantly updated in RFC 7766. Unless I'm missing something, neither of those document support the 65535 length restriction; in fact, RFC 1035 section 3.3.10 indicates that restriction doesn't exist because a response with a single maximally-sized NULL Rdata record could be slightly longer than that, and there is no restriction on how many NULL records can be in the RRset. Such a message could not use name compression into the a section beyond the Answer in that message. Similarly, there is no restriction on the total length of a TXT record. Having such records is clearly a bad idea, but they are not prohibited by the specs.

So, if this WG puts such a limitation in DOH, we are adding a restriction to DNS messages that is not currently in DNS-over-TCP, even though it is a "sensible" restriction. If we do so, I would hope that (as a separate effort) we would get the DNSOP WG to start an update RFC 7766 to have the same restriction. If we don't want to do so, it would be better to only add the following from Bert's proposal (slightly reworded):
   DNS message truncation and the use of the TC bit should
   be handled as if the response was carried over DNS
   in TCP as defined in [RFC7766].

As document author, I'm OK with either outcome, but would prefer the second just because it doesn't require asking the DNSOP to have to add polish to an existing camel toe.

--Paul Hoffman

---

From: George Michaelson <[email-masked]>
Date: Thu, 7 Jun 2018 08:49:36 +1000

I believe the benefits of ensuring a "flow" or "session" underpinning
means that fragmentation doesn't happen: that the effective
application (DNS as the application) layer payload is delivered UN
fragmented, is huge.

signalling that in UDP/53 it *would* have happened, maybe thats
useful. But carrying a complete, unfragmented, processable, integral
outcome, thats a huge upside benefit operationally.

Making an unconstrained, non-fragmented channel perform as if it had
the same underlying 512 Octet UDP DNS constraint in all ways, I think
is a bit silly.

So I think a constraint which effects actual end-to-end DNS flow *to
the benefit of the client* is worth doing.

-G

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 6 Jun 2018 18:55:22 -0400

Hi,

> Three people agreed with this statement. DNS-over-TCP is defined in RFC 1035 and significantly updated in RFC 7766. Unless I'm missing something, neither of those document support the 65535 length…

This sounds actually like a long-unnoticed erratum in RFC 1035,
because I _think_ Bert's calculation is correct that there is as of
now no interoperable way to send a single message longer than 65535
octets, because of limits in the protocol (I haven't thought about it
in detail, but it immediately struck an "exactly" chord with me so I
have confidence).  I agree, however, that it's not a job for this WG
to fix.  Therefore,

>    in TCP as defined in [RFC7766].

I'm ok with this, and I also suspect that an erratum (admittedly not a
simple one) on either 1035 or 7766 would be enough to close this hole.

Best regards,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 6 Jun 2018 18:56:59 -0400

> outcome, thats a huge upside benefit operationally.

Sure.  But if the TC bit is set, surely we're already in the possible
world where that hasn't happened?

A
-- 
Andrew Sullivan
[email-masked]

---

From: Patrick McManus <[email-masked]>
Date: Thu, 7 Jun 2018 09:19:06 +0200

> supporting the language can clear up.
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?

---

From: bert hubert <[email-masked]>
Date: Thu, 7 Jun 2018 11:36:47 +0200

> DoH. e.g. a negotiated json response wouldn't have this kind of limitation.

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.

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? 

	Bert

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Jun 2018 11:33:21 +0100

Paul Hoffman <[email-masked]> wrote:
>
> DNS-over-TCP is defined in RFC 1035 and significantly updated in RFC
> 7766. Unless I'm missing something, neither of those document support
> the 65535 length restriction;

The restriction comes from the 2 octet message length field, RFC 1035
section 4.2.2.

> in fact, RFC 1035 section 3.3.10 indicates that restriction doesn't
> exist because a response with a single maximally-sized NULL Rdata record
> could be slightly longer than that, and there is no restriction on how
> many NULL records can be in the RRset.

Right. You need to make a distinction between RR data size limits and
message size limits. As you say, it's easily possible for an RRset to be
too long to fit in a message.

If a single RR doesn't fit in a message then it isn't possible to create
it via UPDATE or transfer it via AXFR/IXFR, though it can be represented
in master files.

It's clear such large RRs are not supported by the standards - I guess
they don't specify how to cope because huge RRs are an obviously lunatic
idea ;-)

> So, if this WG puts such a limitation in DOH, we are adding a
> restriction to DNS messages that is not currently in DNS-over-TCP, even
> though it is a "sensible" restriction.

No, the message size limit was always there, even though it is smaller
than the RR data size limit. This was the point of Bert's message.

As he said, lifting the 64K limit means "almost every DNS parser in
existence has become obsolete or at least untested! No DNS message larger
than 64KB has ever been possible."

>    in TCP as defined in [RFC7766].

EDNS buffer sizes need to be handled the samee as for TCP as well.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon, Rockall, Malin, South Hebrides: Northerly or northeasterly, 3 or 4,
occasionally 5 later. Slight or moderate. Mainly fair. Moderate or good,
occasionally poor.

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 7 Jun 2018 21:40:45 +0900

Hello Bert,

> This is true if the end transport is JSON or a DNS message wrapped into an

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".

> of a size never seen or supported? Who is the customer?

Not me, at least not for now.

Regards,    Martin.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Jun 2018 13:40:29 +0000

> The restriction comes from the 2 octet message length field, RFC 1035

Ow! (I just slammed my forehead into the desk because this should have been obvious to me.)

Tony is completely correct here. DNS messages have well-defined length limits: 512-or-more-depending if carried over UDP, and 65535 if carried over TCP.

Bert's proposal is fine with me. The fact that RFC 7766 didn't mention this limitation doesn't change anything.

> EDNS buffer sizes need to be handled the samee as for TCP as well.

RFC 6891 says that the payload size is for transport over UDP, not TCP. What change are you requesting here?

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Jun 2018 14:48:14 +0100

> What change are you requesting here?

An explicit note that it doesn't apply to HTTP either. Maybe that is
obvious enough from RCF 6891 that it doesn't need restating?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
partnership and community in all areas of life

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Jun 2018 13:51:31 +0000

> obvious enough from RCF 6891 that it doesn't need restating?

Ah, *doesn't apply*. Sure, if we're adding a note with the max length, this clarification is probably good as well.

--Paul Hoffman

---

From: Patrick McManus <[email-masked]>
Date: Thu, 7 Jun 2018 16:17:31 +0200

> This is true if the end transport is JSON or a DNS message wrapped into an
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.

> 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.

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 7 Jun 2018 12:54:16 -0400

Paul Hoffman writes:
> Tony is completely correct here. DNS messages have well-defined
> length limits: 512-or-more-depending if carried over UDP, and 65535
> if carried over TCP. 

Right.  And completely undefined over any other transport.  There is
no intrinsic limit to the limit of a DNS message, compression pointers
notwithstanding.  I could give you a parser that would happily churn
though a multi-megabyte DNS message.

I was among the first advocating for making it clear that there
needn't be an unnecessary limit imposed here, and I still stand by my
position though at the moment it looks like I'll end up on the wrong
side of consensus.  My point is that when there is not a strict
technical need driving some limit, I don't think it should be there.
Have we learned nothing of scaling on the Internet over all these
years?

While "existing DNS message parsers might have a problem with it" is a
legitimate potential issue, I don't see it as a compelling need to
drive the requirement.  It isn't even a given that all existing
parsers would have a problem with it.  In any event that's something
that should be looked at by the programmer before just blindly pumping
data through.

There's even a use case for going beyond 64k, AXFR.  Despite Tony's
other message claiming that AXFR needs multiple messages, that's not
fully accurate.  I have plenty of zones that fit in a single DNS/TCP
message when sent over AXFR, and DNS/HTTPS would cover the rest quite
easily, except with a restriction on message lengths it actually makes
things a bit more complicated.

I will readily admit that I personally don't currently have a plan to
start doing AXFR over DoH.  My point is that this isn't just purely
academic, but actually has some practical applications.

My personal take is that, given that there is no strict technical
limit for imposing a limit inside a transport that doesn't require it,
the existing "any size" text should remain, and be augmented with a
warning to developers about how that could be an issue with existing
code that assumes no message can be greater than 64k based on earlier
transport definitions.

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 7 Jun 2018 13:21:23 -0400

Bert:
> byte constraint?

Me, and not me.  The two questions are orthogonal.  

Tautologically, putting in limits results in limits -- limits on what
could be built if the limits were not in place.  I'm personally not
particularly hurting right now, though I do know of some people who
are in fact having trouble with large zone transfers that could be
ameliorated with HTTPS restarts (or, of course, by shoehorning some
other data transfer method in).

Beyond pain, I can't really tell you what interesting applications
that would us a hierarchically distributed public database are going
uninvented because of the existing limits.  Give people more powerful
tools and they can build more powerful things.

Patrick:
> 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.

Exactly.

> 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.

"Sort of".  Wire format itself does not have the limitation.  Its use
on certain transports does.  This distinction needs to keep being
made.

---

From: Ray Bellis <[email-masked]>
Date: Thu, 7 Jun 2018 22:21:12 +0100

On 06/06/2018 23:42, Paul Hoffman wrote:

> Similarly, there is no restriction on the total length of a TXT
> record.

Yes, there is.

Every RR is constrained in size by the 16 bit RDLENGTH field.

Ray

p.s. count this as another vote for requiring the DOH limit to be 65535
(when represented in binary format)

---

From: Ray Bellis <[email-masked]>
Date: Thu, 7 Jun 2018 22:23:46 +0100

>    handled as if the response was carried over TCP/53.

NB: that's up to but *not including* 65536.

UDP packets and TCP-framed DNS messages both have a 16 bit length field
with a maximum value of 65535.

In fact for UDP the actual DNS payload size is smaller, because that
65535 has to include the 8 byte UDP header.

Ray

---

From: Patrick McManus <[email-masked]>
Date: Thu, 7 Jun 2018 23:39:16 +0200

> on certain transports does.  This distinction needs to keep being
tale has convinced me of this point.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 7 Jun 2018 17:47:38 -0400

> on certain transports does.  This distinction needs to keep being

That sounds like a foot-gun loaded for bear, to me.  Wire format on
every transport so far has this limitation.  Even if you break that
limitation (and I'm still not fully convinced you can), the mere fact
that this is called the "wire format" will lead people to expect that
they can pop in the very same parsing code they already use for the
"traditional" wire format, and it'll work fine.  So, if the document
is not going to set the limit in concrete, it had better have a Big
Giant Warning section that points out that a completely reasonable
assumption is not true and that the competent implementer will have to
do a bunch of additional work to be safe in a corner condition that is
incredibly rare right now.

What will actually happen, of course, is that some programmer will
say, "Aw, nobody's going to do that," fail to check the bounds
carefully, and create some festering large problem somewhere down the
road.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: bert hubert <[email-masked]>
Date: Thu, 7 Jun 2018 23:58:51 +0200

> 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

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 7 Jun 2018 21:49:31 -0400

Andrew Sullivan writes:
> So, if the document is not going to set the limit in concrete, it
> had better have a Big Giant Warning section that points out that a
> completely reasonable assumption is not true

Yes, I think that either way there should be more of an explanation of
what's going.

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 7 Jun 2018 22:09:44 -0400

> format, has to fit into 64K".

If I understand correctly, you are saying that it is a better state of
affairs to require servers to be cognizant of the encoding size of one
media type when responding with another?  I'm having a hard time
seeing how this wouldn't mean having to at least sometimes do the work
of fully encoding it in the one before it can send it in the other.

Incidentally, this has raised another question in my mind.  In a
defined-limit world, what happens when some rogue DoH server generates
Content-Length > 64k?  Presumably well-behaved clients will be sanity
checking for the possibility of that.  In a Content-Length: unlimited
world you are still free to consider > 64k responses to have failed
until you get around to adapting your software.  It seems to me you're
no worse off for being forward-looking now.

---

From: Robert Edmonds <[email-masked]>
Date: Thu, 7 Jun 2018 22:45:15 -0400

Dave Lawrence wrote:
> notwithstanding.

No, there is an intrinsic limit to the size of a DNS message. If I'm not
mistaken:

12 octets header

1 question resource record:
    255 octets QNAME
    2 octets QTYPE
    2 octets QCLASS

3 response sections:
    65535 RR's per section:
        255 octets NAME
        2 octets TYPE
        2 octets CLASS
        4 octets TTL
        2 octets RDLENGTH
        65535 octets RDATA

12 + 1*(255+2+2) + 3*65535*(255+2+2+4+2+65535) = 12936609271 octets, or,
about 13 gigs.

-- 
Robert Edmonds

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 7 Jun 2018 23:01:23 -0400

> especially given the lack of concrete usecases.

I would characterize "being able to fit a whole AXFR" as a concrete
use case, especially given that it is data already carried by the DNS
and is simpler to implement in a world where it doesn't have to be
chunked.

---

From: Dave Lawrence <[email-masked]>
Date: Thu, 7 Jun 2018 23:03:37 -0400

Robert Edmonds writes:
> > There is no intrinsic limit to the limit of a DNS message,
> 

Right, you are absolutely correct.  I was being lazy and not doing the
math to get "number much larger than 64k".

---

From: Patrick McManus <[email-masked]>
Date: Fri, 8 Jun 2018 11:34:19 +0200

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

---

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

On Fri, Jun 08, 2018 at 11:34:19AM +0200, Patrick McManus wrote:
> some parser of some some format might have a bug.

It's not "some parser".. for a long time implementations have assumed
64kB for message formats and these are implicit assumptions. It isn't
reasonable to alter this now. RFC 1035 is from 1987 and these implicit
assumptions have remained so for the last 30 years.

It is ok if you want to prepare different rules in 2018, but please
don't call it DNS.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Fri, 8 Jun 2018 15:54:45 +0530

> 12 + 1*(255+2+2) + 3*65535*(255+2+2+4+2+65535) = 12936609271 octets, or,

I think BIND will happily load, zone transfer (in and out) and store an
RRset in memory that didn't fit in 64kB. Initially for catalog zones,
we'd have used such an RRset as there's no 64kB transfer limit to an
RRset. However, anything over 64kB cannot be queried for as the server
will fail to construct a reply.

		Mukund

---

From: Ray Bellis <[email-masked]>
Date: Fri, 8 Jun 2018 11:27:17 +0100

On 08/06/2018 10:34, Patrick McManus wrote:

> 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.).

There are likely numerous existing DNS implementations that currently
assume that a 64kB buffer is large enough for any possible DNS message.

I know I've written code that does that, because notwithstanding it's a
limitation of UDP and a limitation of the chosen framing mechanism used
when carried in TCP (but not of TCP itself, mind), it *is* the defacto
limit on the size of a DNS message.

I can allocate a buffer of 64kB, even on the stack, safe in the
knowledge that it's "big enough".  It's a trivial amount of RAM by
today's standards but it avoids a lot of dynamic buffer allocation
and/or re-sizing.

I would also be unsurprised to find DNS server software with enforced
64kB limits on the total size of an RRset.   Whilst I believe AXFR does
permit RRsets to be split across message boundaries, the QUERY opcode
does not (they have to be treated as a single atomic unit) so RRsets
that exceed that size are effectively useless.

I would be OK with special case treatment for AXFR in DOH, but *please*
don't mess with the normal message size constraints for standard queries.

Ray

---

From: "John Dickinson" <[email-masked]>
Date: Fri, 08 Jun 2018 11:33:35 +0100

> It is ok if you want to prepare different rules in 2018, but please

+1, I totally agree.

John Dickinson

http://sinodun.com

Sinodun Internet Technologies Ltd.
Magdalen Centre
Oxford Science Park
Robert Robinson Avenue
Oxford OX4 4GA
U.K.

---

From: bert hubert <[email-masked]>
Date: Fri, 8 Jun 2018 12:33:55 +0200

> today's standards but it avoids a lot of dynamic buffer allocation

Indeed. Another question is also, if 65kB is too small, what is a reasonable
limit, in other words, what can protocol users count on? Several megabytes?
I would expect people arguing for larger messages to come up with a
value they can defend. 

> don't mess with the normal message size constraints for standard queries.

So interestingly enough, AXFR already consists of a series of DNS messages. A
DNS message does not actually need an envelope (as in TCP) since it knows
where it ends. 

So to do AXFR over DOH, simply return multiple DNS messages concatenated.

Interestingly this would make it very easy for existing authoritative
servers to support DOH for AXFR since this is exactly what they do already,
without the need for protocol action.

	Bert

(Oddly enough DNS over TCP could have been done without length fields, but
this was likely easier on the system calls.  )

---

From: Mateusz Jończyk <[email-masked]>
Date: Fri, 8 Jun 2018 13:21:49 +0200

>> It is ok if you want to prepare different rules in 2018, but please

I have been absent from much of this discussion, but I also would support
limiting message size to 64kB.

> another message type is invented and standardised that is not a DNS message
+1

Greetings,
Mateusz

---

From: Patrick McManus <[email-masked]>
Date: Fri, 8 Jun 2018 14:41:32 +0200

On Friday, June 8, 2018, Mukund Sivaraman <[email-masked]> wrote:

> 64kB for message formats and these are implicit assumptions.

Perhaps you feel I was being dismissive - I'm genuinely sorry about that. I
was really trying to ask for specificity. If we understand the scope of the
issue we can then deal with it on a corresponding scope.

I mostly hear general appeals that concern how different implementations
might (without citation) struggle with >64KB wireformat messages because
they were unanticipated and a subsequent request to ban them from all media
types as a result.  I also hear some disagreement that >64KB wireformat is
even a problem. I'm pushing back because the size of the hammer needs more
justification from particular instances of the problem.

I don't deny the possible existence of a legacy problem - I'm asking for
details about it and then we can analyze how those messages will get into
the hands of those implementations.. that will drive next steps

There are a few options here.. sorted roughly on a spectrum from a] do
nothing, b] non-normative there be dragons here text, c] wireformat
specific text that clarifies it already has a 64KB limit, d] restrict all
DoH content-type variants (even non wireformat ones) to 64KB.

If the problem were laid out in specifics, we could more meaningfully
figure out where to be on that spectrum instead of just staking out either
end.

As for justifying longer representations there are two angles to consider..
one is specific use cases, the other is the general architectural
consideration that arbitrary limits come back to bite you later on
(rejecting 640KB is enough for anybody as Bert put it.). Its ok if DoH
enables some use cases that will only be used natively - it is not a mere
tunnel.

wrt use cases, I've spoken about JSON at the last-call level, and other
JSON formats in the works. I also think key management could become an
issue - lots of things are interested in storing public keys in DNS
(including but not limited to dnssec) - post quantum those keys necessarily
explode in size. And of course zone transfers are related large objects too.

Cheerfully,
Patrick

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 8 Jun 2018 14:46:35 +0200

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)?

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.

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?

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.

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 <[email-masked]> 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 <[email-masked]> wrote:
> recursive-resolver interaction) being replaced with the specified mechanism..
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Jun 2018 14:57:09 +0200

Have we agreed that limiting DOH (which might use multiple encodings)
is nonsensical?  And that this is just a discussion about the
wireformat?

On Fri, Jun 8, 2018 at 12:11 PM Mukund Sivaraman <[email-masked]> wrote:
> for a long time implementations have assumed
> 64kB for message formats and these are implicit assumptions

OK, if this is correct, let's examine the consequences.

If we limit the size, that's an artificial limit that will be hard to
remove.  But it is easy to understand.  And future versions of
ourselves will be smarter and more experienced than current us, so
it's really tempting to have them deal with any problems.  YAGNI and
all that.

On the other hand, if we fail to limit the size, it's a little harder
to reason about, but I haven't seen anything significant on the thread
to suggest that this would be a genuine problem.

Implementations that aren't prepared to receive very large messages
will break.  But we have to consider that all DOH implementations will
be new even if they use an existing parser.  Those implementations can
therefore check that they don't break.

And I can't see any way for a message larger than 64k to end up in DNS
over UDP or TCP.  Both contain length fields that just don't permit
it[1].

So the consequences seem limited to those implementations that copy
queries and answers from DOH (copying *to* DOH would obviously be safe
if the limit were higher).  This isn't materially different from
moving from TCP to UDP in that sense.  Requests that go from a DOH leg
to a non-DOH leg and won't fit can be immediately turned around with
an error code; responses that go from a DOH leg to a non-DOH leg and
won't fit can be truncated, or turned into an error response.

So I'm not seeing any need to change text here.  I can see how putting
some fluff in about how it might be sensible to allow for limitations
of decoders and so forth might seem attractive, but it doesn't appear
to be *necessary*.  Of course, I wouldn't object if someone wanted to
insist.

Cheers,
Martin

[1] Absent an implementation of RFC 2675, which I believe is not
relevant on the internet and probably needs to be made Historic.

---

From: Tony Finch <[email-masked]>
Date: Fri, 8 Jun 2018 14:26:53 +0100

> will fail to construct a reply.

BIND handles this better than I feared it might :-) See first dig output
below - you can axfr the zone if you want. However other implementations
did not have as much foresight - the second dig output is from a name
server hosted on the CommunityDNS anycast service - it seems to have
transfered the zone OK, though.

1. BIND

; <<>> DiG 9.13.0 <<>> +tcp +norec 65536.dotat.at in txt @grey.dotat.at
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52562
;; flags: qr aa tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: e70d27f85d21dee83f06c6445b1a828aed3ce0f8f53f262d (good)
;; QUESTION SECTION:
;65536.dotat.at.                        IN      TXT

;; Query time: 0 msec
;; SERVER: 2001:630:212:110::d:7a7#53(2001:630:212:110::d:7a7)
;; WHEN: Fri Jun 08 14:20:10 BST 2018
;; MSG SIZE  rcvd: 71

2. CommunityDNS

;; Warning: Message parser reports malformed message packet.

; <<>> DiG 9.13.0 <<>> +tcp +norec 65536.dotat.at in txt @ns3.gratisdns.dk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52381
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: Message has 2571 extra bytes at end

;; QUESTION SECTION:
;65536.dotat.at.                        IN      TXT

;; Query time: 24 msec
;; SERVER: 2001:678:5::6#53(2001:678:5::6)
;; WHEN: Fri Jun 08 14:21:10 BST 2018
;; MSG SIZE  rcvd: 2615

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Malin, South Hebrides: Cyclonic 3 or 4. Moderate, occasionally slight later.
Fair then thundery showers. Good occasionally poor.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 8 Jun 2018 13:07:44 -0400

Dear colleagues,

The discussion of the "DNS Camel" and the worry about max sizes had
led me to think about what exactly we think we're doing with DOH.  I
am not sure we have agreement on a goal, so I thought I'd try to make
this explicit.

The charter discussion went to some lengths, I thought, to try to
constrain the stuff we were doing effectively just to "the DNS we
always had, only over HTTPS".  I thought that's what this language meant:

  The primary focus of this working group is to develop a mechanism that
  provides confidentiality and connectivity between DNS clients (e.g., operating
  system stub resolvers) and recursive resolvers.

To person with a long history in the DNS, anything that says "DNS
clients" automatically means, "That vast, tractless wilderness of
half-baked implementations that might send a query for DNS and might
accept inbound answers."  DNS nerds assume, in general, that any
condition that has "always been true" is almost certainly deployed
somewhere, which is why we still have things like upward referrals,
EDNS version numbering failures, and so on.  There's even been a flag
day announced to try to cope with some of this, but it's anyone's
guess whether it'll work.

Part of the problem is that the DNS lives in a sort of ambiguous
place.  In the layer model, it's plainly an application.  But it
functions as a kind of connectivity infrastructure, which is why it
was handled in the INT area for so long.  Because it is so old and
crufty, and contains no proper versioning or negotiation or anything
like that, DNS nerds have always been ultraconservative about
operations and deployment.  The downstream consumers of DNS data (the
OS resolver libraries and so on) were often more than a little
primitive, and often turn out to contain assumptions that are not true
and that cause trouble.  Finally, the DNS is defined in a _lot_ of
RFCs, and not always in language that is entirely clear and unsubtle.
While the best-known implementations are high quality, some
implementers appear to have been give 30 minutes with RFC 1035 and
half a day of allotted coding time.

HTTPS is, of course, much more modern, and HTTP 2 has been recently
gone over with a great deal of care.  It is reasonable, therefore, to
make assumptions about what an HTTP 2-implementing system will do.
So, we might think that the right boundary to be drawing is around the
DNS subsystems in a few code bases, plus the transport to be used.
Anyone who is going to implement a DNS API client is going to follow
the rules and do things in a clean and modern way.  I think the
disconnect with some people with a lot of experience in DNS is that
this boundary is too tight: the dependent systems will actually not
expect whatever the RFCs say, but instead what they're used to
expecting based on three things they found in Google plus some code
from 1993 that they inherited and don't understand.

I don't have any trouble saying, "We are actually just going to insist
on assuming a clean, modern architecture; things that make assumptions
not justified by the letter of the RFCs -- including assumptions about
transport -- are going to be broken."  But I think that's the sort of
principle that really does need to be written down somewhere.  At the
moment, the I-D is too cute about this:

   The integration with HTTP provides a transport suitable for both
   existing DNS clients and native web applications seeking access to
   the DNS.

As several posters have already pointed out, this is only true if you
accept a somewhat unusual meaning of "existing DNS clients".  Those
clients are going to have assumptions in them, and they are
assumptions that are based on more than 30 years of deployment -- an
eternity on the Internet.

Architecture inheres not only in how the elements of the thing fit
together, but also how the thing fits with everything else.  In this
case, we have to fit with the deployed Internet systems.  It is
perfectly fine to decide that 64k is not enough for anybody.  But if
that's an assumption we're going to modify, then I think we are in
fact specifying a new architecture for the DNS, and we need to be less
glib about that.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Fri, 8 Jun 2018 13:31:53 -0700

> Could the folks who are concerned about this explain if there are any

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.
>
>
> > 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
> >

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

---

From: Patrick McManus <[email-masked]>
Date: Fri, 8 Jun 2018 16:50:27 -0400

On Fri, Jun 8, 2018 at 4:31 PM, Ólafur Guðmundsson <[email-masked]>
wrote:

> so the fundamental problem is when different transports have different
> size "limitations"
I'm not 100% sure I understand the illustration. perhaps we don't have a
shared understanding of http content negotiation. is the example saying the
terminal auth server generates a non-wireformat big answer and that's why
its big?

A DoH client that was gatewaying from the traditional DNS client wouldn't
send an Accept: big-json (or whatever) request header for exactly this
reason and the DoH server would recognize that and send the best MTI format
it could manage (which is also what the server does if it didn't implement
the json type and it did see the accept header)

but a DoH client that was natively interpreting the response with its own
Json parser would indeed send such a request header. Its effectively an opt
in. (the server isn't absolutely prohibited from sending something you
didn't opt in to, but you would only do it if you had nothing else..
because the client will probably treat it as an error.. so instead you send
whatever version of the MTI you can manage)

a gateway that was playing a caching proxy role just has to deal with 2
variants of the URI in that case - that's a normal http cache problem.

I think that's all 3 versions of that scenario..

> ===> 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
>> status code as appropriate (see <https://httpwg.org/specs/rfc7
>> 231.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
>
>
>>
>> that has been sent to the IESG: https://datatracker.ietf.org/d
>> oc/draft-hoffman-dns-in-json/ and I've heard rumors of others in the

---

From: Dave Lawrence <[email-masked]>
Date: Fri, 8 Jun 2018 17:31:24 -0400

Ó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
that gets an answer over HTTPS that is too big for the implementer to
want to handle, whether for technical or philosophical reasons, is
free to just not handle it.

Any software that is taking a DoH answer from an HTTPS channel is
brand new software, not some legacy problem that we have to worry
about.  If it imposes size limits before passing it on to whatever
legacy code it wants to pass it on to, so be it.  The new software
shouldn't be just blindly passing whatever data it gets into some
legacy parser anyway, especially if the draft comes with an
admonishment to be wary of that very thing.

The DoH recipient will of course be fundamentally incapable of turning
a > 64k DNS/HTTPS answer into a > 64k answer on DNS/UDP or DNS/TCP, so
nothing on the other end of DNS/UDP and DNS/TCP will be dealing with
any new problem.

In the end, what onerous "fails due to size limit" problem is there?
We've already had a demonstration on the list today of a DNS server,
with no HTTPS involved at all, having a zone with a > 64k RRset that
it can't send over faithfully DNS/UDP or DNS/TCP.  Clearly some legacy
software is already cognizant of things that should be representable
in DNS wire format but just can't be because of a legacy transport
limit.  All it means is that the client that wants the data can't get
it in a pre-DoH world, but the world keeps revolving nonetheless.

---

From: bert hubert <[email-masked]>
Date: Fri, 8 Jun 2018 23:58:41 +0200

> 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

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 8 Jun 2018 18:17:00 -0400

On Fri, Jun 08, 2018 at 05:31:24PM -0400, Dave Lawrence wrote:

> I'm a DNS person

…

> about.

I am surprised to see those two claims in the same email.  It is
certainly true that the part of the software that is talking to the
HTTPS channel is new.  I am way less convinced that the rest of it
will be, particularly when the draft explicitly says, "The integration
with HTTP provides a transport suitable for both existing DNS
clients…." 

> If it imposes size limits before passing it on to whatever

Yeah, I'd be much less concerned about if the draft gave those
warnings.  But I also think such warnings will give the lie to the
claim I quoted above.

> limit.

Sure.  And some legacy software deals with EDNS version numbers
correctly, but some does not.  And some legacy software checks for
poison, and some does not.  And some legacy software spits up on
well-formed RRTYPEs it does not know about, and some does not.  We
have _a lot_ of stuff in the DNS that we have worked around because
it's basic infrastructure of the Internet.  I am by no means opposed
to this WG saying, "We're the new transport, and we're Doing It Right,
and broken stuff can all be broken."  But we need to carry that bag
in through the front door.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Lawrence <[email-masked]>
Date: Fri, 8 Jun 2018 19:46:56 -0400

> On Fri, Jun 08, 2018 at 05:31:24PM -0400, Dave Lawrence wrote:

You're questioning that assertion?

> with HTTP provides a transport suitable for both existing DNS

It does provide a transport suitable for existing DNS clients.
DNS/HTTPS carries messages that are usable with existing clients.  The
possibility of a DNS/HTTPS message being bigger than a DNS/UDP or
DNS/TCP client wants to deal with doesn't invalidate that.  It means
that when interfacing from one transport to the other, you have to be
mindful of the difference between them.  You *already* have to be
mindful of the difference between TCP and UDP.  DNS servers can
*already* store data that is too big for the largest possible DNS/TCP
message.  When writing new code *of course* you have to be mindful of
the differences between the transports.

> warnings.

Completely agree.  So if Patrick and Paul add the warning, you're on
board?

> I am by no means opposed to this WG saying, "We're the new
> transport, and we're Doing It Right, and broken stuff can all be
> broken."  But we need to carry that bag in through the front door.

I'm on board with this.  Especially since it hasn't been demonstrated
that this would break stuff that any competent programmer writing new
code should be able to avoid.  If someone is writing DoH code and
concerned that they might be pumping a message longer than 64k
directly into a API that you are even a little unsure of its ability
to handle messages of that size, then don't do that.  This is not
hard.  Especially since if the limits are put in they have to do the
check anyway.

---

From: Dave Lawrence <[email-masked]>
Date: Fri, 8 Jun 2018 20:01:57 -0400

bert hubert writes:
> 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?

First we should be clear that we have identified a use case of zone
transfers, and if you want to refute it then please be more clear on
what your objection to that use case is that makes it not legitimate.
Just hand-waving it away with "can be solved already" isn't really an
answer, since there are lots of ways we can solve problems but that
doesn't make them necessarily better.  It just means we're adaptable
in the face of adversity.

That rebuttal doesn't even yet have to address other potential use
cases that have been mentioned like increased cryptographic
information in messages, which could also benefit from not being
limited to 64k.

> 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?

Sure, you bet.  Since existing software will already emit TC over
DNS/TCP you are absolutely correct that we should address that in
dnsop.  I look forward to working with you on that.

While you're here, can you please tell us what problems your code is
going to have with a > 64k message that you can't solve if there is no
defined limit on message size but that you could solve if there were?

---

From: Mukund Sivaraman <[email-masked]>
Date: Sat, 9 Jun 2018 13:48:52 +0530

> admonishment to be wary of that very thing.

Dave, I don't understand all the ways DoH will be used yet.

I have concerns about use of messages that come via this transport into
traditional DNS software [let's not call it legacy yet ;)].

There are current implementations that will parse a single message as a
"whole" in memory (i.e., not as a stream, in parts). With a 64k message
limit, there is an upper limit on derived objects from a single message.
Such code will have to be reviewed and rewritten when messages are
several megabytes or even gigabytes in size (such as a whole AXFR).

I understand that the >64kB message sizes need not apply to traditional
DNS software, but if we're retrofitting support for DoH into such
products, programmers are going to try to re-use a lot of the existing
code. This code is written with assumptions for traditional DNS, and it
may be very hard to do this based on the design.

On retrofitting, I'll give you an example - take pipelining (and out of
order processing) of queries over TCP. It is a *simple* concept to
describe, requiring not more than a page of text.  But if you wanted to
fit it into existing designs of resolvers (their client-side to auth
code) and authoritative servers, it takes a large amount of effort due
to the design. E.g., I know of a popular resolver that even now doesn't
implement pipelining completely.

Sometimes the benefits outweigh the effort, but as you say for the
opposing opinion, we should not hand wave it in as the effort has a
cost.

A DoH intermediate may not be able to split up a single large message
into multiple pieces, esp. when things like TSIG are involved, e.g., for
a large single AXFR message. It may also not be able to combine several
small ones into a large message. Do you envision such a large-message
AXFR to travel exclusively over DoH?

I'm all for a new protocol if the goal is to not worry about backwards
compatibility and work on something for the current age. Is this the
goal? If so, why even bother with the suboptimal DNS message format?

		Mukund

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 9 Jun 2018 15:07:53 +0200

Hi Andrew,

> On 8 Jun 2018, at 7:07 pm, Andrew Sullivan <[email-masked]> wrote:
> 

"Cute" is a very loaded term.

> fact specifying a new architecture for the DNS, and we need to be less

Or we could just change "clients" to "client use cases," thereby removing the implication that it'll work when dropped in front of any existing client library (which isn't terribly interesting anyway, IMO).

DNS may very well need a new architecture, but loading this responsibility onto DOH post-WGLC is asking too much of it, and is unfair to the folks who brought this work to the IETF in good faith.

Cheers,

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 10 Jun 2018 12:16:45 -0400

> You're questioning that assertion?

Certainly not!  That was very much my point -- that you have a lot of
experience with the protocol and know how far it sometimes is in
practice from what the documents say.

> Completely agree.  So if Patrick and Paul add the warning, you're on

I think if we can come up with the right words, then it'll make things
less risky, but I also worry about the deployment story unless we can
figure out what to do if something in the pipeline can't take the
"jumbo" messages.

> to handle messages of that size, then don't do that.

That's the kind of risk I would rather not take: IMO the protocol
needs to say what happens in case something can't take these
new-fangled messages, I think.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 10 Jun 2018 12:32:54 -0400

Hi,

> "Cute" is a very loaded term.

Apologies; I didn't mean to be loaded.  I just mean that the claim is
either true in a pretty unusual way, or it isn't really true.

> Or we could just change "clients" to "client use cases," thereby removing the implication that it'll work when dropped in front of any existing client library (which isn't terribly interesting anyw…

Well, you might not find it interesting, but people who have been
struggling with the limitations of DNS for a long time might find it
interesting and might try to plumb their bog-standard DNS systems
through this new transport -- especially if the document says that
it's suitable for such use.

> DNS may very well need a new architecture, but loading this responsibility onto DOH post-WGLC is asking too much of it, and is unfair to the folks who brought this work to the IETF in good faith.

If that is true, then it is illegitimate in the IETF context to notice
a technical issue late in any document's life cycle and raise it.  I
don't think that's how the IETF works, and I think it would be an
abuse of rough consensus to insist that, because a problem shows up
late it shouldn't be taken into consideration since people brought
work to the IETF in good faith and had been working on it.

But in any case, my point is just that, whether we like it or don't,
we are _in fact_ making a new architecture in this effort, and we're
doing it with assumptions that appear not to line up correctly across
the sub-communities who are working on the problem.  That ought not to
be too surprising: these are two important protocols that work in
quite different ways, and the people who have worked on them over
time, unsurprisingly, have developed different intuitions about what
to expect.  If we put them together, we're gong to find differences.
It takes time to draw those out, and now we have drawn out an
expectation that some people have because people have attempted to
work through what the I-D will mean in practice.  We ought to be
pleased that we discover these corners now.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Patrick McManus <[email-masked]>
Date: Sun, 10 Jun 2018 19:10:18 -0400

> figure out what to do if something in the pipeline can't take the
After having re-read the related threads, I think it might be helpful to
talk about how content negotiation works in the http pipeline.

let's assume we have 2 message formats - wireformat-64 and traditional
wireformat. And that we define traditional wireformat to be limited to 16
bits (its not clear to me whether or not that is really true in practice,
but let's say we determine that it is.).

I believe the concern is "traditional -> doh -> doh" where the doh -> doh
link could use wireformat-64 and then the initial traditional client cannot
consume wireformat-64 but ends up with it anyhow. Is that right?

That shouldn't happen. The middle node realizes it is a gateway for a
traditional client and only indicates to the final server that it knows how
to speak traditional wireformat for the request it is making. The fact that
it is over DoH does not add new media types to the request by default, the
middle node needs to (essentially) opt-in to that via the Accept: request
header and it wouldn't do that here.

making the middle node a doh http cache makes things a little more
complicated for the cache, but not in a way that is unusual for an http
cache. If in that scenario it had previously done a transaction for a doh
client that supported wireformat-64 it could certainly cache that (modulo
all the other caching rules) and then when the traditional client came
along, the cache just needs to recognize that the variant it has in cache
is not one that the client recognizes. At which point it makes a new
upstream request for traditional-wireformat-only. This works ok even if
there is a non-doh aware http cache in the chain as long as the server
marks the response "Vary: Accept" (which it should do if it creates
different variants based on the accept header.. that's not something DoH
needs to specify, 723x has it covered - pure http behavior).

So if traditional wireformat consumers are limited to 16 bit sizes we
definitely should document that as part of the wireformat definition. The
next question is are they, or are we just at a point where we are concerned
they might be? I'm really not sure on that one.

in either case, I don't see a reason to restrict protocol beyond the
wireformat definition.

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 10 Jun 2018 19:17:04 -0400

On Sun, Jun 10, 2018 at 07:10:18PM -0400, Patrick McManus wrote:
> I believe the concern is "traditional -> doh -> doh" where the doh -> doh link
> could use wireformat-64 and then the initial traditional client cannot consume
> wireformat-64 but ends up with it anyhow. Is that right?
> 
> traditional client

It's the part where the middle node _doesn't know_ it's a gateway for
a "traditional client" that I've been worried about, because someone
takes their existing code, plops an HTTPS transit on it, and thinks
they're golden.  I know Tale thinks I'm worrying about something that
Shouldn't Happen, but I think experience tells us this kind of thing
happens _all the time_ in poorly-constructed DNS implementations. 

In any case, I haven't read it carefully but my quick scan of what
Paul sent to the list makes me think it's enough to prevent that naïve
sort of implementation (or anyway, at least the document will have
said it so that if you do the wrong thing it's obviously your own
fault).

A

-- 
Andrew Sullivan
[email-masked]

---

From: Patrick McManus <[email-masked]>
Date: Sun, 10 Jun 2018 19:21:42 -0400

On Sun, Jun 10, 2018 at 7:17 PM, Andrew Sullivan <[email-masked]>
wrote:

> they're golden.

so that's a doh client, not a traditional client. And they would have to
opt into the wireformat-64 bits in my example explicitly with a request
header for a non default media type. At some point you have to give them
what they ask for :)

> I know Tale thinks I'm worrying about something that

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 11 Jun 2018 01:04:21 -0400

> happens _all the time_ in poorly-constructed DNS implementations. 

To be clear, I am not saying people don't write bugs.  People screw up
our modern specs all the time.

My point is that I don't see any practical way with unlimited-DoH that
legacy DNS software ends up having to deal with wire format over 64k
without someone taking an new, affirmative step to code that.  If they
take that step and are passing it into a function that's ill-equipped
to handle it, despite the standard that they're coding against warning
them of that very thing, that's a programmer error, not a
specification fault.

You just said it yourself.  Poorly-constructed.  Just how much
accommodation do we have to make for as-yet-unwritten bad software?

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 11 Jun 2018 12:52:02 -0400

Mark Nottingham writes:
> DNS may very well need a new architecture, but loading this
> responsibility onto DOH post-WGLC is asking too much of it, and is
> unfair to the folks who brought this work to the IETF in good
> faith. 

With my co-chair hat on, it is absolutely fair for this to be brought
now.  I say that even as I appear to be in opposition to at least one
of the draft authors and on the minority side of consensus, going by a
strict counting of the dozen or so people who've offered an opinion on
the list.

What's genuinely surprising to me is that of all the interesting
architectural issues which come along with DoH, it's only message size
that caused such debate.  It's not quite bike-shedding but it's in
rock-throwing distance of it.

---

From: bert hubert <[email-masked]>
Date: Mon, 11 Jun 2018 22:21:30 +0200

> rock-throwing distance of it.

Perhaps this is at the root (or apex!) of our disagreement.  It is
relatively harmless to innovate at speed at the outer edge of DNS.  Because
various people (including me) are now implementing & deploying versions of
this draft already, I think we can reasonably conclude that what we are
doing is not obviously broken.  Worst we can do is deliver a sub-optimal DOH
spec.

Any changes that impact the core of DNS however have far bigger consequences
and will lead to a lot of work down the road.  We have not overseen, and in
fact can not yet oversee, all the consequences of the existence of newly
increased message sizes.  This is not what our proxies and experiments are
testing at the outer edge of DNS.

Specifically, I know we have no defined semantics for what a TCP DNS speaker
is supposed to do if it finds it has to truncate a response, nor what anyone
on the receiving side should do if it receives such a truncated message. And
once large DNS messages can exist, this becomes an issue. 

I (and many others) consider the existing DNS to be extremely complicated
and tricky enough already, and I'd hate to burden it with new dimensions
before we have really thought it through.  This goes beyond "I don't think
there should be problems". It needs the level of "after serious and
prolonged thought, we have identified what needs to be done".

The entire open source DNS community opined here that they too don't want to
go "large dns message" now, and I suspect this is because their spidey
sense, like mine, is tingling that trouble and complexity could be ahead -
for uncertain gain.

So maybe that explains why this part is getting bike-shedded, and many other
parts of DOH are not. We worry about core DNS complexity.

	Bert

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 11 Jun 2018 17:52:27 -0400

bert hubert writes:
> The entire open source DNS community opined here that they too don't
> want to go "large dns message" now, and I suspect this is because
> their spidey sense, like mine, is tingling that trouble and
> complexity could be ahead - for uncertain gain.
> 
> So maybe that explains why this part is getting bike-shedded, and
> many other parts of DOH are not. We worry about core DNS complexity.

I hear you, I really do.  I don't think it is surprising that someone
might worry.  I too have concern about the overall health of the DNS
ecosystem, and I do not cavalierly make my arguments without regard
for it.

But spidey sense is not a technical argument, and worry is not a great
basis for making decisions.  So what do we do when we have vague
feelings?  Well most analytical computer folks, including you I bet,
puzzle it out to find out the root of the issue.  So far in my
puzzling I've been unable to think of any realistic scenario where the
deployed DNS software is at risk here.

If there were even one solid example of how this impacts the rest of
the DNS, I'd certainly be willing to reconsider my position.  And I
can certainly see that consensus of the open source DNS community
carries a lot of weight.  I just want it to be clear, for the list now
and for the posterity of the archives, that if that's the way it goes
then it was not a technical decision that drove it and it comes with
its own set of consequences.

---

From: Patrick McManus <[email-masked]>
Date: Mon, 11 Jun 2018 18:06:26 -0700

On Mon, Jun 11, 2018 at 2:52 PM, Dave Lawrence <[email-masked]> wrote:

> the DNS, I'd certainly be willing to reconsider my position.

This is my position as well. I'm willing to make minor accommodations here
based on the use of a 2 byte message framing length when using wireformat
over TCP. I've concluded that is evidence that the wireformat is expected
to have no single message be more than 16 bits in length (TCP routinely
uses more than one message, and could have chosen a 32bit framing after
all). One of the things DoH does is define a media type for the classic
wireformat so it should be consistent with the classic definition of that..
unfortunately sometimes these things have to be reverse engineered and
ambiguity leads to disagreement.

However, the scope of that evidence is limited to a single wireformat
message. Its not limited to particularly query types, or alternative media
types, or multipart-schemes, etc..

And I
> its own set of consequences.
If it is not a technical decision, then it is not consensus. RFC 7282 is
pretty helpful in this regard. Obviously, there is still a generous dollop
of "technical is in the eye of the beholder".

But I'm hopeful we can come to a technical resolution - you're right imo to
keep pushing through the general concerns to get to specifics. That makes
it easier for everyone.

-Patrick

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 12 Jun 2018 01:51:09 +0000

> the DNS, I'd certainly be willing to reconsider my position.

Great! Let me try again.

The DNS message format is defined specifically for two transports. Looking at the format without looking at the transports, one can imagine a message that cannot be carried in either format. However, the original specifications and all the ones since have always treated the message format as being handled in one of the two transports.

When we define a new transport that allows messages different than the ones we have always assumed, gatewaying those different messages will be different than gatewaying between the two current transports and thus have an impact on the rest of the DNS.

The WG charter we are working under clearly says:
  Specification of how DNS-formatted data may be used for use cases beyond
  normal DNS queries is out of scope for the working group.
Creating new queries, to me, seems "beyond normal DNS queries".

--Paul Hoffman

---

From: Ray Bellis <[email-masked]>
Date: Tue, 12 Jun 2018 22:46:44 +0100

On 12/06/2018 02:51, Paul Hoffman wrote:

> The DNS message format is defined specifically for two transports.
> Looking at the format without looking at the transports, one can
> imagine a message that cannot be carried in either format. However,
> the original specifications and all the ones since have always
> treated the message format as being handled in one of the two
> transports.
> 
> When we define a new transport that allows messages different than
> the ones we have always assumed, gatewaying those different messages
> will be different than gatewaying between the two current transports
> and thus have an impact on the rest of the DNS.

I do think it would be helpful to consider in more detail where DOH is
expected to sit in the DNS architecture.

Is it going to be a new "first class" transport (sic) protocol, or is it
merely a tunneling protocol for carrying DNS messages whose sole purpose
is to provide interworking for those that cannot use the "normal"
transport protocols because either a) there's a stoopid middlebox in the
way, or b) they're a web client ?

Ray

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 12 Jun 2018 18:02:11 -0400

> On Jun 11, 2018, at 9:51 PM, Paul Hoffman <[email-masked]> wrote:
> 

If there is an uncertainty about how DoH will interact with existing message sizes, then this can be alleviated by having DoH use the TCP wire format instead of the UDP wire format. While the two byte length prepend is not necessary for HTTP, it will prevent the unknown translations that some people seem to be concerned about.

Then a future media type can be defined in another spec to handle larger messages.

Tom

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 12 Jun 2018 22:19:03 +0000

> expected to sit in the DNS architecture.

This is the DNS: "is expected" almost always turns out to be wrong. (No smiley appended.)

The same can be said for HTTP.

> way, or b) they're a web client ?

These are good questions, but if we try to base our protocol on what "is expected" and our expectations turn out to be wrong, we will probably design the protocol badly. 

--Paul Hoffman

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 13 Jun 2018 00:10:35 -0400

Paul Hoffman writes:
> The DNS message format is defined specifically for two
> transports. Looking at the format without looking at the transports,
> one can imagine a message that cannot be carried in either
> format. However, the original specifications and all the ones since
> have always treated the message format as being handled in one of
> the two transports. 
> 

We appear to be two technical geeks separated by a common language.
I'm not sure where either my phrasing has gone wrong or I have not
understood yours.  In either case I apologize for my failing.

What I am looking for is a concrete example of how any pre-DoH clients
or servers are is going to have any sort of problem if a DoH DNS wire
format message exceeds 64k -- a specific mechanism for specific old
software that will react badly to an unexpectedly large message being
fed to it, where it hasn't gotten there as a result of new code that
could easily prevent it.

This is the sort of concern that we've had to worry about in the past
with the DNS and for which we did have concrete answers about
implementations that would have issues with a non-zero ADCOUNT in a
request or the semantics of a KEY RR changing or using compressible
names in rdata of new types or so on.  All of those things impacted
messages that existing servers would see.

As far as I can tell there is no way that the pre-DoH DNS/UDP and
DNS/TCP world can even be aware of the existence of DoH and its
potentially 64k+1 messages because nothing at all is being changed for
the messages that the existing code sends and receives.  You could
spin up a BIND 4 instance in a world of unlimited-DoH and it would
still work just as it always did.

The generalized gateway examples you give don't challenge this.  The
DNS/UDP an DNS/TCP network are still not impacted; they weren't able
to carry messages greater than 64k before, and they still won't after.
No change to their inputs, their outputs, or their behaviour.

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.

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 13 Jun 2018 00:17:50 -0400

> way, or b) they're a web client ?

There's no way you'll be able to keep the genie in the bottle of
"merely a tunneling protocol".

There are already indications from people who want to leverage it to
provide DNS response delivery without involving the traditional
resolution path.  Some of them stated quite clearly at the first DoH
BoF that they really weren't even interested in working on it if it
was just going to be merely a tunneling protocol.

It isn't clear to me how you could meaningfully restrict it from being
a "'first class' transport".  Fiat declaration sure wouldn't do it.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 13 Jun 2018 10:59:42 +0100

On 13/06/2018 05:17, Dave Lawrence wrote:

> resolution path.

Can you elaborate?  I don't know what that means.

> a "'first class' transport".  Fiat declaration sure wouldn't do it.

To be a first class transport IMHO it would have to update STD13.

Ray

---

From: bert hubert <[email-masked]>
Date: Wed, 13 Jun 2018 12:16:00 +0200

> To be a first class transport IMHO it would have to update STD13.

Indeed. This would then also have to define TCP TC=1 behaviour and how
resolvers need to then use the third first-class transport called DOH.

It makes little sense to tell everyone they can use this protocol but leave
the semantics of inevitable downstream effects of its use undefined. 

If there were no downstream effects, for example if we restrict the protocol
to <65535 bytes, life would be a lot easier.

    Bert

---

From: Ray Bellis <[email-masked]>
Date: Wed, 13 Jun 2018 14:04:29 +0100

> resolvers need to then use the third first-class transport called DOH.

which would then effectively become Mandatory To Implement, otherwise
someone's going to start provisioning RRsets that are illegal over TCP
and UDP and only capable of being carried in DoH.

This is getting dangerously close into "get off our lawn" territory.

Ray

---

From: Petr Špaček <[email-masked]>
Date: Wed, 13 Jun 2018 19:47:40 +0200

> These are good questions, but if we try to base our protocol on what "is expected" and our expectations turn out to be wrong, we will probably design the protocol badly.

I think Ray was too shy to ask The Question:

Is the goal of the current doh WG

a) "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 an 
interoperable way, i.e. doing a thing the WG was chartered to do?

OR

b) Invent DNS 2.0 and attempt to hide that the proposal goes beyond the 
original DNS protocol? We badly need DNS 2.0 so let's admit that, it is 
not a shame.

If the answer is b) then I will applaud and support doh doing DNS 2.0, 
we only need to stop pretending that current doh work is just a new 
transport for the original DNS.

My reading of the doh charter is that doh protocol is a transport which 
should help to get the existing DNS to endpoints. Changes beyond 
existing DNS semantics are work on DNS 2.0 and thus outside of current 
doh charter.

I strongly support work on DNS 2.0 but we must not pretend that it is 
still the original DNS with minor tweaks, and recharter doh to admit that.

Clean cut will make all discussions about "what happens if there is a 
dumb proxy" moot because it will be clear to everyone that "doh is going 
to be DNS 2.0".

Or even better, let's use a new name for the new protocol:
HTTP naming system (HNS)
and do not confuse everyone with references to the legacy DNS.

Can we get consensus call to answer what doh WG participants want to do?

a) just do new transport for the existing DNS
OR
b) invent "HTTP naming system" without the burden of legacy DNS
(HNS == DNS 2.0)

Can we get clear answers to this question? Pretty please!

-- 
Petr Špaček  @  CZ.NIC

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 13 Jun 2018 14:16:11 -0400

On Wed, Jun 13, 2018 at 1:47 PM Petr Špaček <[email-masked]> wrote:

> >> way, or b) they're a web client ?functional
> >
> > These are good questions, but if we try to base our protocol on what "is
> expected" and our expectations turn out to be wrong, we will probably
> design the protocol badly.
>

I appreciate your concern but please try to avoid accusing members of the
working group of trying to hide anything.

The question of what message size limits to require or recommend does not
resemble an attempt at any kind of "DNS 2.0".  Note that message size
interoperability questions are not a new issue within the DNS: many
endpoints will reject messages larger than 4K or 8K, even though there is
no way to signal this limitation.  HTTP has similar issues (e.g. URL length
limits).

The charter does not require that the standard guarantee functionality in
all possible use cases and multi-system interactions, and both choices (to
apply a limit or not) fail to serve a desirable use case: either we don't
support 100% reliable gateways from DoH into DNS-over-TCP, or we don't
support large zone transfers over DoH.  It's up to the working group to
balance these concerns, either by choosing one option or by finding a
middle ground.

So far, I've heard two middle-ground proposals: a new media type for >64K
DNS messages, or usage of multipart/related to deliver multiple DNS
messages in a DoH response.  I hope the working group will seriously
consider these proposals, or other ways to satisfy both of the desired use
cases above.

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 14 Jun 2018 00:50:30 +0530

> working group of trying to hide anything.

It's a valid question that has been asked. Many of us are concerned
about things are being said and it's best to discuss them freely without
taking offense.

> a "'first class' transport".  Fiat declaration sure wouldn't do it.

This may well fit in within current DoH charter or may not, depending on
how "existing DNS methods (UDP, TLS [RFC 7857], and DTLS [RFC 8094])
experience problems" from the charter is interpreted.

Is this a replacement for traditional DNS? (there's no need to take
offense at this question.. please let's just discuss it.)

The 64kB limit is just one aspect (we've been asked for proof of
problems - it has been explained already that DNS message parsers do it
in memory currently - 64kB imposes an implicit upper limit on the
derived objects in in-memory message structures (lists of names + RDATA
objects).  E.g., a 32-bit limit would mean the possibility of requiring
to hold 4GB wire data in memory and the larger derived structs from
parsing it, or, reimplementing message parsing with disk storage. (Think
of sax vs. DOM XML parsing for an analogy.)

> no way to signal this limitation.  HTTP has similar issues (e.g. URL length

Implementators are concerned because this 64kB limit has been assumed
forever now and various parts of code aren't written or even designed to
handle larger sizes. I don't know how you mean by "endpoints will reject
messages larger than 4k".. I think any of the popular open source DNS
nameservers will parse 64kB messages over TCP (though some may not
generate > 16kB messages as name compression pointers have a limit of
16kB from the start).

> balance these concerns, either by choosing one option or by finding a

The charter says:

"The primary focus of this working group is to develop a mechanism that
provides confidentiality and connectivity between DNS clients (e.g.,
operating system stub resolvers) and recursive resolvers."

and

"Specification of how DNS-formatted data may be used for use cases
beyond normal DNS queries is out of scope for the working group."

and we're talking about zone transfers. Zone transfers are not DNS
queries. So what's the limit of this charter?

Large zone transfers are supported today using TCP continuation messages
and the same can be encoded by DoH within the 64kB message limit. FWIW,
even we don't use larger than 16kB messages for zone transfers in
traditional DNS because it doesn't compress well, though there is a 64kB
budget.

If DoH is purely an encoding transport to carry traditional DNS
messages, then there will be a problem with larger than 64kB messages
from:

(1) tradtional NS -> (2) trad:DoH intermediate using 1MB messages -> (3) DoH client

and:

(1) DoH NS using 1MB messages -> (2) DoH/trad intermediate -> (3) traditional client

because TSIG will not validate if only (1) has the secret to generate
them and (2) is just a forwarder.

A person like me is wondering about these things, because I don't know
what's the limit for DoH - how all it will be used, because of
everything that's being discussed. It appears that DoH will not be
restricted, so before rushing to update things, please discuss
traditional DNS's concerns, and also discuss what's within scope in the
charter.

As an exercise, it'd be good to read about several practial usage
patterns in which DoH may be used.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 14 Jun 2018 01:00:11 +0530

> queries. So what's the limit of this charter?

Before someone pedantically points out this, AXFRs are sent as DNS QUERY
but they're not a DNS query in the layman's sense and the charter isn't
talking about the opcode. :P

		Mukund

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 13 Jun 2018 15:43:44 -0400

Snipped to focus on one technical point.

On Wed, Jun 13, 2018 at 3:20 PM Mukund Sivaraman <[email-masked]> wrote:

> and the same can be encoded by DoH within the 64kB message limit.

This is currently not true, because each DoH query must return at most a
single DNS message in the response.  Therefore, there is no way to make use
of continuation messages in DoH.  I think this is a major reason why we are
having this conversation: lack of continuation messages renders DoH
strictly less expressive than standard DNS, which is a concern for gateway
applications.

> talking about the opcode. :P

Without veering into charter interpretation, I agree that supporting AXFR
is distinctly lower priority than typical client-recursive queries.
However, some working group participants believe that it would be valuable,
so it's worth considering if there is a reasonable way to include support
for it, or to leave open the possibility of future support.

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 14 Jun 2018 02:26:37 +0530

> strictly less expressive than standard DNS, which is a concern for gateway

I meant it can be encoded by DoH within the 64kB limit as multiple
messages by using a multi-part scheme, instead of extending the DNS
message size. If the above is the concern, then this is the most
interoperable way. Changing DNS message boundaries isn't always doable.

Let me also be the devil's advocate. If the idea is to have more
flexible DNS messages that modern parsers can parse and reframe for
traditional DNS, why limit ourselves? Throw away the DNS message format
with redundant owner names of individual RRs, possibility of TTL
mismatch within RRset, no defined ordering of RRs, which has become
horrible already with hacks like OPT, and other things that make parsing
horrible. Make a clean new message format that encodes and decodes from
traditional DNS message format. I'd prefer that to increasing the
message size which is neither here nor there.

> for it, or to leave open the possibility of future support.

On the topic of charter, my interpretation on reading it is that DoH
will be used to configure a stub resolver when other traditional DNS
transports are tried and will not work, as a means to keep things going.

DoH is not even an RFC yet and there has been an announcement from
Mozilla that by default all its DNS queries will be sent to Cloudflare
via DoH, and this is the default behavior that's all within the Firefox
application. Is anybody else concerned about the Firefox DoH
announcement?

Apart from the privacy implications, the fact that a browser used by
millions with a large market share is switching suddenly to a new
protocol at the application layer, that nobody except one or a handful
of cloud providers are ready for is unnerving.

It seems to be the first major use and it seems quite different from the
charter of DoH. Who is this serving? What will be some typical patterns
of using DoH?  Is DoH a fallback to a transport when traditional DNS
won't work, or is it supposed to become the new way of doing DNS, i.e.,
DNS 2.0? The concerns about what the purpose of DoH is and how it
compares to traditional DNS are not unjustified.

		Mukund

---

From: Patrick McManus <[email-masked]>
Date: Wed, 13 Jun 2018 14:59:01 -0700

> application. Is anybody else concerned about the Firefox DoH
You are overstating the announcement greatly. We're running some fairly
small experiments to see how this works. It has gotten a bit more publicity
than something at this scale normally does because its important to let
impacted users know how their data flow is changing - that's all. I hope it
makes for a better protocol.

This is part of the process of data driven decision making. sometimes known
as running  code - and it makes for successful protocols when the IETF does
it right. I'm happy to say that open standards are an important part of our
mission and we're confident that we won't accidentally create defacto
standards from Internet Drafts - that's something we think carefully about
and have done well managing with HTTP and TLS over the last few years (of
which we have shipped dozes on draft versions to much bigger populations in
service of creating the final consensus product) and I'm confident we'll be
fine aligning with the final DoH as well.

on the other hand, as I've told the HTTP WG on many occasions: this forum
is for open standards, its not the room I make product specific decisions
in (nor would I expect other participants to negotiate their product
decisions with me).

-Patrick

---

From: Ray Bellis <[email-masked]>
Date: Wed, 13 Jun 2018 23:02:02 +0100

On 13/06/2018 22:59, Patrick McManus wrote:

> This is part of the process of data driven decision making.

Here's some data for you.

If Mozilla does go this route and makes this behaviour the default, I'll
never run Firefox again.

no cheers,

Ray

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 14 Jun 2018 09:52:17 +0530

Hi Patrick

> in (nor would I expect other participants to negotiate their product

The questions aren't about Firefox explaining its decision or its usage
of protocol. The questions are about DoH enabling this, what its purpose
is. Until this announcement, I used to view DoH as a way to make DNS
service available where existing secure stub->resolver protocols such as
DNS over TLS and dnscrypt don't work. It seems DoH may be used as the
means to bypass traditional DNS completely, where answers are not
obtained via the system configuration of stub. It may be justified (and
surely this is possible using traditional DNS as well), but let's see
some descriptions of how DoH is expected to be used. On re-reading the
charter, it appears someone had thought about all this which isn't
apparent on a naive reading.

It would help participation, get to more consensus if the usage patterns
are better understood.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Thu, 14 Jun 2018 10:11:13 +0530

> It would help participation, get to more consensus if the usage patterns

As an implementer, it is unclear where this is all going, which is what
I'm curious about over DoH. If there's more description of different
usage patterns, we can better plan how it would fit in our projects. The
switch to DoH at the application layer seems suddenly upon us. I was
thinking of DoH just as a fallback transport, but suddenly it seems
almost like this is the new way to do DNS queries (a switch).

(Musing.. why did we even spend any time on DNS over TLS if this is more
or less the same thing?)

		Mukund

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 14 Jun 2018 10:14:44 +0200 (CEST)

On Thu, 14 Jun 2018, Mukund Sivaraman wrote:

> The switch to DoH at the application layer seems suddenly upon us. I was 
> thinking of DoH just as a fallback transport, but suddenly it seems almost 
> like this is the new way to do DNS queries (a switch).

Users have wanted (and used) "name resolving in the application" layer since a 
long time in various situations. The fact that the standard operating system 
APIs make this hard has never taken away the desire or will for a lot of 
solutions to be able to ask their *preferred* resolvers. Why shouldn't 
applications be able to decide this?

1. DOH doesn't really change this property and 2. there's no DOH support in 
any system name resolver functions yet so there's no way to do DOH other than 
"yourself" at this point.

DOH is just a protocol to deliver DNS data. It can be used in several ways.

-- 

  / daniel.haxx.se

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 14 Jun 2018 15:00:24 +0100

> On 14 Jun 2018, at 09:14, Daniel Stenberg <[email-masked]> wrote:
> 
>> The switch to DoH at the application layer seems suddenly upon us. I was thinking of DoH just as a fallback transport, but suddenly it seems almost like this is the new way to do DNS queries (a switch).
> 
> Users have wanted (and used) "name resolving in the application" layer since a long time in various situations. The fact that the standard operating system APIs make this hard has never taken away the desire or will for a lot of solutions to be able to ask their *preferred* resolvers. Why shouldn't applications be able to decide this?

Applications are free to decide it but it is not without consequences, for example:

1) Many enterprises rely on using internal views for DNS from servers provided by DHCP. If applications override this by _default_ then that model completely breaks internal name resolution _and_ leaks internal queries to the external resolver. Some might consider that a loss of security and privacy. 

2) By ‘users’ above I think you mean ‘application developers’ not ‘actual end users’? While their may be good reasons for application developers to want to do this I would postulate that actual end users who understand enough about DNS to want to control it would prefer to have a single system setting to configure it to point at _their_ preferred resolver, rather than a (transport/DNSSEC/resolver) setting existing in every individual application. 

I’m not saying there is a right or wrong model here, just that there are more concerns than simply what the application prefers. 

Sara.

---

From: Daniel Stenberg <[email-masked]>
Date: Thu, 14 Jun 2018 16:09:45 +0200 (CEST)

On Thu, 14 Jun 2018, Sara Dickinson wrote:

> I’m not saying there is a right or wrong model here, just that there are 
> more concerns than simply what the application prefers.

Sure. And I'm saying they already existed since long before and are 
independent of DOH.

-- 

  / daniel.haxx.se

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 14 Jun 2018 15:38:32 +0100

> On 14 Jun 2018, at 15:09, Daniel Stenberg <[email-masked]> wrote:
> 
> Sure. And I'm saying they already existed since long before and are independent of DOH.

I don't disagree (note I did not mention DoH at all in my response). I was replying to the generic question “Why shouldn’t application be able to decide to use their own preferred resolvers”.

But it is also true to say that prior to DoH applications that made that choice were the _exception_ and not the norm, whereas it seems highly likely that many applications (and most browsers) will soon all choose to perform DoH themselves, making this new model a reality that has to be addressed. That fundamentally shifts the role of DNS and DHCP within the end user device infrastructure and the raises questions about the concept of implicit choice of DNS resolver (e.g. the network resolver vs application resolver).

The observation here is that this shift is being directly driven today by applications wanting to use DoH to their preferred resolver for a variety of reasons, not by (for example) operating systems, enterprises, ISPs, end users or the DNS community. 

Sara.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 14 Jun 2018 15:22:33 +0000

There were a bunch of DoH implementations at the last IETF Hackathon. The fact that two of these implementations are getting early publicity is not indicative of a trend.

On Jun 14, 2018, at 7:38 AM, Sara Dickinson <[email-masked]> wrote:
> The observation here is that this shift is being directly driven today by applications wanting to use DoH to their preferred resolver

It is one implementation of one application, not "applications". And Mozilla has not said if they want to use a preferred resolver or are just doing that now so that they can get better measurements about whether or not they want to deploy DoH at all. If Mozilla (or Chrome, or Edge, or ...) turns DoH into a way in the long term to force a lot of DNS traffic to just one preferred resolver, they will rightly suffer people moving away from them. It's pretty trivial to detect this type of behavior.

> for a variety of reasons, not by (for example) operating systems, enterprises, ISPs, end users or the DNS community. 

There was clearly interest in DoH for operating system use (by Stubby). Enterprises have indeed indicated they are interested in DoH to avoid redirecting of their traffic by intermediaries. We haven't heard from ISPs or end users, but we *certainly* have heard interest on this list from the DNS community.

--Paul Hoffman

---

From: Mateusz Jończyk <[email-masked]>
Date: Thu, 14 Jun 2018 21:12:08 +0200

> I’m not saying there is a right or wrong model here, just that there are more concerns than simply what the application prefers. 
+1
There is a need for robust DHCP to discover DOH servers.

I hope that separate DOH settings in web browsers are just a stopgap measure
until operating systems will support DOH.

Greetings,
Mateusz

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 14 Jun 2018 19:22:34 +0000

> There is a need for robust DHCP to discover DOH servers.

Agree.

> until operating systems will support DOH.

We haven't gotten much traffic on the driu mailing list <https://www.ietf.org/mailman/listinfo/driu>, but I do hope we get more on this.

--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Jun 2018 12:34:54 -0700

Paul, Mateusz, can you talk about the use case for using DHCP to discover
DoH?   It's not at all clear to me.

On Thu, Jun 14, 2018 at 12:22 PM, Paul Hoffman <[email-masked]>
wrote:

> We haven't gotten much traffic on the driu mailing list <
> https://www.ietf.org/mailman/listinfo/driu>, but I do hope we get more on
> this.
>
> --Paul Hoffman
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 14 Jun 2018 19:39:07 +0000

On Jun 14, 2018, at 12:34 PM, Ted Lemon <[email-masked]> wrote:
> Paul, Mateusz, can you talk about the use case for using DHCP to discover DoH?   It's not at all clear to me.

An OS might want to offer protected DNS for its stub resolver. DNS-over-TLS is one obvious option, DOH might be another.

--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Jun 2018 12:45:33 -0700

Okay.   But do you *get* protected DNS if you discover a DoH server using
DHCP?   What does "protected" mean in this context?

On Thu, Jun 14, 2018 at 12:39 PM, Paul Hoffman <[email-masked]>
wrote:

> > Paul, Mateusz, can you talk about the use case for using DHCP to
> discover DoH?   It's not at all clear to me.
>
> An OS might want to offer protected DNS for its stub resolver.
> DNS-over-TLS is one obvious option, DOH might be another.
>
> --Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 14 Jun 2018 19:49:23 +0000

On Jun 14, 2018, at 12:45 PM, Ted Lemon <[email-masked]> wrote:
> 
> Okay.   But do you get protected DNS if you discover a DoH server using DHCP?

Yes, for some value of protected.

>   What does "protected" mean in this context?

That's a topic for the DRIU mailing list and the upcoming BoF. It's not relevant here other than that people are asking where DoH might be used.

--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Jun 2018 12:56:17 -0700

Okay, fair enough, but if that's the case, then you probably shouldn't be
advocating for a DHCP option *here.  *I see that Tom has raised the DHCP
question on that mailing list, so I'll subscribe.   FWIW, Tom and Willem
and I had a discussion about the security implications of this last week,
and while I don't know if Tom and Willem came away agreeing with me on
this, the upshot from my perspective is that this really does need to be
carefully thought through and carefully specified—it's by no means clear to
me that we "need" a DHCP option, but if we do, it has to have the right
security properties.   Thanks for the pointer.

On Thu, Jun 14, 2018 at 12:49 PM, Paul Hoffman <[email-masked]>
wrote:

> That's a topic for the DRIU mailing list and the upcoming BoF. It's not
> relevant here other than that people are asking where DoH might be used.
>
> --Paul Hoffman