Active Directory和DNS 的 SRV记录

首先来看看默认情况下AD下的DNS:

环境：
win2k3
ip:192.168.0.9
dns:192.168.0.9
域:test.com
完整的计算机名:cd1.test.com
DNS建成AD

   下图可以看出，主要分两个部分组成，名为test.com的域在微软的DNS中并没有简单的注册成test.com，DNS实际上是建立tset.com之后，在test.com中建立了一个子域，也就是_msdcs.test.com,然后将_msdcs区域委派给DNS Server自己(在win2k中和win2k3有所不同)。微软这也做的原因有二个，我也只能猜想了（哪位知道，请补充一下）。其一是为了在多个服务器之间分配通信量负载，需要将一个大的区域分成若干小的区域，这提高了 DNS 名称解析性能或创建了一个容错性更好的 DNS 环境。 其二，需要通过立刻添加许多子域来扩展名称空间，例如提供开放的新分支或站点。 简单来说就是建立一个高可用性和可靠性的dns服务系统。

test.com_msdcs：
    灰色的文件夹，看到灰色文件夹不要认为不正常，这里是将_msdcs域委派给了test.com，我们点开_msdcs.test.com来看 看是些什么，msdcs下包含了四个子域dc，domain，gc和pdc。

dc和gc：
    其中dc和gc是按照站点来划分的，这也可以让客户机快速的找到想到找的Active Directory服务（kerberse，ldap等）我这个测试环境只有一个site，名字为Default-first-site-name(DFSN)。那么为什么按照站点来划分？我想应该和客户端登陆过程有关，其登陆使用三种类型的信息来尝试找到域控制器，也就是kerberse服务器。这三种类型分别是域名，GUID，站点识别标识。

按照上图，来说明一下什么是SRV记录，看上图中的_kerbers属性。
域：DFSN._sites.dc.msdcs,这是一个子域，也就是test.com下的子域。
服务：kerberos服务
协议：使用了tcp协议
优先级：0～65535之间的数，数字越小，级别越高
权数（重）:0～65535之间的数.设置附加的优先级，用于确定在应答SRV查询中使用的目标主机的准确顺序或选择平衡
端口号：tcp使用的端口号
以上详细信息查看http://yizh1977.spaces.live.com/blog/cns!2B3776EFF823A0D5!288.entry

这个属性面板到底说的是什么呢？在test.com的DFSN._sites.dc.msdcs子域中有一个使用tcp的kerberos服务器（注意就是域可控制器）。当用户通过tcp协议的88端口对kerberos做请求时，这台dc将做反应。

Domains：
    domains下面的那些数字是domainguid，如下图所示：_ldap._tcp.domainguid.domains._msdcs.test.com.这个属性面板说明，当用户通过tcp协议的389端口对ldap进行请求时，test.com下的子域domainguid.domains._msdcs将做出反应。这个主要是用于复制。

看下图：还剩下_sites,_tcp,_udp和其他两个子域。 那两个子域是存储林信息的，在这里不做介绍。

_sites:
    站点代表的是一个高速连接区域，根据DC的站点从属关系来建立了DC索引之后，客户端就可以检查_SITES来寻找本地服务，而不必通过WAN来发送它们的LDAP查询请求。标准LDAP查询端口是389，全局编录查询则使用3268（如图所示）。在site中提供三种服务，GC，Ldap，kerberos，其实Gc指的也是ldap，但是ms取了一个名字，叫Global Catalog，是与一个域的子集交流的服务。也就是site具备了除_kpasswd这外的其他所有服务。以下是其具体说明：
1，_gc._tcp.._sites.—允许客户机找到与指定的使用活动目录根域的站点最切合的全局目录服务器。
2，_kerberos._tcp.._sites.—允许客户机找到最切合指定站点的域中的KDC。
3，_ldap._tcp.._sites.—允许客户机在最切合指定站点的域中找到ldap服务器

_tcp:
   收集了DNS区域中的所有DC也就是提供kerberos验证服务的服务器。如果客户端找不到它们特定的站点，或者具有本地SRV记录的任何DC都没有响应，需要寻找网络中其他地方的DC，就应该将这些客户端放到这个分组中。在这个子域中，可以得到AD得所有服务gc,kerberos,kpasswd,ldap，以下是其具体说明：
1，_ldap._tcp.—允许客户机在指定域中找到ldap服务器
2，_gc._tcp.—允许客户机找到使用活动目录根域的全局目录服务器
3，_kerberos._tcp.—允许客户机找到对本域的kerberosKDC服务
4，kpasswd._tcp.—允许客户机找到域中的kerberos改变密码服

_udp:
  kerberos v5允许客户端使用获取票证并更改密码。这是通过与相同服务的TCP端口对应的UDP端口来完成的,票证交换使用UDP的88端口，而密码更改使用464。以下是其具体说明：
1，kerberos._udp。－允许客户机找到对本域的kerberosKDC服务，使用udp
2，_kpasswd._udp.—允许客户机找到域中的kerberos改变密码服务，使用udp

搞了一下午终于弄完了，这些概念和知识主要用于排错。

21:31 | 添加评论 | 发送消息 | 固定链接 | 查看引用通告 (0) | 写入日志 | 深入了解活动目录

服务（SRV）记录

服务（SRV）记录
　　从技术上来说，SRV记录是一个实验性的资源记录，微软构造了一个服务基础来消除传统的NetBIOS服务，这个基础是依赖于定位提供查询服务主机的SRV记录的。在旧的操作系统(NT4或更早)下，主机提供什么样的服务是通过NetBIOS来广播的。在新的操作系统即Windows2000下，则通过使用SRV记录来实现。客户机必须认识SRV记录从而通过SRV记录找到提供所需服务的主机，换句话说，如果客户机不知道该向DNS询问些什么，它就不会得到答案。当客户机能够查询一种类型的服务并且得到回答，它将得到一个IP地址，以便和所请求的服务取得联系。
　　一个实例是一个用户通过客户机请求登录上网，要做到这一点，客户机必须能够确认用户使用了正确的域控制器。即客户机必须知道向何处发送确认请求。客户机应向作为登录域域控制器的服务器发送一个DNS查询。尽管实际的过程更为复杂，但是在域控制器被确认后，用户身份认证过程会继续。
　　当DNS能够执行动态更新时，服务记录由NETLOGON进程创建。用来保持活动目录结构，否则，一些SRV记录必须手动地创造，下面列出了一些需要SRV记录服务类型的例子。SRV记录能够被用来广播除了已能被查询的服务外的其他服务。图4-8显示了创建广播s1.example.net主机上的HTTP服务器的SRV记录的过程。

　　服务记录的格式如下所示：

　　注意在“service”和“protocol”之间必须有一个点号。优先级值(值)很像MX记录的优先级值，值越小，优先权越高。取值的范围从0到65535。权值(值)用在对同一个服务有多个具有同等优先权的记录时，取值从1到65535，查询被响应的早晚与权值成正比。这样做比用轮转法对负载平衡的影响更先进一些。当不考虑负载平衡时权值被置为0。对于目标(target)域而言，还有特殊值，即当记录中指示的服务在此域中被确认为不可用时，便在目标域中填入一个句点。
　　以下是一个SRV记录的例子。

　　一些活动目录所需的由SRV记录广播的服务类型如下所示：
　　_ldap._tcp.—允许客户机在指定域中找到ldap服务器。
　　_ldap._tcp.._sites.—允许客户机在最切合指定站点的域中找到ldap服务器。
　　_gc._tcp.—允许客户机找到使用活动目录根域的全局目录服务器。
　　_gc._tcp.._sites.—允许客户机找到与指定的使用活动目录根域的站点最切合的全局目录服务器。
　　_kerberos._tcp.—允许客户机找到对本域的kerberosKDC服务。
　　_kerberos._udp.—除了使用UDP而不是TCP协议外同上。
　　_kerberos._tcp.._sites.—允许客户机找到最切合指定站点的域中的KDC。
　　_kpasswd._tcp.—允许客户机找到域中的kerberos改变密码服务。
　　_kpasswd._udp.—除了使用UDP而不是TCP协议外同上。
　　注意一些用_mcdcs作为或的第一个限定词的SRV记录是被用于构造域控制器的分类和服务查询树的。这样活动目录客户机和服务器就能通过简单的查询而不是一系列的链式查询来定位。这与用_sites把活动目录中与指定名字站点最切合的服务定位收集在一起是很相似的。

18:59 | 添加评论 | 发送消息 | 固定链接 | 查看引用通告 (0) | 写入日志 | 深入了解活动目录

服务位置（SRV）资源记录（SRVRR）

服务位置（SRV）资源记录（SRVRR）
SRVRR是服务定位器（SRV）资源记录。允许使用单个DNS查询操作定位提供类似的基于TCP/IP服务的多个服务器。该记录使您可为按照DNS域名首选项排列的已知服务器端口和传输协议类型维护服务器的列表。例如，在Windows Server 20## DNS中，它提供了通过389号TCP端口定位使用轻型目录访问协议（LDAP）服务的域控制器的方法。
在SRV资源记录中使用的每个专用字段的目的如下。
服务：所需服务的符号名。对于一些大家都知道的服务，保留的通用符号名（如“_telnet”或“_smtp”）在RFC 1700中定义。如果某个已知的服务名称没有在RFC 1700中定义，则可使用本地或用户首选名称。一些广泛使用的TCP/IP服务，特别是邮局协议（POP），没有单独的通用符号名称。如果RFC 1700为本字段中指定的服务指派名称，则RFC定义的名称是可合法使用的唯一名称。只有本地定义的服务才能在本地命名。
协议：指明传输协议类型。尽管可使用在RFC 1700中命名的任何传输协议，但这一般为TCP或UDP。
名称：该资源记录所引用的DNS域名。SRV资源记录在其他DNS记录类型中是唯一的，在DNS记录类型中，它不用于执行搜索或查询。
优先权：为“目标”字段中指定的主机设置首选项。查询SRV资源记录的DNS客户端尝试联系在此列出的最低编号首选项的第一台可访问的主机。尽管目标主机具有相同规定的首选项值，但它们仍可随机进行尝试。首选项值的范围为0～65 535。
权重：除“首选项”外，它可用于提供负载平衡机制，在“目标”字段中指定多个服务器并设为相同的优先级。在这些相同优先级中选择目标服务器主机时，这个值可用于设置附加的优先级，用于确定在应答SRV查询中使用的目标主机的准确顺序或选择平衡。使用非零值时，相同优先级的服务器根据该值的权重按比例地进行尝试。值的范围是1～65 535。如果不需要进行加载平衡，则使用该字段中的0值以使该记录更易于阅读。
端口：位于提供“服务”字段中所指明服务的“目标”主机上的服务器端口。尽管如RFC 1700中所指定的那样，编号通常是公开指派的服务端口号，但端口编号的范围还是0～65 535。未被指派的端口可根据需要使用。
目标：为提供要申请的服务类型的主机指定DNS域名。所使用的每个主机名都必须在DNS名称空间中有相应的主机地址（A）资源记录。可在该字段中使用单个句点（.），以便权威性地指出该DNS域名中没有在SRV资源记录中所指定的待申请服务。
语法格式为：service.protocol.name ttl class SRV preference weight port target
例如：_ldap._tcp._msdcs SRV 0 0 389 dc1.example.microsoft.com。
要定位Active Directory域控制器，需要知道服务位置（SRV）RR。在默认情况下，Active Directory安装向导根据首选或备用DNS服务器列表尝试定位DNS服务器，这些服务器是在任何TCP/IP客户端属性中为任何活动的网络连接配置的。如果联系了可以接受SRVRR（以及有关在DNS中将Active Directory注册为一项服务的其他RR）动态更新的DNS服务器，则配置过程就完成了。
如果在安装过程中无法找到可以接受用于命名Active Directory的DNS域名更新的DNS服务器，该向导可在本地安装DNS服务器，并使用支持Active Directory域的区域自动配置它。例如，如果您为树林中的第一个域选择的Active Directory域是example.microsoft.com，那么在DNS域名example.microsoft.com上确立的区域将被添加并配置为与运行在新域控制器上的DNS服务器一同使用。
不论是否在本地安装DNS服务器服务，在Active Directory安装过程中将写入和创建文件（Netlogon.dns），该过程包含支持Active Directory使用所需的SRVRR和其他RR。该文件在systemroot\System32\Config文件夹中创建。
如果您打算使用符合下列描述之一的DNS服务器，则应使用Netlogon.dns中的记录手动配置该服务器上的主要区域以支持Active Directory。
操作DNS服务器的计算机正在另一个平台上（如UNIX）运行，并且不能接受或识别动态更新。
该计算机上的DNS服务器不是与Windows Server 2003家族一起提供的DNS服务器服务，它对于Active Directory域的DNS域名对应的主要区域具有权威性。
如同Internet草案“指定服务（DNSSRV）位置的DNSRR”中所定义的那样，DNS服务器支持SRVRR，但不支持动态更新。例如，Windows NT Server 4.0提供的DNS服务器服务在更新到Service Pack4或更高版本时符合该描述。

摘抄自网络

第二篇：DNS

DNS的发展以及原理

计科1105 耿姣 04111164（23）

计科1106 南嘉玮 04111182（11）

一、发展背景：

Internel的快速发展是全球实现互联的关键，而IP地址则是全球互联网的粘剂。通过IP地址理论上我们可以访问到世界上每一台因特网内的主机，因为因特网为其中的每一个节点都分配了一个唯一的IP地址。就像一个国家各个地方有自己的邮政编码一样，我们在交流过程中通常会说“xx省xx市”，而不会用类似“12345”这样的纯数字代码。同样，IP地址也有对应的名字，我们称之为域名。域名减轻了人们的记忆负担，提供了比IP地址更加有好的Internel服务，例如，当要访问百度时，我们只需输入，而不需要输入对应IP地址，但是，在Internel的通信过程中，它只能识别IP地址，所以这就要求有一种能把域名映射到与之对应的IP地址上的机制。 DNS的发展可以追溯到19xx年，那时Internet尚不普及，在当时的Internel上，主机名称和它所对应的IP地址被放在一个成为Hosts的文件中。当时主机数量少，这个文件也不用经常改变，因此其他主机几天一次从NIC的主机上下载文件进行主机名和IP地址映射就可以了。也就是说可以用主机名进行网络信息的共享，而不需要记住IP地址。这解决了人们记住复杂无规律的IP号和端口号，再不用一串数字去访问主机。但是随着网络的扩张，这种方法变得无法使用，因为经常会有主机要求下载，对NIC的主机造成巨大压力，而

且也不能保证服务的质量。所以DNS就出现了。分布式数据库，它允许对整个数据库的各个部分进行本地控制（本地控制也就是所谓的授权，可以把数据库的一部分进行授权，减轻主DNS服务器的压力，就是按域结构进行授权）。

二．DNS提供的服务（解决问题）

DNS主要任务是实现域名与IP地址之间的转换，它通常为其它应用层协议所使用，将用户提供的主机名解析为与之对应的IP地址。对普通Internel用户来说，DNS是透明的。假设有某用户主机的浏览器要请求www./index.html页面，浏览器把www.这一主机名传送给DNS的客户端，DNS便开始工作，它通过C/S的形式获取与www.对应的IP地址并把它传送给浏览器。这样，浏览器便可以向有IP地址定位的http服务器发出请求了。

DNS不知是实现域名与IP地址之间的映射，除此之外，它还提供了一些其它相当重要的服务。主机别名类似与人类别名，主机名也可以拥有一个或多个别名，别名比主机规范名更便于记忆，当在应用中使用主机别名时，提供DNS就能获得与之对应的规范主机名以及主机的IP地址。负载分担用到了冗余技术把繁忙的站点冗余运行在不同端系统的多个服务器上，这样一个主机名就对应了多个IP地址，实际应用中就旋转式地把主机名映射到这些IP地址上，这样就减轻了单个服务器的负载，以提高性能DNS为Internel应用提供的服务远不止这些. 运行良好的DNS是Internel成功的有力支撑。

三、DNS工作原理

1. 具有层次结构的分布式数据库

树状结构的域名空间

为便于管理，Internel中的域名采用层次结构，并用域名空间来描述在域名空间中把名字定义到一棵倒置的树形结构中类似家谱树，树的每一级定义了域名层次的每一级。

树状层次结构上的每一个节点都有一个域名，每一个域名都该节点向上读到根节点通常根节点的标号为空。DNS要求每个节点其下的子节点应具有不同的标号。因此这种树状结构保证了域名的唯一性。

2. 地址解析

利用上面的层次结构地址映射就可以分布到所有DNS服务器上了，这就为分布式数据库提供了依据，当主机发出它的DNS请求时该请求首先被发往本地DNS服务器，如有需要，本地DNS服务器将该请求转发到DNS层次结构中去实现地址映射在这种机制下就涉及到DNS客户机与DNS服务器以及各服务器之间的通信。通常采用的查询方式是递归查询和迭代查询。

a.递归查询

所谓递归查询是指接受查询请求的第一个DNS服务器必须对请求进行处理并予以响应。假设主机要请求IP地址，本地服务器将该查询转发到上级服务器上级服务器，再将该查询转发到更高级根服务器，直到查询被解析或出错。响应则逆向直到客户机。

b.迭代查询

如果客户机没有要求递归查询则可以按迭代方式映射， 迭代过程中的每一次查询请求都由客户机发出对查询的每一次响应也直接返回给客户机，如果没有解析到IP地址返回的类容将包括下一个逻辑上更近的DNS服务器的IP地址客户机根据这个IP地址继续查询知道返回的是最终结果或者出错。理论上DNS查询既可以是递归的也可以是迭代的。在实际应用中通常把递归查询和迭代查询结合起来使用。

c. DNS高速缓存

在信息量巨大的Internel中网络带宽服务器负载等是一直我们面临并努力优化的问题。如果DNS服务器每次收到对本地之外的连接请求时都进行逐层查询的话，那么这些应用带来的网络通信量将相当的巨大，并且带来额外的时延。因此DNS设置了高速缓存和很多方面一样它采用冗余技术DNS缓存。原理很简单当DNS服务器收到一个DNS回答时，它就将映射信息缓存在本地存储器上，在下一次收到查询请求时，DNS服务器就首先检查本地缓存，如果在本地缓存中存在，所需信息它就直接从缓存中取出信息回答客户机的请求。如果所需信息不再缓存中，则再发出进一步的查询。

3. 资源记录和DNS报文格式

DNS分布式数据库中存储着所有域名与IP地址的信息。它们主要采用资源记录的形式DNS回答报文中都包含了资源记录。

我们给出资源记录NameValueTypeTL四元组的简化存在形式，

这４个参数的定义:

Name资源记录所在的域名

Value与资源记录有关的数据

Type资源记录的类型

TTL资源记录的生存周期以秒计

4. 传输层协议的选择(UDP 53端口)

通常地址解析程序和DNS服务器都是通过UDP传输层协议实现信息交换的，DNS系统将通用端口53作为端口，UDP协议非常简单，不需要建立连接，因此不会引入建立连接的延时；应用层能更好地控制发送的数据和时间UDP分组首部开销小。基于UDP的这些优点和DNS本身数据量不大的特点UDP是DNS首选的下层协议。但是UDP有效载荷中可携带的DNS数据的长度不能超过512字节。显然这对于较大的数据以及主从服务器之间的大批信息传递就无用了。此时DNS必须采用TCP为其服务，在实际应用中由于TCP消耗的资源更多。所以首先选用UDP，当信息长度大于512字节时，就必须使用TCP协议重发请求。

四、发展

基于ＤＮＳ的未来电话系统

虽然Internel已深入到人们生活和工作的各个领域成为人们相互通信的重要工具但是它却无法完全代替传统的电话系统。电话是今天的主要通讯工具电信产业的迅猛发展使得几乎每个人都可以拥有一个电话。当我们要联系某人时通常是输入一长串的数字也就是所谓的

电话号码。当我们的联系人越来越多或者将来电话号码越来越长可以想象记忆如此多的数字是一件多么费劲的事。为了减轻人们记忆电话号码的负担我们可以借鉴Internel中的DNS原理为全球庞大的电话系统也设置一套专用的DNS系统当我们要联系某人时不必输入长串的数字仅需要提供与该电话号码对应的更友好的信息。比如某地某人。就可以实现通话了。

DNS提供了将Internel上的友好的域名与机器中的IP地址间的转换为Internel的实现提供了灵活可靠强健的地址解析服务是Internel正常运行和发展的有力支撑。在Internel向前发展的同时DNS也面临着很多挑战，如何保证应答信息的正确性如何在ＤＮＳ中存储新的类型的数据如何在保证当前DNS的良好性能的前提下进行优化和功能扩展以及把该技术应用到其它信息领域将是DNS研究的新方向。