下载文档原格式
dns基本原理
DNS(Domain Name System)是一种用于将域名转换为IP地址的分布式数据库系统。
在互联网中，每个计算机都有一个唯一的IP地址用于通信。
然而，由于IP地址很难记忆，DNS系统被用来将易记的域名映射到这些IP地址。
DNS基本原理包括域名层次结构、递归查询、迭代查询和缓存机制。
首先讲一下域名层次结构。
域名系统采用了层次结构的命名体系，其中域名被归类为顶级域名(TLD)、二级域名(SLD)和三级域名等。
域名后缀（如.com、.org 等）是顶级域名，而主机名(如
当用户输入域名时，应用程序会向本地DNS服务器发出请求。
本地DNS服务器会首先搜索自己的缓存中是否有这个域名的缓存记录。
如果没有，它会向更高层次的DNS服务器请求解析此域名，直到找到最终的DNS服务器为止。
这个过程称作递归查询。
如果DNS服务器不能直接回答查询，它会返回一个指向另一个DNS服务器的指针，这样应用程序就可以继续查询，这个过程称作迭代查询。
当找到一个可以回答查询的DNS服务器时，它会返回一个IP地址，本地DNS 服务器会将这个IP地址作为缓存记录存储在自己的缓存中，以便下次查询时直接提供，加快查询速度。
总之，DNS系统通过层次结构的域名和分布式的DNS服务器实现了域名到IP 地址的映射。
这使得用户能够轻松地访问网站，同时加快网络通信和缓存的速度，为互联网提供了可靠、高效的服务。
DNS协议详解协议名称：DNS协议详解一、引言DNS（Domain Name System）协议是互联网中用于将域名转换为IP地址的一种协议。
本协议旨在详细解释DNS协议的工作原理、协议格式和相关概念。
二、协议概述DNS协议是一个分布式的命名系统，用于将域名映射为IP地址。
它是互联网中最重要的基础设施之一，为用户提供了便捷的域名访问方式。
DNS协议基于客户端-服务器模型，客户端通过发送DNS查询请求，服务器则负责返回相应的DNS解析结果。
三、协议工作原理1. DNS查询过程1.1 客户端向本地DNS服务器发送DNS查询请求。
1.2 本地DNS服务器查询自身的缓存，若有相应的解析结果则直接返回给客户端。
1.3 若本地DNS服务器没有缓存，它将向根域名服务器发送查询请求。
1.4 根域名服务器返回顶级域名服务器的地址给本地DNS服务器。
1.5 本地DNS服务器向顶级域名服务器发送查询请求。
1.6 顶级域名服务器返回次级域名服务器的地址给本地DNS服务器。
1.7 本地DNS服务器向次级域名服务器发送查询请求。
1.8 次级域名服务器返回授权域名服务器的地址给本地DNS服务器。
1.9 本地DNS服务器向授权域名服务器发送查询请求。
1.10 授权域名服务器返回解析结果给本地DNS服务器。
1.11 本地DNS服务器将解析结果返回给客户端。
2. DNS协议格式DNS协议使用UDP或TCP作为传输层协议，其数据包由报头和数据部分组成。
报头包含以下字段：- 标识字段：用于标识DNS查询和响应的关联。
- 标志字段：用于指示查询或响应类型。
- 问题字段：包含查询的域名和查询类型。
- 回答字段：包含域名的IP地址或其他资源记录。
- 权威字段：指示响应的授权域名服务器。
- 附加字段：包含其他相关信息。
四、协议相关概念1. 域名（Domain Name）：用于标识互联网上的计算机和服务的字符串。
2. IP地址（Internet Protocol Address）：用于标识互联网上的设备的一组数字。
DNS: 名称解析服务，不是域名解析服务，因为它解析的是计算机FQDN:FQDN ：(Fully Qualified Domain Name)完全合格域名/全称域名，是指主机名加上全路径，全路径中列出了序列中所有域成员。
全域名可以从逻辑上准确地表示出主机在什么地方，也可以说全域名是主机名的一种完全表示形式。
从全域名中包含的信息可以看出主机在域名树中的位置。
DNS 组件：DNS 服务器DNS CLIENTDNS 查询：递归查询：DNS 会回应查询的IP 地址迭代查询：在DNS 迭代查询中，客户端可能得到下一个DNS 服务器的地址根提示：本地的DNS 查询公网的13台根DNS(当DNS 为.域，根提示不可用)转发：将所有的DNS 请求转发给指定的DNS条件转发：windows 2003及之后，主要zone1.辅助zone2.存根zone3.DNS 区域类型正向查找区域 反向查找区域主要区域 辅助区域 存根区域Zone 类型：加入域时，当没有配置DNS 时，可以使用域的netbios 名加入域Enter command 1.Local host name 2.Hosts file 3.DNS server 4.NetBIOS name cache 5.WINS Server 6.Broadcast 7.LMHOSTS File 8.名称解析过程DNS 简介8.LMHOSTS File使用DNSSEC技术保护DNS安全DNSSEC主要依靠公钥技术对于包含在DNS中的信息创建密码签名。
密码签名通过计算出一个密码hash数来提供DNS中数据的完整性，并将该hash数封装进行保护。
私/公钥对中的私钥用来封装hash数，然后可以用公钥把hash数译出来。
如果这个译出的hash值匹配接收者刚刚计算出来的hash树，那么表明数据是完整的。
不管译出来的hash数和计算出来的hash数是否匹配，对于密码签名这种认证方式都是绝对正确的，因为公钥仅仅用于解密合法的hash数，所以只有拥有私钥的拥有者可以加密这些信息。
dns主备工作机制DNS主备工作机制DNS（Domain Name System）是互联网中用于将域名解析为IP地址的系统。
在DNS系统中，主备工作机制是保证DNS服务器高可用性的重要手段之一。
本文将详细介绍DNS主备工作机制的原理和实现方式。
一、DNS主备工作机制的原理DNS主备工作机制是通过设置主服务器和备用服务器来实现。
主服务器负责处理所有的DNS请求，而备用服务器则在主服务器发生故障或不可用时接管主服务器的工作。
主备服务器之间通过持续的数据同步和状态监控来保证服务的连续性和一致性。
二、DNS主备工作机制的实现方式1. 基于区域传输（AXFR）主备服务器之间通过区域传输（AXFR）协议实现数据的同步。
主服务器定期将自己的数据更新发送给备用服务器，备用服务器接收并保存这些数据。
当主服务器发生故障时，备用服务器便可以立即接管主服务器的工作。
2. 基于通知（DNS Notify）主服务器和备用服务器之间通过DNS Notify机制实现状态的监控。
主服务器在数据更新完成后向备用服务器发送通知，告知备用服务器进行数据同步。
备用服务器接收到通知后，发送请求获取最新的数据，并进行更新。
3. 基于负载均衡（DNS Load Balancing）为了提高DNS服务的性能和可靠性，可以在主备服务器之间使用负载均衡。
负载均衡可以将请求分发到不同的服务器上，避免单一服务器负载过重。
常见的负载均衡技术包括DNS轮询、基于权重的负载均衡和基于响应时间的负载均衡。
三、DNS主备工作机制的优势1. 提高系统的可用性：通过设置备用服务器，当主服务器发生故障时，备用服务器可以接管主服务器的工作，确保系统的连续性和可用性。
2. 提高系统的性能：通过负载均衡技术，将请求分发到不同的服务器上，避免单一服务器负载过重，提高系统的响应速度和性能。
3. 简化维护和升级：在进行系统维护和升级时，可以先将备用服务器设置为主服务器，然后对原主服务器进行维护和升级，降低了对系统的影响。
DNS协议详解协议名称：DNS协议详解协议概述：DNS（Domain Name System，域名系统）是一种用于将域名转换为对应IP地址的分布式数据库系统。
它是互联网中最重要的基础设施之一，负责将用户输入的域名解析为对应的IP地址，使得用户能够访问特定的网站或服务。
本协议旨在详细解释DNS协议的工作原理、消息格式、查询过程以及常见的DNS记录类型。
一、DNS协议工作原理：1.1 DNS协议采用客户端-服务器模型，由客户端发起域名查询请求，服务器负责响应并返回解析结果。
1.2 DNS协议使用UDP协议进行通信，使用端口号53。
1.3 DNS协议采用层次化的域名结构，以便于管理和查询。
二、DNS消息格式：2.1 DNS消息由消息头、查询部分、回答部分、授权部分和附加部分组成。
2.2 消息头包含16个字节，包括标识、标志、问题数、回答数、授权数和附加数等字段。
2.3 查询部分包含查询域名和查询类型字段。
2.4 回答部分包含回答域名、回答类型、回答类别、生存时间和数据长度等字段。
2.5 控权部分包含授权域名和授权类型字段。
2.6 附加部分包含附加域名、附加类型、附加类别和附加数据长度等字段。
三、DNS查询过程：3.1 客户端向本地DNS服务器发起查询请求。
3.2 本地DNS服务器首先查询自身缓存，若有则直接返回结果。
3.3 若本地DNS服务器缓存中无结果，则向根域名服务器发送查询请求。
3.4 根域名服务器返回顶级域名服务器的地址。
3.5 本地DNS服务器向顶级域名服务器发送查询请求。
3.6 顶级域名服务器返回权威域名服务器的地址。
3.7 本地DNS服务器向权威域名服务器发送查询请求。
3.8 权威域名服务器返回查询结果给本地DNS服务器。
3.9 本地DNS服务器将查询结果缓存并返回给客户端。
四、常见的DNS记录类型：4.1 A记录：将域名解析为IPv4地址。
4.2 AAAA记录：将域名解析为IPv6地址。
5S 智能DNS架构2016年10月Agenda•背景•概述•解决方案•公网DNS架构•内网DNS架构•案例介绍解决方案背景•DNS托管/DNS基础设施需要更新换代•DNS已经成为数据中心的最为重要基础设施•多活数据中心使DNS需求，呈暴发性增长趋势•内外网DNS需求存在显著差异……概述•外网DNS•外网应用多活数据中心•架构整合（权威域名服务回收，GTM替换原有企业权威域名服务器）•DNS 攻击和安全•外网DNS升级替换（考虑优化服务能力,可视化管理及规范化部署等因素）•内网DNS•DNS 服务器负载均衡•内网应用多中心部署•整合数据中心内网DNS相关基础设施•分行部署可扩展Scalable智能SmartF5 DNS 服务体系架构的5S5S 级DNS 体系功能支持规范化Standard安全Security高可用Stable智能意味着你的BIG-IP 设备基于内容处理DNS 请求（如位置或信誉等级），并能判断查询资源是否是有效的可扩展意味着你的BIG-IP 设备能处理任何浪涌的DNS 查询，保障您的应用对客户是可用的高可用保证您的DNS 系统的可用性的同时，BIGIP 设备自身也具备极高的可用性；应对由DNS 设备硬件引起的故障，并保护您的DNS 基础架构安全提供DNS 系统基于各种网络层及应用层DDOS 攻击的安全防护，确保DNS 系统的安全规范化对于智能域名和普通域名分别部署，同时对于访问来源和上级DNS 进行健康监控和管理5S 级DNS 体系整体架构图GTM VEGTM VEGTM VEGTM VEInternetDNS Cloud ServicesDNS/GTM VE poolIntranet智能•地理位置服务，根据用户的位置提供精准的应用或服务交付•IP智能服务检测并制止来自与恶意活动有关的IP地址进行的任何访问，保护基础架构的安全性•补充BIG-IP智能服务解决方案，例如广域应用交付、策略执行、NAT64和DNS64转换、健康状况监控以及F5脚本语言、以及与DNS iRules集成，实现细粒度的DNS决策和域名服务交付•基于业务逻辑导向用户去往最佳并可用的应用和数据中心•监控外部LDNS是否可以正确解析到DNS记录客户端状态地点, 设备,关系, 认证个上下文内容类型, 大小, 安全,规则, 策略.站点状态性能,位置,容量, 规模网络状况本地的, 远程的,公共的, 私有的,带宽, 延时LDNS ClientsGTM Probes its local resources GTM shares resource stat e, local DNS metrics智能DNS 服务基于应用的健康检查探测本地、CDN和Public Cloud的业务是否可用GTM健康检查GTM同步DNS Request Public Cloud Hosted AppCDN hosted AppCDN hosted App CDN hosted AppGTM Probes PublicresourcesGTM Probes CDN resourcesLDNSClientsDNS zone transfer makes GTM authoritative respon der for domain智能DNS 服务根据用户的位置、业务逻辑、健康监控状况以及F5脚本语言将应用请求发送到最佳的数据中心GTM 健康检查GTM 同步DNS RequestPublic Cloud Hosted AppCDN hosted AppCDN hosted AppCDN hosted AppLDNSClients智能DNS 服务将对LDNS 的解析正确性进行检查GTM 健康检查GTM 同步DNS Request LDNS 正确性检查GTM probes if LDNS response is correctPublic Cloud Hosted AppCDN hosted AppCDN hosted AppCDN hosted AppLDNS可扩展内存缓存响应扩展DNS 云服务扩展单设备多核以及多设备服务池扩展如何估算DNS 请求处理极限阀值？最大带宽/ 单个DNS 请求包大小= DNS 请求处理极限阀值可扩展的DNS 服务单设备多核扩展以及多设备服务池扩展INTERNETLDNSClientsData CenterAppAppAppGTM Services PoolINTERNETLDNSClientsData CenterApp AppAppGTM VIPRION 2400 scales with blades = up to 4M QPSINTERNETLDNSClientsData CenterApp AppAppZone UpdateDNS Servers定时自动获取后台DNS 服务器上的所有DNS 记录在BIG-IP 的内存中运行的高速响应DNS 服务支持百万级的DNS 记录不同与DNS Cache ，不会向后台进行查询INTERNETLDNSClientsData CenterApp AppApp出现爆发式DNS 请求或海量攻击时，修改上级DNS 的NS 记录导向到DNS 云服务，同时在DNS 云服务上启用大量DNS 或GTM 虚机应对，保障业务访问正常。
浅谈DNS体系结构：DNS系列之一DNS是目前互联网上最不可或缺的服务器之一，每天我们在互联网上冲浪都需要DNS的帮助。
DNS服务器能够为我们解析域名，定位电子邮件服务器，找到域中的域控制器……面对这么一个重要的服务器角色，我们有必要对它进行一番深入研究，本文尝试探讨一下DNS的体系结构，从而让大家能更好地了解DNS的原理。
DNS的主要工作是域名解析，也就是把计算机名翻译成IP地址，这样我们就可以直接用易于联想记忆的计算机名来进行网络通讯而不用去记忆那些枯燥晦涩的IP地址了。
现在我们给出一个问题，在DNS出现之前，互联网上是如何进行计算机名称解析的？这个问题显然是有实际意义的，描述DNS的RFC882和883出现在1984年，但1969年11月互联网就诞生了，难道在DNS出现之前互联网的先驱们都是互相用IP地址进行通讯的？当然不是，但早期互联网的规模确实非常小，最早互联网上只有4台主机，分别在犹他大学，斯坦福大学，加州洛杉矶分校和加州圣芭芭拉分校，即使在整个70年代互联网上也只有几百台主机而已。
这样一来，解决名称解析的问题就可以使用一个非常简单的办法，每台主机利用一个Hosts文件就可以把互联网上所有的主机都解析出来。
这个Hosts文件现在我们还在使用，路径就在\Windows\System32\Drivers\etc目录下，如下图所示就是一个Hosts文件的例子，我们在图中可以很清楚地看到Hosts文件把[url][/url]解析为202.108.22.5。
在一个小规模的互联网上，使用Hosts文件是一个非常简单的解决方案，一般情况下，斯坦福大学的主机管理员每周更新一次Hosts文件，其他的主机管理员每周都定时下载更新的Hosts文件。
但显然这种解决方案在互联网规模迅速膨胀时就不太适用了，就算现在的互联网上有一亿台主机，想想看，如果每个人的计算机中都要有一个容纳一亿台主机的Hosts文件！呵呵，是不是快要崩溃了！互联网的管理者们及时为Hosts文件找到了继任者－DNS，DNS的设计要求使用分布式结构，既可以允许主机分散管理数据，同时数据又可以被整个网络所使用。
管理的分散有利于缓解单一主机的瓶颈，缓解流量压力，同时也让数据更新变得简单。
DNS还被设计使用有层次结构的名称空间为主机命名，以确保主机域名的唯一性。
DNS的设计要求您已经看到了，下面我来具体解释一下。
DNS的前身Hosts文件是一个完全的分散解析方案，每台主机都自己负责名称解析，这种方法已经被我们否定了。
那我们能否使用一个完全集中的解析方案呢？也就是全世界只有一个Hosts文件，互联网用户都利用这个文件进行名称解析！这个方案咋一听还是有可取之处的，至少大家都解脱出来了，不用每台计算机都更新那个Hosts文件了，全世界只要把这个唯一的Hosts文件维护好就完事大吉了。
实际上仔细考虑一下，有很多的问题，例如这台存放Hosts文件的主机会成为性能瓶颈，面临巨大的流量压力，而且每个域名解析的结果都要通过这个文件进行更新，更新的速度可想而知不会太及时。
因此，DNS也没有采用这种完全集中的解析方案。
目前DNS采用的是分布式的解析方案。
具体是这样的，互联网管理委员会规定，域名空间的解析权都归根服务器所有，也就是说，根服务器对互联网上所有的域名都享有完全的解析权！且慢，有读者要提问了，那这个根服务器不就相当于全世界唯一的Hosts文件了吗？呵呵，不要着急，根服务器用了一个简单的操作，就改变了这种结构。
根服务器使用的是什么操作？委派！下图就是根服务器委派的示意图，如下图所示，根服务器把com结尾的域名解析权委派给其他的DNS服务器，以后所有以com结尾的域名根服务器就都不负责解析了，而由被委派的服务器负责解析。
而且根服务器还把以net，org，edu，gov等结尾的域名都一一进行了委派，这些被委派的域名被称为顶级域名，每个顶级域名都有预设的用途，例如com域名用于商业公司，edu域名用于教育机构，gov域名用于政府机关等等，这种顶级域名也被称为顶级机构域名。
根服务器还针对不同国家进行了域名委派，例如把所有以CN结尾的域名委派给中国互联网管理中心，以JP结尾的域名委派给日本互联网管理中心，CN，JP这些顶级域名被称为顶级地理域名。
每个被委派的DNS服务器同样使用委派的方式向下发展，例如和讯公司想申请使用域名，这时和讯就要向负责.com域名的DNS服务器提出申请，只要还没有被其他公司或个人使用，而且申请者按时足额缴纳了费用，负责.com域名的服务器就会把域名委派到和讯公司自己的DNS服务器60.28.251.1。
只要DNS服务器使用委派，域名空间就会逐步形成现有的分布式解析架构。
这种架构把域名解析权下放到各公司自己的DNS服务器上，既有利于及时更新记录，同时对平衡流量压力也很有好处。
那么，在这种分布式的解析结构中，DNS服务器如何进行域名解析呢？换句话说，其他的DNS服务器怎么知道由60.28.251.1负责解析的域名呢？如果一个互联网用户想解析域名[url][/url]，过程是怎么样的呢？如下图所示，用户把解析请求发送到自己使用的DNS服务器上，DNS服务器发现自己无法解析[url][/url]这个域名，于是就把这个域名发送到根服务器请求解析，根服务器发现这个域名是以com结尾的，于是告诉查询者这个域名应该询问负责com的DNS服务器。
这时查询者会转而向负责com的域名服务器发出查询请求，负责com域名的DNS服务器回答说[url][/url]是以结尾的域名，以结尾的域名已经被委派到DNS服务器60.28.251.1了，因此这个域名的解析应该询问60.28.251.1。
于是查询者最后向60.28.251.1发出查询请求，这次应该可以如愿以偿了，60.28.251.1会告诉查询者所需要的答案，查询者拿到这个答案后，会把这个查询结果放入自己的缓存中，如果在缓存的有效期内有其他DNS客户再次请求这个域名，DNS服务器就会利用自己缓存中的结果响应用户，而不用再去根服务器那里跑一趟了。
以上介绍的域名解析过程我们可以通过一个实验来加以说明，Berlin是一个DNS 服务器，IP地址为192.168.1.200，其他IP参数如下图所示。
我们现在用Berlin 来解析一个域名，我们用抓包工具ethereal追踪一下域名解析的轨迹。
在DNS服务器上查询[url][/url]，如下图所示，DNS服务器已经解析了这个域名，但到底解析的过程是什么样的呢？向下看！打开抓包工具Ethereal，如下图所示，我们看到第8条记录显示DNS服务器Berlin向198.41.0.4发出了一个查询请求，请求解析[url][/url]，198.41.0.4何许人也，13个根服务器之一！接下来看第9条记录，198.41.0.4给Berlin一个回应，告诉了Berlin这个域名解析问题应该询问负责com区域的DNS服务器，而且198.41.0.4还给出了负责com区域服务器的域名和IP地址。
接下来的第10条记录显示了Berlin向192.55.83.30发出了域名解析请求，从上图可知，192.55.83.30就是负责com区域的域名服务器之一，这次查询会有什么样的回应呢？从下图的第11条记录可以看出，负责com区域的域名服务器告诉Berlin，以结尾的域名已经委派出去，现在有四个服务器负责，Berlin可以向这四个服务器中的任何一个提出查询请求。
从第12条记录可以看出，Berlin这次向59.173.14.26提出了查询请求，59.173.14.26就是上图中提到的负责区域的四个服务器之一。
这次查询会有什么样的结果呢？如下图的第13条记录所示，这次查询终于有了结果，负责的59.173.14.26终于告诉Berlin，[url][/url]对应的IP是60.28.250.55。
通过这个实验，希望大家能够更好地理解DNS的分布式结构，下篇博文中我们要讨论一下如何DNS服务器的常用记录类型。
详解DNS的常用记录（上）：DNS系列之二在上篇博文中，我们介绍了DNS服务器的体系结构，从中我们了解到如果我们希望注册一个域名，那么必须经过顶级域名服务器或其下级的域名服务器为我们申请的域名进行委派，把解析权委派到我们的DNS服务器上，这样我们才可以获得对所申请域名的解析权。
本文中我们将再进一步，假设我们已经为公司成功申请了一个域名，现在的解析权被委派到公司的DNS服务器202.99.16.1，那我们在202.99.16.1服务器上该进行什么样的配置呢？一安装DNS服务器首先我们要在服务器上安装DNS组件，服务器的TCP/IP配置如下图所示。
安装DNS组件非常简单，依次点击控制面板－添加或删除程序－添加/删除Windows组件－网络服务，如下图所示，选择“域名系统”即可。
二创建区域DNS服务器创建完毕之后，我们接下来就要创建DNS区域了，区域是DNS服务器所负责的名称空间，DNS服务器有正向区域和反向区域，正向区域负责把域名解析为IP，而反向区域负责把IP解析为域名。
DNS区域有三种类型，正向区域，反向区域和存根区域。
要理解区域类型，先要明白DNS服务器有主服务器和辅助服务器的区别。
一般情况下，企业申请域名时会考虑配备两个DNS服务器，一个是主服务器，另一个是辅助服务器。
一般的解析请求由主服务器负责，辅助服务器的数据是从主服务器复制而来的，辅助服务器的数据是只读的，当主服务器出现故障或由于负载太重无法响应客户机的解析请求时，辅助服务器会挺身而出担负起域名解析的任务。
现在我们回过头来解释一下什么是主要区域，主服务器使用的区域就是主要区域，同样，辅助服务器使用的区域是辅助区域。
存根区域可以看做是一个特殊的，简化的辅助区域，具体区别我们在后续博文中会加以介绍。
一般我们使用较多的是正向区域，而且从逻辑上考虑，必然是先创建主要区域，因为辅助区域和存根区域都需要从主要区域复制数据，因此我们现在的任务是要为区域创建一个正向的主要区域。
如下图所示，我们在DNS服务器上选择创建一个正向区域。
出现新建区域向导，点击下一步继续。
选择创建一个主要区域。
区域名称和申请的域名是一样的，。
区域数据文件是.dns，区域内的所有记录都存储在这个文件里，注意，这个文件我们以后会用到的。
向导询问是否允许区域动态更新，一般来说，如果DNS区域在企业内网使用，我们会允许动态更新；如果用于Internet，那么一般不需要动态更新。
如下图所示，区域创建完毕。
区域创建完毕之后，如下图所示，区域中只有一个NS记录和一个SOA记录，我们接下来要做的工作就是在区域中创建适当的DNS记录。
三创建记录DNS记录是DNS区域数据的具体表现形式，我们接下来为大家介绍几种最常见的DNS记录，大家掌握了这些记录就可以基本掌握DNS的基本应用了。
