inkblot wrote:
Code:
iptables -t nat -A POSTROUTING -d sitefinder-idn.verisign.com -j DNAT --to $SERVER_OF_YOUR_CHOICE
Some ISPs are already doing this. So now how can you tell if you mistyped the url, or the site is down. This problem applies to all dns-enabled services.
Email is a Hugh one (at least for me)..
- A user mistypes a domain in an email
- the mail server then finds the above A record for the non-existent domain (or, what should be nxdomain)
- and thus tries delivering mail to the above site (sitefinder-idn.verisign.com for now)
- it cannot connect to the site because it's being dos'd, your isp is blocking it, you're blocking it, for whatever reason it just can't contacted it
- it then queues the message for later delivery instead of bouncing back to the user right away saying that the domain does not exist
- it now takes up to a week for the user to realize they simply mistyped the email address
..unless you mail server can actually connect to the ip they are providing, which is currently running
Code:
#!/bin/sh
echo "220 snubby2-wcwest Snubby Mail Rejector Daemon v1.3 ready"
read
echo "250 OK"
read FROM
echo $FROM >> /var/log/suckers
echo "250 OK"
read
echo "550 User domain does not exist."
read
echo "250 OK"
read
echo "221 snubby2-wcwest Snubby Mail Rejector Daemon v1.3 closing transmission channel
Connection closed by foreign host."
exit
(hope I dont get sued for sharing their source!) then your message will get bounced right away (well, if the above actually works with your mail server) and VeriSign makes off with your enduser's email addresses! and if they feel like it, the message body as well.
It's easy to see how the above would cause rare problems for your endusers. Now, instead of it being a legit message going to a non-existing domain, image it being spam that your server is trying to bounce back to a non-existent domain (common with spam). Normally it'd "double-bounce" it (a bounced bounce) and toss the message, but now it takes a week or so for this double-bounce to happen. All of these message waiting to double-bounce are sitting in your queue, this could be hundreds, it could be tens of thousands depending on how much traffic you get.
The good people who make
qmail-ldap released
patches for qmail that handle this by comparing the returned address with the address that is returned from a wildcard lookup of the same tld.
There is a
patch for dnscache. You provide it a list of ips that it should ignore. The problem is that this list can change. You could of course write a script to run once an hour and update this list. The positive is that it doesn't generate the extra lookups that the bind patch will (at least that's my understanding).
This is my problem with VeriSign, they didn't just create a "site-finder" to help lost users, in practice they changed how dns works, thus forcing
everyone else to work around it.
Hehe, sorry this turned out to be a rant.
Kenny
FAQ
Search
Members
Register
Login [ Anonymous ]
