RHEL5下DNS配置詳解3

view bind中的另外的一個技巧他在有防火牆的環境中非常有用。View允許你呈現出不同的配置文件給不同的客戶,當你的服務器既要給內網的用戶又要給外網的用戶提供查詢服務時使用view將是非常方便的。下其實訪問控制列表就是一個有名字的地址匹配列表。
它的語法格式爲除了also-notify語句之外,您可以在需要調用地址匹配列表的任何位置使用訪問控制列表。一定要注意的是acl必須是named.conf中的頂級語句,named.conf只讀一遍,所以訪問控制列表必須在使用之前定義。
view的格式是
view  "interal"  {
};
儘管view的名字可以任意命名,但是做到見名之意是非常不錯的一個好主意。你可以使用  match-clients view 定義那些子區域可以被特定的主機看到,如果你沒有在 match-clients 中限制任何主機,這些區域會被全局可見。下面我們就進行試驗,我的服務器還是上面做實驗的那臺我的view配置如下:
options {
             directory "/var/named";
             listen-on port 53 { 192.168.0.131; };
             allow-query     { 192.168.0.0/24; };
             allow-notify    { 192.168.0.12; };
             notify yes ;
};
acl "fx-subnet" { 192.168.0.8; };
view  "internel" {
          match-clients  { "fx-subnet"; };
zone "." IN { 
         type hint;
         file "named.ca";
};
zone "localhost" IN {
         type master;
         file "localhost.zone";
};
zone "0.0.127.in-addr.arpa" {
         type master;
         file "named.local";
};
zone "0.168.192.in-addr.arpa" IN {
         type master;
         allow-update  { none; };
         file "0.168.192.in-addr.arpa.zone";
};
zone "example.com" IN {
         type master;
         allow-update  { none; };
         file "example.com.zone";
};
zone "movie.com"  IN {
          type master;
          file "movie.com.zone";
};
};
view  "word"  {
          match-clients  { any; };
          recursion  no;
zone "example.com" IN {
         type master;
         allow-update  { none; };
         file "word.example.com.zone";
};
};
下面是我的/var/named/example.com文件的內容:

下面是我的/var/named/word.example.com.zone的內容:

這裏我們故意設置的不一樣,這也是我們使用view所要達到的目標。
我們在客戶機上查詢一下,下面是我在IP地址爲192.168.0.8上查詢的結果:
下面是我在IP地址爲192.168.0.9上面的查詢結果:

看到查詢結果的不同了吧  其實view是比較簡單的,還是那句話有什麼不明白的說出來我們一起進步好吧 我們下面說說DNS日誌管理
named提供幾種內置的輔助調試手段,其中最重要的是可配置性非常靈活的日誌功能,您可以在命令行指定調試級別或者用rndc設置它們。下面我們說說BIND日誌術語的一些詞彙。
channel(通道)消息能去的地方:syslog,文件或者/dev/null
category(類別):named能夠產生的消息類型。例如,有關動態更新或者有關答覆查詢的消息
module(模塊):產生消息來源模塊的名字。
facility(設備):syslog設備名。DNS沒有它自己特有的設備,但是您可以選擇所有的標準設備
severity(嚴重性):出錯消息的糟糕程度。
在設置語句時首先定義通道,即消息可能有的目的地,然後,讓幾種不同類型的消息去往特定的通道。當產生一條消息時,在其發源地就給它指派了一種類別,一個模塊和一種嚴重性級別。然後它被分發到與其類別和模塊相關的所有通道中。每一個通道有一個嚴重性過濾器,用來制定一條消息要通過過濾器所必須具有的嚴重性級別。
logging語句的結構如下;
    logging {
      channel_def;
      channel_def;
       ...
      category category_name {
          channel-name;
          channel_name;
};
};
根據通道是文件通道或系統日誌通道channel_def(通道定義)略顯不同,你必須爲每個通道選擇時file或者syslog,一個通道不能二者都是。
channel channel_name{
        file path [versions numvers | unlimited] [size sizespace];
        syslog facility;
        severity severity;

        print-category yes | no;
        print-severity yes | no;
        print-time  yes | no;
};
對於一個文件通道來說,numvers說明要保存文件的多少備份版本。
sizespec指定在輪換文件之前,他最大應該增加到多大。
facility指定用來對消息做日誌記錄的設備名稱。他可以是任何標準設備。
serviety可以使用的值爲:critical,error,warning,notice,info或者debug。
不同的print選項增加或刪除消息前綴,print-time僅對文件通道有意義,系統日誌將按自己的時間做日誌記錄。
BIND中預先定義的日誌通道有以下幾個:
default_syslog:發送到syslog,設備爲daemon。嚴重性爲info。
default_debug:日誌記錄到文件named.run中,嚴重性設置爲dynamic
default_stderr發送到named進程的標準出錯設備,嚴重性爲info
null:丟棄所有的消息
類別由程序員在編寫代碼的時候確定,他們按照主題或者功能而不是嚴重性來組織日誌消息。
下面我們用一個例子對上述內容進行總結:
我的主配置文件的日誌定義如下:
我們在客戶機上查詢一下,看看/tmp/log.msgs文件中的內容:
好了 到這裏我們的DNS服務的配置也基本上結束了。做這些實驗,我參考了[Linux系統管理技術手冊(第二版)].(美)奈米斯.(這是一本非常經典的書)和OReilly DNS and BIND 5th(2006)(這本書非常詳細的介紹了DNS和BIND)以及我的linux老師的授課視頻。
做這些實驗由於時間匆忙,難免會有錯誤,當你看到是希望你提醒我,讓我們共同進步,關於DNS還有一些功能,以後我會慢慢地補上來的。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章