Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have 70-80 kiosk-type machines with no DNS. We do this so the users of these machines cannot access internet resources not listed in the hosts file. Of course they can access things by IP address, but thats not a problem.

We will be moving to AD soon and Im not sure how to handle these machines. A few thoughts:

  1. Configure a BIND9 DNS server just for them and have it give out the proper records so the clients can find the domain controllers. Not sure if this will be problematic.

  2. Disable recursion and forwarding on the DNS server. Have the clients that need to resolve internet addresses use two DNS server. One AD and a secondary that is a caching DNS server not doing AD. (not sure if this will work, and it seems that having a non-AD DNS is a bad idea).

  3. Get one DNS server on the domain to do local only and another to do internet. I dont see how this is possible. I can disable recursion for the domain but not for individual servers.

Im leaning towards solution 1 as I think thats the only one that will work. Im not planning on doing DDNS, just putting in the proper SRV records. Im assuming this will work. Any other ideas?

share|improve this question

6 Answers 6

up vote 0 down vote accepted

Option 1 is a viable approach. XP Domain members will work fine with Bind provided you populate all of the correct SRV records. Assuming you are going to use AD's own integrated DNS for the rest of your domain it shouldn't be that hard to manage however you can also do it with a non integrated MS DNS (not installed on a DC) rather than Bind but you will have to disable root hints [ as per this ].

Option 2 wont work. Secondary DNS servers on an XP client will only get used if there is no response from the first DNS, if the first one responds with a failure that still counts as a response.

Option 3 is covered in my response to 1.

As a general comment using a non MS DNS is viable in a domain but it's almost always a lot more work than it's worth (IMO).

share|improve this answer
    
I havent tested using MS DNS from a non-DC. Maybe that'll be the way to go, but I still need to manually put in all the SRV records like I would do in BIND, correct? –  drzaius2000 Feb 19 '10 at 14:59

AD requires DNS (there is no alternative option) and will work best with an AD-integrated DNS (i.e. MS dynamic DNS). You need to sit back and reconsider how you want to block sites that are not approved for your kiosk machines.

The most obvious solution seems to me to be to just not add the kiosk machines to your AD and continue as you are. You seem to have no problems with it, and to be at least reasonably on top of things, and I don't see any requirement to add them, so why not?

share|improve this answer
    
They need to be domain members. They are currently on NT4. –  drzaius2000 Feb 19 '10 at 14:36

Please don't use BIND in a Windows client environment -- its a pain in the neck, you will break things and have to spend alot of time doing things that are usually just automatic due to AD dynamic DNS. Solving this problem with DNS is using a sledgehammer to hang a painting.

Check out the free Windows SteadyState tool. SteadyState is a free tool that is designed for folks implementing shared computers for libraries, schools and kiosks. You can set all sorts of policies, including restricting all internet access and whitelisting specific websites.

share|improve this answer
    
BIND is actually fairly trivial to implement in a windows environment. –  Frenchie Feb 19 '10 at 1:35
    
Bind is trivial to implement it's after you implement and start using the environment post bind that makes you realize it was a mistake –  Jim B Feb 19 '10 at 2:04
    
Three years of running with 500 clients and we've not yet seen an issue? Admittedly, we only have our DCs allowed to update their records. –  Frenchie Feb 19 '10 at 6:30
    
Implementing isn't rocket science, but maintaining is a real pain. It's also the wrong approach to solve the problem posed in the question. Why would you take an oddball approach to your infrastructure when free, supportable and easy to use tools are available? –  duffbeer703 Feb 19 '10 at 23:20

Here's an idea (as kooky as it may sound) and you'll have to test it to see if it works:

My assumption is that you allow them to go to some web sites based on the fact that you're adding entries to the hosts file. Based on that assumption my idea goes like this:

  1. Set up AD integrated DNS on your DC.

  2. Disable recursion on the DC\DNS server.

  3. Set up conditional forwarders on the DC\DNS server for the domains that you allow the users to go to. For example, for Google set up a conditional forward for google.com to use ns1.google.com, ns2.google.com, etc.

This will allow domains that you "authorize" (by adding conditional forwarders) to be accessed by the users and will block all other external domains. You can find which forwarders to use for each "authorized" domain by running an NS nslookup for each domain.

This seems like the simplest solution to implement. Your internal DNS is uncomplicated, it allows you to use only a single DC\DNS infrastructure instead of trying to manage multiple DNS servers (internal resolution servers and external resolution servers), and keeps the client configuration simple by allowing you to configure each client with the same DNS settings.

share|improve this answer
    
My other set of computers need full DNS for all domains. Im not sure how that will work out. –  drzaius2000 Feb 19 '10 at 14:49

Active directory can do what you require by default. Set your kiosk servers to get their dns from the domain controller. In the domain controller you should have a . domain so it will only send the domain dns entries and not forward anything else. Either leave your specific addresses in the host files on each kiosk or add them as entries on the DC to make you life easier with updating. Point your machines which need full DNS access at the 2nd DC which replicates the domain dns entries but not the other entries.

share|improve this answer
    
"In the domain controller you should have a . domain so it will only send the domain dns entries and not forward anything else" It does recursion to the root servers by default, so it will attempt to resolve them even with forwarders off. I can disable recursion for the entire domain not per server. Perhaps Im missing something here. –  drzaius2000 Feb 19 '10 at 14:44
    
In forward lookup zones create a zone called "." (set this zone to not replicate) and it will not resolve anything not specifically listed (for that server). The DNS server without a "." zone will continue to resolve everything. Because you set replication by zone, they keep all the (AD)domain stuff in sync automatically. –  JamesRyan Feb 19 '10 at 15:26
    
(untick store in AD to stop it from replicating) –  JamesRyan Feb 19 '10 at 15:34
    
Thanks! I'll try that. –  drzaius2000 Feb 19 '10 at 16:10

You could implement a proxy locking them down to a certain whitelist and allowing the other machines unfettered access, I use it myself, speeds up the net for all, frees up the router from processing so many connections and generally improves your admin life.

The logging helps too.. know what your users have been doing, analyse trends in usage/wastage, figure out if any of them have been infected with a web-accessing-trojan.. then you only allow the proxy through the router, denying all other IP's (assuming the kiosk users can't change the IP). Save dosh in bandwidth!

That way, no need to worry about your DNS infrastructure, easier to maintain and document!

If you want to get really funky, squid lets you run simultaneous copies, so you can run one whole proxy just for the kiosks, and another for your clients (with different run-levels and bandwidth allocations etc), configure them via the DHCP server and the whole mess gets sorted automatically!

http://www.squid-cache.org

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.