Re: [DNSOP] Followup Discussion on TCP keepalive proposals

[John Heidemann <[e-mail]>]

[Warning to rubberneckers: seems like at least two topics here: about
the spec and about TCP as a DoS.]

On Wed, 21 Jan 2015 14:29:22 -0800, Paul Vixie wrote: 
>    # 
>    John Heidemann
>    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.

I'm confused.  I thought we agreed the installed base doesn't do TCP
pipelining basically ever.

Presumably NEW initiators that choose to do pipelining to improve
performance will do so aware of reordering, as is required by the 5-year
old RFC5966.  Not to speak for Mr. Bellis (on the cc), but RFC5966 says:

   [section 6, response reordering for DNS-over-TCP:]

   Client resolvers MUST be able to process responses that arrive in a
   different order to that in which the requests were sent, regardless
   of the transport protocol in use.

You're correct that implementations that ignore this part of the
specification may misbehave, but I stand by the protocol being clear
about what is expected.

It seems like you're arguing that all future responders must be
conservative to protect against old clients that are smart enough to do
pipelined TCP but not smart enough to track TXID.  Is there really a
non-negligible installed base base of such initiators?
(Are there any specific implementations that are known to behave this way?)

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

Let's break this out:

a- some responders may reply to the first query in the pipeline and
abort on the second

b- others may abort before replying to either

Isn't case (a) a performance issue, not a correctness issue?

Case (b) is, I would say, an non-compliant and overly strict responder.
But you frame it as applying a common spam defense technique from tcp/25
to dns.  What is the installed base of such responders?
(Are there any specific implementations that are known to behave this
way?)

If there are, couldn't an initiator work around them in the same way
they deal with other non-compliant responders, by falling back to UDP?
(I believe only new initiators will send pipelined, so we can MUST them
into falling back, I think.)

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

I agree that we must consider reality and installed base, even when it
is non-compliant.  And I'm sure you've seen and tried to work around
far, far more horrible clients and servers than I do.

But before we throw in the towel to HTTP, I'd sure feel better if we
could point to specific broken implementations and have a sense of the
scope of the problem.

Maybe another crazy experiment by Warren or two?

Or maybe I don't want to be just another web programmer. :-)

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

I agree we must consider installed base.

But if you frame TCP as a "new feature" that one can deploy to do
better than UDP, then perhaps we can push this back to their problem.

I.e., IF you want to go fast with DNS-over-TCP, be sane and move forward
and do these things.

If you don't care about speed or privacy, fine, stick with your 512B
UDP/53.

Again, the assumption here is the current use of DNS-over-TCP with
pipelining is minimum, so we don't have crufty initiators gumming things
up.


----------------------------------------


On to DoS:


>
>    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 hear you saying how well HTTP goes through proxies today.

But the question was: why is DNS-over-TCP inherently a DoS?

I don't see that your down-thread comment speaks to that.

It seems speak to performance and deployment issues, and to suggest that
one must have 100% deployment to be successful.  What does that have to
do with DoS?

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

I recognize your experience with installed base, and I'm 
happy to have a separate discussion about deployment.

But the question was: "how DoS is an argument against TCP for DNS".

How does implementation footprint and upgrade answer that question?

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

To me, this reframe changes question into "isn't X clearly better"
(where this X seems to be DNS over JSON and REST and HTTP or HTTPS, but
others have others Xs as well).  While that may be the end result of
DNSOP and DPRIVE, it doesn't answer the questions this thread with:

(1) are protocol changes required for DNS-over-TCP?

and (2) is DNS-over-TCP inherently a DoS?  (Particularly if
DNS-over-HTTP is acceptable.)

I'm still looking for what concretely supports those statements---they
seem like there should be a factual answer to them.

I respectfully want to push off discussion of the "isn't X clearly
better" redirect because, to me, deciding between very different
protocols with many tradeoffs seems a LOT more subjective.  And an
informed choice of "isn't X clearly better" should be include why Y
doesn't work.

   -John Heidemann