Wandering Thoughts archives

2006-01-15

How not to set up your DNS (part 8)

This is one of those amusingly creative mistakes to see in action:

  • microsoftglobal.com lists as nameservers ns1.one-dom4.com and ns2.one-dom4.com.
  • both respond with errors if they are sent queries that allow recursion.
  • sent queries marked non-recursive, both answer all DNS queries for the domain with no actual data, but with an 'additional authority' section that says they're the nameservers for the domain.

Nameservers normally answer a query for a domain they don't serve with a referral to a higher zone, such 'com.' or '.', the root zone. That the one-dom4.com nameservers are answering queries with referrals to themselves means that in some sense they believe they handle the domain; it's just that they don't actually have any data for it.

Returning explicit errors for recursive queries is also unusual nameserver behavior; normally, a nameserver that disallows recursion on queries effectively strips the 'recursion allowed' bit off before it processes things, so you get referrals to higher level zones.

(Mind you, judging from their WHOIS information we may not be missing much by not being able to accept email from 'microsoftpromo@microsoftglobal.com'.)

sysadmin/HowNotToDoDNSVIII written at 11:43:43; Add Comment

Weekly spam summary on January 14th, 2006

This week we received 12,785 email messages from 208 different IP addresses. Our SMTP server handled 17,958 sessions from 984 different IP addresses. Session volume is dramatically down from the levels of last week.

Connection volume is also down: 122,600 connections from at least 44,760 different IP addresses. However, we hit a highwater mark of 50 connections being processed at once on Tuesday, so we have had some significant traffic bursts. Broken down by day:

Day Connections different IPs
Sunday 22,540 +8,110
Monday 17,460 +6,920
Tuesday 21,190 +7,770
Wednesday 15,490 +5,730
Thursday 17,130 +6,220
Friday 14,600 +5,230
Saturday 14,200 +4,770

Kernel level packet filtering top ten:

Host/Mask           Packets   Bytes [Why]
202.157.144.3         16976   1019K [rdns]
66.36.243.74           8108    486K [trap]
62.34.238.215          6576    342K [dyn]
205.178.145.65         5664    324K
212.216.176.0/24       5483    274K
196.21.136.1           4981    239K [rdns]
218.0.0.0/11           4606    263K
66.62.47.57            3834    230K [sbl]
213.29.7.173           3306    198K
202.172.226.15         3093    157K [rdns]

(Key: dyn for dynamic IP/dialup machines, rdns for having bad reverse DNS, sbl for being listed in the SBL, trap for hitting spamtrap addresses and then keeping trying to send us mail with the same MAIL FROM.)

These are down from last week overall, and there's no one blocked for being a source of bad HELO names, for the first time in a while.

  • 205.178.145.65 got blocked for reasons covered in HowNotToDoDNSVII.
  • 213.29.7.173 is a centrum.cz machine, and we don't talk to them due to previously being spammed by them.
  • 202.157.144.3 and 62.34.238.215 reappear from last week.
  • 66.62.47.57 reappears from earlier, still listed in SBL34212. Maybe they'll give up sometime, but I'm not going to count on it.

Connection time rejection stats:

  24153 total
  13837 dynamic IP
   6700 bad or no reverse DNS
   2421 class bl-cbl
    248 class bl-sbl
    189 class bl-sdul
    158 class bl-dsbl
    112 class bl-spews
     90 class bl-ordb
     44 class bl-njabl
      7 class bl-opm

Nothing particularly stands out, although 10 of the top 30 most connecting IPs were on the CBL this time around.

Other stats:

what # this week (distinct IPs) # last week (distinct IPs)
Bad HELOs 880 97 8120 406
Bad bounces 308 83 4349 1629

This week is clearly a quiet one for backscatter: these numbers are a major drop from last week; in fact, they're pretty close to the casual nuisance level.

Hotmail spam volume is up from last week:

  • one email accepted, probably spam.
  • 371 messages rejected because they came from non-Hotmail email addresses.
  • 87 messages sent to our spamtraps.
  • 12 messages refused because their sender addresses had already hit our spamtraps.
  • 4 messages refused due to their origin IP address (two for being in the SBL, one for being in the CBL, and one for being in the XBL).

Hotmail continues to fail to control their major spam problem.

spam/SpamSummary-2006-01-14 written at 01:49:04; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.