devbox
我家自动化
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

Linux入门攻坚——23、DNS和BIND基础入门2

作者：我家自动化 | 2024-05-22 11:59:46

赞

踩

Linux入门攻坚——23、DNS和BIND基础入门2

前一篇实践了正向解析服务器的配置使用，如何配置反向解析呢？

反向区域：
  区域名称：网络地址反写.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域：

  1. //named.rfc1912.zones
  2. zone "mytestvv.com" IN {
  3. 	type master;
  4. 	file "mytestvv.com.zone";
  5. };
  6.  
  7.  
  8. //mytestvv.com.zone
  9. $TTL 1D
  10. $ORIGIN mytestvv.com.
  11. @	IN	SOA	ns1.mytestvv.com.  admin.mytestvv.com (
  12. 		2025051602
  13. 		1H
  14. 		5M
  15. 		1W
  16. 		1D )
  17. 	IN	NS	ns1
  18. 	IN	NS	ns2
  19. ns1	IN	A	192.168.138.139
  20. ns2	IN	A	192.168.138.138
  21. wwt	IN	A	192.168.138.201

子域服务器（138）中的配置ops.mytestvv.com域：

  1. // named.rfc1912.zones
  2. zone "ops.mytestvv.com" IN {
  3. 	type master;
  4. 	file "ops.mytestvv.com.zone";
  5. };
  6.  
  7. // ops.mytestvv.com.zone 
  8. $TTL 1D
  9. $ORIGIN ops.mytestvv.com.
  10. @	IN	SOA	ns1.ops.mytestvv.com.  admin.ops.mytestvv.com. (
  11. 		2024051601
  12. 		1D
  13. 		5M
  14. 		7D
  15. 		1D )
  16. 	IN	NS	ns1
  17. 	IN	NS	ns2
  18. ns1	IN	A	192.168.138.138
  19. ns2	IN	A	192.168.138.139
  20. 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文件：

  1. $TTL 1D
  2. $ORIGIN mytestvv.com.
  3. @	IN	SOA	ns1.mytestvv.com.  admin.mytestvv.com (
  4. 		2025051602
  5. 		1H
  6. 		5M
  7. 		1W
  8. 		1D )
  9. 	IN	NS	ns1
  10. 	IN	NS	ns2
  11. ns1	IN	A	192.168.138.139
  12. ns2	IN	A	192.168.138.138
  13. wwt	IN	A	192.168.138.201
  14. ops	IN	NS	ns1.ops                 //增加子域名称服务器
  15. ops	IN	NS	ns2.ops                 //可以多台服务器
  16. ns1.ops	IN	A	192.168.138.138     //子域服务器地址
  17. 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中定义：

  1. options {
  2. 	listen-on port 53 { 192.168.138.138; 127.0.0.1; };
  3. 	directory 	"/var/named";
  4. 	dump-file 	"/var/named/data/cache_dump.db";
  5.     statistics-file "/var/named/data/named_stats.txt";
  6.     memstatistics-file "/var/named/data/named_mem_stats.txt";
  7. 	allow-query     { any; };
  8. 	recursion yes;
  9. 	forward first;   //此处定义进行转发，并且是先转发，不能解析就迭代
  10. 	forwarders {192.168.138.2; }; //转发到哪个主机
  11.  
  12. 	dnssec-enable no;
  13. 	dnssec-validation no;
  14.  
  15. 	/* Path to ISC DLV key */
  16. //	bindkeys-file "/etc/named.iscdlv.key";
  17.  
  18. //	managed-keys-directory "/var/named/dynamic";
  19. };

这里配置的转发到的地址是这台主机配置的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中增加父域区域：

  1. zone "mytestvv.com" IN {
  2.         type forward;
  3.         forward only;
  4.         forwarders { 192.168.138.139; };
  5. };

这样，子域就可以解析父域中的名称了。实际是转发给父域后获得父域的解析结果。

区域转发优先级高于全局转发。

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定义，定义两台主机，模拟不同的网络：

  1. acl mylocal {
  2.         192.168.138.139;
  3. };
  4. acl others {
  5.         192.168.138.138;
  6. };

2）在/etc/named.rfc1912.zones中配置视图，同时将named.conf中定义的区域，即zone “.”挪到视图中：只定义一个视图，只有本机139能获得mytestvv.com域的解析结果。

  1. view suportlocal {
  2.         match-clients { mylocal; };     //匹配的客户端，定义哪些客户端可以访问这个视图中的区域
  3.         allow-recursion { mylocal; };  //对哪些客户端的请求进行迭代
  4.  
  5. zone "." IN {                 //从named.conf中移动过来的，使用视图，所有区域必须在视图中
  6.         type hint;
  7.         file "named.ca";
  8. };
  9.  
  10. zone "localhost.localdomain" IN {
  11.         type master;
  12.         file "named.localhost";
  13.         allow-update { none; };
  14. };
  15.  
  16. zone "localhost" IN {
  17.         type master;
  18.         file "named.localhost";
  19.         allow-update { none; };
  20. };
  21.  
  22. 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 {
  23.         type master;
  24.         file "named.loopback";
  25.         allow-update { none; };
  26. };
  27.  
  28. zone "1.0.0.127.in-addr.arpa" IN {
  29.         type master;
  30.         file "named.loopback";
  31.         allow-update { none; };
  32. };
  33.  
  34. zone "0.in-addr.arpa" IN {
  35.         type master;
  36.         file "named.empty";
  37.         allow-update { none; };
  38. };
  39.  
  40. zone "mytestvv.com" IN {
  41.         type master;
  42.         file "mytestvv.com.zone";
  43. //      allow-transfer { 192.168.138.138; };
  44. };
  45. zone "138.168.192.in-addr.arpa." IN {
  46.         type master;
  47.         file "138.168.192.zone";
  48. };
  49. };

mytestvv.com.zone中定义的wwt.mytestvv.com 的A地址是192.169.138.201，在139机器上测试：

在138机器上不能获得解析结果。

3）定义第二个视图，在named.rfc1912.zones中增加：

  1. view suportothers {
  2.         match-clients { others;};
  3.         allow-recursion { none; };
  4.  
  5. zone "mytestvv.com" IN {
  6.         type master;
  7.         file "mytestvv.com.others";
  8. };
  9. };

新建mytestvv.com.others文件，其中定义wwt.mytestvv.com.的A地址为192.168.138.221，在139上测试，结果同上图，得到192.168.138.201地址，在138机器上测试：

得到的是192.168.138.221地址。

以上，使用视图，就可以实现联通用户访问联通服务器，移动用户访问移动服务器，而域名是一样的。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/我家自动化/article/detail/608147
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号