BIND配置文件详解(三)






7.server语句



服务器(server)语句的定义和使用:



server ip_addr {



[ bogus yes_or_no ; ]



[ provide-ixfr yes_or_no ; ]



[ request-ixfr yes_or_no ; ]



[ edns yes_or_no ; ]



[ transfers number ; ]



[ transfer-format ( one-answer | many-answers ) ; ]]



[ keys { string ; [ string ; [...]] } ; ]



};



服务器语句定义了与远程服务器相关的性质。



服务器语句可以出现在配置文件的顶层或者在视图语句的内部。如果一个视图语句包括一个或更多的服务器语句,只有那些视图语句内的被应用到视图和任何顶层的语句被忽略。如果一个视图不包括服务器语句,则任何顶层服务器语句都被当做默认。



bogus



如果你发现一台远端服务器正在输出错误数据,使用bogus标记它,将会阻止对它的更多查询。Bogus的默认值为no。



provide-ixfr



provide-ixfr子句决定本地服务器是否作为主域名服务器,当远端的一台辅域名服务器要求的时候,响应增量的域传输。如果设定成yes,增量传输将会在任何可能的时候进行。如果设定为no,所有对远端服务器的传输都将是非增量的。如果不设置,在视图或者全局选项块中的provide-ixfr选项的值将使用默认值。



request-ixfr



request-ixfr子句决定本地服务器是否作为辅域名服务器,将会向给定的远端服务器(一般为主域名服务器)发送域的增量传送请求。如果不设置,在视图或者全局选项块中的provide-ixfr选项的值将使用默认值。



对不支持IXFR的服务器的IXFR请求将会自动转回AXFR。这样,就不需要用手工列出哪个服务器支持IXFR哪个不支持。全局默认值yes 一直会起作用。provide-ixfr和request-ixfr子句的作用是使IXFR无效,甚至当主域名服务器和辅域名服务器宣布支持它。



例如当使用IXFR时,如果一台服务器受灾并且崩溃或者破坏了数据。



edns



edns子句决定本地服务器与远端服务器通讯时是否使用EDNS.默认值为yes。



服务器支持两类域传输方式:



第一类,one-answer,每个源数据传输使用一个DNS报文。



第二类,many-answer,在一个报文中汇集了尽可能多的记录。多答案更有效率,但是



只被BIND9,BIND8.X 和BIND4.9.5补丁版本识别。你可以使用transfer-format选项为



一个服务器指定使用哪种方式。如果transfer-format没有被指定,就使用options里的



语句指定的transfer-format。



transfers



transfers用来限定同时从特定服务器进行数据传输的域的数量。如果transfers子句没有被指定,限制将会参照transfers-per-ns制定。



keys



keys子句用来确定一个由key语句定义的key_id,用于当远端服务器通话时的安全处理。key语句必须在涉及它的服务器语句之前。当一个请求发送到远端服务器,一个请求报文将会产生(使用本地指定键并附在报文上)。一个来自远端服务器的请求不要求被这个键标记。



尽管键子句语法支持多键,但是目前每个服务器只支持一个键.









8. trusted-keys语句



trusted-keys语句的定义和使用:



trusted-keys {



string number number number string ;



[ string number number number string ; [...]]



};



trusted-keys语句定义DNSSEC安全根。当非授权域的公共键是已知的但是却不能安全的通过DNS得到,或者因为DNS根域或者它的当前域没有被标记时定义安全根。一旦一个键被设置成信任键,它就被认为是有效和安全的。解答器在所有存在于安全根次级域中的DNS 数据上尝试DNSSEC有效性。



trusted-keys语句能包含多重键入口,每个由键的域名,旗帜,协议算法和键数据的64进位组成。






9. view语句



视图(view)语句的定义和使用:



view view_name [class] {



match-clients { address_match_list } ;



match-destinations { address_match_list } ;



match-recursive-only { yes_or_no } ;



[ view_option; ...]



[ zone-statistics yes_or_no ; ]



[ zone_statement; ...]



};



视图是BIND9强大的新功能,允许名称服务器根据询问者的不同有区别的回答DNS查询。特别是当运行拆分DNS设置而不需要运行多个服务器时特别有用。每个视图定义了一个将会在用户的子集中见到的DNS名称空间。



根据用户的源地址(“address_match_list”)匹配视图定义的“match_clients”和用户的目的地址(“address_match_list”)匹配视图定义的” matach-destinations”。



如果没有被指定,match-clients和match-destinations默认匹配所有地址。一个视图也可以做为match-recursive-only来指定,意思是来自匹配用户的递归请求将会匹配该视图。视图语句的顺序是很重要的,一位用户的请求将会在它所匹配的第一个视图中被解答。在视图语句中定义的域只对匹配视图的用户是可用的。通过在多个视图中用相同名称定义一个域,不同域数据可以传给不同的用户。例如:在拆分DNS设置中的”内部”和”外部”用户。



许多在named.conf 的options里的语句中给出的选项也能在视图语句中使用,仅仅用于使用哪个视图解答请求的时候。当view-specific值没有给出,options里的语句值就使用默 认值。域选项也可以在视图语句中指定默认值;这些view-specific默认值的优先级高于那些在options里面配置的语句。



视图精确到类。如果没有给定任何类,就假设为IN类。注意到所有非-IN视图必须包含一个暗示域,因为只有IN类具有compiled-in默认暗示。



如果在配置文件中没有view语句,在IN类中就会自动产生一个默认视图匹配于任何用户,任何指定在配置文件的最高级的zone语句被看作是此默认视图的一部分。如果存在外部view语句,所有的域视图必须会在view语句内部产生。






这是一则典型的使用视图语句运行的拆分DNS设置



view "internal" {



match-clients { 10.0.0.0/8; };



// 应该与内部网络匹配.



// 只对内部用户提供递归服务.



// 提供example.com zone 的完全视图



//包括内部主机地址.



recursion yes;



zone "example.com" {



type master;



file "example-internal.db";



};



};



view "external" {



match-clients { any; };



// 拒绝对外部用户提供递归服务



// 提供一个example.com zone 的受限视图



// 只包括公共可接入主机



recursion no;



zone "example.com" {



type master;



file "example-external.db";



};



};






10. zone语句



Zone语句的定义和使用:



zone zone_name [class] [{



type ( master | slave | hint | stub | forward ) ;



[ allow-notify { address_match_list } ; ]



[ allow-query { address_match_list } ; ]



[ allow-transfer { address_match_list } ; ]



[ allow-update { address_match_list } ; ]



[ update-policy { update_policy_rule [...] } ; ]



[ allow-update-forwarding { address_match_list } ; ]



[ alsonotify



{ ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]



[ check-names (warn|fail|ignore) ; ]



[ dialup dialup_option ; ]



[ file string ; ]



[ forward (only|first) ; ]



[ forwarders



{ ip_addr [port ip_port] ; [ ip_addr [port ip_port] ; ... ] }; ]



[ ixfr-base string ; ]



[ ixfr-tmp-file string ; ]



[ maintain-ixfr-base yes_or_no ; ]



[ masters [port ip_port] { ip_addr [port ip_port] [key key]; [...] } ; ]



[ max-ixfr-log-size number ; ]



[ max-transfer-idle-in number ; ]



[ max-transfer-idle-out number ; ]



[ max-transfer-time-in number ; ]



[ max-transfer-time-out number ; ]



[ notify yes_or_no | explicit ; ]



[ pubkey number number number string ; ]



[ transfer-source (ip4_addr | *) [port ip_port] ; ]



[ transfer-source-v6 (ip6_addr | *) [port ip_port] ; ]



[ notify-source (ip4_addr | *) [port ip_port] ; ]



[ notify-source-v6 (ip6_addr | *) [port ip_port] ; ]



[ zone-statistics yes_or_no ; ]



[ sig-validity-interval number ; ]



[ database string ; ]



[ min-refresh-time number ; ]



[ max-refresh-time number ; ]



[ min-retry-time number ; ]



[ max-retry-time number ; ]



}];






A. 域文件类型



master



服务器有一个主域(控制域或主域)的配置文件拷贝,能够为之提供授权解析服务。



slave



辅域(也可以叫次级域)是主域的复制。主域名服务器定义了一个辅域或多个辅域(次级域联系以更新域拷贝)的IP地址.默认下,传输是从服务器上的53端口进行的;对所有的服务器来说这是可变的,通过设定一个在IP地址表前或者在IP地址之后基于每个服务器设定端口数字。对主域名服务器的鉴别也能通过每个服务器上的TSIG键来完成。如果文件被指定了,那么任何主域配置信息改变的时候就要复制文件,并且当辅服务器重新启动的时候都会从主域名服务器上重新下载文件。这可能会导致带宽的浪费和服务器重新启动次数的增加。



注意对每个服务器的数量众多的域来说(数万或者数十万),最好使用两级方式命名配置。



例如:一个域的服务器example.com可能把域内容放到一个叫做ex/example.com的文件中,在此, ex/只是域名前两个字符(如果把100K 的文件放入一个单独的目录中,大多数操作系统都会反应缓慢)



stub



子根域与辅域类似,子域只复制主域的NS记录而不是整个域。根域不是DNS的一个标准部分,它们是BIND运行的特有性质。



根域可以用来避免在本机重新获得该域的NS记录,代价是保存一个根域入口和一组named.conf名称服务器地址。这个用法在新设置中并不建议使用,BIND9只在有限的情况下才支持它。在BIND4/8中当前的域传输包括来自当前域的子根的NS记录。这表明,在某些情况下,用户可以为当前域设置只存在于控制服务器里的子根。BIND9服务器从不以这种方式把来自不同域的数据混合。这样的话,如果一个BIND9控制服务器服务于一个已经设定了子根域的母域,所有的当前域的次级服务器都需要设定相同的子根域。子根域也可以用来作为一种促使一个特定域的解答使用一个授权服务器的特定系。例如,在一个使用RFC2157 地址的私有网络上缓存域名服务器可以用子根域进行设置。



forward



一个”转发域”是一种在每个域基础上进行配置转发的一种方式。forward 类型的域语句包括一个转发语句和转发列表,都应用于在域内的由域名给出的查询。如果当前没有转发器语句,就会给出空列表,在域中就不会转发,也就取消了所有在选项中的转发的作用。如果你要使用此种域来改变整体转发选项的状态(”forward first”,”forward only”但是要用同一服务器作为是全局设置)你需要理解全局转发器的特点。



hint



根名称服务器在最初设置时指定使用一个”hint zone”。当配置了”hint zone”的服务器



启动的时候,它使用根线索的设置找到根的名称服务器并得到根名称服务器的最新表。



如果没有为IN类设定线索域,服务器使用一个compiled-in的默认根服务器列表。






B.



域名后面的选项可以对应类。如果没有指定类,系统假定为IN类。这在大多数的情况下都是正确的。



Hesiod类是以一个信息服务的名称命名的,信息服务源于MIT的Athena工程.。Hesiod类是用来在多系统数据之间共享信息,如用户、组、打印机等等。”HS”对Hesiod来说是相同的类。



MIT发展的另一个是CHAOSnet,一个在70年代中期创立的本地协议。它的域数据可以用CHAOS类设定。






C. zone 选项



allow-notify



allow-query



allow-transfer



allow-update



设定哪台主机允许为主域名服务器提交动态DNS更新。默认为拒绝任何主机进行更新。



update-policy



设定一个”简单安全更新政策”。



allow-update-forwarding



设定哪个主机能够向辅域名服务器的次级域提交动态域名服务器更新。默认值为{ none; },意味着不能进行动态更新转发。要使用更新转发,设定allow-update-forwarding{ any; };设定其他值而不是{ none; } 或者{ any; } 是常常起反作用的,因为主域名服务器拥有接入控制的权利,而辅域名服务器没有。



注意到激活一台次级服务器上的更新转发性质可能使主域名服务器依赖基于不安全IP地址的接入控制而可能使之受到***。



also-notify



只当本域notify被激活时才是有意义的。能够收到本域DNS NOTIFY信息的计算机的集合是由所有域中列明的名称服务器加上任何由also-notify设定的IP地址。一个端口可能用每个also-notify地址设定以发送通告信息到那个端口而不是默认的53端口。



also-notify 对根域是无意义的。默认值为空。



check-names



此选项应用于BIND8中以约束hosts文件中的域名的字符集和/或从网络上接收的DNS响应。BIND9不限制域名的字符集也不执行check-names选项。



database



设定储存域数据的数据库的类型。Database后面的关键词是一列whitespace-delimited(非限制空白空间)词。第一个词定义数据库类型,后续词作为数据库的参数传给数据库,解释为特殊的数据库类型。默认值为"rbt",BIND9的本地native in-memory red-black-tree 库,则此数据库没有参数如果其它数据库驱动连接到服务器上的话其他值也是可能的。这些可能的数据库包括分布式的数据库,但缺省是没有连接的。



dialup



forward



只当域有一个转发器列表的时候才是有意义的。当配置为”only”时,在转发查询失败和得不到结果时会导致查询失败;在配置为”first”时,则在转发查询失败或没有查到结果时,会在本地发起正常查询。



forwarders



用来代替全局的转发器列表。如果如故不在forward类型的域中设定,就不会有这个域查询的被转发;全局的转发设置则没有起作用。



ixfr-base



在BIND8中设定动态更新和IXFR的交易日志文件(journal)的名称。BIND9 忽略这个选项而通过附加".jnl"到域文件名后创建日志文件.



ixfr-tmp-file



BIND8的非正式选项,BIND9忽略



max-transfer-time-in



max-transfer-idle-in



notify



pubkey



在BIND8中,此选项用于为DNSSEC标记域的信号(当它们从磁盘装载的时候)的验证设定一个公共域密钥,BIND9不在装载的时候验证密钥并忽略此选项。



zone-statistics



如果设为”yes”,服务器将会为本域储存统计信息,可以存储到在服务器选项中定义的统计文件中。



sig-validity-interval



transfer-source



transfer-source-v6



notify-source



notify-source-v6



min-refresh-time



max-refresh-time



min-retry-time



max-retry-time






D. 动态更新政策



BIND9支持两个授予用户对一个域执行动态更新权限的备选方案,分别由allow-update和update-policy设定。



allow-update 的使用与以前的BIND版本相同。它授于指定用户对域中的任何名称的任何的记录更新的权利。



update-policy 是BIND9中新出现的,允许更多更新控制,定义了一个规则集,规则授予或者取消一个或多个名称被一个或多个用户更新的权利。如果动态更新要求信息被标记(也就是说,可以包含TSIG 或SIG(0)记录),标记人的身份就能被确定。



规则在update-policy 域选项中指定,并只对主域有意义。当update-policy语句出现,这是一个allow-update的配置错误.。update-policy语句只检查信息的签名人,与源地址是不相关的。



这是一则规则的定义:



( grant | deny ) identity nametype name [ types ]



每条规则赋予或者取消授权,一旦一条信息成功的匹配一个规则,则马上执行该规则的给予或者取消操作,并且不检查其它的规则。一个规则是匹配的,就是当标记人匹配身份字段,名称匹配名称字段并且类型是在类型字段中定义的时候。



身份字段定义一个名称或者一个通配符名称,名称类型字段有四个值:



name, subdomain, wildcard 和self



name



当更新名称与原定义的名称字段相同时匹配。



subdomain



当更新名称与原定义的子域的一个名称字段相同时匹配。(包含它本身的名字)



wildcard



当更新名称与原定义的一个位于名称字段中的统配符名称的有效延伸相同时匹配



self



当更新名称与信息标记人的名称相同时匹配。忽略名称字段。



如果没有设定任何类型,规则匹配所有类型除了SIG、NS、SOA 和NXT;类型可能用



名称设定,包括"ANY"。(ANY 匹配所有类型除了NXT,NXT 不能被更新)。






 


转载于:https://blog.51cto.com/yuanbin/108583