Are you the keymaster. Or how to stop some joker messing up your beautiful network by screwing with client side DNS.

Scenario: You’re a system administrator/network administrator/IT guy (whatever you want to call it) with an excellent setup, and while you sit staring at the blinking lights in the comms room pondering the quintessential meaning of things, or more realistically chatting on IRC (whatever floats your boat) you’re interrupted for the fifteenth time that week by that luser, um user you were forced to give local admin access to. Turns out now they can’t access the intranet or send e-mail.

Upon investigating you find that once again this user has changed the DNS settings on their computer, breaking Active Directory/OpenLDAP/e-mail whatever, despite repeated warnings. They’re operating under the mistaken belief that using the DNS servers provided by OpenDNS, Google DNS or any number of resolvers found here. Will make their Interweb downloads of funny cat pictures faster, you’ve tried chatting and explaining it to the guy, you tried approaching their line manager with no success. Short of beating the user with a hammer you need to find a way to resolve this situation, what do you do? You could block external DNS but that’s only half an answer. If they do it again it will break more connectivity.

Solution: What you need to do is intercept and redirect all DNS requests to a local server, so no matter what the user configures, no matter what dig or nslookup tells them they’re using, your local DNS will handle the queries. If you’re using something based on IPTables then the follow commands should do it, assuming a basic 192.168.1.0/24 network:

iptables -t nat -A PREROUTING -p udp -i br0 --dport 53 -j DNAT --to 192.168.1.1
iptables -t nat -A PREROUTING -p tcp -i br0 --dport 53 -j DNAT --to 192.168.1.1

iptables -t nat -I PREROUTING -p udp -s 192.168.1.0/24 -d ! 192.168.1.0/24 --dport 53 -j DNAT --to 192.168.1.1
iptables -t nat -I PREROUTING -p tcp -s 192.168.1.0/24 -d ! 192.168.1.0/24 --dport 53 -j DNAT --to 192.168.1.1

Of course this depends on the nuances of your setup. Both sets of commands do the same thing but in slightly different ways, I tend to prefer the former set, but again it depends on your configuration. To test simply set a client to use external DNS and try to resolve an internal host, or you could even set a client to use an IP address you know runs no DNS server if you want to be extra sure it’s working. If you happen to use a Cisco device, I’m sure this can be done on them. I haven’t got my lab setup to check the syntax but I believe a transparent proxy or DNS doctoring will handle it depending on the device.

There you have it folks some words of wisdom from your uncle Kris, try not abuse them and say redirect every third to ninth DNS request to kittenwar.com. My final word on this is: Suck in the guts, guys, we’re the Ghostbusters.