DNS 基本工作原理,及正反向解析和主从同步:
今天给大家介绍一下DNS的基本工作原理以及正反向解析和主从同步的应用；
DNS是域名系统(Domain Name System),它是由解析器和域名服务器组成的. 域名服务器是指保存有该网络中所以主机的域名和对应的IP地址,并具有将域名转换为IP地址功能的服务器.域名必须有IP地址，而IP地址不一定有域名。
域名系统太用类似目录树的等级结构, 最上层是根域，一般以 . 开头，根域下面是顶级域,顶级域包含com(商业机构)、edu(教育机构)、gov(政府机构)、net(网络机构)以及国家代码如：.cn .hk 和 .uk ; . cn 是中国专用的顶级域名。顶级域下面是次级域如: ibm.com、microsoft.com 和google.com 以此类推.
当你在网页上输入网址打开网页的时候,其实是通过域名解析服务找到了对应的IP地址,这样才能上网的。
DNS 的是工作在 tcp/53 和 udp/53 号端口的应用层协议;
DNS的查询类型：
递归查询：发送一次请求，就能得到答案。
迭代查询：需要发送多次查询请求才能得到答案.
DNS 服务的类型：主DNS服务器、辅助DNS服务器、缓存DNS服务器以及转发器。
主DNS服务器：维护所负责解析的域内解析库服务器，解析库由管理员维护。
从DNS服务器：从主DNS服务器或其它从DNS服务器那里“复制”（区域传递）一 份解析库.
区域传送又有完全传送(及传送整个解析库)和增量传送(传递解析库变化的那部分内容).
一、下面介绍一下在Linux 下DNS实现的方法：
BIND( Bekerley Internat Name Domain)是Linux下一种开源的DNS 协议的实现,它是互联网上最广泛使用的一种DNS服务器。
BIND的安装配置：
DNS服务： 程序包名bind ,程序名 named。
最主要有这样几个包：
bind.x86_64：主程序包
bind-libs： 库文件
bind-utils： 工具包
bind-chroot：安全套件,测试环境中最好不要安装;
服务脚本：/etc/rc.d/init.d/named
主配置文件：/etc/named.conf , /etc/named.rfc1912.zone , /etc/rndc.key
解析库文件：/var/named/zone_name.zone 负责保存本地的区域数据;
注：
(1) 一台物理服务器可同时为多个区域提供解析；
(2) 必须要有根区域文件
(3) 应该有两个(或更多)实现localhost和本地回环地址的解析库；
下面开始搭建一个DNS服务器：
1）安装 bind 软件包：
2） 进入/var/named/目录下 查看named.ca文件 里面保存着全球13个根服务器的信息;
3) 把/etc/named.conf 主配置文件备份一下,以防止意外情况发生;
最好先把本地主机的IP加入到监听的端口中;注意方便实验解析到该地址;
4) 配置主DNS服务器：进入/etc/named.rfc1912.zones 文件中，在最下面添加一行信息：
zone : 定义区域名;
type: 指定区域的类型；类型有：master、slave、hint、forward.
File: 定义区域解析库文件;
5) 添加 区域解析库文件；
这是在blue.com.zone 编辑的内容：
区域库文件的简要说明：
TTL：缓存资源记录(RR)的秒数;可从全局继承
$ORIGIN ：可用于引用当前区域的名字；
如：INNSns1.blue.com.
等同于： INNSns1
@ 符号： 等于@ORIGIN
区域库文件：由众多的RR组成
资源记录：Resource Record , RR
FQDN: full Qualified Domain Name 完全合格域名 如www.google.com
记录类型：
SOA：Start of authority ,起始授权记录；一个区域解析库有且仅能有一个SOA记录,还必须出现为解析库的第一条记录;
name: 当前区域的名字，例如“blue.com.”;
value: 有多部分组成
(a) 当前区域的主DNS服务器的FQDN,也可以使用当前区域的名字;
(b) 当前区域管理员的邮箱地址;但地址中不能使用@符号,一般用.替换;例如linux.blue.com;
(c) (主从服务协调属性的定义以及否定的答案的统一的TTL)
2015042201;序列号
2H;刷新时间
5M;重试时间
7D;过期时间
1D;否定答案的TTL值
H:小时 M:分钟 W:周 D:天
NS：Name Server，专用于标明当前区域的DNS服务器
name：当前区域的名字
value:当前区域的某dns服务器的名字,例如 ns.blue.com. ;
如：blue.com.INNSns1.blue.com.
blue.com.INNSns2.blue.com.
后面的点（.）一定要加上;
a) 相邻的两个资源记录的name相同时,后续的可省略;
b) 对NS记录而言,任何一个ns记录后面的服务器名字,都应该在后续有一个A记录;
MX：Mail eXchange , 邮件交换器
name:当前区域的名字
value:当前区域的某邮件服务器的主机名
a) 一个区域内,MX记录可以有多个;但每个记录的value之前应该有一个数字，数字(0-99)是优先级；值越低优先级越高;
b) 对MX记录而言,任何一个MX记录后面的服务器名字,都应该有后续的A记录;
如：blue.com.INMX 10mx1.magedu.com.
INMX 20mx2.magedu.com.
A：Internet Address，作用,FQDN 解析为IP地址
name：某主机的FQDN,例 www.blue.com.
Value：主机名对应主机的IP地址;
如：www.blue.com.INA1.1.1.1
www.blue.com.INA1.1.1.2
mx1.blue.com.INA1.1.1.3
mx2.blue.com.INA1.1.1.4
注：*INA172.16.249.226 是通过泛域名解析至某特定地址的；
blue.com INA172.16.249.226不加www 也是一样可访问到特定站点;
AAAA：FQDN –-> IPv6
PTR: pointer 指针, IP-à FQDN 从IP找到主机名
name：IP 有特定格式把IP地址反过来写；226.249.16.172 ; 而有特定的后缀
in-addr-arpa. 完整写法是：226.249.16.172.in-addr.arpa.
如：226.249.16.172.in-addr.arpa.INPTRwww.blue.com.
简写：226INPTRwww.blue.com.
注：网址及后缀可省略;主机地址必须要反着写；
CNAME: Canonical Name，别名记录
Name：别名的FQDN
Value：正式名字的FQDN；
如：web.blue.com.INCNAMEwww.blue.com.
资源记录定义的格式：
语法： name [TTL] IN rr_type value
缓存时长 关键字资源记录类型最重要的值
6) 自检配置文件是否有问题：
7) 修改/var/named/blue.com.zone 的权限和属组；
8) 启动服务即可；
9） 使用dig –t A www.blue.com @172.16.249.226 就可以查看解析到的A记录了;这样一个正向解析的DNS服务就搭建好了；
下面来增加一个反向解析域：
1） 在主DNS名称服务器中：/etc/named.rfc1912.zones 文件中添加一个主的反向区域：
2) 在/var/named/ 目录下定义一个反向区域解析文件：(反向解析库中不需要MX和A、AAAA记录；主要以PTR为主)；最好与正向解析域一一对应.
注： 这里的主机名( ns1.blue.com ) 一定要写上全名;如果不写上就会自动补上$ORIGIN的内容，变成 ns1.249.16.172.in-addr.arpa. 所以一定要写全了.
3) 配置属组，以及权限；
4) 重新启动服务：service named restart
并用# dig -x 172.16.249.226 @172.16.249.226 查看反向解析域名;
使用：host -p ptr 172.16.249.226 172.16.249.226 解析172.16.249.226 的PTR。
检查配置 ：
查看：全量区域传送，会得到对方所有的资源记录信息：(这个命令很危险,不要让任何人能够查看这些信息)。
正向信息：
反向信息：
这样一个反向解析域名就完成了。
二、搭建一个主从的DNS服务器：ns2 服务器 IP是：172.16.249.227 与主服务器一样，先按照bind这个软件包：
然后配置成缓存服务器：
1）修改 # vim /etc/named.rfc1912.zones ; 配置从服务器;
2） 重新启动 172.16.249.12 的dns 服务：
3) 查看日志文件： # tail /var/log/messages 主服务器上的数据将会传递到从服务器；
在主服务器中添加一条信息：然后把序列号加以，这条刚刚更新的信息就会传递给其他所有服务器了; 不用重启服务，只需要用 # rndc reload 重新载入区域解析文件就可以了；
编辑主服务器上的： # cd /var/named/
# vim blue.com.zone
# rndc reload
当所有配置都配置好，完成更新通知后，从服务器上会多出一个文件; 但是,任何时候都不要去编辑从服务器上的文件；要编辑也只能编辑主配置文件.切记。。。
主服务器必须有一条记录指向从服务器的地址;如：ns2INA172.16.249.227 只有指向了从服务器的地址，从服务器才会收到更新通知信息;主服务器只要发生更改会通知所有DNS服务器。
这样一个正向区域的从服务器已经配置好了, 当同步的时间,最好保持主服务器和从服务器上的时间点一致；这样才不会出现问题；
反向区域的从服务：(与正向区域的从服务相同;)
1） 主服务器反向区域必须有一条记录指向从服务器的地址(要不然无法同步信息)：
注释：这是第二次试验的反向解析主服务器上的文件; /var/named/172.16.8.zone 文件
2）修改 # vim /etc/named.rfd1912.zones 文件，增加一条反向区域从服务器的信息（在172.16.249.227中增加）；
注释：这是第二次试验的/etc/named.rfc1912.zones 文件
3）验证是否有语法错误：named-checkconf 然后重新载入区域文件；最后查看日志，发现已经同步了反向区域的信息了；
4）进入/var/named/slaves 目录下会增加 反向区域文件. 在日志中也显示,反向区域文件以及传送过来;
这样一个反向区域的从服务器也搭建好了,是不是也很简单！在反向区域文件中,最好也要指明从服务的地址,要不然会联系不到从服务器;
三、下面来说说子域授权： 实现分布式的主要前提;
子域与父域可以不在同一个网络内,只需要能够相互联系到对方就可以;但是子域必须被主域授权才可以.
1） 先把主服务器搭建起来,配置成缓存服务器;
启动bind服务：
进入到 /etc/named.rfc1912.zones 增加主区域文件;查看是否创建成功;
定义区域解析库文件：
配置权限：
此时父域服务器已经搭建完毕了；
1) 此时该添加子域了, 在 /var/named/blue.com.zone 区域中添加这些内容：
1) 再来配置子域,与配置父域的过程一致; 最后在/etc/named.rfc1912.zones 下面添加子域;
添加子域的区域解析文件： /var/named/ops.blue.com.zone ;
通过父域服务器是可以解析到子域服务器：
子域通过自己是不能解析到父域的：（这能解析是因为从互联网解析到的地址;不是我们内部的私有地址解析到的;请注意）
如果想让子域解析到父域的服务器地址：那就得打开区域转发的功能:
在/etc/named.rfc1912.zones 添加转发功能：
父域打开全局转发的方法：
进入父域的 /etc/named.conf 中添加：就可以了；
此时子域就可以访问外网了：
区域转发的优先级是 高于 全局转发的优先级的;
四、最后来一个bind view 的功能;
视图：
1) 一个bind服务器可定义多个view，每个view中可定义一个或多个zone;
2) 每个view用来匹配一组客户端;
3) 每个view内可能需要对同一个区域进行解析,但使用不同的区域解析库文件;
定义方法：
view VIEW_NAME {
match-clients { };
};
注意：
1) 一旦启用了view,所有的zone都只能定义在view中;
2) 仅有必要在匹配到允许递归请求的客户端所在view中定义根区域;
3) 客户端请求到达时,是自上而下检查每个view所服务的客户端列表;
示例： 需要两个网络在不同一个网段;但是外网是可以ping通服务器地址; 环境如下:
外网地址：
服务器地址：
把 /etc/named.conf 的区域 ,移到 /etc/named.rfc1912.zones 中去;
/etc/named.conf 中的区域 ：
已经移动到了 /etc/named.rfc1912.zones 文件中了；
在 /etc/named.conf 中定义一个ACL 访问控制列表; 定义成本地网络客户端;
然后在 /etc/named.rfc1912.zones 中定义 view .
上面是没有反花括号的，我们是要把中间所有的区域都定义到此处; 所有到结尾处定义反括号,就是把所有区域都包含进来;
验证一下,看下是否有语法错误：
从本机解析,自己的DNS. 是可以解析出来的.
定义外部客户端请求解析的; 区域文件； blue.com.external ;
增加 /var/named/blue.com.external 文件：
重新启动named 服务：
172.16.8.100 这个服务器 自己解析自己：
这里看到的你会觉得我是同一个网段，因为配置其他网段无法ping 同这个服务器,所以改成了172.16.8.101 但是我把 ACL 访问控制列表改了；
之后我用172.16.8.101 去解析 www.blue.com ：结果如下： 结果解析的是1.1.1.1 这个就是我想要的答案；
所以这就是两个VIEW 他们分别匹配不同的客户端,而且分别为每个ZONE提供两个不同的解析库文件;而且同一个解析库解析到的IP地址不一样;所以来自不同的客户端请求时,他们匹配到不同的VIEW时,这VIEW内的ZONE 将提供解析，这些ZONE提供了不同的解析库文件;而不同的解析库文件同一个域名,提供了不同的解析地址，所以解析的结果就不一样了。
这就是DNS的VIEW的实现方法。
实验还有好多不足的地方,希望大家能够来提供一下您宝贵的意见！谢谢观看。
原文地址：http://sailove.blog.51cto.com/3215562/1651563
