Active Directory 和DNS 的 SRV记录

2017-03-27

8749

Active Directory和DNS 的 SRV 记录Naka 原创首先来看看默认情况下AD 下的DNS:环境：win2k3ip:192.168.0.9dns:192.168.0.9域:test.

Active Directory和DNS 的 SRV 记录

Naka 原创

首先来看看默认情况下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 使用的端口号

以上详细信息查看

这个属性面板到底说的是什么呢？在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

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

服务（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把活动目录中与指定名字站点最切合的服务定位收集在一起是很相似的。

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

SRVRR 是服务定位器（SRV ）资源记录。允许使用单个DNS 查询操作定位提供类似的基于TCP/IP服务的多个服务器。该记录使您可为按照DNS 域名首选项排列的已知服务器端口和传输协议类型维护服务器的列表。例如，在Windows Server 2003 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 。该文件在systemrootSystem32Config文件夹中创建。

如果您打算使用符合下列描述之一的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或更高版本时符合该描述。

相关推荐