http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5768
------- Additional Comments From [EMAIL PROTECTED] 2008-01-08 02:03 -------
more details on the symptoms; this may be useful if it happens again with
another BL, etc.:
'The situation applies to at least 2 recursive DNS servers at $WORK, that query
on
behalf of just a handful of customers making queries into the zone
(and I see them querying reversed IP addresses instead of domain names, yikes!
that'll be addressed).
This does not happen from my personal systems, and makes me wonder:
- do you have a DDoS-protection system gone-very-bad running over there?
Problem: our recursive server(s) are seemingly flooding your servers with a
GREAT
amplification factor for customer queries, via both UDP and TCP queries.
Reason:
Your *single( nameserver for the zone (69.59.189.68) is returning "TC" (reply
truncated)
for every UDP-based query sent from us, amplified by 2 because
a.support-intelligence.net
and b.support-intelligence.net are the same IP, but when our resolvers fall back
to TCP
(as it is just and proper when encountering a TC response), your server is
refusing
connections on that port, creating a SERVFAIL situation.
That "SERVFAIL" situation is NOT NEGATIVE-CACHEABLE (unlike an NXDOMAIN *answer*
actually
provided by your servers), hence resolvers will continue to hammer your server
for the same thing - I've seen it retry your servers 20+ times for a single
query!
I've reproduced something interesting from 2 of my personal system(s):
$ dig +tcp @69.59.189.68
bounces.amazon.com.dob.sibl.support-intelligence.net any
; <<>> DiG 9.2.4 <<>> +tcp @69.59.189.68
bounces.amazon.com.dob.sibl.support-intelligence.net any
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20417
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;bounces.amazon.com.dob.sibl.support-intelligence.net. IN ANY
;; AUTHORITY SECTION:
dob.sibl.support-intelligence.net. 900 IN SOA a.support-intelligence.net.
zone.support-intelligence.com. 2006122100 900 900 604800 900
;; Query time: 313 msec
;; SERVER: 69.59.189.68#53(69.59.189.68)
;; WHEN: Mon Jan 7 12:55:18 2008
;; MSG SIZE rcvd: 137
Followed immediately by:
$ dig +tcp @69.59.189.68
bounces.amazon.com.dob.sibl.support-intelligence.net any
;; Connection to 69.59.189.68#53(69.59.189.68) for
bounces.amazon.com.dob.sibl.support-intelligence.net failed: connection refused.
$
E.g.: This returned a proper NXDOMAIN back for the FIRST query only - every
subsequent
53/tcp connection is refused, suggesting this is some sort of very misguided
DDoS defense.
I can still query via UDP afterwards, but maybe my systems are now well on the
way
of getting dropped into the same "deny all service" pool as the resolvers at
$WORK.
Clearly, this is not how you want to control a DDoS situation and make querying
clients go away, for any reason.
Thank you.'
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
