[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward
On 10/14/09 12:16 PM, Ray.Bellis@nominet.org.uk wrote:
> I fully support the idea of the draft, as already indicated.
>
> And I fully support Michael in that we want to use "unmodified TCP".
Indeed - modifying TCP itself is not (as far as I'm concerned) on the
table.
FWIW, yesterday I performed some benchmark tests against Bind 9.6.
Over TCP/IP I was able to do 3000 qps. That was with a brand new TCP
connection for each query, with no parallelisation.
This has ignored loads that might be created by bad actors with the goal
of burdening servers. Transactions per second statements should also
cover the level of reduction caused by credible attack.
The same server will do about 23000 qps over UDP.
This would seem to imply that after an 8x increase in the number of
servers, DNS over TCP could then achieve its current margins. Even
after such a sizable investment, retaining current margins seems
implausible.
> The main reason for having this draft is the perceived unwillingness
> of various parties to implement/support/allow TCP as it was intended,
> a mandatory transport for DNS in case UDP does not suffice, in
> particular for packet size / fragmentation reasons.
Exactly, yes.
DNS is not currently dependent upon TCP, nor had DNS been designed to
become dependent upon TCP. The fact that most CPE equipment does not
proxy DNS over TCP should give this WG some pause about the economical
practicality of depending upon TCP.
At least, TCP will ensure DNS represents less of a threat when exploited
to attack other services. However, nearly all other services heavily
depend upon DNS remaining operational.
> We (or many of us) want to convince those parties posing obstacles
> to this use of TCP that their opposition is not justified, and that
> IMO cannot be done by a simple normative statement of "MUST" for TCP.
> No, we need to provide arguments and show ways to mitigate the raised
> concerns! Exploring the effects of TCP options and parameters and
> giving recommendations to implementers and operators of how to use TCP
> in the best possible manner seems the right way to achieve this goal.
> This should include concrete arguments for implementors and vendors
> of middleboxes that DNS over TCP is not evil.
This is what I've attempted to do already, but I accept that it needs
more work.
Mostly what I'd like to be able to do is dispel (or at least mitigate)
the FUD about TCP as a transport mechanism for DNS.
Would you suggest a substantial increases in the resources needed to
sustain current levels of service is not cause for concern or careful
review of possible alternative? It seems important to ensure that
resources estimates be based upon reasonable expectations of what might
be needed to endure credible levels of abuse?
> If we can agree on this strategy, the draft has a chance to be
> amended and turned into a valuable document that gives enough
> concrete guidance to both implementers and operators to actually
> overcome the observed reservedness against the TCP support for
> DNS transactions as specified in STD 13 and STD 3.
>
> Such exploration and elaboration should also better educate the
> WG on aspects of DNS transport, allowing it to perform -- in a
> second step then -- a more targeted evaluation of proposals for
> alternate DNS transport(s), and eventually make better informed
> decisions on how to proceed with new proposals to this end.
>
> N.B.: The priority of dealing with possible signalling of Transport
> (and/or other feature) support in DNS servers may very well be made
> dependent on the outcome of the first steps above.
>
> Can wee agree on this way forward?
This sounds sensible, although I would like to take the counsel of those
wiser to the ways of the IETF than I am.
At the very least, the idea of having a real expert on TCP advise is
very sensible.
One might have hoped TCP would _not_ have been seen as the _only_ option
available, and that fair comparisons of the alternatives would have been
sought instead of discouraged. It seems unwise to eliminate
alternatives already providing service for other critical infrastructure
in a manner similar to that required by DNS.
When dependent upon TCP, how much DNS infrastructure will become
dependent upon Akamai like services, and who might desire this outcome?
-Doug