DNS服务相关概念详解

实验环境：RHEL 32Bit

DNS服务相关概念详解 DNS是一种域名解析服务，DNS服务的核心以及DNS服务的标准都是基于一个软件来实现的，这个软件叫做BIND(Berkeley Internet Name Domain)，互联网上几乎所有的DNS服务都是由BIND来构建的，虽然也有其它的DNS服务构建标准，但是它们的使用语法以及工作机制都和BIND非常接近。
·Linux服务器和Windows服务器的比较
Linux服务器在没有SELinux的时候它的安全级别和Windows服务器的安全级别是一样的，所以说在没有SELinux的情况下，Linux并不比Windows安全，但是Linux加上SELinux这种机制之后，可以提升操作系统的安全级别，使得Linux服务器变得比Windows服务器更加的安全，而且作为服务器来使用的时候Linux要比Windows稳定的多，如果服务器本身支持长时间无需关机的话，Linux服务器可以成年累月的在线而无需重启，但是Windows服务器绝对做不到这一点，它需要经常性的重启，这对于一些维护关键性服务的核心服务器来讲是绝对不可以接受的，但是对于一些小型的IDC机房来说Windows服务器是可行的，因为每隔一段时间重启一次服务器不会有多大的影响。

·DNS(Domain Name Service/Server：域名服务/器)
·域名

www.baidu.com这是一个主机名，而不是一个域名，域是一个范围，而不是一个特定的对象，故baidu.com才是一个域名，.com也是一个域名，因为在.com这个域内包含了baidu这个个域，baidu.com就是一个域，也称为一级域，.com也称为顶级域，而www则才是baidu.com这个域内的一台主机，baidu.com这个域内还可以有其他主机的存在，而这些所有的主机综合起来就构成了baidu.com这个域，故www.baidu.com这种格式的称呼精确来讲一般不叫做域名而叫做主机名或FQDN(Full Qualified Domain Name:完全限定/合格域名)，而DNS的作用就是用来完成这种名称的解析的：


·名称解析

简单来讲名称解析就是名称转换，但是这个转换的背后涉及一个查询的过程，所以称为域名解析，这个查询的过程依赖的是DNS服务器内部的数据库，DNS名称解析实际上就是实现从FQDN<-->ip地址的双向转换，DNS所提供的名称转换是双向的，而且双向转换使用的是两种完全不同的机制来实现的，这就是DNS名称解析的过程，故为了实现名称解析的过程，通常都会在DNS服务器内部有一个数据库来保存FQDN和ip地址的对应关系，当我们访问对应的FQDN的时候，只需要在该数据库中查找FQDN对应的ip地址即可，这就是正向名称解析的过程，但是能够实现名称解析的服务不只有DNS，用户名和用户id号之间的转换也称为名称解析，系统上的相关服务名称和它们所对应的端口号之间的转换过程也称为名称解析，但是要想在计算机上面实现以上各种各样的名称解析，必须有一个数据库来存储这种对应关系，由以上我们可以知道计算机内部需要用到名称解析的机制有很多，因此为了计算机管理方便，就需要有一个统一的框架来管理这些各种各样的名称解析机制，于是就出现了nsswitch。

·nsswitch
nsswitch是一个给多种需要名称解析的机制提供名称解析服务的平台，它仅仅是提供了一个平台，并不提供实际的名称解析服务，它就相当于是淘宝这个平台，而它上面的每一种名称解析机制就相当于是淘宝上的一个一个的店铺，真正提供名称解析服务的是这样的一个一个店铺而不是nsswitch，如果我们的应用程序需要用到名称解析服务，只需要到nsswitch上面，根据nsswitch的定义找到相关的名称解析机制即可：



nsswitch上面能够给我们提供域名解析服务的机制有两个，libnss_files.so和libnss_dns.so，这是两个库文件，它们是需要被调用的，而调用者就是应用程序，应用程序和名称解析机制彼此之间的关联关系就是依靠nsswitch建立的，而nsswitch展现给用户的只是一个配置文件，/etc/nsswitch.conf：



nsswitch的配置文件中有一行：




这一行中的dns表示调用libnss_dns.so这个库去实现名称解析(即根据DNS服务器内部的数据库去实现名称查找与转换)，files表示调用libnss_files.so这个库去实现名称解析(即根据/etc/hosts文件这个数据库去实现名称的查找与转换)，dns和files这两项还是有前后关系的，哪个在前表示优先使用哪种机制去完成名称解析，于是当我们去访问一个主机的FQDN的时候，FQDN本身无法与主机的ip地址建立联系，但是它会去调用对应的库文件完成FQDN和ip地址之间的转换，这种机制在我们本机上叫做stub resolver(名称解析器)。

·stub resolver
stub resolver叫做名称解析器，是一个软件，它会通过调用某个库来完成名称解析的功能，而调用哪个库，是由nsswitch.conf文件里面的配置决定的，stub resolver会根据nsswitch.conf这个配置文件里面的配置次序去调用某个库，接着再去查找相关的数据库文件，如果查找到对应关系，则解析成功，否则就会去调用下一个次序对应的库，再去查找下一个库对应的数据库文件，例如当我们在本机上使用ping www.baidu.com命令的时候，ping命令就会借助于本地的stub resolver去完成名称的解析。

互联网早期，接入网络的主机数量很少，所有的名称解析过程都是依靠hosts文件来实现的，那时每一台连入网络的主机都维护有一个hosts文件。

·hosts文件
hosts文件在Windows、Linux以及Unix主机当中都是存在的，该文件中记录了互联网中每一个主机的FQDN和它的ip地址的对应关系：




hosts文件的格式如下：

IPADDR FQDN Aliases(主机别名)

因此解析主机的FQDN的时候是根据该文件中的FQDN来查找主机对应的ip地址，在小规模的网络中，hosts文件有效工作了很长一段时间并且足够完成名称解析的功能了，但是随着互联网的发展接入到网络中的主机数量越来越多，如果每个主机都随便给自己起名字，那么彼此间的通信就会变的非常的困难，于是为了解决这种问题就出现了名称地址管理机构IANA。

·IANA
IANA是一个有美国政府背景的名称地址管理机构，但是随着名称解析服务已经成为了整个互联网正常运行的根基，所以后来将这种名称分配的功能被转交给了一个民间组织叫做ICANN，目前我们互联网上的名称以及地址的分配都是依靠ICANN来实现的。

·ICANN
ICANN是用来管理最顶级的名称/域的组织，它在很多地区还有很多二级子机构，这些组织的出现是为了能够规范名称和地址的对应关系，所以如果某台主机想要加入到网络中去和互联网中的其他主机通信的话首先该主机自身得有一个ip地址，因此首先得向IANA申请一个ip地址，接着再申请一个FQDN，由此就由ICANN来维护这个FQDN和ip地址之间的对应关系，所有的这种对应关系就组成了一个数据库，这个数据库就由ICANN来进行维护，该数据库中保存着互联网中每一台主机的FQDN和它的ip地址的对应关系，但是如果ICANN中有一台新加入的主机，那么互联网中的其他主机是如何知道这个新加入的主机呢？早期的IANA通过ftp服务器保留了一个hosts文件，故互联网上的原有主机可以通过定期的去该ftp服务器上下载更新自身的hosts文件就可以完成新的名称解析功能了，但是随着互联网的规模越来越大，仅仅依靠一个或多个这样的服务器维护的hosts文件来保证互联网上正常的名称解析服务功能是不可行的，为了解决上述的这种问题IANA设计了一种全新的结构能够实现将互联网上的所有主机的名称组织成一种分布式的结构，将DNS原本集中的数据库转换成了一个分布式的数据库。

·分布式数据库
所谓分布式数据库就是每一个上级数据库只需要直接管理它的直接下级数据库即可。

DNS的逻辑组成结构类似于我们Linux操作系统上的根目录的层级结构，二者的索引方式也很类似，对于根目录结构来说查找目录结构中的任何节点都是从根目录开始查找，而DNS逻辑结构中的索引方式则是从根域开始，在DNS的逻辑结构中是由域的由大到小进行索引的，并且这种分布式的层级结构是一种自顶向下的层级结构，上级仅知道它的直接下级的存在，而下级则无法知道上级的存在(www.magedu.com.这是一个完整的FQDN的格式，只不过平时我们在使用的时候最后的那个点可以省略而已，www称为FQDN，magedu.com.称为一级域名，.com.称为顶级域名，.则称为根域），但是每一个级别都知道根域的存在，而且根域只需要知道顶级域在哪里就可以了。
·DNS的分布式层级逻辑结构




.叫做根域，根域下面的一层叫做顶级域(TLD)。

·TLD(Top Level Domain:顶级域)

TLD一共分为三类：

1，组织域：.com、.org、.net、.cc

2，国家域：.cn、.iq(伊拉克)、.ir(伊朗)、.jp(日本)

3，反向域：反向域是将ip地址转换为FQDN时专用的域，DNS刚刚出现的时候只能够将FQDN转换为ip地址，反之则不可以，后来基于指针的机制实现了将ip地址转换为FQDN的功能，正向解析和反向解析在DNS服务器内部使用的不是一个数据库，二者分别使用一个单独的数据库，从FQDN-->ip地址的解析称作正向解析，而从ip地址-->FQDN的解析称作反向解析，TLD也叫做一级域，所有的TLD都是划分给对应的组织来进行管理的，例如.com.、.org.等等都是由ICANN来管理的，或者由ICANN授权给某个机构来进行管理，国家域也是由ICANN授权给下辖的某个机构来进行管理的，例如.cn.就是由ICANN授权给中国的域名管理机构进行管理的，DNS的逻辑机构中的主机名索引是自底向上的，而授权则是自顶向下的。




如上图所示，当www主机想要和st1主机首次进行通信的时候，首先www主机属于magedu这个域内，故www主机首先会向magedu这个域的DNS服务器发起名称解析请求，这时DNS服务器会向根域DNS服务器发起请求，由于st1主机在.com域的ibm域内，故根域只会给magedu这个域的DNS服务器返回.com域的DNS服务器的ip地址，此时magedu的DNS服务器会拿着该ip地址去向.com域的DNS服务器发起请求，.com域的DNS服务器就会给magedu的DNS服务器返回ibm域的DNS服务器的地址，此时magedu的DNS服务器就会拿着该ip地址向ibm域的DNS服务器发起请求，这个时候ibm域的DNS服务器就会返回st1主机的ip地址给magedu域的DNS服务器，magedu域的DNS服务器就会将该ip地址返回给www主机并将该对应关系在自己的主机上缓存一段时间，在下次www主机发起同样的请求时，DNS服务器可以直接向它返回答案，此时www主机就可以与st1主机建立通信了，在这个过程中，www主机的查询目标主机地址的方式称为递归的查询方式，而magedu域的DNS服务器的查找方式称为迭代的查询方式，因此互联网上的主机查询是分为两段的，对于客户端来主机来讲是递归查询，而对于DNS服务器来讲是迭代查询的，DNS服务器缓存目标主机的ip地址的时间是有限制的，如果在我们的DNS服务器缓存的限制时间内，目标主机的ip地址发生了改变，那么我们同过缓存返回的答案就会失效，就得重新进行查询，所以我们本地DNS服务器中缓存的答案称为非权威答案，只有我们要访问的目标主机的直接归属域的DNS服务器返回的答案才称为权威答案，而且缓存时间是由目标主机的直接归属域的DNS服务器在向我们返回权威答案的时候一起返回的，它会明确告诉我们缓存时长为多久，这个缓存时长叫做超时时长(TTL值)。
DNS提供的查询机制一共有三种：

1，来自外部域主机查找本域内主机的查询方式

2，本域内主机查找外部域主机的查询方式

3，本域内主机查找本域内主机的查询方式

其实一台DNS服务器可以同时对多个域进行解析，只需要在该DNS服务器里面同时维护多个数据库即可，我们某个域内的主机想要和其他主机进行首次通信的时候，一般都会进行名称的查询与解析，一般情况下都会先向根域的DNS服务器发起请求，此时根域服务器就会从自己维护的那个数据库里面返回下一级相对应的域的DNS服务器的ip地址，依次类推，每一级都会返回相对应的下一级域的DNS服务器的ip地址，而每一级域的相对应的下一级域的DNS服务器的ip地址都保存在上一级域的DNS服务器所维护的数据库当中，这种类型的数据库称为授权数据库。

·授权数据库
授权数据库中明确说明了管理一个域的DNS服务器的ip地址是什么。
一个ip地址可以对应多个主机名，而一个主机名同样可以对应多个ip地址，比如DNS的高级功能：负载均衡，因此主机名和ip地址是多对多的关系。

·DNS小节
1，查询功能

⑴递归查询

⑵迭代查询

2，解析功能

⑴FQDN->ip：正向解析

⑵ip->FQDN：反向解析

3，查询的方式是两段式

⑴客户端的递归查询

⑵DNS服务器的迭代查询

一般是先递归后迭代。

4，DNS服务器的数据库是一个分布式数据库

特点：上级域仅知道自己的直接下级域的存在，而下级域则不知道它的上级域的存在，默认情况下所有的下级域只知道根域的存在。

·DNS服务器的工作方式
1，接受本地客户端的查询请求

这是一种递归查询的方式。

2，外部客户端的请求

请求方式有两种：

⑴请求权威答案

权威答案的结果也有两种：

①肯定答案+TTL值

②否定答案+TTL值

⑵请求非权威答案
递归客户端一般都是同一个域内部的客户端主机，为了不使得自己域的DNS服务器太过繁忙，一般情况下DNS服务器只允许自己允许的客户端主机进行递归查询，非递归客户端一般都是外部域的客户端主机，stub resolver发起的查询请求一般都是要求递归查询的，根域DNS服务器和顶级域DNS服务器一般都不允许被递归查询，只可以进行迭代查询，为了安全起见不会为任何主机提供递归查询服务，递归查询的请求发起方只需要发起一次请求等待答案即可，而迭代查询的请求发起方需要发起多次请求自己去寻找答案，所以说DNS的查询是两段的，先递归后迭代，/etc/resolv.conf文件中的nameserver后面指向的主机，一定是允许和我们本机进行递归查询的DNS服务器。
·DNS的逻辑结构
DNS的逻辑结构是由根域、顶级域以及一级域所组成的，顶级域还分为三类：

1，组织域

2，国家域

3，反向域

这就是DNS的整个逻辑结构。

·DNS的物理结构
真正提供根域DNS服务的是一堆根域DNS服务器，称为root-server，我们的客户端主机在进行DNS查询的时候，如果本地没有或者本地的DNS服务器失效的话，请求通常都会提交给根服务器，所以DNS根服务器的安全性至关重要，全球一共只有13台DNS根服务器，从a.root-server.net到m.root-server.net一共13台，DNS根服务器是全球互联网正常运行的根基，所以DNS根节点是一定不可以出问题的，根域下属的所有域都是由根域直接授权的，DNS逻辑结构上的每一个级别的域，为了保证它们的安全性都可能会有多台服务器来共同维护，而且这多台服务器上的内容都得完全一样。

·DNS服务器的常见类型
DNS的服务器是有主从结构的，故从这一点说起每一个域的DNS服务器都有主从之分：

1，主DNS服务器

2，辅助DNS服务器

我们上面说过，DNS逻辑结构中的每一个节点为了保证请求不落在一个服务器上导致服务器宕机，所以每一个节点都会有多个DNS服务器来进行维护，但是这多个服务器是有主从之分的，原因如下：

如果此时我们在本地新加入了一台主机，我们应该将这台主机的FQDN和它的ip地址之间的对应关系添加到我们本地的所有DNS服务器上面去，如果我们本地的DNS服务器数量很少，那么还是可以实现的，如果我们本地的DNS服务器的数量非常巨大，那么我们这么做就会非常麻烦，但是DNS服务器的主从结构就可以解决这种问题，我们每一次在本地新加入一台主机的时候，我们可以将该对应关系添加到主DNS服务器上面，接下来的辅助DNS服务器可以到主DNS服务器上面去同步该信息即可，客户端向服务器请求数据的机制叫做拉取(pull)的机制，而服务器主动向客户端发送数据的机制叫做推送(push)的机制，辅助DNS服务器的工作机制就是定期到主DNS服务器上面去请求数据，如果主DNS服务器发生宕机，辅助DNS服务器还是会定期到主DNS服务器上发起请求，如果长时间得不到主DNS服务器的响应，辅助DNS服务器就会自杀。
辅助DNS服务器是如何到主DNS服务器上面进行数据同步的呢？二者的数据同步依靠的是主从DNS服务器上的数据信息的版本号的比较，主DNS服务器上面的数据有一个版本号。辅助DNS服务器上的数据也有一个版本号，一旦主DNS服务器上的数据发生改变它就会把该版本号加一，辅助DNS服务器一旦发现主DNS服务器上面的数据的版本号和自己的不同，那就意味着主DNS服务器上的数据发生了改变，因此我们得在主DNS服务器上面定义5个属性(主DNS服务器上的任何数据都可以手动改变，而辅助DNS服务器上的数据都不可以手动改变，辅助DNS服务器如果发现自己的数据版本号比主DNS服务器上的数据版本号小的话，那就意味着主DNS服务器上的数据更新了)：

1，序列号(serial number)，即数据版本号

2，refresh time

检查的时间周期，即每隔多长时间，辅助DNS服务器到主DNS服务器上检查一次数据版本号

3，retry time
重试时间，即辅助DNS服务器在没有得到主DNS服务器响应的时候，重新发起请求的间隔时间，这个时间小于refresh time。

4，expire

过期时间，到达过期时间之后，辅助DNS服务器就会认为主DNS服务器宕机了

5，nagtive answer TTL

否定答案的缓存时间
因此主从服务器之间能够完成彼此间的数据同步，一般来讲就要定义这5个属性信息。

DNS服务器还有一种类型叫做DNS缓存服务器，缓存服务器不提供任何权威答案，只提供DNS缓存服务。

还有一种类型的DNS服务器叫做转发器，转发器不缓存名称解析信息，而只提供将客户端主机的请求转发至目的地的服务，所有提供地址解析服务的DNS服务器都是由自己的上级域的DNS服务器中的授权数据库直接授权的。
DNS服务器的数据库中的每一个条目都有固定的格式，而且在这些条目中还得标明每一个条目是用来做什么的，比如某些条目对应的是一个www服务器，某些条目对应的是一台DNS服务器或邮件服务器等等，数据库中的每一个这样的条目叫做一个资源记录。

·资源记录(Resource Record，简写为RR)
DNS服务器内部数据库的每一个条目都是一个资源记录，资源记录的格式如下：

第一段：NAME(名称)

第二段：TTL值->每一条记录都有自己的TTL值，而且TTL值是可以省略的

第三段：IN->表示Internet

第四段：RRT(Resource Record Type)->表示资源记录类型

第五段：VALUE->表示名称对应的数据

例如：

NAME TTL IN RRT VALUE

www.magedu.com.(FQDN必须写全) 600 IN A 1.1.1.1 --> 正向解析

1.1.1.1 600 IN PTR www.magedu.com. -->反向
以上两种过程统一叫做名称解析，正向解析的名称是www.magedu.com.，值是1.1.1.1，而反向解析的名称是1.1.1.1，值是www.magedu.com.。
· RRT

资源记录类型用来标识我们所要解析的名称的值，资源记录类型的种类如下：

1，SOA(Start Of Authority:起始授权)记录

SOA记录用于标识一个区域内部，主从服务器之间如何进行数据同步以及起始授权的对象。

SOA记录的格式如下：

ZONE NAME TTL IN SOA 主DNS服务器 邮箱地址 (serial number

refresh time

retry time

expire time

na ttl)

SOA记录必须出现在DNS服务器数据库中的第一条，以便于标明本区域内多个DNS服务器是如何进行数据同步的。

SOA记录中的时间单位：

H(小时)、M(分钟)、D(天)、W(周）以及默认时间单位秒钟

SOA记录中的邮箱地址的格式：

SOA记录中的邮箱地址中不能使用@符号，因为@符号在SOA记录中有特殊的意义，@符号在SOA记录表示的就是ZONE NAME，它是一个通配符，用来通配当前区域的名称，所以在SOA记录中邮箱地址中的@使用.来代替，比如admin@magedu.com就可以写成admin.magedu.com.。

SOA记录格式示例：

ZONE NAME TTL IN SOA 主DNS服务器 邮箱地址 5个属性

@ 600 IN SOA ns1.magedu.com. admin.magedu.com. (20170114

1H

5M

1W

1D)

serial number的长度最长不可以超过10位，serial number的后面可以使用";"添加注释信息。

2，A(Address)记录

A记录用来标识FQDN-->ipv4地址的名称解析，A记录是最常用的RRT，只要我们需要将主机的FQDN转换为ipv4地址，那么都会使用到A记录。

3，AAAA记录

AAAA记录用来标识FQDN-->ipv6地址的名称解析。

4，PTR(PoinTeR：指针)记录

PTR记录用来标识ip(ipv4或者ipv6都可行)-->FQDN的名称解析。
5，NS(Name Server)记录
NS记录用于标识DNS服务器，NS记录的格式如下：
ZONE NAME TTL IN RRT VALUE
magedu.com. 600 IN NS ns.magedu.com.
ns.magedu.com. 600 IN A 1.1.1.2
即实现ZONE NAME --> FQDN --> ip的转换，NS记录一定得和A记录成对出现，NS记录的名称一定是一个区域名，而值一定是一个FQDN。
6，MX(Mail eXchanger：邮件交换器)记录
MX记录用于标识邮件服务器，MX记录的格式如下：
ZONE NAME TTL IN RRT pri VALUE
magedu.com. 600 IN MX 10 mail.magedu.com.
mail.magedu.com. 600 IN A 1.1.1.3
即实现ZONE NAME --> FQDN --> ip的转换，邮件服务器有优先级的概念，即一个区域内可能会有多台邮件服务器，而访问哪一台服务器是由优先级来决定的，0-99数字越小优先级越高，和NS记录一样，MX记录也必须和A记录成对出现。
7，CNAME(Canonical Name：正式名称)记录
CNAME记录用于标识一个主机的FQDN的别名，所以CNAME记录又叫做别名记录，CNAME记录格式示例：
CNAME TTL IN RRT VALUE

www2.magedu.com. 600 IN CNAME www.magedu.com.
表示www.magedu.com.是www2.magedu.com.的正式名称，而前者是后者的别名。
DNS服务器内部的数据库文件就是由这些所有类型的资源记录组成的。

·域和区域

域：Domain，区域：Zone，站在DNS的角度，域是一个逻辑概念，区域是一个物理概念，比如说我们申请了一个域名，我们就有了一个域，但是在这个域内，我们不仅会进行正向解析，还可能会进行反向解析，而在这个域背后的DNS服务器中进行正向解析和反向解析的数据库文件是不同的，所以我们就得在域内维护两个数据库文件，一个数据库文件进行正向解析，而另一个数据库文件进行反向解析，在这个域内进行正向解析的数据库文件就叫做正向区域，进行反向解析的数据库文件就叫做反向区域，正向区域和反向区域就组成了一个域，所以说域是一个逻辑概念，而区域是真真实实存在的，但是区域和域之间没有必然的包含关系：



在DNS逻辑结构的同一级别上，域的概念可能会包含区域的概念，但是下一级域是由上一级区域直接授权的，并且正向区域的授权和反向区域的授权是分开进行的，它又包含于上一级的区域，所以说域和区域没有绝对的包含关系，域只是一个逻辑上的概念，而真正工作的只是区域。

DNS逻辑结构的每一级别的正向区域的名称和域名称是相同的，但是反向区域名称和域名称却是不一样的，比如我们现在向ICANN申请了一个域名和一个网段如下：

magedu.com. 192.168.0.0/24

如何实现我们这个网段内的主机能够被互联网上的其他主机访问到：

第一步，首先得在.com.域上获得直接授权，并且在.com.域上指定magedu.com.这个域的DNS服务器的ip地址。
magedu.com. 600 IN NS ns.magedu.com.

ns.magedu.com. 600 IN A 192.168.0.10

第二步，将某台主机的ip地址设置为192.168.0.10,那么这台主机就是我们这个域的DNS服务器。

接下来在该主机上安装DNS服务软件，然后开始建立DNS服务器的数据库文件，此时这台主机就可以负责我们整个域内其他所有主机的名称解析。

第三步，开始规划域内的主机

假设在这个域内我们有两台主机：

一台www主机：192.168.0.1

一台mail主机：192.168.0.2

接下来我们在DNS服务器上面规划这两台主机的区域文件，规划示例：

无论是正向区域文件还是反向区域文件，第一条资源记录一定是SOA记录，通常第二条资源记录就是NS记录，正向区域的第三条资源记录就是A记录，反向区域的资源记录就是PTR记录，正向区域和反向区域还可以有CNAME记录。

1，正向区域的格式

magedu.com. IN SOA

正向区域的SOA记录的名称还可以简写为@，即：

@ IN SOA

A记录的FQDN也可以简写，比如在magedu.com.这个域内就可以如下简写：

www IN A 192.168.0.1

A记录简写时候的区域名称不可以加点，但是全写的区域名称必须要加点。

2，反向区域的格式

反向区域的区域名称和域名称是不一样的，反向区域的区域名称是将本域的网络地址反过来写并加上特定后缀，反向区域格式示例:

ZONE NAME TTL IN RRT VALUE

0.168.192.in-addr.arpa. 600 IN SOA ...

反向区域的PTR记录格式示例：

192.168.0.1 600 IN PTR www.magedu.com.
反向区域的PTR记录中FQDN一定不可以简写，因为如果简写为www，它会将FQDN自动补全为反向区域SOA记录中的区域名称即：www.0.168.192.in-addr.arpa.从而出错，但是反向区域的PTR记录中的ip地址可以简写，比如：
192.168.0.1 600 IN PTR www.magedu.com.
中的ip地址可以简写为1,1不加点，它会自动补全为1.0.168.192.in-addr.arpa.

区域文件就是资源记录的集合，区域文件中的第一条记录一定都是SOA记录，在正反向区域文件里面SOA记录的格式除了名称以外其余的都是相同的，MX记录只可以定义在正向区域中，而NS记录正反向区域都可以定义，A记录只能定义在正向区域中，PTR记录只能定义在反向区域中。

·DNS主从服务器
一个域中的DNS服务器，到底哪一台是主服务器，哪些是从服务器是和区域相关的，而且辅助服务器多长时间到主服务器上面同步一次数据取决于区域文件里面的SOA记录中的refresh time，主DNS服务器上面的数据一旦发生更改，是需要向从DNS服务器进行通知的，这样可以保证主从DNS服务器上的数据始终保持一致，主从DNS服务器上的数据传送过程称为区域传送。

·区域传送
区域传送的类型有两种：

1，完全区域传送(axfr:all transfer)->主DNS服务器将自己的所有数据传送给一台新的从DNS服务器。

2，增量区域传送(ixfr:incremental transfer)->主DNS服务器只把自己发生改变的那部分数据传送给从DNS服务器。
在区域传送的过程中是通过区域类型来标识主从DNS服务器的。

·区域类型
针对于传输数据过程中的区域类型有以下几种：

1，主区域->master(主DNS服务器)

2，从区域->slave(从DNS服务器)

3，提示区域->hint:该区域用于定义根DNS服务器的位置，因为客户端主机一旦找不到目标主机的位置就得向根DNS服务器发起请求。

4，转发区域->forward:当客户端主机发情查询请求时，无需每次都向根DNS服务器发起请求，而可以直接向目标主机的域DNS服务器发起请求。