He did indeed - I was as I said chasing a ghost, I'd already spotted it - BUT
I only put the URL into an alias because it was getting reported by 'something', at the time I didn't have 'log_queries' enabled so I didn't know where from. I don't tolerate 'unknown' behaviour within my network so my first response was to add the URL as an entry in a block table - I have a bad boy table that I use to block 'bad behaviour' sources and targets - spammers that aren't in another blocklist, multiple chinese sites, people that try to log into my mailserver multiple times with multiple users from same IP etc etc.
When I saw the constant 'dns rebinding' the first thing I did was to put it into this 'block table' - while I searched for the culprit, the culprit has not been found on my local LAN despite 18 hours of packet capturing, I am still running wireshark with the url as a filter - but on the DNS / DHCP server that I created where it isn't such a pain to 'start capture, stop capture, download - - yada yada'.
I also completely rebuilt pFSense in case it had been compromised, and so far this URL doesn't appear anywhere so I have kind of fixed the issue but not in the preferred manner, it would have been nice to know who was originating the request that prompted me to 'block it' in the first place.
I would expect that where a URL does resolve to a private IP that the bogon filters should deal with it, where an IP generates such an event the system shouldn't keep re-trying but should put it into some 'holding place' for investigation - and should provide sufficient information to give the investigation a place to start - i.e. source Network, source IP, source MAC, date, time.
Every one gets retarded about stuff getting in - 80% of security breaches are caused 'internally' by users - so events noted by things trying to get out must carry even more weight / priority.
