第4章高级概念(1)-Linux -idc中文资讯站-客观公证的IDC产业权威媒体,关注域名、虚拟主机、服务器、网络、开源技术资讯，整合运营商资源，客观评价各地机房带宽线路质量、IDC企业名录等信息

第4章高级概念(1)

来源： ChinaUnix博客　作者： ChinaUnix博客　发布时间:2008-04-24 06:28:35

第4章高级概念
目录
4.1.
动态更新
4.2.
增量数据传送（IXFR）
4.3.
分开的DNS？
4.4.
TSIG
4.5.
TKEY
4.6.
SIG(0)
4.7.
DNSSEC
4.8.
IPv6支持
4.1. 动态更新
动态更新这个术语是指在指定的条件下增加、修改或删除管理域文档中的记录或RR配置。这个特性完整描述在RFC 2136。
动态更新（Dynamic update is enabled on a zone-by-zone basis），通过zone 语句中的allow-update 或update-policy 子句启用。
更新秘密区域 (使用DNSSEC的区域) 按RFC 3007: SIG的规定，服务器使用在线区域关键字自动更新NXT 记录。主管理区域则基于信号和直接的服务器策略。
4.1.1. 日程文档
一个区域任何的动态更新都被存储在区域的日程文档（zone’s journal file）。这个文档是动态更新第一次发生时服务器自动产生的，日程文档的名字都是对应的区域文档后面加上.jnl扩展名。日程文档是二进制格式的，不能手工编辑。
服务器有时候也把整个更新过的区域文档的内容存入("dump")一个区域文档中。这并不是在动态更新后就立即执行，因为一个很大的区域文档假如很频繁的更新，将会使服务器变的很慢。实际上这个保存（dump）过程会后延15 分钟，允许马上又发生其他更新。
当服务器关机或崩溃后重启，他会读入日程文档，假如记录日程文档后发生的变化就会丢失。
区域数据增加也使用日程文档，方法相似。
动态变化的区域文档不能手工编辑是因为他们不能确保是最新的，要确保他是最新的唯一方法就是运行rndc stop。
假如必须手工改变动态区域数据，按下面的流程操作：使用rndc stop 关闭服务(发信号或 rndc halt 不行)，等服务器退出后，删除（remove ）区域的.jnl文档，编辑区域数据文档，然后重启服务。删除.jnl 文档是必须的，因为存在日程文档时，手工编辑的内容不会有效。
4.2. 增量区域数据传送（Incremental Zone Transfers (IXFR)）
增量区域数据传送(IXFR)是为从属服务器只传送改变部分数据的协议。不同于必须传送整个区域数据。详情参见RFC 1995.
Proposed Standards
.
作为一个管理区域服务器时， BIND 9 支持IXFR，提供必要的区域数据改变历史信息。这些包括被动态更新维护的管理区域数据和从IXFR接收数据的从属服务器的区域信息，但是手工维护的管理区域数据和从属区域数据必须执行完整的区域数据传送（a full zone transfer (AXFR)）.
作为从属服务器时， BIND 9会尝试使用IXFR特性，除非明显的禁止这个功能。怎样禁止IXFR，参看server语句中的request-ixfr 子句。
4.3. 分离DNS（Split DNS）
从不同的视角去看，DNS空间能够分为内部的外部的，这样可能会用到分离DNS。一个组织会有多个原因将DNS配置成分离状态。
一个通常的原因是向互连网上的“外部”用户隐藏“内部”DNS信息。有一些关于这个措施是否有用的辩论。互连网DNS信息泄漏有很多渠道 (例如，通过电子邮件的头部数据) ，许多聪明的“攻击者”会用其他方法找到这些信息。
第二个原因是允许在过滤器后面的内部网络用户或RFC 1918里面的地址 (保留 IP地址段, 文档见RFC 1918)使用DNS解析。分离DNS也允许用于外部邮件回到内部网络中。
下面是分离DNS配置的例子：
假定一个公司名字是Example, Inc. (example.com) ，有几个站点，使用保留IP地址空间的内部网络和外部的非军事区 (DMZ), 或能够和外网通讯的部分。
Example公司希望内网客户能够解析外网的主机名，并且能够和外网进行邮件交换。公司也希望内部解析器能够存取一些只有内部网才可访问的区域数据，这些部分外部网络都不能访问。
为了完成这个需求，公司需要建立两组域名服务器，一组在内部网中，使用保留IP地址空间，另一组是堡垒主机，他们像代理服务器那样，能够同时和外、内网通讯，他们在DMZ中。
内部服务器被配置成转发任何查询，除了site1.internal, site2.internal, site1.example.com,和 site2.example.com，对于DMZ中的服务器，这些内部服务器将有完整的site1.example.com, site2.example.com, site1.internal,和site2.internal的信息。
为了保护site1.internal和site2.internal 这两个域，内部服务器必须配置不允许任何外部主机查询他，包括堡垒主机。
在DMZ的堡垒主机，外部服务器将会把site1 和site2.example.com 区域配置成“公开”型。这包括公众服务器的主机记录 (www.example.com 和
ftp.example.com
)，和邮件交换记录（mail exchange (MX)），如a.mx.example.com 和b.mx.example.com。
另外，公众服务器的site1 和 site2.example.com 区域数据应该指定MX 记录包含通配符(`*’)，指向堡垒主机，这是因为外部邮件服务器没有任何其他办法找到怎样传送邮件到他们内部的主机。使用通配符记录，邮件将会传送到堡垒主机，然后转发到内部主机。
这是通配符MX记录的例子：
* IN MX 10 external1.example.com.
现在，他们按内部网络的行为需要接收邮件，堡垒主机需要知道怎样传送邮件到内部网主机中，为了使他工作正常，堡垒主机的解析器需要配置以指明由内部DNS解析。
查询内部主机由内部服务器应答，查询外部主机将由堡垒主机转发。
为了使这些都工作正常，内部主机需要配置只查询内部DNS服务器，这也能够通过一个选择过滤器来强迫执行。
假如一切都配置正确， Example, 公司的内部用户将能够：
?       查询site1 和site2.example.com 区域中任何的主机。
?       查询site1.internal 和site2.internal 域中任何的主机。
?       查询互连网上任何的主机。
?       和内部网、外部网的用户交换邮件。
互连网主机能够：
?       查询site1 和site2.example.com 区域中任何的主机。
?       和site1 、site2.example.com 中任何用户交换邮件
这是我们前面描述的范例配置，注意这只是配置信息，怎样配置区域数据文档，参看
Section 3.1
内部DNS服务器配置：
acl internals { 172.16.72.0/24; 192.168.1.0/24; }; acl externals { bastion-ips-go-here; }; options { ... ... forward only; forwarders {                               // forward to external servers       bastion-ips-go-here;    }; allow-transfer { none; };                // sample allow-transfer (no one) allow-query { internals; externals; };    // restrict query access allow-recursion { internals; };          // restrict recursion ... ...}; zone "site1.example.com" {                   // sample master zone  type master;  file "m/site1.example.com";  forwarders { };                            // do normal iterative                                              // resolution (do not forward)  allow-query { internals; externals; };  allow-transfer { internals; };}; zone "site2.example.com" {  type slave;  file "s/site2.example.com";  masters { 172.16.72.3; };  forwarders { };  allow-query { internals; externals; };  allow-transfer { internals; };}; zone "site1.internal" {  type master;  file "m/site1.internal";  forwarders { };  allow-query { internals; };  allow-transfer { internals; }}; zone "site2.internal" {  type slave;  file "s/site2.internal";  masters { 172.16.72.3; };  forwarders { };  allow-query { internals };  allow-transfer { internals; }};
外部 (堡垒主机) DNS服务器配置：
acl internals { 172.16.72.0/24; 192.168.1.0/24; }; acl externals { bastion-ips-go-here; }; options {  ...  ...  allow-transfer { none; };                   // sample allow-transfer (no one)  allow-query { internals; externals; };       // restrict query access  allow-recursion { internals; externals; }; // restrict recursion  ...  ...}; zone "site1.example.com" {                   // sample slave zone  type master;  file "m/site1.foo.com";  allow-query { any; };  allow-transfer { internals; externals; };}; zone "site2.example.com" {  type slave;  file "s/site2.foo.com";  masters { another_bastion_host_maybe; };  allow-query { any; };  allow-transfer { internals; externals; }};
在堡垒主机的resolv.conf (或其他相似的)：
search ...nameserver 172.16.72.2nameserver 172.16.72.3nameserver 172.16.72.4

喜欢本文，那就收藏到：

上一篇: 分享交换机 VLAN 配置基础及实例探讨

下一篇: 第4章高级概念(2)

相关推荐

相关资讯