全部博文（2065）
分类： LINUX
2010-06-08 13:39:09
1. 當我在Linux
2.2.x上使用以–enable-threads選項編譯的bind程序時，為什麼-u參數不起作用？
答：Linux線程並沒有完全實現Posix線程（pthreads）標準。特別是setuid()只能對當前線程起作用，而不適用於整個進程。 正是由於此項限制，Linux上的BIND 9就無法像在其他支持的系統平台上一樣使用setuid()。在創建線程之前不能調用setuid()，因為服務器只有在線程啟動之後才能開始監聽預留端 口。
對於2.2.18或2.3.99-pre3以及更新的內核而言，則能在調用setuid()之後仍然保持可用性。這使得BIND 9可以更早些調用setuid()，而同時又保持了綁定預留端口的能力。這是針對Linux所作的特別處理。
在2.2內核上，BIND 9的確放棄了許多root權限，所以相對於那些沒有放棄權限的root進程而言，這會更加安全一些。
如果Linux線程已經正常工作，那麼這項限制也就不復存在。
用戶可以使用–disable-threads選項（這是默認選項）來編譯BIND9，這樣會生成一個非線程的版本，用戶能夠使用-u選項。
2、為什麼named的日誌中會給出警告信息”no TTL specified - using SOA MINTTL instead”？
答：你的zone文件不符合RFC1035標準。你可以使用兩種方法來解決此問題：
1）在zone文件的開頭加入一行對TTL的定義，例如：$TTL 86400
2）在zone文件的第一條記錄中包含TTL字段，例如：example.com. 86400 IN SOA ns hostmaster
3、為什麼我在Linux上會看到5個（或者更多）的named副本？
答：在ps下每個Linux線程也會像進程一樣顯示出來。一般運行的線程個數為n+4，這裡n表示CPU的數目。注意在內存量的使用上並不遵從累加的原則；如果每個進程使用10M內存，那麼所有線程總共也只使用10M內存。
4、為什麼即便我在Linux系統上用root身份運行BIND 9，在訪問配置文件或zone文件時，仍然會得到關於”permission denied”錯誤的日誌？
答：在Linux上，BIND 9在啟動時就放棄了絕大部分root權限，這其中就包括打開其他用戶所屬文件的權限。因此，如果服務器是以root身份運行的，那麼配置文件和zone文件也應該由root所有。
5、為什麼我得到類似於”dns_zone_load: zone foo/IN: loading master file bar: ran out of space”的錯誤提示？
答：這通常是由於TXT記錄中少了一個引號所致。檢查所有TXT記錄是否都包含了完整的引號。
6、我怎樣能夠在Linux上從多線程named生成一個可用的core文件？
答：如果Linux內核是2.4.7或更新的版本，多線程core導出（dump）是可用的（也就是說，將導出正確的線程）。否則，如果使用的是
2.2內核，那麼需要應用在contrib/linux/coredump-patch中的內核補丁並重新編譯內核。該補丁可以使多線程程序導出正確的線
程。
7、我怎樣限制別人查詢我的服務器版本？
答：在named.conf的”options”段中放置”version”選項，並將其值設成與你實際使用版本不同的其他版本。注意：這樣做不能避免攻擊，反而可能會妨礙別人對你服務器問題的診斷嘗試，而且這同樣可能成為別人鑑別你服務器的標誌。
8、我怎樣限制只有遠程用戶才能查詢服務器版本？
答：當存有版本信息的內部視圖被最後匹配時，下面的視圖語句將攔截查詢。上面一問回答中的警告在這裡同樣適用。
view “chaos” chaos {
match-clients { ; };
allow-query { none; };
zone “.” {
type hint;
file “/dev/null”; // or any empty file
};
};
9、”no source of entropy found”或”could not open entropy source foo”是什麼意思？
答：服務器需要信息熵（entropy）源來執行特定的操作，通常這與DNSSEC相關。這些信息提示沒有信息熵源。在有/dev/random或類似設備的系統上，默認會使用它們。信息源也可以通過named.conf中的random-device選項來定義。
10、我安裝了BIND 9並且重新啟動了named，但是它仍然是BIND 8，這是為什麼？
答：BIND 9默認安裝在/usr/local下。而BIND 8通常安裝在/usr下。檢查是否正確的named在運行。
11、我嘗試使用TSIG來驗證動態更新或者zone傳輸。我確信密鑰設置是正確的，但是服務器仍然拒絕TSIG，為什麼？
答：這可能是時鍾不准的問題。檢查客戶端的時鐘和服務器上的是否同步（例如使用ntp）。
12、我嘗試編譯BIND 9，但”make”卻因為某些文件無法找到而失敗了。為什麼？
答：使用並行或分佈式的”make”來編譯BIND 9是不支持的，而且也無法工作。如果你確實使用的是它們中一種，建議你使用一般的make或gmake來替代。
13、我有一台BIND 9的主服務器和一台BIND 8.2.3的從服務器，而主服務器記錄到類似於”notify to 10.0.0.1#53 failed: unexpected end of input”的錯誤信息。哪有問題？
答：該錯誤信息是由BIND 8.2.3中一個已知的bug所致，這在BIND 8.2.4中得到了修復。你可以完全不必理會它 - 不管錯誤信息如何，notify都在正常工作著。
14、我不斷地得到如下的日誌信息，為什麼？
Dec 4 23:47:59 client 10.0.0.1#1355: updating zone ‘example.com/IN’:
update failed: ‘RRset exists (value dependent)’ prerequisite not
satisfied (NXRRSET)
答：DNS更新程序允許更新請求在進行更新之前進行測試以確認特定的條件是否滿足。以上信息說明條件不滿足，無法繼續進行更新。參看doc/rfc/rfc2136.txt以獲知關於前提條件的更多信息。
15、我不斷地得到如下的日誌信息，為什麼？
Jun 21 12:00:00.000 client 10.0.0.1#1234: update denied
答：有人在嘗試使用RFC2136動態更新協議來更新你的DNS數據。Windows
2000的機器有這樣的習慣：無需事先配置就發送動態更新請求給DNS服務器。如果更新請求來自於Windows
2000機器，請參看
16、我看到如下的日誌信息，為什麼？
couldn’t open pid file ‘/var/run/named.pid’: Permission denied
答：很可能你是以非root用戶在運行named，而該用戶又對/var/run沒有寫權限。通常的修複方法是創建由named用戶所有的
/var/run/named目錄並設置pid文件為”/var/run/named/named.pid”，或者設置pid文件為
“named.pid”，這將把該文件放到由directory選項指定的目錄（在此情況下，該目錄必須對named用戶可寫）下去。
17、當我在執行「dig . ns”時，許多關於root服務器的A記錄都丟失了。為什麼？
答：這是正常的情況，並無大礙。在BIND 9實現RFC 2181的信任級別（trust ranking）的方法和BIND 9對避免相關數據（glue）進入回答所作的努力上，有些令人迷惑的副面效果。
當BIND
9第一次啟動並初始化其緩衝時，它接收根服務器地址作為根服務器權威響應的附加數據，並且這些記錄符合包含在響應中作為附加數據的條件。隨後，它接收根服
務器地址的子集作為根服務器的非權威（推薦）響應的附加數據。這導致這些地址現在被視為非權威的（相關的）數據，它們不適合包含在響應中。
服務器的確總是有一組完整的根服務器地址作為緩衝，只是有可能沒有包括全部的地址作為附加數據，這取決於它們最後接收的是響應還是相關數據。你通常可以使用顯式查詢如「dig a.root-servers.net A”來查找這些地址。
18、從BIND 9主服務器傳輸zone到Windows 2000從服務器失敗了。為什麼？
答：這可能是由於Windows 2000
DNS服務器的一個bug所致，在Windows機器上，大於16K的DNS消息就無法正確處理。這可以通過設置選項”transfer-format
one-answer;”來解決。也可以檢查你的zone是否包含了內嵌的空格或其他的特殊字符，例如”John
