几年前第一次接触到活动目录的时候,正是领导要求部署活动目录的时候。虽然当时手头上有几本书,但是时间紧迫没有来得及仔细研究。边看着帮助边运行dcpromo就开始活动目录的部署了,相信不少人和我当年差不多,稀里糊涂的就开始当起了活动目录的管理员。
对于DNS,因为安装会提示自动部署,相信很多人都不会在这方面下很多功夫(包括我原来也是)。我为此付出了不少代价--因为不懂DNS所以遇到DNS的问题不知如何解决。我有保存论坛上感兴趣帖子的习惯(显然直接另存是保存不下来的),我保存有关DNS问题的帖子数量,占各种问题的第三位(我也很吃惊)。
但是论坛上也没有很系统的关于DNS的总结(这毕竟是一个可以写成一本书的很大的方面)。我通过对自己收藏的帖子和参考书的阅读,加上自己经验的总结得出一些操作方面的结论和总结。希望对大家能有所帮助,因为我不擅长DNS(在论坛上我也很少给朋友解决DNS问题),所以我想肯定有我写错的地方,我希望斑竹们能帮忙校正。我的真正目的是通过这篇文章认识到我在DNS方面都存在哪些误解(我还是挺有私心的)。
闲话少说,书归正传。
有过DNS域部署经验的朋友都能感觉到,活动目录的DNS、DHCP和WINS(用的不多了)和NetBios是息息相关的。也是很容易混淆的。所以很麻烦,通常我们开始部署AD的时候是在一个小公司里,大约有几十台电脑的局域网。人员流动不是很频繁,所以的电脑也差不多的天天都开。很少有电脑会换地方,我们全都使用DNS的默认配置就可以很少会出问题。但这样的地方我们不能待一辈子,我们来到一个相对复杂的网络环境时,意识到自己缺乏对DNS的起码常识,怎么办? 为了在遇到难题时能正确表述自己的问题(否则别人想帮你都没办法,除了UP我们更重要的是说清楚自己的问题和听明白高手的意思)那么和我一样从基础开始吧。
什么样的DNS系统是一个比较完美的系统呢?DNS服务器的连续性能提供出色的性能,减少WAN的通信,安全性也必须得到保障。
我们先从概念开始
1.DNS和活动目录关系
DNS定义“命名空间”(名字空间)---微软把例如“contoso.com”的东东叫命名空间,这个空间内的主机储存在一个“区域文件”(zone file)里---主要是一种映射的关系(中学数学就有映射的概念)
活动目录的域(domain)“存储域和域中的对象”,把用户、租计算机帐户记录组注册表的SAM里。---当然域不止这些内容。
DNS和域的结合--完全合格域名(FQDN):例如srv1.contoso.com--说明了srv1主机位于contoso.com这个域里面。
注意:
DNS的结构中,顶级域com.的末尾是有一个句点"."的。DNS解析器是从左到右解析FDQN(看看上面FDQN的例子)的,最后到“.”结束。因为windows的DNS会自动在末尾添加“.”所以我们很容易忘了它的存在,在我们检测DNS(尤其是命令行方式)最好加上末尾的这个"."正因为根域上有这个点,所以我们在林根的DNS上设置转发的时候会发现那个转发器的选现是灰的,不让你设置,因为"."认为自己是根了,没必要转发。所以解决的方法是删掉这个点,才能转发(删掉后就不会灰色可以选择转发了)。
如果没有行政方面的要求你完全可以在域里使用例如devil.coco的域名称,不一定非要.net或者.com.即使父域叫contoso.com,子域也可以叫devil.coco。
当一个企业在做DNS规划时要注意。当企业外部服务(例如网站)需要在internet上注册名称(例如,公司.com)。如果企业内部使用活动目录,那么要使内外部使用不同的名字或者内部的活动目录使用外部名称的一个子域。例如:“contoso.com”,作为企业在internet上的网站,使用www.contoso.com域名。内部的域可以使用contoso.net或者corp.contoso.com作为DNS名。如果不这么做将有可能使内部和外部名称空间出现重叠。客户端登陆域或访问internet都将可能产生问题。尤其当涉及网络地址转换 (NAT) 并且外部 IP 地址处于内部客户端够不到的范围中时就会有麻烦了(了解NAT 的 人应该知道,如果客户端不配置可以正确解析外部地址的DNS是无法访问相关网站的.)。
DNS和活动目录使用各自不同的数据库解析名字。关于这一点我觉得对于实际操作意义不大所以不说了有兴趣的看看上面提到的那个帖子。
2.hosts文件
很多帖子里都有人回复说,看看那个hosts文件有没有问题,或者说修改那个hosts文件里的什么地方(例如屏蔽QQ)。这是为什么?
hosts存在的目的:减少DNS服务器的工作量,如果客户端查找的一个主机名在hosts文件里有记录(说明不久前访问过),那么客户端就不必找DNS服务器了直接就知道了该主机的IP。我们可以用记事本打开hosts文件。找不到?一般在这里C:\WINDOWS\system32\drivers\etc 这里除了hosts还有好几个文件,也能用记事本打开。都是和TCP/IP相关的,详细我就不说了跟DNS关系不大。
TTL(生存时间),DNS记录必须有TTL,Hosts中得缓存超过了ttl就将被删除,否则DNS得改变将无法在hosts文件中体现。
我们需要一个具体的例子:
有天,客户发现srv1.contoso.com主机无法访问了,我们查看DNS表,发现确实没有相关A记录了。我们手动添加了记录,但是客户还是抱怨无法访问该主机――因为客户端的缓存里里,还是认为该主机无法访问。这时我们就必须在客户的电脑上运行ipconfig/ flushdns 来清除缓存信息。是的,服务器也有缓存。服务器清理缓存的命令是dnscmd /clearcache
3.主DNS服务器和辅助名称服务器
这个概念在论坛上也无数次的被提起,我觉得还是有必要说明一下的。照例我不会用很专业的词汇,需要考MCSE的朋友最好不要看我写的东西。
我是这样认为的,DNS服务器把所有资源记录到一个文件中(zone file)。只有“主DNS服务器”能对该文件进行写操作(能修改DNS记录),辅助DNS服务器从主DNS服务器(或者其他辅助DNS服务器)那里获得该文件的拷贝(默认24小时得不到拷贝的话,辅助DNS服务器就将失效)。
除此之外还有一种“仅缓存名称服务器”(caching-only name server),它上面仅保存缓存的查询结果(从辅助DNS服务器那里获得),以便使客户端尽快获得查询信息。
这种机制让人想起NT时代的主域控制器和备份域控制器――当然这是一种脆弱的机制。微软为了能多凑合一些时间,允许任何运行DNS的DC都能被设置为它所在域的主DNS服务器。
4.权威性应答与非权威性应答
按照我的理解,如果DNS服务器在自己的区域文件里找到了客户端需要查询的记录,就会返回一个权威性应答。―――例如客户端要查找srv1. contoso.com主机的IP地址。在contoso.com的DC(也就是DNS服务器)上查找该主机的“A记录”,我们找到了。就把记录内容通过DNS应答的方式发还给客户端,这就是一个权威性应答。――当然实际的查询方式比较复杂远没有我说的这么简单。
此外,如果DNS服务器最近被查找过该主机(可能其他客户端也查找过)记录,就会在缓存里找到记录应答客户端――当然上一种方法快。
如果该DC服务器找不到srv1. contoso.com主机的A记录,就会返回(Record Not Found)应答――同样也是权威性应答
如果接到DNS查询请求的服务器不是contoso.com的DC(Dns服务器),那么有3种方法处理该请求:
首先,查询其他DNS服务器直到找到,然后此服务器将找到的内容返回给客户端――非权威性应答
其次,推荐客户端到上一级DNS服务器找。―――非权威性应答。
最后,如果原来被别人访问过,本地有该缓存,那么用缓存里的数据回答―――非权威性应答。
说到这里就要讲清楚,为什么会出现3种方法,为什么有的时候DNS服务器要努力帮客户端查寻有的时候又只是打发到上层就不管了?
因为在客户端查询的请求里面包含一个“搜索类型”(Search type)的东东,一共有两种状态:
(1) 递归查询(Recursive),要求DNS服务器一定要救人救到底送佛送上西。反正我就赖上你了,你得给我查到。
(2) 迭代查询(Iterative),你(DNS服务器)如果找不到可以给我介绍到另一个DNS服务器那里去找――这种方式的客户端就文明多了――自然DNS服务器的压力就减轻了。
默认情况是递归查询的,我们可以在DNS服务器参数配置禁用(高级选项)。
当DNS服务器被客户端要求递归查询而去查询其他DNS服务器时,默认是迭代查询的。
5.Netbios解析和DNS解析
对于两者的概念我不想多做说明了,值得注意得是他们的查询步骤。
假定我们启用了Netbios解析,windows客户端会按照下面的步骤进行解析(默认B节点配置可以修改为H节点)
(1) Netbios缓存
(2) Wins查询
(3) Lmhosts文件(看看hosts的目录)
(4) 广播
(5) hosts文件
(6) DNS
我们举个例子,如果我们在客户端ping一下srv1.contoso.com主机。我们通常的做法是运行cmd。输入ping srv1 回车。这时发生了什么?
首先,客户端会把计算机的DNS后缀附在名称上发送到DNS服务器。 如果名字里有“.”存在,但是末尾并没有“.”结束,系统会自动追加末尾“.”,如果这样查询也失败了,就会向上面那样追加DNS后缀再试。 如果添加DNS后缀也无法获得主机记录,那么系统就会追加事先为“接口”配置好得备用DNS后缀(仔细看看本地连接的属性)。
文章来源于领测软件测试网 https://www.ltesting.net/
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073