网站备案 我有一些话想说 [转]
fport v2.0
2007/07/26 16:58 | by 
你不必要求正反兩解之一致性, 只是, 若查詢的程式若發現不一致(PARANOID),
則取決於該程式如何處理了.
請記著一點: DNS 只負責解釋, 至於解釋出來的結果如何用? 那就不是 DNS 要擔心的.
本文撰寫於 www.chinaunix.com ,撰寫人為:
netman/abel
歡迎任意轉載,轉載時請注明出處
除錯別字外(哈~這個我常發生),勿對本文加油添醋
主題:反向解析域是怎么授权的 (http://bbs.chinaunix.net/forum/16/20040812/385903.html)
-------------------------------------------------------------------
正文開始,文接 netman 那篇
建議您在看前,對 DNS 解析流程及授權有一定的概念,並巳充份了解正解的狀況
1.前言
首先, 我上次問過大家一個問題:
--- 在 internet 上是正解查詢多還是反解查詢多?
若你有朋友在 NIC 或 ISP 內管 dns 的話, 應該不難問出答案:
---> 反解多!
那, 你或許會問: why?
嗯, 先回看我前面提到的:
--- DNS 只負責解釋, 至於解釋出來的結果如何用? 那就不是 DNS 要擔心的.
那接下來, 誰要操這份心呢?
簡單來說, 就是那些使用到 dns 的程式了...
那再下來, 有哪些程式呢?
簡單來說: 分 client 與 server 兩類程式就夠了.
然後, 只要你能統計出在 dns 查詢中, 究竟是 client 多還是 server 多? 就立見分曉了....
答案是: server 居多!
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.
4. 反解的意義何在? 反解對行為的影響
最重要的解釋就是這個 IP 的的網路身份是被認可的 ! 只是你的 Server 認不認可
他由你自己 config 決定,如前言 netman 兄的例子, mail server 必然會 check 反解,check
不到,你可以收或不收, check 到是某個名稱,您也可以決定收或不收,例如,你對 xxx 電信很
不滿,拒絕他們的連線或是信件,你會想到一個問題,他們有多少IP,你要怎麼查,要如何維護呀 !?
但是若他們每個 IP 都有反解設定或是反解設定有一個規則可循,你就會很好做,也不用特別去
維護,像前面舉的例子 IP_addr.dynamic.hinet.net,這種 Reverse Domain 可以用在各種地方,
如 DNS 的 allow-query,view,allow-update ...,Proxy 的 ACL ...,Firewall ,FTP,
tcp_warpper(hosts.allow/hosts.deny),Apache 的 allow/deny...,基本上寫成反解格式,好
一點的檢查 rule 都是 double check 的,例如也就是連線由 IP 發起, Proxy 上有條 ACL 是
同意 mydomain.com.cn 代理服務,Proxy 會查反解,得到一個名稱,再將名稱拿去查一次 A 記錄,
驗證是否為 mydomain.com.cn, 正反解的一致性也就變得必要.所以,不論對 IP 的認證存取有
用,對於大量不連續的 IP 更有統合的效果.另外,對於外面的人來說,用 IP 查人或公司兩大途
徑,反解和 whois,CN 在這方面的表面都不夠好,這是值得大家努力的,給 ISP 壓力吧,眾志成城.
反解造成的 delay time sample,由未反解的 CU 所寄來的三封主題回覆通知:
| 代码: |
| Received: from chinaunix ([61.135.136.123]) by domain (8.13.1/8.13.1) with SMTP id i83BNOBs031000 for <my_email@domain>; Fri, 3 Sep 2004 19:23:26 +0800 Received: (qmail 29635 invoked by uid 80); 3 Sep 2004 11:23:12 -0000 Received: from chinaunix ([61.135.136.123]) by domain (8.13.1/8.13.1) with SMTP id i83BcPXZ012844 for <my_email@domain>; Fri, 3 Sep 2004 19:38:27 +0800 Received: (qmail 30479 invoked by uid 80); 3 Sep 2004 11:38:12 -0000 Received: from chinaunix ([61.135.136.123]) by domain (8.13.1/8.13.1) with SMTP id i83HY8iR013736 for <my_email@domain>; Sat, 4 Sep 2004 01:34:10 +0800 Received: (qmail 48488 invoked by uid 80); 3 Sep 2004 17:33:55 -0000 |
你會發現, Received 欄位,在我收到時,和 CU 發出時,差了約 14~15 秒,這中間主要即是因為沒
有反解所致,同時我找了一個有反解的,同樣用 qmail 的 sample 如下:
| 代码: |
| Received: from dragon.xxx.net (dragon.xxx.net [202.145.xxx.193]) by mydomain (8.13.1/8.13.1) with SMTP id i828lXoU006975 for <my_email@mydomain>; Thu, 2 Sep 2004 16:47:33 +0800 Received: (qmail 22562 invoked from network); 2 Sep 2004 08:47:30 -0000 Received: from gate.noc.xxx.net (HELO jj) ([202.145.xxx.34]) (envelope-sender <xxx@ttn.xxx.tw>) by 0 (qmail-ldap-1.03) with SMTP for <my_email@mydomain>; 2 Sep 2004 08:47:30 -0000 |
一個差3秒,一個差15秒左右(當然有可能是時間差的問題,我們 Server 都會跑 ntp,相信像 CU 這
種大站也會跑 ntp,至於下面的 sample 有無我就不知了),所以時間上來說應都是同步的.
(若你認為是路途太遠,那就不及格了)
所以,你若還有跑什麼 Mail Gateway,或 Smart Relay,基本你經過的點愈多,時間差距就會愈大
CU 的例子,15 秒還在可接受的範圍內.
註1: 若要縮短這 15 秒,可以在自己的 /etc/hosts 將 CU 給指出來,沒試過,理論應可行
註2: 若你送了信,但要半天一天才到,那大多事 DNS delegation 的問題為主
5.反解如何授權
我想本節才是重點,我們就以 pku.edu.cn 那個 sample 為例好了,105.162.in-addr.arpa.
由於這是整個 Class B 的規模,所以他要做授權的話,以 C 為單位是很簡單的,和正解的思考
是一樣的,
| 代码: |
| $TTL=86400 $ORIGIN 105.162.in-addr.arpa. 105.162.in-addr.arpa. 86400 IN SOA ns.PKU.EDU.CN. hostmaster.PKU.EDU.CN. (2004090602 3600 900 604800 86400) IN NS dns.EDU.CN. IN NS ns2.cuhk.hk. IN NS pkuns.PKU.EDU.CN. IN NS sun1000e.PKU.EDU.CN. IN NS ns.PKU.EDU.CN. 0 IN NS ns1.cc.pku.edu.cn. 0 IN NS ns1.cc.pku.edu.cn. 1 IN NS ns1.ee.pku.edu.cn. 1 IN NS ns1.ee.pku.edu.cn. 2 IN NS ns1.gg.pku.edu.cn. 2 IN NS ns1.gg.pku.edu.cn. ... |
5.1 滿一個 Class C
所以,可以讓 cc 一個系所有一個 Class C (255 個 IP) 的授權,此時 cc 系在架 DNS 時就要有兩部
| 代码: |
| $TTL=86400 0.105.162.in-addr.arpa. 86400 IN SOA ns1.cc.PKU.EDU.CN. hostmaster.PKU.EDU.CN. (2004090602 3600 900 604800 86400) IN NS ns1.cc.pku.edu.cn. IN NS ns2.cc.pku.edu.cn. $ORIGIN 0.105.162.in-addr.arpa. 1 IN PTR ns1.cc.pku.edu.cn. 2 IN PTR ns2.cc.pku.edu.cn. 3 IN PTR pc3.cc.pku.edu.cn. ... 254 IN PTR pc254.cc.pku.edu.cn. |
目前為止我相信各位都能體會,如果不能體會請先將正解弄熟,弄懂,你就會了解.
上面這樣的設法,基本上可能對管理這部主機的人而言太重覆,所以 BIND 9 時就加了一個
$GENERATE 的功能變數
| 代码: |
| ;SOA NS 如上例 $ORIGIN 0.105.162.in-addr.arpa. $GENERATE 3-254 $ PTR pc$.cc.pku.edu.cn. |
其說明了 $ 是由 3 至 254 組成,要擴展為 252 (254-3+1=252) 行(你將 $=3,$=4 代進去
就是了,IN 不用寫)
5.2 不滿一個 Class C
好了,以上都是標準的狀況,但是現在誰有 Class C 呢 !?
例如, cc 系所下面還有四個單位(ex:64,32,32,128 個 IP 分配好了,cc 本身是第一個), cc 系
所要如何授權出去呢 !?
最簡單的方法就是(不知大家是否懂 $ORIGIN 意思,就是FQDN最後若沒有 . 要補這個字) 直接 NS
再授權下去,但這也是最不經濟的方法:
| 代码: |
| $TTL=86400 0.105.162.in-addr.arpa. 86400 IN SOA ns1.cc.PKU.EDU.CN. hostmaster.cc.PKU.EDU.CN. (2004090602 3600 900 604800 86400) $ORIGIN 0.105.162.in-addr.arpa. IN NS ns1.cc.pku.edu.cn. IN NS ns2.cc.pku.edu.cn. $GENERATE 3-63 $ PTR pc$.cc.pku.edu.cn. $GENERATE 64-95 $ NS ns1.unit2.cc.pku.edu.cn. $GENERATE 64-95 $ NS ns2.unit2.cc.pku.edu.cn. $GENERATE 96-127 $ NS ns1.unit3.cc.pku.edu.cn. $GENERATE 96-127 $ NS ns2.unit3.cc.pku.edu.cn. $GENERATE 128-254 $ NS ns1.unit4.cc.pku.edu.cn. $GENERATE 128-254 $ NS ns2.unit4.cc.pku.edu.cn. |
$GENERATE 功能自己多體會就可以很快上手了,而這個時候, ns1.unit2.cc.pku.edu.cn 就得要
把 zone 建出來了,這個 zone 要寫滿整個 IP,
| 代码: |
| #/etc/named.conf 中的內容 .... zone "64.0.105.162.in-addr.arpa" {type master;file "64.ggyy_ip_zone";}; zone "65.0.105.162.in-addr.arpa" {type master;file "65.ggyy_ip_zone";}; zone "66.0.105.162.in-addr.arpa" {type master;file "66.ggyy_ip_zone";}; zone "67.0.105.162.in-addr.arpa" {type master;file "67.ggyy_ip_zone";}; .... |
然後那個 zone file 內都只有一行 PTR 資料,因為是將 IP (4 octets) 指了過來:
| 代码: |
| $TTL=86400 @ 86400 IN SOA ns1.unit2.cc.PKU.EDU.CN. hostmaster.unit2.cc.PKU.EDU.CN. (2004090602 3600 900 604800 86400) IN NS ns1.cc.pku.edu.cn. IN NS ns2.cc.pku.edu.cn. @ IN PTR pc64.unit2.cc.pku.edu.cn. |
那不就瘋了~拿到 128 個 IP 要設 128 次 zone , 及建 128 個 zone file ..
的確是這樣,如果有 128 個 IP 他也甘願,且這種方法還有不少人用.而很多人在
這種情況下,會不明所以,反而設成一個 C (255 個 IP ) 的反解:
| 代码: |
| #ns1 of unit4 在 /etc/named.conf 中寫 zone "0.105.162.in-addr.arpa" ; |
在 zone file 中只寫自己那一段 128-254,這也是不對的,因為當他碰到另一半時(0-127),
他就會解不出來,且上層的 NS 指向是 [128-254].0.105.162.in-addr.arpa 共 128 個
NS,你用比他大的 NS 去接是會出錯的(想想,你有一個 domain:xxx.com.cn,那你的 zone
何不設成 cn 就好或 com.cn ,不出問題才怪哩),dns log 會出現
0.105.162.in-addr.arpa >=1.0.105.162.in-addr.arpa 這種 bad referral 訊息,相信
有經驗的人一定見過.
5.3 不滿一個 Class C 標準解法
所以,用一個 IP 去指 NS 授權是不經濟的作法,正確的做法是在 Class C
(0.105.162.in-addr.arpa) 這一層以 CNAME 去定義,詳情可見 RFC2317
http://www.ietf.org/rfc/rfc2317
| 代码: |
| ;在 ns1.cc.pku.edu.cn 上的 0.105.162.in-addr.arpa $TTL=86400 0.105.162.in-addr.arpa. 86400 IN SOA ns1.cc.PKU.EDU.CN. hostmaster.cc.PKU.EDU.CN. (2004090602 3600 900 604800 86400) $ORIGIN 0.105.162.in-addr.arpa. IN NS ns1.cc.pku.edu.cn. IN NS ns2.cc.pku.edu.cn. $GENERATE 3-63 $ PTR pc$.cc.pku.edu.cn. $GENERATE 64-95 $ CNAME pc$.unit2.cc.pku.edu.cn. $GENERATE 96-127 $ CNAME pc$.unit3.cc.pku.edu.cn. $GENERATE 128-254 $ CNAME pc$.unit4.cc.pku.edu.cn. |
以上請您先充份理解 $GENERATE 的功能,要到用看的也看的出來的程度,且不用寫
兩次(原來寫兩次是因為一個 domain 一定要有兩部以上的 NameServer),因為全部
都會轉到正解檔去
| 代码: |
| ;$GENERATE 128-254 $ CNAME pc$.unit4.cc.pku.edu.cn. 的擴展 128 IN CNAME pc128.unit4.cc.pku.edu.cn. 129 IN CNAME pc129.unit4.cc.pku.edu.cn. 130 IN CNAME pc130.unit4.cc.pku.edu.cn. 131 IN CNAME pc131.unit4.cc.pku.edu.cn. ... 254 IN CNAME pc254.unit4.cc.pku.edu.cn. |
這裏一定有人犯疑,反解檔可以用 CNAME 嗎 ? 誰說不行的呀,就像 MX 可不可以是接 IP
一樣,正解檔裏也是可以放 PTR 的,重點只在,他們都是 DNS 的 zone,正解/反解 只是人
們區分上的差別而以:
| 代码: |
| ;原來 unit4.cc.pku.edu.tw zone,NS SOA 等不列 $ORIGIN unit4.cc.pku.edu.tw. @ IN MX mail mail IN A 162.105.0.143 www IN A 162.105.0.133 .... ;以下補上 $GENERATE 128-254 pc$ PTR pc$ |
好了,這樣就可以了,當你 dig -x 162.105.0.143 時,就會出現解到 CNAME (參閱上面),
換到 CNAME 後會查原來的 FQDN,就會找到 pc143.unit4.cc.pku.edu.cn.
用 $GENERATE 只是適用有規則的變化,在本例中,一般會建議你依順序排列,以便日後管理:
| 代码: |
| www IN A 162.105.0.133 pc133 IN PTR www ;...134,135.... mail IN A 162.105.0.143 pc143 IN PTR mail ;... |
所以 pc133 等這種名稱,純粹就會變成一種 "接取" 的狀況,主要是要 "串連" 起來.
實例:
| 代码: |
| [root@twnic joanna]# dig @168.95.1.1 -x 210.17.9.228 ; <<>> DiG 9.2.1 <<>> @168.95.1.1 -x 210.17.9.228 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55880 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: 找 PTR ;228.9.17.210.in-addr.arpa. IN PTR ;; ANSWER SECTION: 找到 CNAME, 再對應成 PTR 228.9.17.210.in-addr.arpa. 3600 IN CNAME 228.sub224-255.9.17.210.in-addr.arpa. arpa. 228.sub224-255.9.17.210.in-addr.arpa. 77747 IN PTR www.twnic.net.tw. |
syslog 中會出現像(有的 OS 版本不會出現):
| 代码: |
| Sep 6 10:40:11 SIP syslog: gethostby*.getanswer: asked for "228.9.17.210.in-addr.arpa IN PTR" , got type "CNAME" Sep 6 10:40:11 SIP syslog: gethostby*.getanswer: asked for "228.9.17.210.in-addr.arpa", got "228.sub224-255.9.17.210.in-addr.arpa." |
大概就這樣,你會發現,到後面講 CNAME 的地方有點難理解,這是正常的,有程度的人用力看
大概可以看得懂,若普通的話,實作即可知道,若連正解都不懂大概很難體會.
DNS 這種東西若你以為用看的就全看的懂表示你太看輕它了.
