来,建个DNS服务器吧(Part2)

(Updated: )
, ,

这次来说说反向解析和主从同步的话题.

反向解析

之前的Part1中 ,我们已经搭建了能够正向解析的DNS服务器.

首先我们来看看反向区域这个概念.

反向区域是什么呢? 首先他的区域名称是很独特的, 要讲注册的得到的网络名称反过来写并且加上in-addr.arpa.

例如: 得到了 172.16.100 这个非变化部分就是我们的网络地址, 那么就写成: 100.16.172.in-addr.arpa. [注意后面的.]

那么怎么定义这个反向区域呢? 和定义正向区域基本相似:

1
2
3
4
zone "ZONE_NAME" IN {
	type {master|slave|forward};
	file "网络地址.zone";
};

接下就是提供解析库文件了. 反向区域和正向区域的解析库是有区别的, 他需要SOA和NS记录, 但它不需要A,AAAA,MX, 以PTR记录为主.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 一个解析库文件示例, 和Part1对应
$TTL 86400
$ORIGIN 199.168.192.in-addr.arpa.
@	IN	SOA	ns1.yaoxuannn.com.	admin.yaoxuannn.com (
			2017090101
			1H
			5M
			7D
			1D )
	IN	NS	ns1.yaoxuannn.com.
	IN	NS	ns2.yaoxuannn.com.
1	IN	PTR	ns1.yaoxuannn.com. # 这些数字其实就是主机名了, 会自动用上面的$ORIGIN补全
2	IN	PTR	ns2.justin13wxy.me.
10	IN	PTR	www.yaoxuannn.com.
10	IN	PTR	wwww.yaoxuannn.com.

与之对应, 我们在/etc/named.rfc1912.zones里面加上一条:

1
2
3
4
zone "199.168.192.in-addr.arpa" IN {
	type master;
	file "199.168.192.zone";
};

接着重新载入解析库文件之后, 我们进行反向解析:

1
2
3
4
5
6
7
8
9
10
11
12
[root@WWW named]# host -t ptr 192.168.199.10
10.199.168.192.in-addr.arpa domain name pointer www.yaoxuannn.com.
10.199.168.192.in-addr.arpa domain name pointer wwww.yaoxuannn.com.
[root@WWW named]# dig -x 192.168.199.1
...(omitted)
;; ANSWER SECTION:
1.199.168.192.in-addr.arpa. 86400 IN	PTR	ns1.yaoxuannn.com.

;; AUTHORITY SECTION:
199.168.192.in-addr.arpa. 86400	IN	NS	ns1.yaoxuannn.com.
199.168.192.in-addr.arpa. 86400	IN	NS	ns2.yaoxuannn.com.
...(omitted)

dig还有一个特别神奇的技能, 他可以进行模拟区域传送 :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@WWW named]# dig -t axfr yaoxuannn.com

; <<>> DiG 9.9.4-RedHat-9.9.4-50.el7_3.1 <<>> -t axfr yaoxuannn.com
;; global options: +cmd
yaoxuannn.com.		86400	IN	SOA	ns1.justn13wyx.me. admin.yaoxuannn.com.yaoxuannn.com. 2017090101 3600 300 604800 86400
yaoxuannn.com.		86400	IN	NS	ns1.yaoxuannn.com.
yaoxuannn.com.		86400	IN	NS	ns2.yaoxuannn.com.
ns1.yaoxuannn.com.	86400	IN	A	192.168.199.1
ns2.yaoxuannn.com.	86400	IN	A	192.168.199.2
www.yaoxuannn.com.	86400	IN	A	192.168.199.10
wwww.yaoxuannn.com.	86400	IN	CNAME	www.yaoxuannn.com.
yaoxuannn.com.		86400	IN	SOA	ns1.justn13wyx.me. admin.yaoxuannn.com.yaoxuannn.com. 2017090101 3600 300 604800 86400
;; Query time: 3 msec
;; SERVER: 192.168.56.101#53(192.168.56.101)
;; WHEN: Sat Sep 09 11:44:59 EDT 2017
;; XFR size: 8 records (messages 1, bytes 247)
#  看吧, 所有区域的记录一览无余.

这种全量区域传送是挺不安全的, 因为如果大家都可以进行这种, 那么全公司的网络拓扑甚至可以猜测出来.

如果用户想要访问 www.yaoxuannn.com 这个优秀的网站, 但是不小心它在前面加了一个 nizubang.yaoxuannn.com 这样解析就会出现问题, 所以 我们可以为刚才的解析库中增加一条泛解析条目:

1
2
3
4
[root@WWW named]# echo -e "*\tIN\tCNAME\twww" >> /var/named/yaoxuannn.com.zone
[root@WWW named]# tail -2 /var/named/yaoxuannn.com.zone 
wwww 	IN	CNAME	www
*	IN	CNAME	www

OK, reload之后, 就可试着解析了. 但是试着试着又发现了一个问题, 如果我什么都不写的话好像还是解析不了, 那么就需要再添加一条:

1
2
3
4
5
6
7
8
9
10
11
12
[root@WWW named]# echo -e "yaoxuannn.com.\tIN\tA\t192.168.199.10" >> /var/named/yaoxuannn.com.zone 
[root@WWW named]# tail -4 /var/named/yaoxuannn.com.zone 
www	IN	A	192.168.199.10
wwww 	IN	CNAME	www
*	IN	CNAME	www
yaoxuannn.com.	IN	A	192.168.199.10
[root@WWW named]# rndc reload
server reload successful
[root@WWW named]# dig yaoxuannn.com
...(omitted)
;; ANSWER SECTION:
yaoxuannn.com.		86400	IN	A	192.168.199.10

主从复制

主从复制并不是说就那么死板的安排的. 其实你可以有很多种不同的主从设计, 一台主服务器同时可以成从服务器, 从服务器也可以成为另一台从服务器的主服务器等等..

现在我的实验环境是这样安排的:

实验机一号: CentOS Linux release 7.3.1611 (Core) IP: 192.168.56.101 – 主

实验机二号: CentOS Linux release 7.3.1611 (Core) IP: 192.168.56.103 – 从

OK, 实验环境已经准备好了, 现在现在我们的二号机上做个测试:

正向解析

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[root@WWW ~]# dig axfr yaoxuannn.com @192.168.56.101

; <<>> DiG 9.9.4-RedHat-9.9.4-50.el7_3.1 <<>> axfr yaoxuannn.com @192.168.56.101
;; global options: +cmd
yaoxuannn.com.		86400	IN	SOA	ns1.justn13wyx.me. admin.yaoxuannn.com.yaoxuannn.com. 2017090101 3600 300 604800 86400
yaoxuannn.com.		86400	IN	A	192.168.199.10
yaoxuannn.com.		86400	IN	NS	ns1.yaoxuannn.com.
yaoxuannn.com.		86400	IN	NS	ns2.yaoxuannn.com.
*.yaoxuannn.com.	86400	IN	CNAME	www.yaoxuannn.com.
ns1.yaoxuannn.com.	86400	IN	A	192.168.56.101
ns2.yaoxuannn.com.	86400	IN	A	192.168.56.102
www.yaoxuannn.com.	86400	IN	A	192.168.199.10
wwww.yaoxuannn.com.	86400	IN	CNAME	www.yaoxuannn.com.
yaoxuannn.com.		86400	IN	SOA	ns1.justn13wyx.me. admin.yaoxuannn.com.yaoxuannn.com. 2017090101 3600 300 604800 86400
;; Query time: 3 msec
;; SERVER: 192.168.56.101#53(192.168.56.101)
;; WHEN: Sun Sep 10 01:06:08 EDT 2017
;; XFR size: 10 records (messages 1, bytes 279)

显然没有问题, 和Part1不同的是, 我把ns1和ns2的地址进行了更改, 因此和之前的解析库不一样了.

配置一个从服务器是比主服务器要简单的(废话啊), 我们先安装bind.

接着编辑namd.conf文件, 监听地址, 查询权限, dnssec啥的. 在Part1这些都提到过了, 所以就不说了.

我们先从正向区域的从服务器开始建立. 首先, 我们前往rfc1912.zones:

1
2
3
4
5
zone "yaoxuannn.com" IN {
        type slave; # 种类已经是从了
        masters { 192.168.56.101; }; # 不论主服务器有几个, 都要使用复数形式
        file "slaves/yaoxuannn.com.zone"; # 注意这里的路径
};

你可能想问, 难道说我们一定要把文件放在slaves这个目录下? 一般来说, 是的. 我们观察一下这个named目录下的构造:

1
2
3
4
5
6
7
8
9
10
11
[root@WWW named]# ls -lF /var/named/
total 16
drwxrwx--- 2 named named   23 Sep  9 03:39 data/
drwxrwx--- 2 named named   60 Sep 10 01:22 dynamic/
-rw-r----- 1 root  named 2281 May 22 05:51 named.ca
-rw-r----- 1 root  named  152 Dec 15  2009 named.empty
-rw-r----- 1 root  named  152 Jun 21  2007 named.localhost
-rw-r----- 1 root  named  168 Dec 15  2009 named.loopback
drwxrwx--- 2 named named   33 Sep 10 01:35 slaves/
[root@WWW named]# ls -ld /var/named/
drwxr-x--- 5 root named 127 Sep 10 01:02 /var/named/

经过观察可以很清楚的看出来, named用户仅仅可以对slaves, data, dynamic有写权限, 事实上. 这个就是bind为我们提供的结构. 凡是从解析库文件都扔到slaves里面就可以了.

接下来我们进行配置reload:

1
2
3
4
5
6
7
8
9
10
11
12
[root@WWW named]# rndc reload
server reload successful
[root@WWW named]# tail /var/log/messages
Sep 10 01:35:20 WWW named[10333]: reloading configuration succeeded
Sep 10 01:35:20 WWW named[10333]: reloading zones succeeded
Sep 10 01:35:20 WWW named[10333]: all zones loaded
Sep 10 01:35:20 WWW named[10333]: running
Sep 10 01:35:20 WWW named[10333]: zone yaoxuannn.com/IN: Transfer started.
Sep 10 01:35:20 WWW named[10333]: transfer of 'yaoxuannn.com/IN' from 192.168.56.101#53: connected using 192.168.56.103#59331
Sep 10 01:35:20 WWW named[10333]: zone yaoxuannn.com/IN: transferred serial 2017090101
Sep 10 01:35:20 WWW named[10333]: transfer of 'yaoxuannn.com/IN' from 192.168.56.101#53: Transfer completed: 1 messages, 10 records, 279 bytes, 0.008 secs (34875 bytes/sec)
Sep 10 01:35:20 WWW named[10333]: zone yaoxuannn.com/IN: sending notifies (serial 2017090101)

看到没~ 我们的文件传输过来了, 来看一下是否多出了个文件? 你可能会有有趣的发现.

接下来, 我们再看看主服务器那边的情况吧:

1
2
3
4
5
[root@WWW ~]# tail /var/log/messages
Sep 10 01:35:19 WWW named[10298]: client 192.168.56.103#59331 (yaoxuannn.com): transfer of 'yaoxuannn.com/IN': AXFR started
Sep 10 01:35:19 WWW named[10298]: client 192.168.56.103#59331 (yaoxuannn.com): transfer of 'yaoxuannn.com/IN': AXFR ended
Sep 10 01:35:20 WWW named[10298]: client 192.168.56.103#21742: received notify for zone 'yaoxuannn.com'
...(omitted)

如果刷新时间没有到, 但是我们主服务的解析记录发生了变化的话, 那么从服务器会得到更改吗? 我们来做这个实验:

  1. 首先我们为yaoxuannn.com这个域增加一个MX记录并且更新Serial Num.(+1)
1
2
        IN      MX 10   mx1
mx1     IN      A       192.168.199.20
  1. 接着我们reload配置
1
2
[root@WWW named]# rndc reload
server reload successful
  1. 看看日志怎么样
1
2
3
4
5
6
7
8
9
[root@WWW named]# tail /var/log/messages
Sep 10 02:35:33 WWW named[10298]: reloading configuration succeeded
Sep 10 02:35:33 WWW named[10298]: reloading zones succeeded
Sep 10 02:35:33 WWW named[10298]: zone yaoxuannn.com/IN: loaded serial 2017090102
Sep 10 02:35:33 WWW named[10298]: all zones loaded
Sep 10 02:35:33 WWW named[10298]: running
Sep 10 02:35:33 WWW named[10298]: zone yaoxuannn.com/IN: sending notifies (serial 2017090103)
Sep 10 02:35:33 WWW named[10298]: client 192.168.56.103#59346 (yaoxuannn.com): transfer of 'yaoxuannn.com/IN': AXFR-style IXFR started
Sep 10 02:35:33 WWW named[10298]: client 192.168.56.103#59346 (yaoxuannn.com): transfer of 'yaoxuannn.com/IN': AXFR-style IXFR ended

不错, 我们更改过后, 主服务器就直接去通知自己的从服务器去更新这份记录了.

那么现在来稍微总结一下:

  • 从服务器应该为一台独立的名称服务器
  • 主服务器的区域解析库文件中必须有一条NS记录是指向从服务器的
  • 从服务器只需要定义区域, 不需要提供解析库文件
  • 主服务器需要仅允许从服务器做区域传送
  • 主从服务器的时间应该得到同步
  • bind程序的版本应该保持一致, 即使不一样, 也需要保证从服务器的版本高于主服务器.

定义从服务器的方法上面也说明的挺详细了. 这就是正向解析从服务器的建立啦.

反向解析

上面都铺垫这么多了, 我们就直接进行zone的编辑就好了! 其实超乎想象的快:

1
2
3
4
5
zone "56.168.192.in-addr.arpa" IN {
        type slave;
        masters { 192.168.56.101; };
        file "slaves/56.168.192.in-addr.arpa.zone";
};

哦对了, 这里的示例记录也和Part1是不一样的.

接下来, check一下:

1
2
[root@WWW slaves]# named-checkconf 
[root@WWW slaves]#

OK!万事俱备, 只差reload啦.

1
2
3
4
5
6
7
8
9
[root@WWW slaves]# rndc reload
server reload successful
[root@WWW slaves]# tail /var/log/messages
Sep 10 02:51:10 WWW named[10333]: client 192.168.56.101#46304: received notify for zone '56.168.192.in-addr.arpa'
Sep 10 02:51:10 WWW named[10333]: zone 56.168.192.in-addr.arpa/IN: Transfer started.
Sep 10 02:51:10 WWW named[10333]: transfer of '56.168.192.in-addr.arpa/IN' from 192.168.56.101#53: connected using 192.168.56.103#56337
Sep 10 02:51:10 WWW named[10333]: zone 56.168.192.in-addr.arpa/IN: transferred serial 2017090101
Sep 10 02:51:10 WWW named[10333]: transfer of '56.168.192.in-addr.arpa/IN' from 192.168.56.101#53: Transfer completed: 1 messages, 8 records, 276 bytes, 0.007 secs (39428 bytes/sec)
Sep 10 02:51:10 WWW named[10333]: zone 56.168.192.in-addr.arpa/IN: sending notifies (serial 2017090101)

这样就完成了. 同理 如果我们改变了主服务器上的记录, 从服务器也会被通知来改变.

RNDC

来说说RNDC吧. 这个小东西管理named通过连接一个套接字来实现. 这是客户端的情况 而服务器端是通过监听在953/tcp端口的. 可以这么理解 rndc客户端(A主机)会去连接rndc服务端(B主机 953/tcp)来进行管理. 但是这样十分的不安全 所以你可以理解成这个A主机和B主机是一台主机. rndc只允许连接自己.

那么这个rndc到底除了reload还有什么能力呢? 直接rndc -help 我们可以得到很多子命令.

Usage: rndc

1
[-b address][-c config][-s server][-p port][-k key-file ] [-y key] [-V] command

由于一般不会特别需要指定server port key-file什么的, 所以我们就直接专注于command就好.

COMMAND:

  • reload: 重新载入主配置文件和区域解析库文件
  • retransfer: 手动触发zone传送, 不看serial number
  • notify: 对区域传送发送通知
  • reconfig: 重载主配置文件
  • querylog: 开启/关闭查询日志
  • trace [LEVEL]: 开启DEBUG, 后面用0-5来表示等级, 不添加LEVEL只递增等级VEL]**: 开启DEBUG, 后面用0-5来表示等级, 不添加LEVEL只递增等级