April 15, 2005
When DNS Goes Bad
The University's DNS servers appeared to have an issue earlier today. Of all services to go, this has to be the worst. Although I can't remember the last time this happened, disruption of work can be very frustrating. The solution: install your local caching DNS server. If you are running Linux, I prefer dnscache, which is part of the lightweight djbdns package. Set it up to forward initial requests to the university DNS servers (129.22.4.3, 129.22.4.1, and 129.22.104.56), set it to bind on 127.0.0.1 (the university computing policy forbids you to run a public DNS server), set it to run at startup, change your /etc/resolv.conf so your first nameserver record points to 127.0.0.1, start it up, and enjoy DNS caching goodness. Now, if I can find a free DNS replicating service...
Trackback
You can ping this entry by using http://blog.case.edu/gps10/mt-tb.cgi/1057 .
Comments
'Twasn't the DNS servers. 'Twas a firewall being installed in the machine room.
I love it when firewalls allow you to ping DNS servers but deny any DNS query packets from passing. Why is there an internal firewall between university computers and the DNS servers anyway? DNS servers are robust. Properly configured, they are pretty immune to attack. What do I know; I'm no server engineer.
Couldn't tell you why it was being put in place. I am not a Network Engineer or Security Engineer. Though, from what I heard, it was being put in front of *all* of the servers in the Crawford server room and not just the DNS boxes.
I have full faith in those engineers and why they did what they did; after all, the current maintainer of GNU/bash is their boss. He's pretty knowledgeable and thorough with these things.