On Sun, 25 Jan 2015 09:44:24 +1100, Mark Andrews wrote:
>
>In message <[email protected]>, Paul Vixie writes:
>> > Mark Andrews <mailto:[email protected]>
>> > Thursday, January 22, 2015 6:29 PM
>> > In message <[email protected]>, John Heidemann writes:
>> >> ...
>> >> 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.
>>
>> both statements above are partly correct.
My statement above ("the installed base doesn't do TCP
pipelining basically ever") was unclear. I meant (in the context of
discussion that's now been cut), the installed based on INITIATORS
doesn't do pipelining.
Mark is correct that some of the installed base on responders DOES
generally handle pipelining incoming queries. (I have not done a
careful survey and so cannot make a stronger statement.
Specifically, for all clients of which I'm aware (both
recursives and stubs), when they make DNS queries over TCP,
they make one query and close the connection.
Again, anecdotes should be taken with care, but I think published work
analyzing traces will bear this out.
>> the installed initiator base does not use pipelining, ever.
YES that was the point I was trying to make.
If we agree on that, then we need to review at Paul's concerns about old
clients causing failures.
>From other parts of the thread:
On 24Jan15, Paul Vixie allegedly wrote:
could violate older implementations' reasonable-at-the-time assumptions,
against the burden of choosing a non-interfering signal pattern, like a
new port number, or a new protocol verb.
And I think Mark Delay replied:
Does it have to be that drastic? Wouldn't an EDNS option "I understand
out-of-order" be enough? Once seen in a TCP session it would hold true
until closed. The non-presence of such an option could then entrench
the in-order assumptions that may exist in the installed base.
I think these statements are both overly strong. They both suggest
that careful signaling is required before deploying DNS over TCP with
pipelining or
persistence.
BUT, I think there is rough consensus that there are near-zero INTIATORS
that actually request this feature. (I think both Mark Andrews and Paul
Vixie have said this more or less at in the thread; please correct me if
I'm wrong.)
If we can successfully demonstrate that the there are no (or virtually
no) DNS-TCP-pipelined or persistent initiators, then signaled seems
like overkill.
I asked up-thread:
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?)
We are, I think, in the lucky place of having a new feature (multiple
DNS queries over TCP with pipelining and reordering) with SOME level of
responder support and basically zero initiator use.
Do we really need new signaling?
Put differently: If we all accept Paul's "first, do no harm"
principle, if there are no initiators that don't follow the spec, as we
think, then there is no harm to deploy.
And there IS harm in mandating new signaling, because options get
filtered, as Mark Andrews said:
[Wouldn't an EDNS option be enough?]
Only if you want 8% of your queries to fail.
http://users.isc.org/~marka/ts/alexa.optfail.html
That's harm on the initiator side. The other question is harm on the
responder side. That's why I was trying to get to the bottom of the
assertion that DNS-over-TCP is inherently a DoS. I haven't seen
evidence supporting that claim, and I think we can all recognize the
installed base of HTTP to show that at least someone can make TCP work
at scale on the server side.
>>bind
>> responders, since 4.8, has accepted pipelining, but with ordered
>> responses until a currently unreleased patch was put in recently. bind
>> responders through bind 8 did not read the next (potentially pipelined)
>> request out of the tcp socket until after it had sent its response to
>> the previous request, so, there was no parallelism of any resulting
>> cache miss activities.
Most implementations whose TCP we've examined (bind 9.9 and unbound)
have performance problems when running over TCP. But performance
problems can be fixed incrementally and in place, unlike correctness
issues where people fail.
Yes, there are definitely performance problems that will need to be
fixed. But performance has very different deployment issues
than correctness does.
(on to installed base)
Mark Andrews wrote:
We should also stop thinking of the installed base as something
that cannot be changed. This is particularly true of authoritative
servers. We can identify broken servers. We can inform their
operators that they are broken.
And Paul Vixie replied:
mark, you and i know better than anybody that this approach
doesn't work. it didn't work for lame delegation checking, it
hasn't worked for EDNS, and it's so much of a risk in DNSSEC
that we're now discussing ways that an RDNS operator can turn
off validation for signed zones rather than signal failures on
failed lookups.
EDNS is a powerful example, but I think it can be misleading.
EDNS is a requirement for using DNSSEC, so to the extent that DNSSEC is
manditory (i.e., if it's validated DNSSEC or nothing), EDNS becomes
manditory and it's slow rollout is a huge problem.
I haven't seen anyone assert that TCP should become *manditory* for
future DNS. If it's encouraged, or at least not discouraged, then I
suggest we can abide a multi-year rollout.
-John
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
