关于DNS反解的一些资料

 

没有做DNS反向解析引起的邮件被国外拒收问题

转自《没有做DNS反向解析引起的邮件被国外拒收问题》

一般反向解析是和IP地址分配有联系的，所以isp直接申请反向解析的授权很难得到。而电信运营商在这方面就具备天然优势，通常这个授权都会直接授予本地的电信运营商（当然，电信运营商也要去申请才可以），然后再由电信运营商授予各个使用此IP地址的isp（当然，这个isp至少要完全占有整个C类地址的使用权，否则不会得到授权），或者由电信运营商自己的DNS来提供相应IP地址的反向解析服务。
解释一下，由于反向解析的记录格式是：
d.c.b.a.in-addr.arpa （IP地址是a.b.c.d）

它的体系及解析过程是和正向解析同样的，所以还是由根开始查询下一级的NS记录，直至查到 c.b.a.in-addr.arpa 的NS记录，再在此记录的DNS服务器上查询 d.c.b.a.in-addr.arpa 的 PTR记录，所以拥有反向解析授权的DNS服务器一定是有限的且授权的最小单位为一个C类地址段
因此我在这里建议大家如果想要做反向解析请向当地电信运营商的业务部门申请。
现在国际上的反垃圾邮件组织普遍要求邮件服务器需要有反向解析，以此来确认这台邮件服务器是能够在internet上稳定存在的服务器，而不是打一枪换一地的垃圾源。希望大家能够尽早为自己的邮件服务器做好反向解析，以免发生被国外拒收邮件的情况 。

反向域名解析的意义：
最重要的解释就是这个IP地址的网络身份是被认可的。
反向域名解析的大体过程：
假设IP地址为a.b.c.d
查询时先向in-addr.arpa.域查询a.in-addr.arpa.域
返回一个ns地址，中国一般是apnic的dns
再向apnic的dns查询b.a.in-addr.arpa.域
返回一个ns地址，一般是isp的dns
再向isp的dns查询c.b.a.in-addr.arpa.域
返回一个ns地址，一般还是isp的dns或者授权后的dns
最后向这个dns查询d.c.b.a.in-addr.arpa.既c.b.a.in-addr.arpa.域中的记录d
返回一个对应的地址
在中国一般到isp这里以后in-addr.arpa.域的ns记录就没有了。

 

ISP 不给做dns反向解析怎么办

转自《ISP 不给做dns反向解析怎么办》

 

困境

• 国外的邮件，送不出去。
• 想做反解，isp 不给做，也不授权，，告诉我说，，它们的dns没有这个功能。
• 国内很少做反解，那些isp自己都没做。

 

解决办法

• relay 到另一台有做反解的 mail server。如：外出信件先到台北，而后出去。。回来的信，还是直接或来。

 

状况

反解問題早年在台灣也很嚴重, 不過近年來由於 twnic 的輔導, 已好很多了!

目前,全台灣的IP 應該在 1500 萬個左右,可反解的有 8xx 萬個
至於全中國 IP 數應5000 多萬,可反解的應在 20~40 萬間
台灣反解比率約近6成,而中國大陸..可能最多不超過 2%
至於我們的做法:
1. 教育 user 認識反解的重要性(我們做, ISP 有得也會做)
2. 向 APNIC 申請 IP 時,台灣的 ISP 多是 ISP--->;TWNIC --->;APNIC
所以在 TWNIC 這邊可以要求 ISP 要設反解,才核發 IP 給 ISP
且我們有一個很完整的 ISP 反解及 Whois 登記系統, 可對 ISP
及 APNIC 互傳IP 登記資料. 所以.台灣從 APNIC 拿到的 IP , 99%
都有從 APNIC 做反解授權到 TWNIC , TWNIC 再做授權給 ISP.
所以在台灣有個單位會卡 ISP 一定要做反解,ISP 也多會讓 User
免費的自由修改反解內容(PTR)
至於大陸,就我所知,都是 ISP 直接向 APNIC 拿, APNIC 也很難管得了
那麼多,而 Domain Name 的單位或 ISP 也是對反解一事不甚認真.
我記得板上曾有一位朋友,向 ISP 要做反解,還交了快千元的錢及無數
次的溝通,(這可比正解多花 N 倍的成本 )
所以樓主若沒有這麼努力..大概很難達到這位朋友的結果...
換 ISP 也多不過換湯不換藥,因為9成以上都沒有做.
另外要注意的是,沒有反解,若被列入 RBL, 八成都沒有救.因為 RBL 解除
的第一要務就是反解要求.

其实，有无反解，果真就是教育层面的问题。isp的那帮人，唉。打电话过去，“没有啊，我们的Dns没有反解功能，大家都没有啊。”，“你的域名从哪里申请的？那你也去找他啊，为什么找我。。”  费了半天的工夫，也解释不清楚。
其实，无论如何，总是要把问题解决。本来就是友好协商。
从我的角度看过去，两条腿走路好了，考量自己可以动用的资源，目前最快的方法，只有请台北那边给我们做relay了。
于心不甘那，这样下去，不知道什么时候，我们的isp才会意识到 反解的重要性？ 难不成等到我们的网络与世界都断开的时候？

我还向apnic写了投诉+建议的信呢。但是没有回音。
至于cnnic，我今天还要继续电话。铁通我是暂时不报希望了。
希望cnnic,不要让我太失望。
一件事情，执行下来，难就难在跟自己的接口单位说都说不清楚。

 

反向解析域是怎么授权的

转自《反向解析域是怎么授权的》

本文撰寫於 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
騙人~這部根本就沒有管 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 
 
 
  
  ;; 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 
  
  
   
   ;; 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 
   
   
    
    ;; 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 
 
 
  
  ;; 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 
  
  
   
   ;)

   
   
          by 0 (qmail-ldap-1.03) with SMTP

   
   
          for 
   
   
    
    ;; 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 這種東西若你以為用看的就全看的懂表示你太看輕它了.