Re: [DNSOP] Followup Discussion on TCP keepalive proposals

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, John Heidemann writes:
> 
> [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.

The installed base has supported pipelining forever.  BIND 4.8
supported it.

What the installed base didn't do was out of order reponses /
parallel processing.  That said doing this is permitted by RFC
103[45].  A client that pipelined queries needed to check the txid
of responses.

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

Not that I am aware of.  That said we will have a acl that will force in-order
processing if matched (default no match).
 
> >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?)

DNS doesn't need this defence.  You are sending repsonses back to
the initiator.  If there are too many new upstream queries this is
no different to lots of UDP queries.  The only difference is you
return SERVFAIL/REFUSED rather than dropping the query.  Alternatively
you can drop and close the connection.

Pipeling itself is supported by the protcol whereas SMTP didn't
support pipelining as it is a lock step protocol.

> 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.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]