关于DNS的一篇好文章

2.為什麼反解多 ?

2.1 發生次數多
不用懷疑, 假設以一封 email 的遞送來跑一下流程就知道了:
1) client 查 smtp 的正解
2) smtp server 查 client 的反解
3) smtp server 查目標 server 的正解
4) 目標 server 查 smtp server 的反解
是的, 我們可以肯定 srever 查的多是沒錯, 但正解與反解不是相等的嗎?
呵, 那你就有所不知了…
因為, 除了 smtp 連線要查 dns 之外, 事實上, 還有很多地方要查 dns 的,
這得看各 server 的配置而定, 很難有個”統一”的答案…
比方說, smtp server 設了 super daemon, 要做 syslog, 還會交給 tcpwrapper…
然後 smtp daemon 還會查 relay db, rbl, … 諸如此類的…
還有, 若 dns server 本身有起用一些 log facility , 那事實上, 每一次被查都會再查一次 resolver 端的反解…
所有上述這些, 都只是一些例子, 還不是全部哦~~~
然而, 我們可以肯定的是:
上面那些服務, 大都是查反解的!
因此, 你不難算一算一個單一的 email 遞送過程中, 會觸發多少個 dns 查詢? 及其中的正反解的比例?
最簡單的羅輯是:
有一個正解需求的連線發生後, 通常就會引起一個反解, 但更多時候會引起更多的反解!

2.2 遞歸次數多
正解查詢,大家都想求正確,求快,求穩定,那為什麼反解不用呢 !?
因為你感受不明顯!但 server 可明顯了,網路的 traffic 也會受影響.

我們先看 CU 為例:
www.chinaunix.com.
61.135.136.122==>122.135.136.61.in-addr.arpa.

若 CU 的 IP 有設反解, 正解在沒有 Cache 因素干擾下,從 Client (C) 到
DNS Server (S) 解出來會有 :

代码:

C->S
S->Root (.)
Root->S
S->com.
com->S
S->CU
CU->S
S->C

共發生 8 次 packet..

你去訪問 CU 時,若 CU 的 Web Log 有開 Lookup IP 的功能(一般是不會開
的,但你跑 awstats 還是要查一次,有開的沒反解再查一次),

代码:

CU->S
S->Root
Root->S
S->ARPA
ARPA->S
S->in-addr.arpa.
in-addr.arpa.->S
S->122.in-addr.arpa.
122.in-addr.arpa.->S
S->136.61.in-addr.arpa.
136.61.in-addr.arpa.->S
S->135.136.61.in-addr.arpa.
135.136.61.in-addr.arpa.->S
S->CU

發生 12 次
(domain 愈長查愈多次不是嗎 !? )

很可惜, CU 的 IP 沒有反解,最後只到 122.in-addr.arpa. 而以,所以查詢只到
這裏而以,那也發生了8次呀.再來看,正解會 Cache,被 (S) Cache 6 小時,那反解
呢 ? 跟本是失敗的呀…抱歉,多數的 DNS 在發生時會再查一次,少數的 DNS 會做
negative cache (ncache),若有做 ncache,算你幸運,那 apnic 把這個值設成兩天,
但這只是少數而以.

代码:

61.in-addr.arpa. 172800 IN SOA ns1.apnic.net. read-TXT-record-of-zone-first-dns-admin.apnic.net.
2004081901 7200 1800 604800 172800

註:ncache 會看 SOA 第五個數字,在 bind 8 叫 min TTL,bind 9 叫 ncache TTL,
ncache 發生時(就是 DNS 知道找不到答案),會和此值和 SOA 的 TTL 值誰高而定,
但是你的 DNS Server 有 ncache 功能嗎 !? (這個議題這裏就不論述了,會受太多
因素影響)

好了,現在我們知道,不僅發生頻率反解多,Recusion 也是反解多,為什麼你要浪費
這麼多的 Traffic 呢 !? 更有意思的是….如果全中國上千萬個 IP 可解的不到
3%,那又是一個什麼樣的情況呢 !? 反解真正的含義是什麼呢!? 為什麼台灣可
以到 50% 左右的反解率呢 !?

3. 中國有多少個 IP ? 反解情況如何 ?
這個數字你可以從 APNIC 取得,並計算出來:

代码:

wget http://ftp.apnic.net/stats/apnic/delegated-apnic-latest
(cat delegated-apnic-latest | grep -i ‘CN|ipv4′ |cut -f 5 -d’|’ | tr ‘n’ ‘+’;echo 0) | bc

Ans:54449664 (2004/09/04)
我自己三年前曾做過這樣的測試,將中國的所有 IP 都查一次反解,實際的總數巳不
記得了,但記得結果是 2%,所以,我們先來推論現況,但是這邊我們還是可以來做一個
簡單的實驗:

上一篇發現一些小錯誤,以下做了一些調整,以求得更正確的值,原來的 script 有點問題:

代码:

#取得 IP (net_id) , 共 731 段,每段IP數量不等
cat delegated-apnic-latest | grep -i ‘CN|ipv4′ |cut -f 4 -d’|’ >ipv4_cn
#把 .0 都換成 .1,主要是要 host,用 .0 來查可能會有問?#125;,雖說 .0 都換成 .1 可能不準,但也只存在 /24 的問?#125;才有
replace ‘.0’ ‘.1’ — ipv4_cn
for ip in `cat ipv4_cn`
do
echo -e “$ip==>$(dig -x $ip | grep ‘IN.*NS’ | head -1)” >>ns_rr_cn
done

這個答案是 72 筆,約為1/10 ,依照約數,中國的反解率最多僅為 10%,如果這其中並
沒有設錯的或少設的,隨意舉個 “北大,pku.edu.cn” 的例子好了(第一個就挑中好
sample,這個 sample 我們後面再講授權時還會用到,請務必理解):
北大的 IP 是 162.105.x.x,我們先來看看授權(NS delegation) 及解析情形如何:

IP 在反查時,一定會先到 in-addr.arpa. 我想這是很平常的觀念,所以我們查詢
in-addr.arpa 有那些 NameServer:

代码:

SIP> dig in-addr.arpa. ns

; < <>> DiG 9.2.3 < <>> in-addr.arpa. ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 48366 ;; flags: qr rd ra; QUERY: 1, ANSWER: 12, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;in-addr.arpa. IN NS ;; ANSWER SECTION: in-addr.arpa. 86400 IN NS L.ROOT-SERVERS.NET. in-addr.arpa. 86400 IN NS M.ROOT-SERVERS.NET. in-addr.arpa. 86400 IN NS A.ROOT-SERVERS.NET. in-addr.arpa. 86400 IN NS B.ROOT-SERVERS.NET. in-addr.arpa. 86400 IN NS C.ROOT-SERVERS.NET. in-addr.arpa. 86400 IN NS D.ROOT-SERVERS.NET. in-addr.arpa. 86400 IN NS E.ROOT-SERVERS.NET. in-addr.arpa. 86400 IN NS F.ROOT-SERVERS.NET. in-addr.arpa. 86400 IN NS G.ROOT-SERVERS.NET. in-addr.arpa. 86400 IN NS H.ROOT-SERVERS.NET. in-addr.arpa. 86400 IN NS I.ROOT-SERVERS.NET. in-addr.arpa. 86400 IN NS K.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: M.ROOT-SERVERS.NET. 58742 IN A 202.12.27.33 ;; Query time: 14 msec ;; SERVER: 211.72.210.250#53(211.72.210.250) ;; WHEN: Tue Sep 7 13:16:06 2004 ;; MSG SIZE rcvd: 254 並且 DNS 是隨機選一部來查,所以我們要查 162.105.x.x 就隨便選一部,但是 先從 IP 的第一碼查起: 代码: SIP> dig @L.ROOT-SERVERS.NET. 162.in-addr.arpa. ns

; < <>> DiG 9.2.3 < <>> @202.12.27.33 162.in-addr.arpa. ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 58133 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 0 ;; QUESTION SECTION: ;162.in-addr.arpa. IN NS ;; AUTHORITY SECTION: 162.in-addr.arpa. 86400 IN NS chia.ARIN.NET. 162.in-addr.arpa. 86400 IN NS dill.ARIN.NET. 162.in-addr.arpa. 86400 IN NS BASIL.ARIN.NET. 162.in-addr.arpa. 86400 IN NS henna.ARIN.NET. 162.in-addr.arpa. 86400 IN NS indigo.ARIN.NET. 162.in-addr.arpa. 86400 IN NS epazote.ARIN.NET. 162.in-addr.arpa. 86400 IN NS figwort.ARIN.NET. ;; Query time: 385 msec ;; SERVER: 202.12.27.33#53(202.12.27.33) ;; WHEN: Tue Sep 7 13:16:21 2004 ;; MSG SIZE rcvd: 185 再來這一步,我們還是查 162,驗證上層與下層的 NS RRs 是否一致,不一致我們 通常會稱為 Lame Server,這會造成解析上的問題: 代码: SIP> dig @chia.arin.net 162.in-addr.arpa. ns

; < <>> DiG 9.2.3 < <>> @chia.arin.net 162.in-addr.arpa. ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 30464 ;; flags: qr aa rd; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 8 ;; QUESTION SECTION: ;162.in-addr.arpa. IN NS ;; ANSWER SECTION: 162.in-addr.arpa. 86400 IN NS figwort.arin.net. 162.in-addr.arpa. 86400 IN NS chia.arin.net. 162.in-addr.arpa. 86400 IN NS dill.arin.net. 162.in-addr.arpa. 86400 IN NS basil.arin.net. 162.in-addr.arpa. 86400 IN NS henna.arin.net. 162.in-addr.arpa. 86400 IN NS indigo.arin.net. 162.in-addr.arpa. 86400 IN NS epazote.arin.net. ;; ADDITIONAL SECTION: chia.arin.net. 10800 IN A 192.5.6.32 chia.arin.net. 10800 IN AAAA 2001:440:2000:1::21 dill.arin.net. 10800 IN A 192.35.51.32 basil.arin.net. 10800 IN A 192.55.83.32 henna.arin.net. 10800 IN A 192.26.92.32 indigo.arin.net. 10800 IN A 192.31.80.32 epazote.arin.net. 10800 IN A 192.41.162.32 figwort.arin.net. 10800 IN A 192.42.93.32 ;; Query time: 227 msec ;; SERVER: 192.5.6.32#53(chia.arin.net) ;; WHEN: Tue Sep 7 13:16:43 2004 ;; MSG SIZE rcvd: 325 由此可知,上下是一致的,也就是在 in-addr.arpa 中將 162 指向了七部 NS,這 七部 NS 都有設立起來,且七部的名稱與上層的名稱皆完全正確的對應,至於 AAAA 這是IPv6 的記錄,想來是這部主機同時有 IPv4/IPv6 位址. 再來,我們從 chia.arin.net 看,162.105.x.x 分配給北大使用的情形,得到下列結果: 代码: SIP> dig @chia.arin.net 105.162.in-addr.arpa. ns

; < <>> DiG 9.2.3 < <>> @chia.arin.net 105.162.in-addr.arpa. ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 8873 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0 ;; QUESTION SECTION: ;105.162.in-addr.arpa. IN NS ;; AUTHORITY SECTION: 105.162.in-addr.arpa. 86400 IN NS sun1000e.pku.edu.cn. 105.162.in-addr.arpa. 86400 IN NS ns.pku.edu.cn. 105.162.in-addr.arpa. 86400 IN NS pkuns.pku.edu.cn. ;; Query time: 225 msec ;; SERVER: 192.5.6.32#53(chia.arin.net) ;; WHEN: Tue Sep 7 13:17:31 2004 ;; MSG SIZE rcvd: 108 這代表著由 162 下長出來的 105 (162.105.x.x) 基本上都由北大管理,那北大這三部 NS 呢,不知是什麼樣的情形 ? 所以我們就查詢北大這三部 NS ,看看有什麼狀況: 代码: SIP> dig @sun1000e.pku.edu.cn 105.162.in-addr.arpa. ns

; < <>> DiG 9.2.3 < <>> @sun1000e.pku.edu.cn 105.162.in-addr.arpa. ns
;; global options: printcmd
;; connection timed out; no servers could be reached

Time Out,試了 N 次都是 Timeout …授權失敗,應該是陣亡或是換掉了吧..
反解查詢若三選一選到這部,就查不出來了,即會變成沒有反解狀況.

再來我們選第二部(DNS 查詢時不會自動切到第二部,選到 sun1000e ,沒有查到不會自動
Switch 到第二部的,此處我們意在講解,所以可以用手動的方式來驗證):

代码:

SIP> dig @ns.pku.edu.cn 105.162.in-addr.arpa. ns

; < <>> DiG 9.2.3 < <>> @ns.pku.edu.cn 105.162.in-addr.arpa. ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 45872 ;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3 ;; QUESTION SECTION: ;105.162.in-addr.arpa. IN NS ;; ANSWER SECTION: 105.162.in-addr.arpa. 86400 IN NS ns.PKU.EDU.CN. 105.162.in-addr.arpa. 86400 IN NS dns.EDU.CN. 105.162.in-addr.arpa. 86400 IN NS ns2.cuhk.hk. 105.162.in-addr.arpa. 86400 IN NS pkuns.PKU.EDU.CN. 105.162.in-addr.arpa. 86400 IN NS sun1000e.PKU.EDU.CN. ;; ADDITIONAL SECTION: ns.PKU.EDU.CN. 86400 IN A 202.112.7.13 pkuns.PKU.EDU.CN. 86400 IN A 162.105.129.27 sun1000e.PKU.EDU.CN. 86400 IN A 162.105.129.26 ;; Query time: 523 msec ;; SERVER: 202.112.7.13#53(ns.pku.edu.cn) ;; WHEN: Tue Sep 7 13:18:16 2004 ;; MSG SIZE rcvd: 199 哦耶~有回應耶...不過為什麼是五部...162.in-addr.arpa. 上層不是說有三部管 162.105.x.x 嗎? 你(ns.pku.edu.tw) 又說有五部,我要相信誰 !? 誰告訴我你們 那個說的是真的 >< " 算了,我們看 162.in-addr.arpa. 上講的第三部好了: 代码: SIP> dig @pkuns.pku.edu.cn 105.162.in-addr.arpa. ns

; < <>> DiG 9.2.3 < <>> @pkuns.pku.edu.cn 105.162.in-addr.arpa. ns
;; global options: printcmd
;; connection timed out; no servers could be reached

timeout ….無言的結局,因為如果有人要查 162.105.1.1,即使真有這個的反解記錄(PTR),有
三分之二的機會會查不到…,如果是這樣那查詢失敗率可就太高了.

好吧,那前面 ns.pku.edu.tw 你說有五部,其中三部我們看過了,那我們看你說的天外那兩部好了
SIP> dig @dns.EDU.CN 105.162.in-addr.arpa. ns

; < <>> DiG 9.2.3 < <>> @dns.EDU.CN 105.162.in-addr.arpa. ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: REFUSED, id: 40192 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;105.162.in-addr.arpa. IN NS ;; Query time: 560 msec ;; SERVER: 202.112.0.35#53(dns.EDU.CN) ;; WHEN: Tue Sep 7 13:45:50 2004 ;; MSG SIZE rcvd: 38 [/code] 騙人~這部根本就沒有管 105.162.in-addr.arpa. 你說假話! 再來看最後一個希望: 代码: SIP> dig @ns2.cuhk.hk. 105.162.in-addr.arpa. ns

; < <>> DiG 9.2.3 < <>> @ns2.cuhk.hk. 105.162.in-addr.arpa. ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: NOERROR, id: 31411 ;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 5 ;; QUESTION SECTION: ;105.162.in-addr.arpa. IN NS ;; ANSWER SECTION: 105.162.in-addr.arpa. 86400 IN NS pkuns.PKU.EDU.CN. 105.162.in-addr.arpa. 86400 IN NS sun1000e.PKU.EDU.CN. 105.162.in-addr.arpa. 86400 IN NS ns.PKU.EDU.CN. 105.162.in-addr.arpa. 86400 IN NS dns.EDU.CN. 105.162.in-addr.arpa. 86400 IN NS ns2.cuhk.hk. ;; ADDITIONAL SECTION: pkuns.PKU.EDU.CN. 86400 IN A 162.105.129.27 sun1000e.PKU.EDU.CN. 86400 IN A 162.105.129.26 ns.PKU.EDU.CN. 86400 IN A 202.112.7.13 dns.EDU.CN. 172800 IN A 202.112.0.35 ns2.cuhk.hk. 86400 IN A 137.189.6.21 ;; Query time: 64 msec ;; SERVER: 137.189.6.21#53(ns2.cuhk.hk.) ;; WHEN: Tue Sep 7 13:46:36 2004 ;; MSG SIZE rcvd: 231 還好,有了答案了,看來 ns2.cuhk.hk 代管的 domain 還真不少, TTL 都不會減少, 過程中共有五部 NS,只有兩部正確 Work (這兩部有一部不在上層出現),有二部不能 連,有一部不管這個反解的 zone , 就通算你 2/5 可解吧! 以上有些部份後面我們還會看到,但是從這個例子來看,105.162.in-addr.arpa. 的反解有 N 個問題,如果連 pku 都這樣... 另一個重點,就是非 edu/ac doamin 部份, 代码: #我們只要 NS 記錄,並且把 edu.cn/ac.cn 去掉,來看看最多人使用的 ISP 狀況 SIP>cat ns_rr_tw | grep NS|grep -Eiv ‘edu.cn|ac.cn’
161.207.1.1==>207.161.in-addr.arpa. 85037 IN NS dns2.cnpc.com.cn.
202.1.176.1==>176.1.202.in-addr.arpa. 20252 IN NS pijin.com.sb.
202.3.77.1==>77.3.202.in-addr.arpa. 51124 IN NS ns2.yahoo.com.
202.38.184.1==>1.184.38.202.in-addr.arpa. 85052 IN PTR ANS.CERNET.NET.
202.93.1.1==>1.93.202.in-addr.arpa. 51113 IN NS netmgr.cninfo.com.cn.
202.96.136.1==>136.96.202.in-addr.arpa. 85067 IN NS dns.guangzhou.gd.cn.
202.97.8.1==>8.97.202.in-addr.arpa. 85067 IN NS ns1.cn.net.
202.97.16.1==>16.97.202.in-addr.arpa. 85066 IN NS ns1.cn.net.
202.99.64.1==>64.99.202.in-addr.arpa. 62844 IN NS ns.tpt.net.cn.
202.100.112.1==>112.100.202.in-addr.arpa. 85086 IN NS euro2000.yc.nx.cn.
202.100.200.1==>200.100.202.in-addr.arpa. 85094 IN NS ns.hihkptt.net.cn.
202.100.208.1==>208.100.202.in-addr.arpa. 85093 IN NS ns.hisyptt.net.cn.
202.101.96.1==>96.101.202.in-addr.arpa. 85093 IN NS dns.fz.fj.cn.
202.102.128.1==>128.102.202.in-addr.arpa. 5908 IN NS ns.spt.net.cn.
202.103.224.1==>224.103.202.in-addr.arpa. 9511 IN NS ns.lzptt.gx.cn.
202.130.224.1==>224.130.202.in-addr.arpa. 34811 IN NS ns2.east.net.cn.
202.165.96.1==>96.165.202.in-addr.arpa. 51258 IN NS ns3.yahoo.com.
203.81.16.1==>16.81.203.in-addr.arpa. 85212 IN NS ns1.net-infinity.net.
203.93.16.1==>16.93.203.in-addr.arpa. 600 IN NS ns.gb.com.cn.
210.21.1.1==>1.21.210.in-addr.arpa. 85225 IN NS gz1-dns.gdgz.cncnet.net.
211.101.128.1==>128.101.211.in-addr.arpa. 42074 IN NS ns.capitalnet.com.cn.
218.64.1.1==>1.64.218.in-addr.arpa. 85284 IN NS ns.jxjjptt.net.cn.

這個部份我就不知誰有名了,不過看到 capitalnet.com.cn 看名字好像規模不小的感覺,
你可以用像上面一樣的流程,一直查下來,會發現到 capitalnet.com.cn 這一層時,只有一個
NS RRs,但是他上層登記的是兩個….也是不一致,當然,也有很多做的非常好的,像east.net.cn
就 100 分!

註:NS 上下不一致情形,不同的 Bind 版本在查詢處理上略有不同,非本處重點所在,個人
亦不打算另起主題說明

另外一個重點就是, Reverse Domain 的 SOA 中 Email 也是要注意之處 !

代码:

64.119.202.in-addr.arpa. 10800 IN SOA 64.119.202.in-addr.arpa. root.localhost.64.119.202.in-addr.arpa. 2 28800 7200 604800 86400

上面 202 結果 sample 的第
四個,看到這樣的內容其實大概這個反解授權會有問題,因為管理人員觀念不好,通常我們在
SOA 中的 email address 會要求至少是個可資連絡的 email,但這個 sample 的 email 是寄
給自己,如果是正解檔,你還可以反應過來,但反解你沒法將 localhost 想像成什麼 domain.
所以,這是個真實錯誤的示範.你自己在做時,也要注意這一點,zone contact email 要對.

所以,綜合前面論點,反解絕對沒有 1/10 ,即使有 NS 指向的達到 1/10 !

再來,我們看看 ISC 的年度調查報告, http://www.isc.org/ops/ds/reports/2004-01/dist-bynum.php
你會發現數字非常低,不到 20 萬個 ip 可解成 .cn , 我們假設, CN 下的 IP,很多都解成
com/net/org 好了,將這個數字x10,結果為 1604210 ,1604210/54449664,答案是多少自己算一下
(想一下,x10 是高估還是低估了,為什麼)

CN 反解授權小結:
得到 72 行資料意味著什麼,代表著有600 餘段 APNIC 分配給 CN 的 IP 沒有授權出去,
你想要做反解,或反解授權,而你在這 600 餘段中,那就不必了,這內容我就不整理了
,你可以自己試 dig -x your_IP ,若 SOA 出現 apnic 就是沒有了,(我猜大部份有在看這
一篇的人,大概都會出現 apnic ,那可以不用再寫下去了嗎!!? ccc)
為什麼 APNIC 沒把 IP 反解授權出來!!! 答案要去問你的 ISP 為什麼沒有去申請反解授權
權,APNIC 都有說怎麼做,做起來也很簡單,但你的 ISP 只想賺錢,不想盡義務,也有可
能是教育面的問題,沒有人教過 ISP 這樣的觀念,但個人的想法較傾向前者.

台灣的數字和台灣 Internet 歷史發展有關,從 TANET (學術網路) 興起 ,1996 年就教育
User 反解意義,並且要求連線單位一定要設反解,不然連不到 BBS/FTP …,到今天,當年的學生
現在多巳入行…這都得感謝 TANET 前輩的努力呀 ! 其中著力最深的個人認為當屬 nschen
(陳昌盛老師),在網路上的鼓吹!! 今日,若在台灣的 ISP 若不做反解(或反解授權或可自行修改),
是無法被用戶接受的.若屬動態IP,ISP 也會以 IP_addr.dynamic.ISP_domain 標示出來,讓 Mail
Server admin 自行決定是否 Reject.