第4节. 实现反向区域和主从复制服务

PRT是独立了存放的数据

image-20230220140056105

发邮件的时候可能需要PTR反向解析

1、当你发送邮件到达对方邮件服务器的时候,

2、对方邮件服务器就会将发送方的IP地址方向解析成域名,如果该域名和发件人的邮箱后缀不一致,则认为是垃圾邮件。

3、就是防止对方冒充一些合法域名发送邮件咯。这个不一定通过IP,通过邮件的源码好像也能判断。

TXT记录的用在:

1、SPF反垃圾邮件记录

2、HTTPS验证记录

示例:_dnsauth TXT 2022122200000051qgs71beoh5h6wht4n1h0lr021x

厂家提供的字符串

搭建反向DNS

image-20230220134922654

主dns里定义了专门用来存放区域信息的路径:

include "/etc/named.rfc1912.zones";

image-20230220140809189

image-20230220142156664

image-20230220142132326

image-20230220143854841

image-20230220143947496

解决wwww.oneyearice.aisa的问题

image-20230220144329986

image-20230220144336123

* (泛域名解析)可以CNAME过去,泛域名解析是垫底的策略,类似路由表,也是最长匹配。与zone数据文件里的记录 顺序无关。

泛域名不能覆盖@功能,就是说*.xx.com 不能覆盖xx.com的解析。

@ 阿里云上可以CNAME,bind配置里不能CNAME,奇怪

rndc flush清缓存
rr的批量简化写法:

$GENERATE 1-254 HOST$ IN A 1.2.3.$

代表了:

HOST1.@解析到1.2.3.1

HOST2.@解析到1.2.3.2

... ...

HOST254.@解析到1.2.3.254

image-20230220151355541

image-20230220151503173

开始做反向解析

image-20230220153302758

image-20230220153458886

开始创建

image-20230220154400291

如果是192.168.10.0段的PRT就是协亨

zone "10.168.192.in-addr.arpa" {

​ type master;

​ file "192.168.10.zone" # 这里知识文件名称,无需倒着写。

};

image-20230220155435436

创建完后,检查、加载

image-20230220155545624

image-20230220155642781

image-20230220155702257

看下面这张图

image-20230220160049298

简写,的自动补全,存在冲突,也就是说SOA里的master主域写的ns1.oneyearice.asia.其实还依赖于正向解析咯。邮件当然得使用正向解析,否则admin.10.in-addr.arpa.也不是邮箱地址。

image-20230220160350819

image-20230220160531924

看来确实无关功能,解析拿不到的时候倒是可以看到SOA记录,这里其实理解错误,下文有讲。

image-20230220161201908

-x的简化

image-20230220161016642

看看老师的写法

image-20230220161445415

image-20230220160853025

他的图里有ns1记录的,可以看到其实也不涉及SOA里的 所谓的 主域名 ,ns记录的补齐也是补的ptr域。

从DNS服务器

直接克隆一台出来,改一下IP地址

1、zone区域配置得类型得改一下

image-20230220180556557

image-20230220180621652

这个zone的数据文件,其实不需要手动创建

重启服务就可以自动同步了。注意,上图的/var/named/下的oneyearice.asia.zone和10.zone都是克隆过来的,不要管他,要看zone配置的指向路径里的文件--也就是/var/named/slaves下面当前为空,

上图有错误一大堆👆

image-20230220182104671

上图的file名字最好也加上.slave后缀,看起来舒服些。

然后这是一些报错,备忘放在这里了:

使用named-check查看,要改成masters才行:

image-20230220180941573

配置都OK了,但是重启服务,没有同步自动生成zone文件,systemctl status 发现是主拒绝53,基本就是服务没启动了,上文都关掉了firewalld和selinux了。

image-20230220181927965

image-20230220182254515

开启主的named服务后,重启从的named,zone数据自动同步创建了。

image-20230220182436286

不过同步过来都变成了data文件,cat也看不了

image-20230220182614033

image-20230220182657261

好像就是centos7开始这样的,看不了了,以前是纯文本。

这样的好处就是从不能编辑修改,从就是得从主上面拿东西。

到这里,从服务器的解析也就正常了

image-20230220183124478

image-20230220183232367

image-20230220183329296

三个PRT好了👆,然后正向的再看看

image-20230220183355934

image-20230220183448488

考察下主从同步机制

版本号是和自己的上一次比较的。 推和拉都要版本号发生递增,所谓递增就是主自己看自己和上一次相比增加了,否则无法同步,不管推还是拉。

image-20230220192844879

保存,rndc reload 重新加载,主也 不会push过去,从get拉也没到3小时呢。

所以当前还是无法立马同步,从那边是配置了masters的,所以等3H,也就能同步,但是想要主推过去,就得让主知道谁是从服务,当前它还不知道谁是从呢。

利用ns记录来告诉master谁是从

所以学到这SOA记录里的主域名就很有意义咯,就不是上文说的没有功能咯。

image-20230220193536839

image-20230220193735744

image-20230220193807197

这样就OK啦,从就同步了

image-20230220193850567

然后nslookup看看

image-20230220194432138

可以了,从拉的时间也没那么及时,我测试在2分钟左右能拉好

image-20230220201104459

image-20230220201011768

image-20230220201018079

安全性问题

上文中可见,从服务器的配置,只要指明master就可以实现数据的同步了,只要主的版本号递增,就能get也好,push也罢,都能拿到数据了。主上面没有做验证措施。

image-20230220201859761

其实也还好,就算有人自己搭一个从服务器,拉取数据下来,他看不清除,因为file是data数据库文件。

此外还有一个安全性问题,就是能够拉取对应域的所有信息:

dig -t axfr oneyearice.asia @192.168.126.129

image-20230220202503440

对比公网人家的dns,肯定做了安全措施了

image-20230220202643052

image-20230220203142045

此时axfr就抓不到了,因为129上做了白名单👇

image-20230220204149164

进一步防止到"从服务器"上抓取。

image-20230220204530490

image-20230220204604484

image-20230220204557486

好了,主从就OK了,

client端就可以配置2个dns服务器了

windows和linux的两个dns服务器的优先级 需要研究下

总之最基础的来讲,就是主dns挂了down机了,从dns就生效了。

两个都down了,windows有缓存,linux无client端缓存。

image-20230220205903897

image-20230220205926413

image-20230220205950789

image-20230220210008888

主从切换OK,这个其实是依赖于client系统的一个自行判断。

Copyright 🌹 © oneyearice@126.com 2022 all right reserved,powered by Gitbook文档更新时间: 2024-07-28 14:47:43

results matching ""

    No results matching ""