On 09/09/11 20:08, ropers wrote: > On 9 September 2011 08:54, Holger Glaess <gla...@glaessixs.de> wrote: >> hi >> >> i wrote a perl daemon to handle all these situations. >> >> he resolv the servername and add or delete the ip(s) to an spezific >> table. >> >> maybe it's time to work on a package for ports. >> >> holger > > Maybe I'm terribly confused (so bear with me), but isn't the trouble > with these round-robin DNS CDN type of situations that most near any A > record resolution request is likely to return a different IP address > than before? So given that, how would updating your pf.conf (table) > with a given IP (even a few given IPs) do any good if you're not also > running a proxy server or DNS server? > > I mean, wouldn't this just cause your Perl daemon to dutifully update > a table for, say, hostname.tld to IP w.x.y.z, only to have the next > client just moments later get a response of IP a.b.c.d from the remote > DNS server? Which at that point in time wouldn't be covered by your PF > table/rules at all? > > Am I terribly confused? What am I missing?
I used to work at a company where we had a firewall that permitted DNS names in the filtering rules. MAN did we have some fun and excitement caused by that. Once in a while, someone in the company would get the "This page has been blocked" message when going to google.com...which was clearly NOT a place we were trying to block. But very, very rarely, and only individual people...not the entire company. And usually not at home office where one of us could get up and take a look at the problem. Took quite some time before it happened to someone where we could investigate hands-on. Turned out that someone had decided to block the Google Talk instant messenger service...and turns out that Google does what several big companies do -- has huge farms of servers, with DNS direction to any of them, then name-based and service-based direction beyond that. So, the google talk block ended up being mostly ineffective, but once in a while, it DID block www.google.com (and gmail and ...) dig www.disney.com dig www.espn.com discovered this pair when explaining how the Internet worked to a high school class probably about six or seven years ago. "Give me a domain name" "espn.com!" "ok, let's find the IP address" "X.X.X.x" "ok, now punch that into your browser's URL box, hit enter and what do you get?" "Disney!" "um. ok, Wasn't planning on covering this topic, but ..." In short... dns to address blocking is not the right way to do this. I have found DNS mangling at the dns server is much more effective. There are a number of theoretical problems with this, but in Real Life, it works pretty well, and a lot easier to set up than the technically superior solutions (which seem to have a higher real-life "issue" rate). Nick.
