Selective DNS Caching/Forwarding

MaestroRC asks: "I've been looking around online, and I have found several people wanting to do the same thing, but no one seems to have figured it out yet. What I am wanting to do (and before you go further, understand this is for work, i.e.: no innocent people will be harmed in the implementation) is to set up a name server that selectively forwards queries. For example, I would like to create a list of acceptable domains (less than 20) using wildcards such as *.google.com, that the name server will forward a query on to and reply to normally. For anything not in the list, I want it to reply NXDOMAIN or some such. I've looked at BIND, and there doesn't appear to be a way to do what I'm wanting; it can either have recursion on or off, and any specific zones of type forward still do not forward if it is off. The solution doesn't have to be pretty, and it can just be a simple DNS proxy, but I'm not adept at coding, so it needs to be installable by a regular sysadmin on Linux. Has anyone heard of something like this?"

Comments

Can be done with W2K3 DNS Server...

[ErMaC]

I'm not a Linux person, but I know a way you could do this with Windows Server 2003 DNS Server...
It has an option called "conditional forwarding" where you can forward anything ending with "example.com" to the DNS server x.x.x.x - just set up the DNS server and then set conditional forwarding of the domains you want to allow to a real DNS server.
We use this for setting up trusts between separate Active Directories but it could conceivably be used for this purpose as well.

Re:Can be done with W2K3 DNS Server...

[Phormion]

BIND also provides exactly this through forward zones, nothing spectacular here.

BIND can kind of do what you want. So can perl.

[Anonymous Coward]

I tried to do something similar to this once. In BIND, you can define a zone called "." In there, add a record "* IN A 127.0.0.1" (this isn't really NXDOMAIN, but it does prevent people from getting places :)). Then create forward zones for each domain you want to resolve properly.

There are [at least] 2 problems with this. 1) You have to keep the forwarders up to date for the zones you list. 2) If google decides to make www.google.com a CNAME for www.google.akamai.net (OK, Google probably wouldn't do this, but Apple, Microsoft, etc do) and you don't have that other domain defined in a forward zone, it ain't gonna work.

I also wrote a perl script to do what you want. It's really quite simple with a couple modules from CPAN. But, it's not suitable for any sort of remotely demanding DNS environment. If it's just for your kid's computer ... then it'll probably suffice.

Re:djbdns?

[r_naked]

My solution is similar but with bind.

Edit the root.hints file and replace the root servers with 127.0.0.1. Then just list forwards for the domains you want to a nameserver that is capable of resolving them. Unfortunately with this method you will get a timeout on any domain that you don't have a forward for, not an NXDOMAIN.

Re:Straight to the packet filtering?

[arivanov]

No need to drop.

Selectively change the destination name server using DNAT and send it to a fake name server. I use a similar hack for other less nefarious purposes. It used to be (before wireless hotspot ops got inventive) a very good way of supplying roaming clients with a well behaved and working DNS. You set the nameservers in the client to two well known, well behaved nameservers so it works with the VPN down. You also set the firewall/VPN gw to hijack all traffic to these well known nameservers coming down the VPN and direct it to your nameservers. As a result the clients consistently get good DNS after the VPN gets brought up and you do not get any silly split DNS scenarios.

Alternatively, besides master and slave there are several less known zone types. You should be able to achieve results similar to what you are looking for by using forward or stub type zones. This will give you a "bind-only" solution without playing silly firewall games.

Re:BIND can kind of do what you want. So can perl.

[Bargearse]

So set it to something other than 127.0.0.1 -- 127.0.0.2 for example :)

Even better set it to the IP of a webserver that throws up an information page explaining why you can't browse to the site you're trying to visit, and who to contact if you think it's a mistake/problem.

Of course that won't help anything other than web traffic, but I'm guessing that's the main point of this exercise.

Re:BIND can kind of do what you want. So can perl.

[dmayle]

Forget the whole 127.0.0.1 game playing, this is VERY simple with BIND

Simply create zones for the domains you want to forward on to be looked up as type forward and disable the "." zone

And since when did Ask Slashdot become an IT troubleshooting forum?

Re:It's called Websense, maybe Squid

[cr0sh]

Why is it annoying? Aside from the fact that you have to update a hosts file (ugh), you should just have a cron job (or equiv) on each of those computers to pull down the new hosts file and install it, at some "low usage" time (depending on where the computers are located geographically/timezone-wise). An even better solution would be: if those machine are individual workstations, set up a "host file server" at each group of computers location - and have them pull from their local "cache" copy on that server. Then, each of the servers grabs from the central hosts file publishing server at low usage times (of course, it is likely that those 100+ machines are the servers for 100+ locations, in which case the first solution is more appropriate). Another possibility would be similar, but instead it would be distributed: first, set up a periodic cron task (say every 12 hours) to keep the time on each server equal to the time on one of a randomly picked server in a pool within each time zone (if they are distributed across time zones - if not, it becomes simple). Have a seperate cron job that runs every hour or so and randomly picks on servers in its own time zone to check and see if the time and checksum on that servers hosts file is the same as the calling server's host file. If the time/checksum is different, have it grab the hosts file from there. If a server has to ask another server outside of the time zone (maybe one can be dedicated to do this?), then hours would have to be added/subtracted depending on what timezone it is in - but overall, you should be able to set things up so it can compare the times, and make sure that the times (+/- for timezones) match. Then, you just publish on your one machine, and all of the other machines (over a few hours) automagically via a distributed system, update their hosts files, because it changed on one machine and the neighbors noticed - let's call this the "keeping up with the Jones'" method of distributed file propagation...