前一篇实践了正向解析服务器的配置使用,如何配置反向解析呢?
反向区域:
区域名称:网络地址反写.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 (20250516021H5M1W1D )IN NS ns1IN 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. (20240516011D5M7D1D )IN NS ns1IN 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 (20250516021H5M1W1D )IN NS ns1IN 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地址。
以上,使用视图,就可以实现联通用户访问联通服务器,移动用户访问移动服务器,而域名是一样的。