another foible in maintaining dodgy dns for netreg
One of my projects here at UVM is that I manage NetReg at UVM, which provides network registration for the dormitories on campus. Basically, the NetReg server also provides DHCP, but it only does so to known addresses. If it doesn't recognize you, you get an address that's in a restricted network that can't reach very many services. If you try to access a website that's not on the limited list, you get bounced to a NetReg page which asks for your UVM NetID, does a quick Nessus scan of your computer, and if everything looks OK it lets you on the network.
Part of NetReg is the "dodgy" DNS, which in general forwards you to the NetReg server no matter what URL you request in your browser, with certain exceptions. We want to allow unregistered users (mostly students) to be able to access webmail, the software downloads site, student information systems, and online learning at UVM. We also want them to be able to self-service, to some extent - we want Windows Update, Apple Software Update and the like to work, so that if users aren't let on because they have some nasty security hole, they aren't completely stuck.
That's a little tricky, though. In the past, I have been able to run one instance of ISC BIND which both did forwarding for allowed domains (www.uvm.edu, www.microsoft.com, www.apple.com &c) while for everything else it returned an A record pointing to the NetReg server.
Through various config file hacks, I was able to get one instance to do this. But with every version of BIND that got installed on the server, it would break things in the .com and .net domains. Probably because other people considered this "feature" a "bug". I had an entry in the "root" authoritative zone file that looked like this:
*. 86400 IN A 10.242.101.109
That would recurse down (up, if you prefer) to the higher domains (.us, .org, slashdot.org) that didn't have any other authority data defined on the name server. The problem was, it wouldn't recurse down to domains that had even one domain defined (microsoft.com, for example) so if someone searched for www.weatherbug.com, they'd get "unknown host". Not cool, since we would like those queries to go to the NetReg server. A user could run around in circles for hours thinking their network connection is broken when actually they are just on the unregistered network.
So, I've had to create a SECOND instance of BIND on the same server, which I call the "dumber" instance, running on an alternate port, which is authoritative for EVERYTHING and has just that one root "*." entry.
The first instance answers to the normal port (53) and is not authoritative for anything, but for the domains I want supported, I have configured forward-only zones which forward to "real" DNS servers which return the normal public addresses. Everything else is forwarded to the "dumber" instance, which thinks it's authoritative for everything and always returns the address of the NetReg server.
Hopefully this configuration won't break every time I upgrade BIND.
A good reference for how this is done for windows update is here. The user in question actually has two separate servers (on different platforms!) to support the dodgy DNS - as I said before, I use alternate ports to set up a separate instance of BIND on the same server.