关于DNS服务器我想大家并不陌生，通常情况下我们都只知道DNS服务器是域名解析用的，如果我们没有DNS服务器那么我们想要访问互联网上的网站什么的就不得不去记忆这些网站的IP地址了。对于我们而言众多的IP地址是很难记忆的而且也不方便。所以就出现过了DNS服务器。主要实现把主机名解析成IP地址，这样就方便我们在网上通信。
通常情况下我们之用到了DNS服务器的正向解析功能，而DNS还有方向解析功能，就是把IP地址解析成主机名的。
那么接下来就来跟大家分享一下DNS的工作方式。
DNS是基于C/S架构的，服务端是由程序来实现的，而客户端则是一个共享库。
DNS默认是监听在UDP的53端口和TCP的53端口。
【名称解析】：解析主机名，说白了就是把一种名称转换成另一种名称的过程。
【名称】：就是字串或者数字（就是我们通常所理解的主机名或者IP）
【解析库】：存放名称和地址的对应关系（就是我们的DNS在解析过程中要解析库中查找名称和IP的对应关系）
【解析库存储方式】：1、文本文件存储（缺点：文件过大时查找过程较慢，而且在查找过程中会把文件加载至内存中，这样就占用了我们大量的内存）
2、关系型数据库（支持索引，这样查找起来就只用通过索引列表去查找，但是同样存在一个问题，如果我们的数据上千万行怎么办？这样创建出来的索引目录也会变得相当长，查找起来也是非常不方便的。不过还好关系型数据库支持多级索引，就是给索引再次创建索引。这样就会比较快。）
3、LDAP （这种方式是监听在TCP的389端口，LDAP的速度要比关系型数据库的快10倍不止，因此LDAP的用途就是某些站点拥有很多的用户的话，用来用户名的保存。）
【解析】：根据用户提供的一种名称，去查询解析库，以得到另一种名称。
如果是这样的话我们就会出现另外一个问题:
全球这么多的主机，那这些关系映射文件存放在哪呢？一台服务器存放行吗？
答案显然是不行的，众多的文件放在一台服务器上，天啊它不坏才怪，就算是不坏你也能想象出你的网速会有多快。
那么该怎么解决这个问题呢，DNS中才用了授权管理机制。
【DNS授权管理机制】：最大域就是根域，用.表示
接下来就是一级域，也就是顶级域（如果把根域比喻成皇帝的话，那么一级域就是宰相，一人之下万人之上。）
注：根域和顶级域是特殊的，不能由个人指定。
然后就是二级域三级域等，直到最后的主机（这些是可以由公司、组织、个人申请使用的）
【简述有权管理机制】：其实授权管理机制很好理解的，就像是皇帝治理国家一样，根域（皇帝）不需要知道各个主机（百姓）的名字，就算是累死他他也记不住啊，根域只需要知道自己直接管理的是谁就行了，别的什么也不用管。
【例】：一主机向根域申请访问www.baidu.com
根域收到申请后就问：www.baidu.com这个小弟是由谁负责的？
然后根域下的一个叫.com的大臣一看是自己辖区内的
于是这个大臣就回话：回禀吾皇此乃微臣之小弟
然后根域就说了：好了那这事就交给你了朕就不再管了
然后叫.com的这个大臣就开始问自己辖区内的小官：www.baidu.com这个小弟是谁带的？
然后有一个叫.baidu的家臣就回答：回禀老爷这是我的小弟
然后.com这个大臣就说了：好了这事交给你了老爷我就不再过问了
然后叫.baidu的这个家臣就在自己众多小弟中找到了叫www的小弟
然后就把这个小弟的IP地址返回给主机。
这样主机就知道了www.baidu.com的IP地址。
然后通过路由就能访问www.baidu.com了。
通过上边实例我想大家大致明白了DNS的工作方式，但是又有一个问题出现了。
上述实例过程中，主机具体是怎么问到www.baidu.com的地址呢？
这里有两种方式:
方式1（递归）：主机问根域->根域问一级域->一级域问二级域->二级域找到www.baidu.com把信息返回给一级域->一级域再把信息返回给根域->根域再把信息返回给主机
方:式2（迭代）：主机问根域，根域说你去找一级域
主机问一级域，一级域说你去找二级域
主机问二级域，二级域把www.baidu.com的信息告诉主机
到底是由哪种方式实现的呢？
实际上DNS是由这来那个种方式结合实现的。
【DNS具体实现过程】：事实上我们的主机是不能跟根域直接相连的，在解析过程中我们的主机事先是需要根域在哪的，主机在寻找根域的过程是用的递归的方式，而在找到根域后寻找目标主机时使用的是迭代方式。
注：如果在根域寻找目标主机的过程中使用的递归的方式的话，每次查找到后还要再次反馈给根域那么势必会增加根域服务器的负担，所以为了减少根域服务器的负担，在查找目标主机的过程中使用的是迭代的方式。
那么我们想要访问一台主机的话每次都这样去解析是很麻烦的一件事，而且势必会占用我们的带宽和时间。
有没有一种办法让我们第一次解析以后访问都不用再解析呢？
这就需要我们计算机中的缓存了，缓存的功能就是为了减轻DNS服务器的压力，第一次解析完成后就会把这条记录记忆在缓存中，下次访问的时候就会读取缓存中的记录，而不用去找DNS服务器解析。
同样的,DNS服务器中也有缓存，目的就是为了让一台主机访问后其他主机访问的时候不在去找根域解析。大大减轻了服务器的负担。
DNS中的名称与对应的主机名不要求是一样的，一个名称可以对应多个IP，一个IP也可以对应多个名称。
一级域（顶级域）：组织域.com .org .net .mil .edu .gou
国家域.cn .us .uk .ip .tw .hk .iq .ir
反向域：.in-addr.arpa（反向解析时使用）
域：domain （逻辑概念）
区域：zone （物理概念）
【区域解析库】每一行一个资源记录rr（resource record）
资源记录：有类型概念，用于标记此记录解析的属性
资源记录类型：
SOA：起始授权记录，一个区域文件只能有一个
NS ： name server 标记谁是解析服务器，可有多个
MX： 标记谁是域内的邮件服务器，可有多个（有优先级0-99）
A ： 主机名->IP的映射关系
PTR：IP->主机名的映射关系
AAAA：主机名->IPV6的映射关系
CNAME：正式名称 如：A CNAME B ：A是B的别名
注：A和PTR不能同时出现，一个解析库要么是正向解析库要么是反向解析库。
【权威服务器】：负责某域内全部主机的DNS服务器
【非权威应答】：通过本地缓存访问主机
【DNS服务器类型】：主DNS服务器（权威DNS服务器）、缓存服务器、转发器、从DNS服务器（备DNS服务器）
当然了一个网络中只有一台DNS服务器是不安全的，如果哪天这台服务器坏掉了，那么将造成整个网络无法访问外部网络主机。因此我们引入了从DNS服务器。
那么从DNS服务器上的库文件是从哪里来的呢？
既然是主服务器的备用，当然是要跟主服务器的库文件一致了。从服务器会去复制主服务器上的库文件。
如果在复制过程中数据传输出现点小问题，传输的数据是一些错误的怎么办？
所以区域间传输库文件的时候是要基于TCP这种可靠的链接。（这就是为什DNS还要监听在TCP的53端口）
那么在传输过程中是每次都要把全部的库文件传输过去还是只是把更新的库文件传输过去呢？
在区域间的传送分为两种：1、完全区域传送
2、增量区域传送
注：第一次的传送过程是完全区域传送，之后使用增量区域传送，只传送更新的库文件
那么从DNS服务器是怎么知道主服务的库文件有更新呢？
从服务器会定期发送请求，询问主服务器的库文件是否有改动，如果有改动那就开始传送更新的内容，如果没有更新则等待到下一个周期再次发送请求。
这样从服务器一次又一次的询问要是你是主服务器的话你也会烦死的吧！
其实主服务器的库内容发生变动的时候，主服务器会主动通知从服务器的，主服务器会告诉从服务器：我更新了，你来我这里更新吧。这就是DNS服务器的传送机制：周期性检查+通知
假如某天从服务器给主服务器发送请求,主服务器不理它，过了一段时间从发服务器再次请求,主服务器还是不理它怎么办？
这时从服务器就会很苦逼的一次又一次的发送请求，直到某天主服务器还是没有搭理从服务器，从服务器就认为主服务器一定是down了。这时从服务器也就随主服务器去了，不再工作了，整个网络陷于瘫痪状态。
资源记录类型：任何解析库的第一个文件必须为SOA（标记主DNS服务器）
【库文件通用格式】：
name [ttl] IN RRType 值
当前域名 缓存时长 记录类型 主机名
【记录类型格式】：
SOA：name当前区域名，可简写为@
值：主DNS的主机名，也可以是当前区域的区域名称
管理员邮箱
（serial number:解析库版本号
Refresh time：周期性同步间隔
Retry time ：重试时间间隔
Expire time ：过期时长
Negative answer ttl：否定答案的统一缓存时间 ）
【例如】：@ IN SOA ns.mageedu.com. admin.mageedu.com. (
20140805
1H：一小时
2M：两分钟
1W：一周
2D：两天 ）
NS：name区域名称，可用@简写
值：DNS服务器的FQDN
【例如】：@ IN NS ns.mageedu.com.
注：1、如果有多台NS服务器，每一个都必须有对应的NS记录。
2、对于正向解析的文件来讲，每一个NS的FQDN都应该有一个A记录。
MX：name区域名称，可用@简写
值：邮件服务器的FQDN
【例如】：@ IN MX 10 mail.mageedu.com.
注：1、如果有多台MX服务器，每一个都必须有对应的MX记录，但各MX记录有优先级。
2、对于正向解析文件来讲，每一个MX的FQDN都应该有一个A记录。
A：name主机的FQDN
值：主机IP地址
【例如】：www.mageedu.com, IN A 172.16.0.12
CNAME:name别名FQDN
值：FQDN
【例如】：www.mageedu.com. IN A 172.16.0.12
wed.mageedu.com. IN CNAME www.mageedu.com.
PTR:name:IP逆向的主机IP地址 如：172.16.0.12/16 其name为：12.0.in-addr.arpa
值：FQDN
【例如】：12.0.in-addr.arpa IN PTR www.mageedu.com.
Linux 下的DNS服务的工具：bind
其服务脚本为：/etc/rc.d/init.d/named
其主配置文件为：/etc/named.conf /etc/named.rfc1912.zones
其区域解析库文件：/var/named/ZONE_NAME.zone
Linux 下的DNS安全：服务进程以系统用户的身运行：named named
named进程运行于chroot环境
【案例】：配置一个mageedu.com的DNS服务器，其地址为172.16.249.29，包含的主机有www,mail,pop
注：1、在真实工作环境中我们首先是需要注册域名的；
2、支持泛域名解析，如：* IN A 172.16.249.29
(表示任何主机名的IP都为172.16.249.29）
安装配置过程：1、安装程序包：yum install bind -y
2、修改主配置文件：
定义区域：
Options {
全局配置段：
//directory “/var/named”;
};
zone “ZONE_NAME” IN {
type {master|slave|hint|forward};
file “mageedu.com.zone”;
};
logging {
日志段；
}；
3、为每一个区域提供解析库
变量的定义
资源记录
【正向解析配置过程实例】
首先编辑主配置文件
编辑内容如下：
注：图片中加红线的内容是需要在前边加//注释掉的。
编辑完主配置文件，我们需要定义区域；
在区域配置文件中添加如下内容
之后我们需要编辑区域文件
添加如下内容
编辑完成后检查一下语法是否有错误并启动一下DNS服务
然后为了安全，修改一下文件的属组和权限
这样就算是做好了一个正向的DNS解析器
我们可以测试一下
配置完正向的DNS解析器后我们还可以配置一个反向的解析器
【反向解析器配置】
首先编辑区域文件添加一个反向解析区域
添加内容如下
添加完成后我们需要配置反向解析区域库文件
添加内容如下
检查配置文件是否有语法错误
重启服务器，然后进行测试
说明：正向解析和反向解析文件中的名称可以仅使用相对名称，他们均相对当前区域而言。
绝对后缀可以使用$ORIGIN来定义。
【从服务器的配置过程】
在另外一台服务器上我们首先要修改主配置文件，方法同正向解析过程
首先编辑主配置文件
编辑内容如下：
注：图片中加红线的内容是需要在前边加//注释掉的。
然后编辑区域配置文件
添加内容如下
编辑完成后我们只需要在/var/named/slave目录下创建一个名叫congjsh.com.zone的文件
然后主从服务器会自动完成区域传送，无需手动配置。
注：区域传送需要两台服务器的时间保持一致，否则将造成传送出错，可以使用NTP服务器进行时间同步。
两台服务器的bind版本尽量相同，就算是不同，从服务器的版本必须要比主服务器的版本高。
从服务器的添加需要在父域的解析库文件中添加一条从服务器的NS记录。
从服务器与主服务器的关系如下
【区域传送的限制功能】
bind ：有内置的ACL
none表示所有的都不
any表示任意的
local表示仅本机
localnet表示本网络
allow-transfer { IP;IP; } 表示允许括号内的主机递归，其他均拒绝
allow-uodate { none; } 表示不允许任何人更新（为了安全）
rndc命令：rndc flush 清空缓存信息
reconfig 测试配置文件
status 查看DNS状态
reload 重新装载DNS
【DNS子域授权】
正向子域授权：只需在父域的区域解析库中添加“胶水记录”，格式如下：
子域名称 IN NS 子域名称服务器
例如：ops IN NS ns.ops
ns.ops IN A 172.16.100.7
ops IN NS ns2.ops
ns2.ops IN A 172.16.100.29
后两行是给子域添加的从域
【DNS子域授权实例】
在之前创建的父区域库中添加如下内容
然后再172.16.249.208的主机上做子域
但是这样配置的话我们去测试父域的主机的时候就会找不到，默认的子域去找父域的主机，子域是不会直接去父域查找，而是通过互联网访问根来递归查找。
如果在局域网内我想通过子域直接找父域怎么办？
配置转发器
转发器：转发所有的非本机负责的区域的请求至某指定的DNS服务器
【转发器配置】
在我们的子域服务器的/etc/named.conf文件中添加内容
检查语法是否有错，并且重读配置文件
如果我们只想转发某个区域呢？
【区域转发】
首先我们需要注释掉我们在主配置文件中添加的转发内容
把这些内容注释掉以后我们需要在区域配置文件中添加一个区域
添加如下内容
然后再重读一下配置文件
【bind view】
bind view：根据客户端来源的不同，将同一个名称解析至不同的值。
智能的DNS服务商：dnspood dns.la
其实bind的view功能就相当于是一个访问控制列表，做一些访问控制规则来限制用户使用那个服务。
bind acl可以自己定义： acl ACL_NAME {
IP；
IP；
network;
}
bind view的使用：view VIEW_NAME {
match-clients { ACL_NAME; };
区域
}；
view VIEW_NAME {
match-clients { any };
区域
}；
注：这些acl的匹配规则是这样的，首先匹配第一条，第一条匹配成功则按照第一条规则来执行，如果第一条规则没有匹配成功，则继续匹配第二条...
【bind view的用法】
编辑区域配置文件
把整个区域给括起来。
使用view的注意事项：
1、通常只为内网客户端提供递归功能，提供跟区域等。
2、通常只为外网客户端提供本机所负责的区域的解析。
Linux之DNS正向反向解析以及主从复制、子域授权、转发和view功能,布布扣,bubuko.com
Linux之DNS正向反向解析以及主从复制、子域授权、转发和view功能
原文：http://8455162.blog.51cto.com/8445162/1536564