|
abelyang
|
 |
« 於: 2003-07-10 02:00 » |
|
1. 上層 DNS 中 .tw 及 .com.tw 的 DNS 查詢量那一個較多 ? 為什麼 ?
2. 依據 ISC 及 CERT/CC 組織的說明,建議使用 BIND 運行 DNS 的人,為了安全的理由,最好都換到 BIND 9.X 版,為什麼像 HINET/SEEDNET 這些 ISP 都不願意換呢 ?
3. BIND 8.X 與 BIND 9.X 何者查詢效能較好 ? 為什麼 ?
4. 當我們網路分 "內網 (192.168/24)" 與 "外網" 時,在過去的時代,都說要內外都要建一個 DNS , 讓內對內,外對外,以保護一些資訊,但是多一部機器或多一個 Server 都是成本,這種狀況在 BIND 9.X 是可以解決的,如何實現 ?
5. 有人在 TWNIC 指定了其 xxx.com.tw 的資料如下: ns1.xxx.com.tw 1.2.3.4 ns2.xxx.com.tw 1.2.3.5 而在其自身 DNS 的 xxx.com.tw 的 zone file 中的 ns rr 如下 ns1.xxx.com.tw 11.22.33.44 ns2.xxx.com.tw 11.22.33.55 5.1試問 當 dns.seed.net.tw 去查詢時其會named會產生什麼 log (一般的 log level) 及 cache 什麼資料 ? 5.2 而又當 ns.nctu.edu.tw 去查詢時,其 log 及 cache 情形又為何 ?
6. 有一個網域名稱叫 tw.com.tw , 為什麼他的查詢是高達每小時數萬次 ? 管理人員覺得很困擾,用 FireWall 將 DNS query 給檔下來又會發生什麼事 ?
7. DNS 欺騙有那幾種狀況 ? 如何預防 ?
8. 以下這兩行訊息,如何在實作上表現 ? 意義為何 ? Sep 24 10:40:11 pc071 syslog: gethostby*.getanswer: asked for "37.103.74.204. in-addr.arpa IN PTR" , got type "CNAME" Sep 24 10:40:11 pc071 syslog: gethostby*.getanswer: asked for "37.103.74.204.in-addr.arpa", got "37.32/27.103.74.204.in-addr.arpa"
9. 這一行 log 有那些可能性存在 ? Jun 11 11:36:07 pc071 named[6103]: Response from unexpected source ([168.95.1.24].53) for query "_ldap._tcp.tmt.gtmt.com.tw IN SOA"
10. Windows DNS 可以在 GUI 的介面上顯示 Cache 資料, 那在 BIND 要如何知道現在的 DNS Cache 了那些資料 (BIND 8.x 與 9.x 方法各為何 )?
|
|
|
|
|
已記錄
|
|
|
|
bill09
可愛的小學生

文章: 8
|
 |
« 回覆文章 #1 於: 2003-07-10 07:56 » |
|
自我介紹一下好了... 我是柯玲芬...>< 幼小心靈忽然受到打擊....
|
|
|
|
|
已記錄
|
|
|
|
|
ericshei
|
 |
« 回覆文章 #2 於: 2003-07-10 08:55 » |
|
看來看去只會一題,慘了被當定了......
/me 跑去角角啜泣~~~
|
|
|
|
|
已記錄
|
|
|
|
|
小穎
|
 |
« 回覆文章 #3 於: 2003-07-10 09:32 » |
|
完了!回家哭泣! 4、用「View」 7、只記得有TSIG、DNSSEC及ACL...無言 9、BIND的版本過舊,不支援SRV RR! 10、BIND 8 => ndc BIND 9 => rndc 不要全錯呀…… :cry: 再研究再研究!
|
|
|
|
|
已記錄
|
|
|
|
|
ozakipw
|
 |
« 回覆文章 #4 於: 2003-07-10 10:20 » |
|
我也只會一題....@@"
|
|
|
|
|
已記錄
|
img]http://61.222.212.236/~test1/sing.jpg[/img]
|
|
|
|
abelyang
|
 |
« 回覆文章 #5 於: 2003-07-10 10:23 » |
|
4、用「View」 7、只記得有TSIG、DNSSEC及ACL...無言 9、BIND的版本過舊,不支援SRV RR! 10、BIND 8 => ndc BIND 9 => rndc
4. 答對了 ~~ 7. 這一題的答案是希望 那些 Spoofing 手法, 各可用什麼解, DNSSEC 算是對一點點了哦...其他都不是這題所要的 (當然,TSIG/ACL 是可以增進安全) 9. 不對 10. 對一半
|
|
|
|
|
已記錄
|
|
|
|
|
duan
|
 |
« 回覆文章 #6 於: 2003-07-10 10:48 » |
|
果然是很有深度的題目啊, 看著看著也傻眼了 :~~ 1. .com.tw 比較多, 因為 .com.tw 的網域名稱比較多. 2. 查詢效能? 3. bind 8x 比較好. 因為...........功能比較單純? ^^; 4. view 5. 雖然是兩小題, 可是分不出來. :~~ 只是看起來 NS 資料不合, 應該會有問題? 6. 會產生 loop ? 哇勒......好想找扇窗往外跳....... @_@ 7. 太難了太難了, 要上網找資料  8. 反查 37.103.74.204 的資料? 可是怎麼會有 CNAME ... ^^; 太少注意 named 產生的 log, 可是這是內定的 log level 產生的嗎? 看起來 好陌生  9. (左手打開窗戶, 右手準備把這封信轉給朋友, 預備答完第十題就跳出去) 10. (咻..........................砰.....)
|
|
|
|
|
已記錄
|
|
|
|
|
horse
|
 |
« 回覆文章 #7 於: 2003-07-10 11:43 » |
|
疑~~我覺得第一題的答案應該是 .tw 比較多, 因為要查 .com.tw 必須先去詢問 .tw 凡是要查xxx.tw 的都必須先去詢問 .tw
|
|
|
|
|
已記錄
|
|
|
|
|
paulso
|
 |
« 回覆文章 #8 於: 2003-07-10 11:46 » |
|
我沒一條懂… 真考人…
|
|
|
|
|
已記錄
|
|
|
|
|
godeagle
|
 |
« 回覆文章 #9 於: 2003-07-10 11:51 » |
|
1. .com.tw。因為 .tw只包含.com.tw, .idv.tw, .edu.tw,...等資料而已 雖然每次要詢問 .com.tw 的時候,都要先向 .tw要求一次,但要記得 $TTL 這東東, 所以, .com.tw 主機位置,就會 cache 在你所用的 dns server 了, 換句話說,你的 dns server 只有向 .tw 主機要一次資料而已, 再來就都使用 cache 裡的資料......除非 $TTL 過期... 4. view。剛好我前一陣子才玩過...  ,我弄了三個zone,一個對外兩個對內
|
|
|
|
|
已記錄
|
|
|
|
|
abelyang
|
 |
« 回覆文章 #10 於: 2003-07-10 11:54 » |
|
duan 兄一出手,就知有沒有 ~~ 1. com.tw 較多, 因為 .tw 的 DNS 只有六部, 很容易就被 Cache, 且其下的 .tw 其下的 record 僅有 net/org/gov/...tw,所有資料亦不過十幾筆 但 com.tw. 下的資料會有數萬筆以上,所以,當有人查詢 x1.com.tw. 時,沒有 cache 就會問到 .tw 及 com.tw., 再查 x2.com.tw. 時,因為巳有 cache, 短期內就不會再去問 .tw 了 而是問 .com.tw , x2.com.tw. 在那裏, 所以 com.tw. 的量會較多,且多好幾倍 ! 2. 大家可想想~~3. 再想想4. 這題看來大家都知道答案了... 5. 這題很難哦~~ 再想想6. 是會有像 loop 的效果...但是 還沒有完全答出來哦 7. 參考這裏 http://www.twnic.net.tw/download/download_01.htm [dns 安全] 8,9,10. 再想想目前解出來的僅有 1,4,7 題...大家加油
|
|
|
|
|
已記錄
|
|
|
|
|
Jishon
|
 |
« 回覆文章 #11 於: 2003-07-10 12:03 » |
|
好難啊, 查了一些資料..不知道對不對
2. BIND9實作封包認證機制解決DNS Spoofing, 但效能會降低 3. BIND8,BIND9如果使用包認證機制效能較差? 7. 冒名者提供假的網域名稱與網址的對照資訊, 將使用者引導至假網站 .....採用封包認證機制
|
|
|
|
|
已記錄
|
Sendmail, BIND 惡補中.....
|
|
|
|
abelyang
|
 |
« 回覆文章 #12 於: 2003-07-10 12:24 » |
|
2. BIND9實作封包認證機制解決DNS Spoofing, 但效能會降低 3. BIND8,BIND9如果使用包認證機制效能較差? 7. 冒名者提供假的網域名稱與網址的對照資訊, 將使用者引導至假網站 .....採用封包認證機制 2. 不太對哦~~因為封包認證(您指應是 DNSSEC 吧?) Default 並不會啟動 且以 DNS 的授權關係, Root Server 不做 DNSSEC ,下面的DNS做也沒有意 義, ISP 也不會給自己找麻煩.... 3. 同上解譯...所以不太對哦 7. 巳解答了, 因為長篇大論~~所以給一個 Link 讓大家自己去參考囉
|
|
|
|
|
已記錄
|
|
|
|
|
abelyang
|
 |
« 回覆文章 #13 於: 2003-07-10 14:11 » |
|
8. 反查 37.103.74.204 的資料? 可是怎麼會有 CNAME ... ^^; 太少注意 named 產生的 log, 可是這是內定的 log level 產生的嗎? 看起來 好陌生 這個剛沒有看到 ~~ 這是 syslogd 產生的,gethostbyaddr 要查一個 IP 的 PTR 記錄, 可是得到的是 CNAME 的記錄...意思是這樣 ~~ 但這裏我想知道的人就會知道了~~不知道的人還是會不知道哦 ~ 和反解有關
|
|
|
|
|
已記錄
|
|
|
|
|
netman
|
 |
« 回覆文章 #14 於: 2003-07-10 14:12 » |
|
哇﹗好難哦,沒去查資料之前先猜一猜: 1,com.tw 吧,因為在 cache 後就不再需查 tw 了。 2,版本兼容問題嗎?我不了解他門的實際情形,若他們原本有另行開發一套管理系統(如 database之類),要轉移的成本及風險需要緊慎評估。不過,我是亂猜的... ^_^ 3,不確定,好像是 9 比較好。 4,view 5,視 resolver 版本而定,有些以 SOA 的 answer 為準,有些則不然,有 answer 就好。 6,真的猜不懂?難道是那個 tw 作怪($ORIGIN com.tw. 下面的 record 沒用 . 結尾?)?不過,若將 query ban 掉,那麼這台 name server 也沒必要存在了。 7,哦,很多... 反正 dns 很好騙,能將你的查詢道到我想要的 server ,就甚麼 answer 都做的出來。 8,子網反解授權。 9,"_" 不能作 record name 。 10,真的不知,我都是用 dig 來查的。
|
|
|
|
|
已記錄
|
|
|
|
|
duan
|
 |
« 回覆文章 #15 於: 2003-07-10 14:34 » |
|
這個剛沒有看到 ~~ 這是 syslogd 產生的,gethostbyaddr 的要查一個 IP 的 PTR 記錄, 可是得到的是 CNAME 的記錄...意思是這樣 ~~ 但這裏我想知道的人就會知道了~~不知道的人還是會不知道哦 ~ 和反解有關 看到 abelyang 兄這裡的說明, 以及 netman 兄之後的答案, 才知道這 個 log 代表的意思. ^^ 真慘, 沒幾題對的, 果然是一出手......就知道沒有.... ^^;;; 那個最後一題, 您說小穎兄的答案對一半, 是指 rndc 的部份是對的嗎? 剛剛去查這題, 想說設 cache-file , 可是 cache-file 產生後好像不是放 cache 的資料 (真是胡搞啊 ^^) , 後來看 rndc 有 dumpdb 的參數. 可以 執行後沒產生檔案. :O 繼續試試看...... @_@
|
|
|
|
|
已記錄
|
|
|
|
|
duan
|
 |
« 回覆文章 #16 於: 2003-07-10 14:37 » |
|
第五題是不是會產生 lame server 的 log 啊?
可是還是不懂由 seednet 和 nctu 去詢問會有什麼差別.... ^^;
|
|
|
|
|
已記錄
|
|
|
|
|
duan
|
 |
« 回覆文章 #17 於: 2003-07-10 14:41 » |
|
後來看 rndc 有 dumpdb 的參數. 可以 執行後沒產生檔案. :O
繼續試試看...... @_@ oooops......找到 dump 下來的檔案, 看起來 bind 9 的答案是 rndc dumpdb 沒錯了. ^^;; 手上沒有 bind 8 , 裝死去.......... :Q
|
|
|
|
|
已記錄
|
|
|
|
|
abelyang
|
 |
« 回覆文章 #18 於: 2003-07-10 14:44 » |
|
2,版本兼容問題嗎?我不了解他門的實際情形,若他們原本有另行開發一套管理系統(如 database之類),要轉移的成本及風險需要緊慎評估。不過,我是亂猜的... ^_^ 因為 BIND 9.x 對 DNS 資料的檢查較 8.X嚴謹,一般 ISP 的 DNS 都用於 Client 端指定,有很多設定錯誤的 Zone File 可能會查不到,但用 8.x 就可以查得到之故 國內曾有 ISP 單位換到 BIND 9.x , 但是 User 反應有些網域名稱查不到, 換回來 8.X 後就可以查得到了 3,不確定,好像是 9 比較好。 這題大家可能較難找資料吧 ~~答案是 Bind 8.X why ? 因為 Bind 8.X 在處理資料時是以 Hash Table 來儲存的 而 BIND 9.x 是用二元樹 (binary tree, 正確一點的說法是紅黑二元樹,red-black binary tree,較能達到 Balance),不了解這兩種演算法的可以參考這篇 http://ciips.ee.uwa.edu.au/~morris/Year2/PLDS210/niemann/s_man.pdf而實作出來的 BIND 8.x 及 9.x 在處理查詢效率上差了近一倍, 如果 8.x 是一萬次/每秒,但 9.x 大概只能到 5000 為什麼 9.x 反而退步了 :roll: 因為 BIND 9 要和資料庫結合及驗證 DNS tree 的結構性(所以較嚴謹).... DB 本來就是 Tree 結構不是嗎 第五題 我就先不解答了,這題涉及很多層面哦 6. 請從 default domain/search , reslover 去想... block port 53, 除非他的頻寬超過 T1, 不然一定塞 ( timeout/retry 去想) 這是一個 real case 8. 這是一個 不滿一個 Class C , IP 的反解授權的查詢結果 9,"_" 不能作 record name 。 10,真的不知,我都是用 dig 來查的。 9. 再想想看哦~~ "_" 是 Cleint 送出去的, 合不合法和這個 log 較無直接關係 10 有人答對了 BIND 9 是用 rndc, 但 BIND 8 是不一樣的哦... 還有 5,6,9,10 題 還沒解出來哦...
|
|
|
|
|
已記錄
|
|
|
|
|
abelyang
|
 |
« 回覆文章 #19 於: 2003-07-10 14:48 » |
|
第五題是不是會產生 lame server 的 log 啊? 可是還是不懂由 seednet 和 nctu 去詢問會有什麼差別.... ^^; hint: 兩個單位的 DNS 是 不同版本 ... dig @name_server soa chaos txt version.bind 可以得到結果 ... 但如果 在 named.conf 中加 options { version "....."; ...; }; 查到的就是 ..... 了
|
|
|
|
|
已記錄
|
|
|
|
|
netman
|
 |
« 回覆文章 #20 於: 2003-07-10 15:36 » |
|
6. 請從 default domain/search , reslover 去想... 哦,原來是 hosts 的設定... 不過,要將 search 設為哪樣的 domain 才會去打擾 tw.com.tw 呢?還是沒猜得出。 另,就算在 firewall 將 udp 53 給 block 掉,對 inbound traffic 不見得有改善。 只是 firewall 到 ns 之間的流量少了,internet 到 firewall 的流量還是一樣... 而且 udp 連線本身也不需作 connection 確認,封包只管往這邊丟就是了... 10 有人答對了 BIND 9 是用 rndc, 但 BIND 8 是不一樣的哦... 我到 google 輸入 "bind 8 cache dump" 來找,第三篇有如下這段: (Note: the in.named(8) man page mentions that sending a SIGINT to the in.named process will dump the current data base and cache to, by default, /var/tmp/named_dump.db. Some sites may find this useful in looking for self-referential CNAMEs. Please see the in.named(8) man page for further details.) 不過我沒試過... 還有 5,6,9,10 題 還沒解出來哦... 嗯,的確很難... 真要找一下資料才行...(不常碰到也不會找啦)
|
|
|
|
|
已記錄
|
|
|
|
|
abelyang
|
 |
« 回覆文章 #21 於: 2003-07-10 15:39 » |
|
哦,原來是 hosts 的設定... 不過,要將 search 設為哪樣的 domain 才會去打擾 tw.com.tw 呢?還是沒猜得出。 另,就算在 firewall 將 udp 53 給 block 掉,對 inbound traffic 不見得有改善。 只是 firewall 到 ns 之間的流量少了,internet 到 firewall 的流量還是一樣... 而且 udp 連線本身也不需作 connection 確認,封包只管往這邊丟就是了... 這個問題我想和 OS 的 resolver 實作有關,如果我們將 Doamin/Search 設成了 xxx.com.tw. , 在自動 Append 的機制上,有的平台會有這種情況 ping abelyang.xxx.com.tw <==最後沒有加 . resolver abelyang.xxx.com.tw. resolver abelyang.xxx.com.tw.xxx.com.tw. resolver abelyang.com.tw.com.tw. resolver abelyang.com.tw.tw. 會將 xxx.com.tw 一層一層拆開來試 至於 Domain 的 53/UDP port 在 timeout 太多的狀況下有可能會換成 53/TCP, 所以就可能會有影響了..., 如下  這個網域名稱會衍生出一個問題 ....如果他在 tw.com.tw 的 Zone File 中加入 * IN A MailServer_IP ....結果會如何呢 ? bind 8 的 cache dump 指令 kill -ILL named_pid 還是 kill -IRR named_pid 兩個其中一個就是了...
|
|
|
|
|
已記錄
|
|
|
|
|
netman
|
 |
« 回覆文章 #22 於: 2003-07-10 16:06 » |
|
耶﹗i like this feeling! 這就是討論的樂趣了~~~ 比單純的 asking "爽" 多了﹗.. ^_^
abel 兄再多帶些"樂趣"來吧...
|
|
|
|
|
已記錄
|
|
|
|
|
abelyang
|
 |
« 回覆文章 #23 於: 2003-07-10 16:14 » |
|
如果這十題 over 了, 我再出 11-20 題好了 不過我的題目都非常深入哦 ~~ 
|
|
|
|
|
已記錄
|
|
|
|
|
duan
|
 |
« 回覆文章 #24 於: 2003-07-10 16:21 » |
|
這個問題我想和 OS 的 resolver 實作有關,如果我們將 Doamin/Search
講到這個, 弟之前處理一個客戶的問題時, 在這邊有遇到這樣的經驗. /etc/resolv.conf 裡, 弟一般是設定 search abc.com.tw 而有同事則習慣設為 domain abc.com.tw 客戶的問題是, 他用 nslookup 去看, set d3 , 會看到查詢過程中, 若查尋不到 www.def.com , 會依次查詢 www.def.com.abc.com .tw, www.def.com.com.tw , 然後才回報說查不到. 當時 check 一下設定, 如果把 domain abc.com.tw 換成 search abc.com.tw , 就會變成 www.def.com 查不到, 就會查 www.def.com.abc.com.tw , 但不會去試 www.def.com.com.tw 試了幾台都是這樣的情況, 印像中 bind 8, bind 9 都會這樣. 這是 bind 正常 的行為嗎? ^^;
|
|
|
|
|
已記錄
|
|
|
|
|
duan
|
 |
« 回覆文章 #25 於: 2003-07-10 16:23 » |
|
如果這十題 over 了, 我再出 11-20 題好了 不過我的題目都非常深入哦 ~~  深入沒關係, 就怕每天都在解題, 三天就被老闆 fire 了..... ^^;;; 等等要去找簡單點的題目來 balance 一下, 免得想不開... @_@
|
|
|
|
|
已記錄
|
|
|
|
|
abelyang
|
 |
« 回覆文章 #26 於: 2003-07-10 16:24 » |
|
duan, 是的,如果不希望有這種情況,在所有的名稱後都加一個 "." 就不會發生了 曾經用 gethostbyname, 查不到資料,但明明有那筆資料, 後來用 tcpdump 看, 原來一開始就幫我加了 defualt domain... XD
|
|
|
|
|
已記錄
|
|
|
|
|
netman
|
 |
« 回覆文章 #27 於: 2003-07-10 16:39 » |
|
哈,我的習慣都是將 resolv.conf 的 domain 及 search 兩行砍掉或註解掉。
我之前只以為 appanding 的 domain 只是所指的 domain.name.com (入 abc.com.tw) 而沒想到如 abel 兄提到的"逐級" appand 的情形,即: + abc.com.tw + com.tw + tw ...
|
|
|
|
|
已記錄
|
|
|
|
|
abelyang
|
 |
« 回覆文章 #28 於: 2003-07-10 16:59 » |
|
我想這可能要看 resolver 才能下定論, 像 duan 一樣,只是恰巧發現這像的現象而以 目前還有 5,9 兩題未解哦... 第六題的 tw.com.tw. 如果在 Zone 內加 *.tw.com.tw. 會如何的問題了
Hints: 5. 是會都會有 lame server 的 log, 但是 DNS Cache 的資料不同 9. Response from unexpected source ([168.95.1.24].53) for query "_ldap._tcp.tmt.gtmt.com.tw IN SOA" 字面解釋是 查詢 "_ldap._tcp.tmt.gtmt.com.tw" 的 SOA 時,意外的從 168.95.1.24 來了回應,也就是原來這部 Local DNS 去問的不是 168.95.1.24 而是另有其人,但結果卻從 .24 回來了
|
|
|
|
|
已記錄
|
|
|
|
|
abelyang
|
 |
« 回覆文章 #29 於: 2003-07-11 00:02 » |
|
|
|
|
|
|
已記錄
|
|
|
|
|