On Fri, 2004-07-09 at 08:58, Alan DeKok wrote:
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
This does not show the relationship is non-linear. Do you need more
information as to what linear means, or are you ignoring the point and
spreading FUD on purpose?
You have not offered simulations for traffic flow to counter this
The original question was entirely independent of traffic flow.
Any question of network stability would, by its very nature, be related
to traffic flow. : )
You have not offered a premise for your assumptions regarding the
number of queries needed.
The relationship I originally discussed, and what Greg was talking
about, was how the number of DNS queries depended on the number of
incoming SMTP connections.
Let's define some terms:
N = number of SMTP connections to an MTA
D = number of DNS queries performed by that MTA, per SMTP connection.
T = total number of Sender-ID DNS queries performed by the MTA.
Q: Is T = \theta(N)?
Your response was that D was large, and would cause the net to
collapse. I don't see how that could be construed as answering the
Taking the limits recommended by the draft (as a should), there may be
as many as 20 DNS queries per message, or more! If compared to normal
SMTP use where, as example, 100 messages are being transfered, at the
receiving SMTP server, there may be a single DNS lookup at the beginning
of the session. Assuming an average message size of 4k bytes in this
example, where the average TCP packet payload is 1,400 bytes, this means
within about 300 TCP packets received, there would be one small UDP
query. For Sender-ID, the number of DNS queries added if at the should
not exceed limits, would be 2000 UDP queries. The ratio of UDP queries
to TCP packets, in this case, goes from 0.3 % to 666.0 % of TCP packets.
An effective proponent would not resort to personal berating to
An effective opponent would answer questions, and would not resort
to avoiding the issue. The alleged ad hominem was directly on point:
You were asked a question, and you refused to answer it. Your answer
was ambiguous as to whether or not you even understood the question.
From my reading of Sender-ID, all of the DNS lookups it performs are
initiated from SMTP connections. Therefore, the relationship must be
that T=\theta(N), and probably T=DN.
Your argument that D is large is a nice one, but irrelevant to the
question you were asked.
The limits as to the number of DNS queries per message should have some
basis. : > My question, I thought, was clear. What is the basis of
this limit in terms of DNS queries per message? This is expressed
within the draft. I simply asked what the basis of this limit was.
The next related question, of course, is what is the basis of the 10
second recommended timeout for the total of these 20 DNS queries?
This is referencing information added to the core document
5.4 Recursion Limitations
Evaluation of many of the mechanisms in section 5.1 will require
additional DNS lookups. To avoid infinite recursion, and to avoid
certain denial of service attacks, an MTA or other processor SHOULD
limit the total number of DNS lookups that it is willing to perform
in the course of a single authentication. Such a limit SHOULD allow
for at least 20 lookups. If such a limit is exceeded, the result of
authentication MUST be "hardError".
MTAs or other processors MAY also impose a limit on the maximum
amount of elapsed time to perform an authentication. Such a limit
SHOULD allow at least 10 seconds. If such a limit is exceeded, the
result of authentication SHOULD be "transientError".
Domains publishing records SHOULD keep the number of DNS lookups to
less than 20. Domains publishing records that are intended for use
as the target of "indirect" elements SHOULD keep the number of DNS
lookups to less than 10.
Please notice, these limits are expressed only as SHOULD. I know a
particular vendor was hoping to add to this and may explain why these
limits are so large. : 0
I assume these numbers were not pulled from someone's hat. ; >
Using these limits, how does the nature of the traffic change? These
DNS queries will be comprised of Ethernet (26), IPv4 (20), and UDP (8)
for about 54 bytes of transport overhead. Add to this the size of TXT
record with about another 56 bytes response overhead and the size of the
name referenced. Add to this the SOA field and Additional Data field. I
will assume an average DNS response to be 350 bytes (out of a 576 byte
packet limit) and about 100 bytes for the query. (The 512 byte DNS limit
allows for transport overhead.) So for the TCP traffic of about 400
kbytes, 900 kbytes is used for the DNS queries. This recommended limit
changes the traffic ratio of UDP/TCP traffic from 0.007 % to 225.0 % at
the 666.0 % UDP/TCP packet ratio.
Such a change to the amount of UDP traffic will impact the amount of
packet loss, as UDP does not have congestion avoidance. I looked at a
5% packet loss to make a rough estimate of what this could mean with
respect to the timeout on these series of DNS queries being produced for
each message. With 20 DNS queries (40 packets) and a 5% packet loss and
a 5 second DNS query retry period, the 10 second recommended timeout
forces a 450 error at the end of the data phase for first message of 4
kbytes (although completely received in this storm of DNS traffic).
This message will be discarded and require a retransmission at some
later point as well as stopping the remaining messages.
A few points added to this was that a common technique used by spammers
was employing a random (often several) sub-domains accessing a
wildcarded record to obfuscate their identity as a ploy to thwart
filtering. This means the DNS cache will not contain this record. This
is an important consideration as with the Sender-ID, all traffic is
received before being discarded and a high percentage of this will be
spam. The behavior of many spammers is not to remember the message
rejected with an error or to wait any period of time before retrying. A
different message identity will appear, still not found in the cache,
and where the rejection process does not lessen the traffic load.
As legitimate data attempts to slog through this blizzard of UDP, they
will be dropped rather often and forced to retry as the per DNS query
set allotment ensures a reduction of connection integrity compared to
TCP. A basis for these numbers before making a serious assessment would
be expected of anyone asked to take on such a difficult endeavor. The
impression I have is these numbers were simply guesses and do not
justify such examination until there is some expectation these will not
change again and again.