自从实验室的服务器升级为Winodws Server 2008，其DNS服务功能就总是间或出现问题。具体表现为，实验室旗下的域名无法解析。但令人百思不得其解的是，这个问题并不一直存在，而是大约每天出现一两回，每回几十分钟到一个小时不等。每次故障之后，总是在没有进行任何设置上的修改的条件下自动恢复正常。
为了解这个问题的实质，关掉了服务器的防火墙以及其他一切与IP限制有关的设置，但无效。使用nslookup对DNS服务器进行诊断，也只能在不能解析时得出request timeout的错误，无进一步信息。就这样一直郁闷了很久，不得不忍受实验室网站间歇不能访问的痛苦（因为一台IIS上承载了多个网站，都是使用同一个IP地址但通过不同的主机头来区分的），有些时候实验室的邮件服务也会发生延迟。
某天，有位网友建议我同时在客户端和服务器端抓数据包，以此来彻底地查清到底哪里出现了问题。似乎这是最好的办法了。于是便同时在客户端和服务器上安装了Windows Network Monitor。对DNS协议中查询内容包含实验室域名的数据包进行抓取后，发现了一个非常奇怪的问题。当客户端使用实验室的服务器作为首选DNS服务器时（所有VPN客户默认都是这样），查询实验室旗下的域名竟然会导致：(1)本身就负责这个域的实验室服务器向学校的域名服务器发送解析请求；(2)学校的域名服务器发现所请求的域名由实验室服务器负责，便又将该请求发回实验室服务器；(3)此时，实验室服务器才有可能将正确的解析结果发回客户端。
可以看出，实验室服务器一开始并不知道自己便是实验室域名的负责者，反而向外部寻求帮助，形成了一个回环。而一旦域名刷新期学校的域名服务器未及时获取到实验室域名服务器的地址，解析便会在第(1)步与第(2)步之间失败！这便是导致DNS服务器间或出现问题的基本原因。
知道了问题的核心以后，解决起来就很方便了。在服务器网络连接的属性里，把不知道什么时候设置的首选DNS服务器改回127.0.0.1，实验室服务器在收到DNS请求以后不管如何都会先请求自己的DNS服务尝试解析，实验室旗下的域名便不会转发给外面的服务器，回环不再存在，这些诡异的问题便彻底解决了！