DNS体系结构是一个分层的分布式数据库和一组相关的协议,定义为:
- 一种查询和更新数据库的机制。
- 在服务器之间复制数据库中的信息的一种机制。
- 一种数据库的模式。
DNS起源于互联网早期,当时的互联网是美国国防部为研究目的而建立的一个小型网络。这个网络中计算机的主机名是通过使用位于中央管理的服务器上的单个HOSTS文件来管理的。需要解析网络上主机名的每个站点都下载了这个文件。随着Internet上主机数量的增加,更新过程产生的流量以及hosts文件的大小都增加了。对新系统的需求越来越明显,该系统将提供诸如可伸缩性、分散管理、支持各种数据类型等功能。
1984年引入的域名系统成为了这种新系统。使用DNS,主机名驻留在可以分布在多个服务器上的数据库中,从而减少了任何一台服务器上的负载,并提供了按分区管理这个命名系统的能力。除了在HOSTS文件中使用的主机名到ip地址映射之外,DNS还支持分层名称,并允许注册各种数据类型。因为DNS数据库是分布式的,所以它的潜在大小是无限的,当增加更多的服务器时,性能不会下降。
最初的DNS是基于RFC 882(域名:概念和设施)和RFC 883(域名-实现和规范),它们被RFC 1034(域名-概念和设施)和RFC 1035(域名-实现和规范)所取代。描述DNS安全性、实现和管理问题的其他RFC后来补充了最初的设计规范。
DNS (Berkeley Internet Name Domain (BIND))的实现最初是为4.3 BSD UNIX操作系统开发的。微软对DNS的实现成为微软Windows NT Server 4.0操作系统的一部分。Windows NT 4.0 DNS服务器,像大多数DNS实现一样,在RFC 1034和1035中有它的根。
DNS域名
域名系统被实现为一个分层的分布式数据库,包含各种类型的数据,包括主机名和域名。DNS数据库中的名称形成一个称为域命名空间的分层树结构。域名由一个个用点分隔的标签组成,例如:mydomain.microsoft.com。
完全限定域名(FQDN)通过指定从引用的主机到根的路径中由点号分隔的名称列表,惟一地标识主机在DNS层次结构树中的位置。下图显示了一个DNS树的示例,其中有一个名为mydomain的主机位于microsoft.com. 域中。主机的FQDN将是mydomain.microsoft.com。
了解DNS域的命名空间
DNS域命名空间基于“命名域树”的概念,如下图所示。树的每一层都可以表示树的一个分支或叶子。分支是一个级别,其中使用多个名称标识已命名资源的集合。叶子表示在该级别使用一次的单个名称,以指示特定的资源。
[图片上传失败...(image-f73743-1652108940445)].gif)
这张图显示了Internet根服务器是如何为Internet上自己的DNS域命名空间树分配权限的。DNS客户端和服务器使用查询作为基本方法,将树中的名称解析为特定类型的资源信息。这些信息是由DNS服务器在对DNS客户端的查询响应中提供的,然后DNS客户端提取这些信息并将其传递给一个请求程序来解析所查询的名称。在解析名称的过程中,请记住,DNS服务器通常作为DNS客户端,通过查询其他服务器来完全解析所查询的名称。
DNS的命名空间是如何组织的
从技术上讲,树中使用的任何DNS域名都是一个域。但是,大多数DNS讨论都会根据级别和名称的常用用法,以五种方式之一来标识名称。例如,注册到Microsoft的DNS域名(microsoft.com.)被称为二级域名。这是因为名称有两个部分(称为标签),表明它位于树的根或顶部以下的两层。大多数DNS域名都有两个或多个标签,每个标签都表示树中的一个新级别。在名称中使用句号来分隔标签。
下表描述了通过命名空间中的功能来描述DNS域名的五种类别,并给出了每种名称类型的示例。
名称类型 | 描述 | 示例 |
---|---|---|
根域 | 这是树的顶部,代表一个未命名的层;它有时显示为两个空引号(""),表示空值。当在DNS域名中使用时,它由一个尾部的句号(.)来表示该名称位于域层次结构的根或最高级别。在本例中,DNS域名被认为是完整的,并指向名称树中的确切位置。以这种方式声明的名称是FQDNs。 | 单个句点(.)或在名称末尾使用的句点,如" example.microsoft.com." |
顶级域 | 用于指出使用名称的国家/地区或组织类型。 | ".com ",表示在互联网上为商业用途而注册的企业名称。 |
第二级域 | 注册给个人或组织在互联网上使用的可变长度的名称。这些名称总是基于适当的顶级域名,这取决于使用名称的组织类型或地理位置。 | "microsoft.com".,这是由互联网DNS域名注册商注册给微软的二级域名。 |
子域 | 组织可以创建的派生于已注册的二级域名的其他名称。其中包括为组织中的DNS名称树而添加的名称,并将其划分为部门或地理位置。 | “example.microsoft.com.“,这是一个虚构的子域,由微软分配用于文档示例名称。 |
主机或资源名 | 在DNS名称树中表示叶子并标识特定资源的名称。通常,DNS域名最左边的标签标识网络上的特定计算机。例如,如果在一个主机(a)资源记录中使用了这个级别的名称,则使用它根据其主机名查找计算机的IP地址。 | "host-a.example.microsoft.com. ",其中第一个标签(" host-a ")是网络上特定计算机的DNS主机名。 |
DNS和互联网域
互联网域名系统由互联网上的名称登记机构管理,负责维护由组织和国家/地区分配的顶级域名。这些域名遵循3166国际标准。保留供各组织使用的许多现有缩略语中的一些以及各国/区域使用的两字母和三字母缩略语见下表:
DNS 域名 | 组织类型 |
---|---|
com | 商业组织 |
edu | 教育组织 |
org | 非盈利组织 |
net | 网络(互联网的骨干) |
gov | 非军事政府组织 |
mil | 军事政府组织 |
arpa | 保留的 DNS |
“xx” | 两字母的国家码 (例如: us, au, ca, fr) |
资源记录
DNS数据库由资源记录(RRs)组成。每个RR标识数据库中的特定资源。DNS中有各种各样的rr。本节介绍资源记录的常用结构。
常见RR结构的详细信息如下表所示。
描述 | 类别 | 存活时间 (TTL) | 类型 | 数据 |
---|---|---|---|---|
起始授权机构(Start of Authority) | 互联网 (IN) | 默认的 TTL is 60分钟 | SOA | 所有者名称 主要的名称服务器 DNS 名称, 序列号 刷新间隔 重试间隔 超时时间 最小 TTL |
主机(Host) | 互联网 (IN) | 记录特定的TTL(如果存在), 或其他区域(SOA) TTL | A | 所有者名称(主机DNS名称) 主机IP地址 |
命名服务器(Name Server) | 互联网 (IN) | 记录特定的TTL(如果存在), 或其他区域(SOA) TTL | NS | 所有者名称 名称服务器 DNS 名称 |
邮件交换器 | 互联网 (IN) | 记录特定的TTL(如果存在), 或其他区域(SOA) TTL | MX | 所有者名称 邮件交换服务器 DNS 名称, 偏好数 |
规范名称(一个别名) | 互联网 (IN) | 记录特定的TTL(如果存在), 或其他区域(SOA) TTL | CNAME | 所有者名称 (别名名称) 主机的DNS名称 |
分配DNS数据库:区域文件和委托
一个DNS数据库可以划分为多个区域。区域是DNS数据库的一部分,其中包含资源记录,其所有者名称属于DNS名称空间的连续部分。区域文件维护在DNS服务器上。单个DNS服务器可以配置为主机0、1或多个区域。
每个区域锚定在一个特定的域名上,称为区域的根域。区域包含以区域根域名结尾的所有名称的信息。如果DNS服务器加载包含该名称的区域,则认为该名称具有权威性。任何区域文件中的第一个记录都是起始授权机构(SOA) RR。SOA RR将专区的主DNS名称服务器标识为该专区内数据的最佳信息源,并作为处理专区更新的实体。
区域内的名称还可以委托给托管在不同DNS服务器上的不同区域。委托是将DNS命名空间的一部分的责任分配给独立实体拥有的DNS服务器的过程。这个独立的实体可以是公司内的另一个组织、部门或工作组。这种委托由NS资源记录表示,该记录指定了被委托的区域以及该区域授权的服务器的DNS名称。跨多个区域委派是DNS最初设计目标的一部分。
委托DNS命名空间的主要原因包括:
- 需要将DNS域的管理委托给组织中的许多组织或部门。
- 需要将维护一个大型DNS数据库的负载分配到多个DNS服务器,以提高域名解析性能,并创建DNS容错环境。
- 需要通过将主机包含在适当的域中来允许主机的组织从属关系。
NS (域名服务器) RRs 通过为每个区域标识DNS服务器来实现委托,NS RRs 出现在所有区域中。当DNS服务器需要通过委托来解析名称时,它将引用目标区域中的DNS服务器的NS RRs。
如下图所示,对于 microsoft.com的管理。 域跨两个区域委托,即microsoft.com. 和mydomain.microsoft.com。
DNS委托复制DNS数据库
可以有多个区域表示命名空间的相同部分。这些区域有三种类型:
- 主要的
- 次要的
- 末节区域
主区域是对属于该区域的所有记录进行更新的区域。次要区域是主区域的只读副本。stub区域是主区域的只读副本,它只包含标识DNS域名授权的DNS服务器的资源记录。对主区域文件所做的任何更改都会复制到次要区域文件。承载主要、次要或stub区域的DNS服务器被认为是该区域中DNS名称的权威服务器。
由于DNS服务器可以承载多个区域,因此它既可以承载主区域(具有区域文件的可写副本),也可以承载单独的次要区域(获得区域文件的只读副本)。托管主要区域的DNS服务器称为该区域的主要DNS服务器,托管次要区域的DNS服务器称为该区域的次要DNS服务器。
区域传输
将一个区域文件复制到多个DNS服务器的过程称为区域传输。通过将区域文件从一个DNS服务器复制到另一个DNS服务器,可以实现区域传输。区域传输可以在主要的和次要的DNS服务器进行。
主DNS服务器是传输过程中区域信息的来源。主DNS服务器可以是主DNS服务器,也可以是备DNS服务器。如果主DNS服务器是主DNS服务器,那么区域传输直接来自承载主区域的DNS服务器。如果主服务器是辅助DNS服务器,则通过区域传输从主DNS服务器接收的区域文件是只读辅助区域文件的副本。
区域传输是通过以下方式之一启动的:
- 主DNS服务器向一个或多个辅助DNS服务器发送区域文件中发生更改的通知(RFC 1996)。
- 当备DNS服务器的DNS Server服务启动或域的刷新周期已过(域的SOA RR默认为15分钟)时,备DNS服务器将向主DNS服务器查询域的刷新时间。
区域文件复制的类型
有两种类型的区域文件复制。第一种是完整区域传输(AXFR),它复制整个区域文件。第二种是增量区域传输(IXFR),它只复制已修改的记录。
BIND 4.9.3和更早的DNS服务器软件,以及Windows NT 4.0 DNS,只支持全区域传输(AXFR)。有两种类型的AXFR:一种要求每个包只有一条记录,另一种允许每个包有多条记录。Windows 2000和Windows Server 2003中的DNS Server服务支持这两种类型的区域传输,但默认情况下,每个包使用多条记录。为了兼容不允许每个包有多条记录的服务器,例如BIND服务器版本4.9.4和更早的版本,可以对其进行不同的配置。
查询数据库
DNS查询可以从DNS客户端(解析器)发送到DNS服务器,也可以在两个DNS服务器之间发送。
DNS查询仅仅是请求具有指定DNS名称的指定资源记录类型的DNS资源记录。例如,一个DNS查询可以请求指定DNS名称的所有a类型(主机)的资源记录。
有两种类型的DNS查询可以发送到DNS服务器:
- 递归
- 迭代
递归查询强制DNS服务器以失败或成功的响应响应请求。DNS客户端(解析器)通常进行递归查询。使用递归查询时,DNS服务器必须联系它需要解析请求的任何其他DNS服务器。当它收到来自其他DNS服务器(或多个服务器)的成功响应时,它将向DNS客户端发送响应。递归查询是解析器查询DNS服务器和DNS服务器查询其转发器(配置为处理转发给它的请求的另一个DNS服务器)所使用的典型查询类型。
当DNS服务器处理递归查询,而该查询无法从本地数据(本地区域文件或以前查询的缓存)解析时,必须将递归查询升级到根DNS服务器。每个基于标准的DNS实现都包含一个缓存文件(或根服务器提示),其中包含Internet域的根DNS服务器的条目。(如果DNS服务器配置了转发器,则在使用根服务器之前先使用转发器。)
迭代查询是指DNS服务器根据其从本地区域文件或缓存中获得的信息,使用其所拥有的最佳本地信息进行响应。如果DNS服务器对该名称没有授权,则此响应也称为引用。如果DNS服务器没有任何可以回应该查询的本地信息,它只发送一个否定响应。当DNS服务器试图查找其本地域(或多个域)以外的名称时(当它没有配置转发器时),会进行这种类型的查询。在试图解析名称时,它可能必须查询许多外部DNS服务器。
下图显示了这两种查询的示例。
DNS查询类型
图中显示了用于确定www.whitehouse.gov的IP地址的大量查询。查询顺序如下:
1、www.whitehouse.gov的递归查询 (一个资源记录)
2、对www.whitehouse.gov(一个资源记录)的迭代查询
3、转到.gov名称服务器(NS资源记录,为.gov); 为简单起见,省略了DNS服务器(左边)用于解析由其他DNS服务器返回的名称服务器的主机名的IP地址的迭代A查询。
4、对www.whitehouse.gov(一个资源记录)的迭代查询
5、转到whitehouse.gov名称服务器(用于whitehouse.gov的NS资源记录)
6、对www.whitehouse.gov(一个资源记录)的迭代查询
7、回答来自whitehouse.gov服务器的迭代查询(www.whitehouse.gov的IP地址)
8、回答从本地DNS服务器到解析器的原始递归查询(www.whitehouse.gov的IP地址)
资源记录的存活时间
资源记录中的存活时间(time -to- live, TTL)值表示其他DNS服务器使用的时间长度,用于确定一条记录在过期和丢弃之前缓存信息的时间。例如,DNS Server服务创建的大多数资源记录继承了从授权(SOA)资源记录开始一小时的最小TTL(默认),这防止了其他DNS服务器的扩展缓存。
DNS客户端解析器缓存它在解析DNS查询时收到的响应。然后可以使用这些缓存的响应来回答以后对相同信息的查询。然而,缓存的数据有一个有限的生存期,该生存期在与响应数据一起返回的TTL参数中指定。TTL可确保DNS服务器不会将信息保存太久而使其过时。TTL缓存可以设置在DNS数据库(为每个单独的资源记录,通过指定的TTL字段记录和每个区域通过SOA记录的最小TTL领域)以及DNS客户端解析器一侧通过指定的最大TTL解析器允许缓存资源记录。
在设置TTL时,有两个相互竞争的因素需要考虑。第一个是缓存信息的准确性,第二个是DNS服务器的利用率和网络通信量。如果TTL很短,则存在旧信息的可能性会大大降低,但这会增加DNS服务器的利用率和网络流量,因为DNS客户端在下一次请求时必须向DNS服务器查询过期的数据。如果TTL很长,缓存的响应可能会过时,这意味着解析器可能会对查询给出错误的答案。同时,较长的TTL降低了DNS服务器的利用率,并减少了网络流量,因为DNS客户端使用其缓存的数据来应答查询。
如果用缓存中的条目回答一个查询,那么该条目的TTL也会随响应一起传递。这样,接收响应的解析器就知道条目的有效时间。解析器接收响应服务器的TTL;它们不会根据自己的TTL重置它。因此,当条目从一个DNS服务器移动到另一个DNS服务器并更新TTL时,它们将真正过期而不是永久存在。
注意:一般情况下,不要将TTL配置为零。设置为0或60之间对于记录的准确性差异来说是最小的,但是当TTL设置为0时,会对DNS服务器的性能有很大的影响,因为DNS服务器会不断地查询过期的数据。
更新DNS数据库
因为区域文件中的资源记录可能会更改,所以必须更新它们。
DNS构架图
下图说明了DNS Client和Server服务如何工作,并提供了有关名称解析、更新和管理操作的附加信息。
第一个图说明了DNS Client服务体系结构的名称解析和更新操作。在此图中,使用Web浏览器和Microsoft Outlook演示了名称解析体系结构,并由DHCP客户端表示更新。
DNS客户端服务架构
下图说明了DNS Server服务体系结构及其管理工具和Windows Management Instrumentation (WMI)接口。
DNS服务端架构
网友评论