前一篇实践了正向解析服务器的配置使用，如何配置反向解析呢？
反向区域：
区域名称：网络地址反写.in-addr.arpa.
192.168.138. --> 138.168.192.in-addr.arpa.
(1)定义区域：
zone "ZONE_NAME" IN {
type master | slave | forward ;
file "网络地址.zone"
};
(2)区域解析库文件：
注意：不需要MX和A，以及AAAA记录，以PTR记录为主；
示例：对比正向解析文件
还需要在named.rfc1912.zones文件中增加区域定义：
测试反向解析：
dig -x IP @SERVER
host -t ptr IP SERVER
dig可以模拟区域传递：
dig -t axfr ZONE_NAME @SERVER
泛域名解析：
可以使用名字为*的A记录，也可以使用域名的A记录：
主从复制：
1、配置从服务器（应该为一台独立的名称服务器），先安装bind软件，然后配置成名称缓存服务器（这里从服务器地址是192.168.138.138）：
.
2、主服务器的区域解析库文件中必须有一条NS记录是指向这个从服务器的。主服务器解析库文件修改时，仅通知NS记录的服务器。
3、配置从服务器成为正向解析的从服务器，从服务器只需要定义区域，而不需要提供解析库文件，解析库文件从其他服务器中传递过来；解析库文件应该放置于/var/named/slaves目录中。在从服务器中配置/etc/named.rfc1912.zone，定义区域即可；
要注意从服务器的解析库文件的位置，解析库文件主要配置好就行，不需要手工建立，区域传递时自动创建该文件。
4、主服务器得允许从服务器做区域传递；
从服务器重新加载，将会获得主服务器的解析库文件记录，并创建从服务器的解析库文件：
但是测试结果在从服务器中始终没有生成解析库文件，即没有/var/named/slaves/mytest.com.zone文件生成，看上面的日志，最后一条，“dumping master file: slave/tmp-pZsdilcpVm: open: file not found”，好像是最后转储主文件时文件没发现。
捣鼓了半天，终于发现是从服务器的配置出了错误，从服务器的mytest.com区域定义的文件位置错误了，slaves写成了slave，所以转储一直失败，无法成功建立slave/mytest.com.zone文件，因为named用户或用户组，在/var/named目录下没有写权限，也就无法创建slave目录，无法生成salve/mytest.com.zone文件。
意外收获，虽然解析库文件没有生成，但是用从服务器进行解析时，是可以解析到结果的，也就是缓存服务器的作用起到了。
修改错误后，最终生成了从服务器的解析库文件：
主服务器中相关区域记录进行了修改，会主动通知其他从服务器，从而其他从服务器能够在主服务器修改后几乎同步获得修改信息，而不是等到刷新时间到后再传递。
定义从区域的方法：
zone “ZONE_NAME” IN {
type slave；
masters { MASTER_IP； }；
file “FILE_NAME”
}；
5、反向解析从服务器的配置：
主服务器的区域中定义从服务器的NS记录和PTR记录
从服务器中配置区域，在/etc/named.rfc1912.zones中增加：
然后重新加载配置项，从服务器中通过区域传递获得解析库文件。
6、主从服务器时间应该同步，可以通过ntp进行；
7、bind程序的版本应该保持一致，否则，应该从高主低；
rndc工具：
rndc（客户端） --> rndc（953/tcp，服务器端） --> named
为了保证安全，服务器端只接收127.0.0.1地址的连接，即只能本机连接。
rndc COMMAND：
COMMAND：
reload：重载主配置文件和区域解析库文件；
reload zone：重载区域解析库文件
retransfer zone：手动启动区域传递过程，而不管序列号是否增加；
notify zone：重新对区域传递发通知；
reconfig：重载主配置文件；
querylog：开启/关闭查询日志；
trace：递增debug级别；
trace LEVEL：指定使用的级别；
子域授权：分布式数据库
正向解析区域子域授权方法：
定义一个子区域：
ops.mytest.com. IN NS ns1.ops.mytest.com.
ops.mytest.com. IN NS ns2.ops.mytest.com.
ns1.ops.mytest.com. IN A 1.1.1.1
ns2.ops.mytest.com. IN A 1.1.1.2
定义转发服务器：每个子域都不知道其父域在哪里，只知道根在哪里。如上面的ops.mytest.com子域中有一台主机要访问其父域中的一台主机，如www.mytest.com，因为ops.mytest.com子域名称服务器并不知道这个域名的地址，它只能去问根，因为它只知道根的位置，而不会去问其父域mytest.com的名称服务器，这显然有些啰嗦且不合理，于是在子域中可以定义转发服务器，即指定一个区域，在自己不负责解析的时候，转发给这个指定的区域。
注意：被转发的服务器需要能够为请求者做递归，否则，转发请求不予进行。
两种转发服务器：
（1）全局转发：凡是对非本机所负责解析的区域的请求，统统转发给指定的服务器；
Options{
forward {first | only} ；
forwarders ；
}；
（2）区域转发：仅转发对特定的区域的请求至某服务器：
zone “ZONE_NAME” IN {
type forward；
forward {first | only}；
forwarders ；
}；
注意：关闭dnssec功能：
dnssec-enable no；
dnssec-validation no；
全局转发：编辑/etc/named.conf
实践操作：
1）父域服务器（139）中配置mytestvv.com域：
//named.rfc1912.zones
zone "mytestvv.com" IN {
type master;
file "mytestvv.com.zone";
};
//mytestvv.com.zone
$TTL 1D
$ORIGIN mytestvv.com.
@ IN SOA ns1.mytestvv.com. admin.mytestvv.com (
2025051602
1H
5M
1W
1D )
IN NS ns1
IN NS ns2
ns1 IN A 192.168.138.139
ns2 IN A 192.168.138.138
wwt IN A 192.168.138.201子域服务器（138）中的配置ops.mytestvv.com域：
// named.rfc1912.zones
zone "ops.mytestvv.com" IN {
type master;
file "ops.mytestvv.com.zone";
};
// ops.mytestvv.com.zone
$TTL 1D
$ORIGIN ops.mytestvv.com.
@ IN SOA ns1.ops.mytestvv.com. admin.ops.mytestvv.com. (
2024051601
1D
5M
7D
1D )
IN NS ns1
IN NS ns2
ns1 IN A 192.168.138.138
ns2 IN A 192.168.138.139
wwo IN A 192.168.138.201
此时，dig -t A wwt.mytestvv.com @192.168.138.139和
dig -t A wwo.ops.mytestvv.com @192.168.138.138都能解析
而dig -t A wwo.ops.mytestvv.com @192.168.138.139和
dig -t A wwt.mytestvv.com @192.168.138.138都不能解析
2）修改父域，增加子域的名称服务器，就可以实现父域解析子域名称：
mytestvv.com.zone文件：
$TTL 1D
$ORIGIN mytestvv.com.
@ IN SOA ns1.mytestvv.com. admin.mytestvv.com (
2025051602
1H
5M
1W
1D )
IN NS ns1
IN NS ns2
ns1 IN A 192.168.138.139
ns2 IN A 192.168.138.138
wwt IN A 192.168.138.201
ops IN NS ns1.ops //增加子域名称服务器
ops IN NS ns2.ops //可以多台服务器
ns1.ops IN A 192.168.138.138 //子域服务器地址
ns2.ops IN A 192.168.138.203
父域中增加子域及子域服务器后，使用服务器名称服务器就可以解析子域的名称：
dig -t A wwo.ops.mytestvv.com @192.168.138.139就可以得到解析结果，但是子域名称服务器还是无法解析父域的名称：dig -t A wwt.mytestvv.com @192.168.138.138还是不行。
3）修改子域配置，使不在子域解析范围的名称转发到父域解析：
两种转发方法，其一是全局转发，在/etc/named.conf中的options中定义：
options {
listen-on port 53 { 192.168.138.138; 127.0.0.1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { any; };
recursion yes;
forward first; //此处定义进行转发，并且是先转发，不能解析就迭代
forwarders {192.168.138.2; }; //转发到哪个主机
dnssec-enable no;
dnssec-validation no;
/* Path to ISC DLV key */
// bindkeys-file "/etc/named.iscdlv.key";
// managed-keys-directory "/var/named/dynamic";
};
这里配置的转发到的地址是这台主机配置的DNS地址（主机可以访问互联网），并且将主机地址配置的DNS去掉。
如果不去掉本机配置的DNS，在测试时，本地名称服务器解析不了的默认也转发给了这个DNS服务器，即如果这里不配置forward和forwarders，dig测试也能解析到互联网上的域名。
dig -t A www.qq.com @192.168.138.138对于这条测试，没有配置上面的两条命令，且本机IP配置
了DNS，能够获得解析；如果去掉本地主机IP的DNS配置，则无法或的解析；这时配置上上面的两条配置命令，又可以获得解析。
而dig -t A wwt.mytestvv.com @192.168.138.138则无法解析，因为此解析请求会被转发到192.168.138.2上，然后会迭代，从根开始查找，因为在互联网上根本就没有注册mytestvv.com域名，所以最终不会迭代到192.168.138.139这个名称服务器。
然后测试将转发的服务器地址配置为192.168.138.139，即父域名称服务器。即
forwarders { 192.168.138.139；} ；此时，父域的和互联网上的名称都能解析到，即先转发到139这个名称服务器，这个服务器查找解析库文件，此时父域中的名称会被解析，如果不是父域中的名称，会被139转发出去，从互联网的根名称服务器开始迭代查找。
其二是区域转发：
在/etc/named.rfc1912.zones中增加父域区域：
zone "mytestvv.com" IN {
type forward;
forward only;
forwarders { 192.168.138.139; };
};
这样，子域就可以解析父域中的名称了。实际是转发给父域后获得父域的解析结果。
区域转发优先级高于全局转发。
dns中基础的安全相关的配置：
acl：把一个或多个主机归并为一个集合，并通过一个统一的名称调用；
acl acl_name {
ip；
ip；
net；
}；
示例：
acl mynet {
172.16.0.0/16；
}
bind中有四个内置的acl：
none：没有一个主机
any：任意主机
local：本机
localnet：本机的IP同掩码运算后得到的网络地址
注意：acl只能先定义，后使用，因此，其一般定义在配置文件中options的前面。
访问控制的指令：
allow-query {}； 允许查询的主机，白名单；
allow-transfer {}； 允许区域传送的主机；白名单；
allow-recursion {}；允许递归的主机，白名单；
allow-update {}； 允许更新区域数据库中的记录内容；
bind view：视图
一个是公网上不同运营商的客户访问同一个域名，得到的地址是不同的。也就是不同运营商的客户在dns中看到的内容不同；二是公网、私网不同网络的用户访问私网内的一台服务器（通过地址转换对外服务），希望得到的dns解析结果也不同（公对公，私对私）。
视图：一个bind服务器可定义多个view，每个view中可定义一个或多个zone；每个view用来匹配一组客户端（或者说一类客户端比较好）；多个view内可能需要对同一个区域进行解析，但使用不同的区域解析库文件；
view VIEW_NAME {
match-clients { }；匹配哪些客户端
zone “ZONE_NAME” IN {}；可定义多个
}
注意：
1）一旦启用了view，所有的zone都只能定义在view中；
2）仅有必要在匹配到允许递归请求的客户所在view中定义根区域；
3）客户端请求到达时，是自上而下检查每个view所服务的客户端列表；
智能DNS：dnspod、dns.la
view使用示例：
1）在/etc/named.conf增加acl定义，定义两台主机，模拟不同的网络：
acl mylocal {
192.168.138.139;
};
acl others {
192.168.138.138;
};
2）在/etc/named.rfc1912.zones中配置视图，同时将named.conf中定义的区域，即zone “.”挪到视图中：只定义一个视图，只有本机139能获得mytestvv.com域的解析结果。
view suportlocal {
match-clients { mylocal; }; //匹配的客户端，定义哪些客户端可以访问这个视图中的区域
allow-recursion { mylocal; }; //对哪些客户端的请求进行迭代
zone "." IN { //从named.conf中移动过来的，使用视图，所有区域必须在视图中
type hint;
file "named.ca";
};
zone "localhost.localdomain" IN {
type master;
file "named.localhost";
allow-update { none; };
};
zone "localhost" IN {
type master;
file "named.localhost";
allow-update { none; };
};
zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
type master;
file "named.loopback";
allow-update { none; };
};
zone "1.0.0.127.in-addr.arpa" IN {
type master;
file "named.loopback";
allow-update { none; };
};
zone "0.in-addr.arpa" IN {
type master;
file "named.empty";
allow-update { none; };
};
zone "mytestvv.com" IN {
type master;
file "mytestvv.com.zone";
// allow-transfer { 192.168.138.138; };
};
zone "138.168.192.in-addr.arpa." IN {
type master;
file "138.168.192.zone";
};
};
mytestvv.com.zone中定义的wwt.mytestvv.com 的A地址是192.169.138.201，在139机器上测试：
在138机器上不能获得解析结果。
3）定义第二个视图，在named.rfc1912.zones中增加：
view suportothers {
match-clients { others;};
allow-recursion { none; };
zone "mytestvv.com" IN {
type master;
file "mytestvv.com.others";
};
};
新建mytestvv.com.others文件，其中定义wwt.mytestvv.com.的A地址为192.168.138.221，在139上测试，结果同上图，得到192.168.138.201地址，在138机器上测试：
得到的是192.168.138.221地址。
以上，使用视图，就可以实现联通用户访问联通服务器，移动用户访问移动服务器，而域名是一样的。
