When I first installed SK2 I was getting a large number of false positives from the RBL and Trackback referrer plugins. At the time I tracked it down to weird DNS issues and disabled them as I was at work and didn’t have time to look into it.
Since then I have investigated, discovered and fixed the problem.
Symptoms:
- All the SK2 plugins that use DNS in one form or another give positive karma to comments / trackbacks that are spam.
- When you look at the karma report the IP address returned by the RBL looks familiar – Its the IP address of your web server!
- Trackback checks find links to your site in the referrer but a manual check finds that the site doesn’t exist
Looking at what was going on, I was a tad confused – it seemed that the dns server was returning the local ip address if it couldn’t get a result – very strange – to start with I thought that maybe the dns proxy I was using was screwed so I disabled that but the problem still existed. Dragging out my favourite network analyser, tethereal, I watched what was going on when the dns lookups occurred and noticed the following:
- The first dns request looked ok and got a failed response.
- The second dns request had the localdomain name tacked on the end and got an successful response.
This got me thinking and I went and looked at the dns setup at my host – looking through the zone file I found and interesting entry that I didn’t remember adding:
* IN A 217.155.152.65
This catch-all dns entry meant that any lookup under ftwr.co.uk was going to resolve to the web servers IP address!
There are a number of ways to fix this issue, which in order of preference are:
- Fix the code so that all dns lookups are specified with a “.” on the end, this means that the resolving library will not try adding the local domain on the end (I believe so anyway).
- Remove the catch-all entry from your dns – whether or not you want to do this or not depends on why its there in the first place and whether you have control over it.
Yes, I know I have a catchall. As I tend to add/remove vhosts pretty often, it allows me to do so without messing with the DNS records.
I’m in favour of solution #1 🙂
Solution #1 is the one I’d go for too!
#2 is a useful stopgap if you can’t/don’t know how to fix the code though! 😛
Just thought I’d mention for future archiving reference: Solution #1 was adopted and the code, as of 2.0b1, works fine now.
Cheers Peter for finding the problem…