[原创] Chapter 10.6 - 视图

10.6. Views

1、BIND 9 引入'视图'的概念 ，这在含有防火墙的环境中非常有用。视图允许你对不同的主机群（团体）显示不同的配置。 例如对外网和内网的用户

2、如果没有配置任何视图，BIND 9 自动建立一个对所有查询主机都一样的视图，名为 _default 。该视图对任何地址的主机都匹配

3、建立视图需要使用 view 语句 ：

     

4、使用 view 语句需要注意的地方 ：

Ø         视图的定义顺序非常重要。因为对于一台主机，首先匹配哪个 match-clients 列表，就采用哪个视图。所以在定义视图时，一定要按照 match-clients 覆盖的范围从小到大排列。当然如果两个match-clients 的范围不相交叉或者覆盖，则无所谓顺序。

Ø         如果使用了视图，则所有的 zone 语句只能出现在 view 语句之内，不能出现在 view 语句之外。

Ø         不同的 view 可以包含不同的 zone ，一个zone 不需要出现在所有的 view 。

Ø         view 语句必须放在 options 语句之后的，但不需要紧跟着

Ø         match-clients 带一个 address match list 作为参数

Ø         acl 、logging 、options 语句不能放在 view 之内

5、使用 view 可以解决问题 ：

Ø         根据不同地址来源进行不同的响应，特别是在存在内外网的情况下

Ø         内外网看到的 zone 不同，例如 zone2、zone3 这两个 zone 不需要让外界看到，只对外公布 zone1

Ø         同一个 zone 出现于多个 view ，包含不同的内容。

6、view 可用的语句包括 ：

7、view 在实际实施中的困难 ：

Ø         如果只是一台 name server 包办一切，那只需简单的建立 view 就可以了

Ø         如果是存在“主-从”、“下级子域”的情况，那就复杂多了 ：

n         主-从 ：

ü         notify 问题 ：主服务器修改某个view的某个zone的zone data file后，会发出 notify 消息，该notify 消息的源地址自然是主服务器的地址（假设主服务器只有1个地址）。

u        如果修改的是内部view的zone data files，从服务器发送 soa query 后，主服务器返回的是内部view的序列号，这没有什么不对的。

u        如果修改的是外部 view 的 zone data files，从服务器发送 soa query 后，主服务器返回的仍然是内部 view 的序列号 ！！！

ü         refresh 问题 ：同上，主服务器在收到从服务器发出的 SOA query 后，会返回 internal-view 的信  

息，而不是 external-view 的信息

ü         zone transfer 问题 ：主服务器在收到从服务器的 xfer 请求后，只会返回内部 view 的信息。

n         上级-下级 ：

ü         上级查询下级问题 ：一个外部主机向 dns.bob.com. 查询下级子域 movie.bob.com的一个主机（递

归查询），dns.bob.com 使用外部 view 的 bob.com 的 zone data files ，发

现 movie.bob.com 的 NS 记录（当然是 dns.movie.bob.com的外部地址），如果 dns.bob.com 配置了 recursion no; 则 dns.bob.com 不会向 dns.movie.bob.com 发送非递归查询 。这样外部主机就无法查询下级子域了。

ü         下级转发上级问题 ：当一个主机（不管是内部还是外部主机）查询 dns.movie.bob.com关于 bob.com

                        的一个主机时，dns.movie.bob.com. 如果在内部view和外部view都使用了转

发器，转发给上级域服务器的相应地址，如何保证源地址是跟view对应的呢？

8、应对措施 ：

Ø         notify 问题 ：假设主服务器和从服务器都有有内网和外网地址 （这一点很重要，否则下面无法完成）

n         主服务器方面 ：

u        internal-view 的 NS 使用内网地址，external-view 的 NS 使用外网地址 ：

l         如果 soa query 是内部地址，则返回内部view的序列号

l         如果 soa query 是外部地址，则返回外部 view的序列号

u        rndc reload 的执行问题 ：

l         内部view ：rndc reload  IN  

l         外部 view ：rndc reload  IN 

l         如果只用 rndc reload  ，会使用那个 view 呢？

u        NS 和 rndc reload 一起解决了 NOTIFY 、NOTIFY Response 问题

l         NS 记录保证了 NOTIFY 消息正确的目的地址

l         rndc reload 指定 view 保证了 NOTIFY 消息正确的源地址

u        内部view和外部view的正向区的名称是一样的，但反向区的名称是不一样的 ：

l         因为内部view使用的是内网地址，所以要定义为 ：254.253.192.in-addr.arpa

l         因为外部 view使用的是外网地址，所以要定义为 ：95.105.202.in-addr.arpa

n         从服务器方面 ：

u        从服务器方面必须跟主服务器一样，建立内外view

u        从服务器的 masters 语句 ：

l         内部 view 的 zones ：masters { 主服务器的内网地址; };

l         外部 view 的 zones ：masters { 主服务器的外网地址; };

l         从服务器在收到 NOTIFY 消息后，会根据 NOTIFY 消息来源的地址来判断要检查那个 view ，所以 masters 的地址必须跟 view 相对应。

u        从服务器的 transfer-source 语句 ：

l         如何保证从服务器使用正确的地址查询主服务器 (soa query)

ü    masters 指定正确的目的地址

ü    transfer-source 指定从服务器使用正确的源地址（soa query 和 zone transfer）

u        从服务器使用 allow-notify ：

l         内部view ： allow-notify {主服务器的内网地址;} 

l         外部 view ： allow-notify {主服务器的外网地址;};

Ø         refresh 问题 ：refresh 的问题就是 NOTIFY 的问题，只要 NS 记录和 masters 、transfer-source正确就

可以实现正确的 refresh 

Ø              zone transfer 问题 ：使用 transfer-source 同时也解决了该问题

Ø         上级查询下级问题 ：

n         内部 view ：由于内部 view 的上级域服务器提供递归功能，所以内部 view 不需要考虑该问题

n         外部 view ：

u        上级域服务器 ：在外部 view 设置 recursion no;

u        上级域服务器 ：增加一个 movie.bob.com 的 forward zone ，forwarders 为 dns.movie.bob.com 的外部地址

u        上级域服务器在转发查询到 dns.movie.bob.com 时是否使用外部地址？

Ø         下级查询上级问题 ：

n         下级域服务器 ：增加一个 bob.com 的 forward zone ，内部 view 的 forwarders {} 使用上级域

                         服务器 dns.bob.com 的内网地址；外部 view 的 forwarders {} 使用上级域服务

                         器 dns.bob.com 的外部地址

n         下级域服务器在转发查询到 dns.bob.com. 时使用的地址是否会自动对应 view ？