一、Master/Slave架构(辅助DNS)
1.1）基本概念
PTR：Pointer Record Reverse（反向记录解析）
辅助DNS出现的原因：通常一个区域至少有两台DNS服务器，如果其中一台DNS服务器宕机了，并不影响客户的体验！
明确一点：如果区域有两台以上的DNS服务器，那么网络上是随机搜寻的，所以如果这些DNS服务器数据不同步的话就可能使用
户无法获取正确的数据！
引申：为了解决这个问题，除了.(root)根这种hint类型的数据库文件之外，还提供了两种基本的数据类型
Master(主要、主人)和Slave(奴隶，次要、从属)数据库类型
Master/Slave架构解决的问题：不同DNS服务器上数据同步问题的
1.2）Master
特点：管理员需要手动修改与设置，还需要重新启动DNS服务去读取更新的正确的数据库的内容，才算完成数据库的更新！
额外：还能提供数据库给Slave的DNS服务器！
1.3）Slave
场景：当用户要求DNS服务器的管理者进行修改、添加、删除数据的时候，如果全是主DNS，一笔数据就需要做三次，而
且可能手滑导致某几台出现错误！
应用场景：一台DNS服务器作为主DNS，其余的作为该Master的Slave服务器，当客户要求修改某个IP与主机名的记录的时候，只需要手动更改Master那台DNS服务器的数据库配置文件，然后主DNS重新启动服务，其余的两台的Slave就会自动的被通知更新(更不更新，主要是看serial是否发生变化)，便于维护！
明确：Slvae DNS服务器本身并没有数据库，它的数据是有Master DNS 所提供的！
1.4）Master/Slave数据的同步化过程
更新方式
方式1：Master主动告知
如果在Master中修改了数据库内容，并且加大了数据库序号(可以理解为第几次修改或者版本号)，重新启动DNS服务，那那么Master会主动告知Slave来更新数据库，此时就可以实现数据库的同步了！
方式2：Slave主动提出要求(删除slaveDNS的数据，看是否更新)
Slave会定时向Master查看数据库的序号，当发现数据库的序号比Slave的还大(代表Master更新了，而自己还没有及时更新)，那么Slave就会开始更新，如果序号不变，那么就判断数据库没有更动，就不会同步更新！
安全的角度：两个DNS服务器都需要你能够掌控！
SOA标志位：多久更新一次、更新失败(网络问题，没有查询到Master的序号)再更新一次
1.5）/etc/reslov.conf的补充说明
问题：DNS服务器要设置多个？
原因：其中一个DNS服务器宕机时，客户端可以使用第二个DNS服务进行查询，有点像DNS的备份功能！
优先级：永远只有第一台DNS的服务器会被用来查询，其它的设置值只有第一台出现问题才会使用！
DHCP分配IP：当系统主动使用DHCP服务器传来的数据进行系统配置文件的修订，必须告知不要使用DHCP传来的某些网络参数，默认会覆盖原有的/etc/resolv.conf的配置文件的内容！
两种形式来声明取消传递过来的某些参数：nmcli命令的形式、配置文件的方式
PEERDNS(第6行)
二、辅助DNS
环境的搭建：Master/Slave的防火墙关闭或者添加服务到防火墙上，目的是可以同步更新信息
Slave的DNS的服务器配置
1）安装软件
2）修改主配置文件 vim /etc/name.conf
关键点：53端口的绑定IP来监听请求(any)、允许访问主机(any)、此DNS服务器不进行安全认证！
3）修改子配置文件
修改1：vim /etc/named.rf*
zone "westos.com" IN {
type slave; #数据类型判断是从DNS(不是master)！
masters { 172.25.2.110; }; #标识主DNS的IP，与谁同步(注意是有s的)！
file "slaves/wzj.com.zone";#同步Master的数据块的位置！
};4）修改/etc/reslov.conf
nameserver 172.25.2.102 (从DNS的服务器的IP，自身的IP)！！！
注意：如果换成主DNS看不到实验效果，这里是拿自己作为DNS服务器，如果是主DNS服务器IP那么，一旦主DNS更新数据，named.conf配置文件中又允许所有的客户端来询问，从DNS也是这个域的成员！
说明：Slave既然是DNS，当然也具有权威性，所以设置为自己的IP！
5）主DNS主配置文件(named.conf)说明
策略1：将原来做的双向解析注释掉，把原来的注释还原(主要是为了实验效果的说明)
策略2：将之前的数据复制一份到其他目录(例如/opt)
6）主DNS重启服务，然后从DNS重启服务，观察实验现象
/var/named/slaves 多了一个数据块，表示更新过来了！
原因：刚开始没有数据，所以没有serial可以对比，所以直接同步Master的数据块(data 类型)！
粗略查看：hexdump -C wzj.com.zone
测试：dig www.wzj.com
7）测试2
步骤：此时主DNS修改区域数据的信息，然后重启服务，Slave的DNS也重启服务
具体：Master中修改www.wzj.com的主机的IP信息
Slave DNS测试 dig www.wzj.com测试，没有读取到更新的内容？
原因分析：首先主DNS的子配置文件中，不允许(默认)从DNS服务器来更新IP，并且由于此时Slave已经更新到数据了，会对比serial和Master的DNS的serial，如果发现Master的sermial不大于自己的seral就不更新！
8）测试3
主DNS修改子配置文件允许SlaveDNS服务器来同步更新自己
修改1：Master的子配置文件
zone "wzj.com" IN {
type master;
file "wzj.com.zone";
also-notify { 172.25.2.102; }; #主DNS添加的内容(注意是also不是allow，又开始意淫了)，自己作为主导，允许谁来同步自己！
allow-update { none; };
};
修改2：正解的数据配置文件
sermial 修改为1，常见的模式是YYYYMMDDUP(最大为2^10)测试方式：通过时间戳和dig的方式看数据是否同步！
错误的方法是：删除SlaverDNS的数据块的内容，然后重启服务，来同步！
前提：是允许此Slaver DNS服务器同步，并且也没有修改serial！
seria标志位的说明：不能超过10位，2^32，最大是4294967296！
五、协同DNS
含义：哪台Slave DNS可以对我的Master主机信息的数据进行修改，需要Master DNS对我进行授权！
注意：Master/Slave DNS需要有可以相互传输的zone file的相关信息才行！
zone "wzj.com" IN {
type master;
file "wzj.com.zone";
also-notify { 172.25.2.102; };
allow-update { 172.25.2.102; }; #允许谁来更改我的内容(授权)！
};
说明1：关于报错信息(7.3的没有报错信息，7.0的有报错信息)
chmod g+w /var/named -->named用户属于named用户组，默认没有写的权限(重大变革)
原因：这个send动作会导致主DNS创建文件，但是权限的限制，不允许named来创建文件(没有w的权限)
主DNS修改:通过看日志得到原因
删除：update delete bbs.westos.com
测试
说明2：此时不管是主DNS还是从DNS，都可以通过dig的方式来看到数据进行更新
说明3：主DNS也会经过一段时间主动去更新，或者主动重启服务也能及时更新到数据库的文件中！
六、利用RNDC命令来管理DNS服务器
功能：检查已经存在的DNS缓存中的资料，重新更新整个Zone而不需要重新启动整个DNS，以及检查DNS的状态和统计资料
思考：由于rndc可以深入的管理DNS服务器，所以要加以控制，控制的方式是通过rndc来建立密钥，并将密钥的信息写入named.conf的主配置文件中！
说明：要与产生rndc.key密钥的算法一致
需求：由于上述修改的方式不安全，想通过认证的方式允许谁来修改
核心：基于key的远程更新
1 前面我们讲过的指定IP更新不安全，我们现在指定用钥匙更新。利用密钥进行更新顾名思义，只有有钥匙才可以对此更新，必须先加密，等进行分配钥匙，更新。
(1)主DNS产生密钥匙，注意对比/etc/rndc.key的加密算法！
(2)将产生的密钥写入配置文件中，并在/etc/named.conf的主配置文件中引用，当远程的某个主机要修改的时候，看它发送过来的密码和钥匙是否匹配，若匹配则同意修改！
cp -p /etc/rndc.key /etc/wzj.key！
vim /etc/wzj.key -->生成的加密字符串写入，并修改名字(与创建的名字一致)！
vim /etc/named.key -->引用/etc/wzj.key文件！
vim /etc/named.rf* -->改变allow-update 的认证方式{key wzj;};！
重启服务
测试：出现的问题
分析原因
以下几个问题
(1)时钟不同步-->第一个错误！
(2)同步以后，生成密钥，只发给从DNS，主DNS没有更新！
(3)此时主DNS的从配置文件声明不是IP的形式，而是只有拿钥匙的才能同步！
(4)生成的密钥是否引入主DNS的主配置文件中！
(5)生成的秘钥是否修改了密钥的名字！功败垂成，终于搞定了
说明：Master DNS可以看到配置文件中还有此主机的信息，但是dig www.wzj.com查询不到，主DNS重启以后就没有此信息了！
注意：还原的时候，权限的问题很重要，看日志！
六、DDNS
DDNS（Dynamic Domain Name Server）是动态域名服务的缩写
概念：DDNS是将用户的动态IP地址映射到一个固定的域名解析服务上，用户每次连接网络的时候客户端程序就会通过信息传递把该主机的动态IP地址传送给位于服务商主机上的服务器程序，服务器程序负责提供DNS服务并实现动态域名解析。业界称只之为花生壳！
思路：搭建动态的DNS服务器，让客户端可以通过这个机制来修改他们在DDNS主机上面的zone file 内的文件！
DDNS理解：--> DNS的动态解析--> Dynamic DNS 或者DHCP +DNS 的理解
说明：左下面的实验之前必须充分理解上面的实验过程和原理
(1) 实验环境的还原
策略：删除/var/named/wzj.com.zone*的文件，然后 cp -p /opt/named.com.zone /var/named
(3)保证原有的Master DNS服务器配置不变，安装DHCP服务软件！
(4)测试：以 music.wzj.com主机来测试，首先看客户端能不能自动获取IP(首先得有dhcp的需求)，然后进行下一步！
(5)如果成功，通过man 5 dhcpd.conf ，搜索与DNS有关的，会看到两种模式的DDNS配置，我们选择interim
vim /etc/dhcp/dhcpd.conf -->编辑这个配置文件
ddns-update-style interim;默认是none表示分配某个域的IP时不通知DNS，INTERIM -->MD5 vs SHA1 (加密的方式)
类似更新DNS服务器的主机信息所用的密钥！
key wzj {
alogorithm hmac-md5;
secret 内容; #不能加""，(主DNS生成的密钥)
#说明：分配IP时通过此DNS认证的密钥才能去更新域名与IP的影射关系,
}； #注意有;号更新的区域
zone wzj.com {
primary 127.0.0.1;#说明：如果是DHCP和DNS位于同一个主机，回环地址速度比较快！
如果不在同一个主机，需要写主DNS的IP 地址(172.25.254.105)，这个是通知主DNS更新
自己写回环地址出错：主要是named并非是回环地址监听，所以dhcpd也要设置成监听的IP！
key wzj; #更新的时候所引用的密钥认证(模块)，才能成功！
} #注意：没有;号说明：注意分号的问题，并且 key wzj(这个可以随便写，不是通过这个来识别的，只要引用模块即可)！
更新的时候告知的DNS域名服务器，拿着数据信息和密钥通过DNS的验证来更新主机信息(理解之前操作)
说明：全局参数的设置，给IP的同时给DNS
option domain-name "wzj.com";
option domain-name-servers 172.25.2.105;(6)主DNS修改配置文件之后，重启dhcpd和named服务
(7)music.wzj.com的测试，dig music.wzj.com是否可以看到信息
错误
原因：dhcpd.conf配置文件中.没有写，以及primary写成回环地址！
结果
(8)重点来了，修改主DNS主机中的DHCP服务器，让刚分配给music的主机的IP不在地址池的范围内
结果(并且服务器生成了一个.jnl文件)
实验效果：每次music的主机重启network服务会获取自动分配IP，通过dig music.wzj.com从主DNS获取的IP信息都是动态更新！
小技巧：host -l wzj.com -->DNS服务器的管理员查看此域的所有主机的信息，注意其他成员没有权限查看！
扩展：解读DNS缓存投毒与欺骗
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
