Re: [DNSOP] Followup Discussion on TCP keepalive proposals

[Paul Vixie <[e-mail]>]

> John Heidemann <mailto:[e-mail]>
> Wednesday, January 21, 2015 1:53 PM
> On Wed, 21 Jan 2015 09:30:44 +0000, Ray Bellis wrote:
>
> I want to restate this, because people often confuse current practice
> with current specifications:
>
> DNS over TCP/53 is *already* persistent. No *protocol* changes are needed.

i disagree with your use of terms here. see below.
>
> *Implementation* changes, however, are needed:
>
> - clients need to not blindly close the connection after one request
>
> - clients and servers need to use well known implementation techniques
> (from HTTP) to get good performance---pipelining, processing requests
> in parallel, sending replies out-of-order (rfc5966), handling TCP
> fastopen (newly minited rfc7413).

at the moment, a tcp/53 initiator that assumes in-order response and
does not check the TXID works. the protocol neither permits nor forbids
this. the burden is either on the responder to be conservative in what
it generates in the presence of the ambiguous specification, or on
end-users to be able to upgrade their tcp/53 initiation software to be
more cautious in how it treats the answers.

similarly, a responder who aborts the tcp/53 session when pipelining is
seen (which is a common technique for spam defense on tcp/25, so,
unimaginable here) would have neither caused nor experienced any
operational problems related to that implementation choice from 1985 to
the present day, even though the specification was silent on the matter
of pipelining, neither forbidding it nor requiring that it be supported.

historically we say we don't want to break working configurations even
if their interpretation of the ambiguous specification is not to our
liking. and we treat the tightening up of the specification as a
protocol change even though by some reading the new behaviour was also
acceptable under the older more ambiguous specification.

you can see this principle in use here
<https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00>:

> 5.2. It is strongly urged that the DNS specification be amended to
> require that the question section from the request MUST be copied,
> exactly, bit for bit, into the question section of the response.  The
> DNS specification is silent on the matter of altering 0x20 bits in the
> question name when copying it from the request to the response, so, this
> change is "within the spirit."
>
> A change to the specification is necessary because while such bit for
> bit copying "happens to be" nearly universal practice today, we must
> warn all future responder implementors that the 0x20 bits, while not
> significant for name matching, are now in use as a "covert channel" by
> the requestor, to itself. 

since this draft did not go forward, any responder which does not copy
the 0x20 bits of the QNAME is compliant, and any initiator who depends
on the copying of 0x20 bits being copied has to allow for this perfectly
reasonable interpretation of the existing, somewhat ambiguous,
specification.

in other words the installed base gets a seat at the table, and if
you're going to behave very differently in a way that older
implementations could reasonably refuse to interoperate with, it's your
problem, not theirs. and under those circumstances, a mandatory change
to how the other end interprets the older ambiguous specification is, in
effect, a protocol change.

>
> Paul Vixie replies:
> } if they did,
> [that is: if clients take advange of persitent TCP over port 53]
> } then those initiators would either be a DoS from the responder's
> point of view, or a
> } DoS from other initiators' points of view. we are a prisoner to the
> reasonable expectations of
> } the billions of devices that were created in the decades-long era of
> RFC 1034 section 4.2.2.
>
> You're saying TCP is inherently a DoS when used for DNS?

yes. well, TCP/53 is. TCP/80, with an appropriate RESTful/JSON API,
would be fine. as i've said every time someone has said "to avoid
$problem, let's use TCP/53 as the primary transport", RFC 1035 section
4.2.2 is a mine field, and anyone at all can deny service to any
initiator who depends on tcp/53 service from anyone else at all. that's
why the fix to the Kaminsky bug was source port randomization, rather
than TCP/53.
>
> I don't get it. Some how the web community tolerates persistent TCP
> without
> falling over. And you've suggested DNS-over-HTTP is desirable. Won't
> that also create any DoS problems that stem from TCP?

no, it won't. i believe i spoke to this question in detail, down-thread:

> but, more importantly, persistent tcp is all we've got. RFC 6013
> failed, in the sense that the tcp-m WG chose not to give it the IANA
> resources it would have needed. google's tcp-fastopen is at best
> unsecure. SCTP seems to have jammed in the breach.
>
> if we want (and we do want) to keep a hot path open between a dns
> initiator and its pool of dns responders, then we need persistent tcp
> in the HTTP/1.1 style, and we need a large number of tcp slots on the
> responder, in the style of HTTP/1.1 responders.
>
> the t-shirt is wrong. it's not "cross out 'lets take it to the ietf'
> and write 'just put it into dns'". rather, it's "cross out 'lets
> assume that our initiator has an internet connection' and write 'lets
> assume that our initiator has a web connection'". the internet is
> older than the web, but no longer larger than the web. just as
> ethernet was the RS232 of the 1990's, so now TCP/80 is the RS232 of
> the new century. i do not love this fact, but i do recognize it.
>
> I don't see how DoS is an argument against TCP for DNS. (Unless one
> assumes hardware and software at the servers is fixed to something
> like the
> 2004 standards.) What am I missing?

what you appear to be missing is an understanding of how large the DNS
implementation footprint is, and what perfectly valid assumptions the
iceberg-that-will-never-upgrade has made, and what respect they are due
by us. whereas the tip-of-that-iceberg
that-will-actually-be-upgraded-ever deserves to be unshackled from RFC
1035 section 4.2.2 and given the vast capabilities of HTTP/1.1 in terms
of connection management, pipelining, and number of available tcp slots.

background:

let me turn your question around. we have a JSON schema. we can develop
a RESTful API in a few hours. given that altering the way we use TCP/53
would require upgrading the DNS server software and possibly OS kernels
on responders, and altering initiators, and that this will only ever be
done on a small number of the total responders now active on the
internet, why aren't we preferring a TCP/80 (and perhaps TCP/443)
solution, which has the exact same costs, will reach the exact same
subset of servers-that-will-ever-be-upgraded, but would have zero impact
on existing TCP/53 servers (including feature negotiation overhead), and
far better results? so, to borrow your question, what am i missing?

deeper background:

note: i deeply, deeply regret EDNS. we should have added another UDP
port number and used the "slabs" schema, and we should have moved to
TCP/80 (and maybe TCP/443). UDP/53 and TCP/53 should have been relegated
to last-resort transports, but left unchanged -- no negotiation overhead
(timeouts, state, complexity) and no IP fragments.

if we think the DNS will outlive us all, and i do think this, then
there's plenty of time to amortize the cost of a non-bandaid fix. the
middlebox-using hotel rooms, coffee shops, and national firewalls have
decided that DNS is their protocol and that if we try to speak it then
we must intend to speak to their middlebox not to the far end. this
means end-to-end DNSSEC as required by DANE cannot be done on Web
connections, which are many, but rather on Internet connections, which
are few.

-- 
Paul Vixie