<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 11/01/14 18:10, Paul Vixie wrote:<br>
</div>
<blockquote cite="mid:54556867.8000006@redbarn.org" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:5455455D.6050706@lcrcomputer.net" type="cite">
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr">
<div style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px">
<div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="lyle@lcrcomputer.net" photoname="Lyle
Giese" src="cid:part1.07030107.02000105@lcrcomputer.net"
name="compose-unknown-contact.jpg" width="25px"
height="25px"></div>
<div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true"
href="mailto:lyle@lcrcomputer.net" style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Lyle Giese</a></div>
<div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">Saturday,
November 01, 2014 1:41 PM</span></font></div>
</div>
</div>
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div class="moz-cite-prefix">On 11/01/14 12:21, Paul Vixie
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:54551690.4000701@redbarn.org">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<br>
<blockquote type="cite"
cite="mid:20141101154923.GA14152@nic.fr" style="border:
0px none;">
<div class="__pbConvHr" style="margin:30px 25px 10px
25px;">
<div style="display:table;width:100%;border-top:1px
solid #EDEEF0;padding-top:5px">
<div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
name="compose-unknown-contact.jpg"
src="cid:part1.07030107.02000105@lcrcomputer.net"
photoname="Stephane Bortzmeyer"
photoaddress="bortzmeyer@nic.fr" width="25px"
height="25px"></div>
<div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;" href="mailto:bortzmeyer@nic.fr"
moz-do-not-send="true">Stephane Bortzmeyer</a></div>
<div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">Saturday,
November 01, 2014 8:49 AM</span></font></div>
</div>
</div>
<div class="__pbConvBody" __pbrmquotes="true"
style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;">
<pre wrap="">On Sat, Nov 01, 2014 at 10:10:07AM -0500,
Lyle Giese <a href="mailto:lyle@lcrcomputer.net" class="moz-txt-link-rfc2396E" moz-do-not-send="true"><lyle@lcrcomputer.net></a> wrote
a message of 23 lines which said:
</pre>
</div>
</blockquote>
</blockquote>
<blockquote type="cite"
cite="mid:54551690.4000701@redbarn.org">
<blockquote type="cite"
cite="mid:20141101154923.GA14152@nic.fr" style="border:
0px none;">
<div class="__pbConvBody" __pbrmquotes="true"
style="color:#888888;margin-left:24px;margin-right:24px;">
<blockquote type="cite">
<pre wrap="">Oct 31 04:10:52 linux1 named[2899]: client
2607:f8b0:4001:c07::151#61651: no more TCP clients: quota reached
</pre>
</blockquote>
<pre wrap=""><!---->
If you wish to handle this amount of requests, you can raise
the tcp-clients parameter.
options { tcp-clients 300; };
</pre>
</div>
</blockquote>
<br>
there is no number you can insert here, including the
largest number your OS can support, such as 2^16, which will
make your tcp listener robust in the face of attacks. even
if both sides of a non-attack flow (so, client and server)
fully implemented the recommendations of <a
href="https://tools.ietf.org/html/draft-dickinson-dnsop-5966-bis-00"
class="moz-txt-link-rfc2396E" moz-do-not-send="true"><https://tools.ietf.org/html/draft-dickinson-dnsop-5966-bis-00></a>,
intentional tcp state exhaustion will remain a viable attack
vector.<br>
<br>
</blockquote>
While interesting and I learn from discussions like this, it
doesn't answer my original question. When Named goes into
SLIP via UDP queries, the other party should(and did) retry
using TCP. What happens when we throttle via TCP, like
above? Does NAMED just drop the connection? Or does it send
back a meaningful error message or status of some sort?<br>
</div>
</blockquote>
<br>
first, SLIP isn't a mode, it's a ratio. "SLIP X;" means every X'th
drop will be turned into a TC=1 response. so, higher values for X
result in fewer TC=1 responses (since 1/N > 1/M for all M >
N). from your syslogs, you would benefit from more drops and fewer
slips, which is why i advised you to increase your slips to at
least 5, and be willing to consider 8 or 10 if the problem
persists.<br>
<br>
second, you're not throttling via TCP, you're doing two
related-but-not-that things. you are encouraging TCP by
deliberately mixing slip frames (TC=1) in with your rate-related
intentional drops. second, you're seeing more TCP traffic than you
have state quota for. these are probably related, but need not be
related. if i were attacking you i would make sure you had lots of
TCP sessions open at the same time that i blasted you with UDP in
a way that forced you to start sending TC=1 responses. all i have
to do is ask google dns over and over for answers it won't have in
cache and that won't fit in UDP responses. (you can only stop me
by ensuring that IP fragmentation and therefore EDNS are working
to your authority servers, which is often not under your control.
BWA HA HA HA!) i can also just open a lot of TCP sessions from
other parts of the internet, since it's unlikely that you have
per-client-ip flow quotas, and i can just ask lots of questions,
returning ACK's very slowly, tar-pit style. i'll never be idle,
and if you RST or FIN me i'll just call back.<br>
<br>
to precisely answer your question, in the log snippet you showed
(no more TCP clients: quota reached) there is no meaningful error
message or status to send. you could send SERVFAIL but it's more
likely you're just RST'ing. neither one is meaningful to the far
end. you have no choices available to you which will be meaningful
to the far end. (as i said, BWA HA HA HA).<br>
<br>
happy belated all-hallows eve, everybody.<br>
<br>
<div class="moz-signature">-- <br>
Paul Vixie<br>
</div>
</blockquote>
I don't think I showed the logs from Named that show RRL had kicked
in (rate limit slip NXDOMAIN response to 2607:f8b0:4001:c00::/56)
and also for a google IPv4 address during this same time frame.<br>
<br>
The response to the rate limit slip, I understand. TC=1 is telling
the other side to try again using TCP.<br>
<br>
Now on the TCP side, I am seeing 'no more TCP clients: quota
reached'. I am still not clear on what the other side is told or
what it thinks is going on at this point. My thought process/logic
is that a TCP Reset should be handled above the application layer
and that an application could not create/generate that. Of course,
I can be wrong on this point and would welcome corrections.<br>
<br>
Now that I have written this, I suspose it's within reason that an
application can tell the upper layers, I am to busy to handle that
request, drop the TCP session and those layers use the RST function
to accomplish that.<br>
<br>
But it sounds more and more like an DoS attempt against my
authoritative servers by exhausting TCP resources. And they were
utilizing Google's servers to assist in that process. Not at all
sure what the heck they would be trying to accomplish hitting up my
servers. And I would assume that it would take a lot more to
accomplish a DoS attack against Google's servers this way! But it's
an excellent way for the attackers to hide their identity from me as
I see only Google's IP addresses in the requests.<br>
<br>
Lyle Giese<br>
LCR Computer Services, Inc.<br>
<br>
</body>
</html>