通过ip找域名，如果是这个过程的话，那就不好理解了
我可以把域名指向任何地方，但是那个地方的ip我是管不了的，就是我做了反向解析也是没用的
網中人 回复于：2004-08-13 00:57:40
反解與正解本來是分開的...
你不必要求正反兩解之一致性, 只是, 若查詢的程式若發現不一致(PARANOID),
則取決於該程式如何處理了.
請記著一點: DNS 只負責解釋, 至於解釋出來的結果如何用? 那就不是 DNS 要擔心的.
Fun-FreeBSD 回复于：2004-08-13 09:03:31
我只是觉得这样的话，反向解析就没多大用处了，尤其在internet上
Fun-FreeBSD 回复于：2004-08-13 09:52:34
[quote="網中人"]
陳昌盛老師 的一篇文章給大家參考一下：
http://dnsrd.nctu.edu.tw/DNS-abc/WhenToUse-Rev.html
quote]
这篇文章我打不开，google上只找到两个地址，都打不开，能不能转贴一下放到精华，另外，等着看你的Reverse讲解，期待期待
網中人 回复于：2004-08-13 13:59:40
嗯. 真不好意思, 一直沒能抽時間出來跟大家說反解的部份.
除了時間關係外, 也不知一時之間能講些啥? 我先將本貼置頂一段時間, 然後我再慢慢補充好了.
首先, 我上次問過大家一個問題:
--- 在 internet 上是正解查詢多還是反解查詢多?
若你有朋友在 NIC 或 ISP 內管 dns 的話, 應該不難問出答案:
---> 反解多!
那, 你或許會問: why?
嗯, 先回看我前面提到的:
--- DNS 只負責解釋, 至於解釋出來的結果如何用? 那就不是 DNS 要擔心的.
那接下來, 誰要操這份心呢?
簡單來說, 就是那些使用到 dns 的程式了...
那再下來, 有哪些程式呢?
簡單來說: 分 client 與 server 兩類程式就夠了.
然後, 只要你能統計出在 dns 查詢中, 究竟是 client 多還是 server 多? 就立見分曉了....
答案是: server 居多!
不用懷疑, 假設以一封 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 查詢? 及其中的正反解的比例?
最簡單的羅輯是:
有一個正解需求的連線發生後, 通常就會引起一個反解, 但更多時候會引起更多的反解!
好了, 今天, 我先讓大家知到" dns 查詢中反解比正解多"這一事實.
等這幾天有空, 我再來講更多的關於反解的知識. 不要太期待哦~~~ ^_^
jby365 回复于：2004-08-13 16:18:45
up
不是特别期待中……
haha451 回复于：2004-08-17 15:45:47
不是特别地特别期待中。。。
Fun-FreeBSD 回复于：2004-08-18 09:30:15
不期待，等待~
網中人 回复于：2004-08-18 16:48:18
sorry, 最近在準備兩場演講, 沒太多時間寫這個問題.
請再等幾天...
耽誤大家時間真不好意思!
memory_008 回复于：2004-08-21 02:25:04
和高手总是能学到很多啊！
haha451 回复于：2004-08-21 13:10:32
看一下。。。
wingger 回复于：2004-08-28 20:40:34
呵呵，在国内，很多运营商都没按规范作反解。。。所以很多国外邮件都没法收到。。。 :lol: :lol: :lol:
peng 回复于：2004-08-31 15:03:21
反解一般都是程序上需要的，client（个人）访问网站，用的是整解。但是一般的服务器（程序）多数用反解。
再用楼上网中人老大的例子：
在一般的邮件运营商的邮件smtp和pop3的机制中，对付垃圾邮件都有很多过滤规则。很普遍的一条，就是域名反相解析。
很多垃圾邮件制造者，都使用假的域名，例如盗用：sina、263等的。或者是没有注册的域名。正常是没有办法知道这些是假的或者无效的，但是邮件系统在接收或者relay的时候，对域名反相解析一下，就能知道这些是不正确的，就直接过滤掉。所以说，这个还是比较有用的。
对于反相的域名解析，是你的上级isp（接入服务商）来提供的，要求从上级一级一级的指下来。而不是你从下级来决定的。
所以说，你必须要求上级来解决，而不是自己解决。。
網中人 回复于：2004-08-31 15:46:44
嗯, peng 差不多說出我下一次要講的內容了...
呵... 看來我可以偷懶躲過了?? (大家會放過小弟嗎?)
peng 回复于：2004-08-31 23:30:33
[quote:877cbaffbf="網中人"]嗯, peng 差不多說出我下一次要講的內容了...
呵... 看來我可以偷懶躲過了?? (大家會放過小弟嗎?)[/quote:877cbaffbf]
坚决不放过！呵呵～ :m01:
網中人 回复于：2004-08-31 23:36:03
好吧, 看來是"禍"躲不過~~~
不過最近真的很忙, 我先取消置頂, 等有空再回來補吧... sorry...
abel 回复于：2004-09-02 22:40:12
如果各位看了前面 netman 兄的說明,相信應能理解為什麼反解行為發生多
總之,你在網路上的行為時時刻刻都和反解有關就是你,你有正解發生,多一定
會帶來反解需求,沒有正解發生也會帶來反解需求,
-------------------------------------------------------------------
正文開始,文接 netman 那篇
正解查詢,大家都想求正確,求快,求穩定,那為什麼反解不用呢 !?
因為你感受不明顯!但 server 可明顯了,網路的 traffic 也會受影響.
我們先看 CU 為例:
www.chinaunix.com.
61.135.136.122==>122.135.136.122.in-addr.arpa.
若 CU 的 IP 有設反解, 正解在沒有 Cache 因素干擾下,從 Client (C) 到
DNS Server (S) 解出來會有 :
[code:1:bb6bb8230e]
C->S
S->Root (.)
Root->S
S->com.
com->S
S->CU
CU->S
S->C
[/code:1:bb6bb8230e]
共發生 8 次 packet..
你去訪問 CU 時,若 CU 的 Web Log 有開 Lookup IP 的功能(一般是不會開
的,但你跑 awstats 還是要查一次,有開的沒反解再查一次),
[code:1:bb6bb8230e]
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.122.in-addr.arpa.
136.122.in-addr.arpa.->S
S->135.136.122.in-addr.arpa.
135.136.122.in-addr.arpa.->S
S->CU
[/code:1:bb6bb8230e]
發生 12 次
(domain 愈長查愈多次不是嗎 !? )
很可惜, CU 的 IP 沒有反解,最後只到 122.in-addr.arpa. 而以,所以查詢只到
這裏而以,那也發生了8次呀.再來看,正解會 Cache,被 (S) Cache 6 小時,那反解
呢 ? 跟本是失敗的呀...抱歉,多數的 DNS 在發生時會再查一次,少數的 DNS 會做
negative cache (ncache),若有做 ncache,算你幸運,那 apnic 把這個值設成兩天,
但這只是少數而以.
[code:1:bb6bb8230e]
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
[/code:1:bb6bb8230e]
註:ncache 會看 SOA 第五個數字,在 bind 8 叫 min TTL,bind 9 叫 ncache TTL,
ncache 發生時(就是 DNS 知道找不到答案),會和此值和 SOA 的 TTL 值誰高而定,
但是你的 DNS Server 有 ncache 功能嗎 !?
好了,現在我們知道,不僅發生頻率反解多,Recusion 也是反解多,為什麼你要浪費
這麼多的 Traffic 呢 !? 更有意思的是....如果全中國上千萬個 IP 可解的不到
3%,那又是一個什麼樣的情況呢 !? 反解真正的含義是什麼呢!? 為什麼台灣可
以到 50% 左右的反解率呢 !?
先到這裏,家裏 12 點要停電,得回去了,後續再補
haha451 回复于：2004-09-03 09:45:30
[quote:a82399351d="abel"]
我們先看 CU 為例:
www.chinaunix.com.
61.135.136.122==>122.135.136.122.in-addr.arpa. [/quote:a82399351d]
绝对支持，学习ing...
但上一句似乎笔误，应为：61.135.136.122==>122.136.135.61.in-addr.arpa.
Fun-FreeBSD 回复于：2004-09-03 19:29:35
真是高手啊，对你的敬仰之情如滔滔江水，绵绵不绝
abel 回复于：2004-09-05 04:40:08
如果各位看了前面 netman 兄的說明,相信應能理解為什麼反解行為發生多
總之,你在網路上的行為時時刻刻都和反解有關就是你,你有正解發生,多一定
會帶來反解需求,沒有正解發生也會帶來反解需求,
-------------------------------------------------------------------
正文開始,文接 netman 那篇
[/b]建議您在看前,對 DNS 解析流程及授權有一定的概念,並巳充份了解正解的狀況[/b]
正解查詢,大家都想求正確,求快,求穩定,那為什麼反解不用呢 !?
因為你感受不明顯!但 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) 解出來會有 :
[code:1:a68eca342a]
C->S
S->Root (.)
Root->S
S->com.
com->S
S->CU
CU->S
S->C
[/code:1:a68eca342a]
共發生 8 次 packet..
你去訪問 CU 時,若 CU 的 Web Log 有開 Lookup IP 的功能(一般是不會開
的,但你跑 awstats 還是要查一次,有開的沒反解再查一次),
[code:1:a68eca342a]
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
[/code:1:a68eca342a]
發生 12 次
(domain 愈長查愈多次不是嗎 !? )
很可惜, CU 的 IP 沒有反解,最後只到 122.in-addr.arpa. 而以,所以查詢只到
這裏而以,那也發生了8次呀.再來看,正解會 Cache,被 (S) Cache 6 小時,那反解
呢 ? 跟本是失敗的呀...抱歉,多數的 DNS 在發生時會再查一次,少數的 DNS 會做
negative cache (ncache),若有做 ncache,算你幸運,那 apnic 把這個值設成兩天,
但這只是少數而以.
[code:1:a68eca342a]
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
[/code:1:a68eca342a]
註:ncache 會看 SOA 第五個數字,在 bind 8 叫 min TTL,bind 9 叫 ncache TTL,
ncache 發生時(就是 DNS 知道找不到答案),會和此值和 SOA 的 TTL 值誰高而定,
但是你的 DNS Server 有 ncache 功能嗎 !?
好了,現在我們知道,不僅發生頻率反解多,Recusion 也是反解多,為什麼你要浪費
這麼多的 Traffic 呢 !? 更有意思的是....如果全中國上千萬個 IP 可解的不到
3%,那又是一個什麼樣的情況呢 !? 反解真正的含義是什麼呢!? 為什麼台灣可
以到 50% 左右的反解率呢 !?
[b:a68eca342a]1. 中國有多少個 IP ? 反解情況如何 ?[/b:a68eca342a]
這個數字你可以從 APNIC 取得,並計算出來:
[code:1:a68eca342a]
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
[/code:1:a68eca342a]
Ans:54449664 (2004/09/04)
我自己三年前曾做過這樣的測試,將中國的所有 IP 都查一次反解,實際的總數巳不記得了,
但記得結果是 2%,所以,我們先來推論現況,但是這邊我們還是可以來做一個簡單的實驗:
[code:1:a68eca342a]
#取得 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
# 查 ip 反解,要 SOA 段,若出現 apnic 表示整段未做反解授權,
dig -x $ip | grep SOA | grep -v 'apnic' >>ns_rr
done
[/code:1:a68eca342a]
Ans: 共得到 202 行資料,例如下列結果:
[code:1:a68eca342a]
32.118.202.in-addr.arpa. 10800 IN SOA advan.syit.edu.cn. master.advan.syit.edu.cn. 2003030320 10800 1800 3600000 608400
64.118.202.in-addr.arpa. 10800 IN SOA cedrus.dlut.edu.cn. ygh.dlut.edu.cn. 2002052401 10800 3600 604800 86400
1.119.202.in-addr.arpa. 3600 IN SOA seic2.seu.edu.cn. root.seic2.seu.edu.cn. 2000061201 3600 1800 604800 3600
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
[/code:1:a68eca342a]
得到 202 行資料意味著什麼,代表著有500 餘段 APNIC 分配給 CN 的 IP 沒有授權出去,
[b:a68eca342a]你想要做反解,或反解授權,而你在這 500 餘段中,那就不必了[/b:a68eca342a],這內容我就不整理了
,你可以自己試 dig -x your_IP ,若 SOA 出現 apnic 就是沒有了,(我猜大部份有在看這
一篇的人,大概都會出現 apnic ,那可以不用再寫下去了嗎!!? ccc)
為什麼 APNIC 沒經 IP 反解授權出來!!! 答案要去問你的 ISP 為什麼沒有去申請反解授
權,APNIC 都有說怎麼做,但你的[b:a68eca342a] ISP 只想賺錢,不想盡義務[/b:a68eca342a],也有可能是教育面的
問題,沒有人教過 ISP 這樣的觀念,但我的想法較傾向前者.
所以,那反解的有 2/7 囉 !? 如果你要這樣的想法就該打,你看上面 202 結果 sample 的第
四個,看到這樣的內容其實大概這個反解授權會有問題,因為管理人員觀念不好,通常我們在
SOA 中的 email address 會要求至少是個可資連絡的 email,但這個 sample 的 email 是寄
給自己,如果是正解檔,你還可以反應過來,但反解你沒法將 localhost 想像成什麼 domain.
所以,這是個真實錯誤的示範.你自己在做時,也要注意這一點,zone contact email 要對.
再來,我們看看 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 是高估還是低估了,為什麼)
--------------------------------------------------------------------------------------
今天先到這裏,我會將我寫的部份,每次都整合在一起,方便大家連貫來看...
謝謝筆誤的提醒..寫不好請給我糾正一下,寫得好,也給我拍手一下好了 :em04:
每個人的程度及想法可能都不同,若您有心,請說明何處我需要加強說明,以便您更能體會
台灣的部份我就不寫了,因為狀況不同...對大家意義也不大
你可以用同樣的方式來檢驗,下一段再為大家解釋反解的含
意,再來再說明實際的作法
localking 回复于：2004-09-06 09:42:11
听君一席话，胜读十年书！期待下一篇！
skylove 回复于：2004-09-06 22:58:53
厉害，netman和abel两位来自台湾的朋友真是出手不凡，相当有大家风范，说起来如数家珍。。。佩服&期待ing
網中人 回复于：2004-09-07 01:18:35
不敢不敢...
跟 abel 兄比起來, 小弟只是個剛入門的學生而已啦.
我的確常如此告誡自己的... ^_^
abel 回复于：2004-09-07 20:15:56
本文撰寫於 www.chinaunix.com ,撰寫人為:
netman/abel
歡迎任意轉載,轉載時請注明出處
除錯別字外(哈~這個我常發生),勿對本文加油添醋
主題:反向解析域是怎么授权的 (http://bbs.chinaunix.net/forum/16/20040812/385903.html)
-------------------------------------------------------------------
正文開始,文接 netman 那篇
[b:3f03d4c907]建議您在看前,對 DNS 解析流程及授權有一定的概念,並巳充份了解正解的狀況[/b:3f03d4c907]
[b:3f03d4c907]1.前言 [/b:3f03d4c907]
首先, 我上次問過大家一個問題:
--- 在 internet 上是正解查詢多還是反解查詢多?
若你有朋友在 NIC 或 ISP 內管 dns 的話, 應該不難問出答案:
---> 反解多!
那, 你或許會問: why?
嗯, 先回看我前面提到的:
--- DNS 只負責解釋, 至於解釋出來的結果如何用? 那就不是 DNS 要擔心的.
那接下來, 誰要操這份心呢?
簡單來說, 就是那些使用到 dns 的程式了...
那再下來, 有哪些程式呢?
簡單來說: 分 client 與 server 兩類程式就夠了.
然後, 只要你能統計出在 dns 查詢中, 究竟是 client 多還是 server 多? 就立見分曉了....
答案是: server 居多!
[b:3f03d4c907]2.為什麼反解多 ?[/b:3f03d4c907]
[b:3f03d4c907]2.1 發生次數多[/b:3f03d4c907]
不用懷疑, 假設以一封 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 查詢? 及其中的正反解的比例?
最簡單的羅輯是:
有一個正解需求的連線發生後, 通常就會引起一個反解, 但更多時候會引起更多的反解!
[b:3f03d4c907] 2.2 遞歸次數多 [/b:3f03d4c907]
正解查詢,大家都想求正確,求快,求穩定,那為什麼反解不用呢 !?
因為你感受不明顯!但 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) 解出來會有 :
[code:1:3f03d4c907]
C->S
S->Root (.)
Root->S
S->com.
com->S
S->CU
CU->S
S->C
[/code:1:3f03d4c907]
共發生 8 次 packet..
你去訪問 CU 時,若 CU 的 Web Log 有開 Lookup IP 的功能(一般是不會開
的,但你跑 awstats 還是要查一次,有開的沒反解再查一次),
[code:1:3f03d4c907]
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
[/code:1:3f03d4c907]
發生 12 次
(domain 愈長查愈多次不是嗎 !? )
很可惜, CU 的 IP 沒有反解,最後只到 122.in-addr.arpa. 而以,所以查詢只到
這裏而以,那也發生了8次呀.再來看,正解會 Cache,被 (S) Cache 6 小時,那反解
呢 ? 跟本是失敗的呀...抱歉,多數的 DNS 在發生時會再查一次,少數的 DNS 會做
negative cache (ncache),若有做 ncache,算你幸運,那 apnic 把這個值設成兩天,
但這只是少數而以.
[code:1:3f03d4c907]
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
[/code:1:3f03d4c907]
註:ncache 會看 SOA 第五個數字,在 bind 8 叫 min TTL,bind 9 叫 ncache TTL,
ncache 發生時(就是 DNS 知道找不到答案),會和此值和 SOA 的 TTL 值誰高而定,
但是你的 DNS Server 有 ncache 功能嗎 !? (這個議題這裏就不論述了,會受太多
因素影響)
好了,現在我們知道,不僅發生頻率反解多,Recusion 也是反解多,為什麼你要浪費
這麼多的 Traffic 呢 !? 更有意思的是....如果全中國上千萬個 IP 可解的不到
3%,那又是一個什麼樣的情況呢 !? 反解真正的含義是什麼呢!? 為什麼台灣可
以到 50% 左右的反解率呢 !?
[b:3f03d4c907]3. 中國有多少個 IP ? 反解情況如何 ?[/b:3f03d4c907]
這個數字你可以從 APNIC 取得,並計算出來:
[code:1:3f03d4c907]
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
[/code:1:3f03d4c907]
Ans:54449664 (2004/09/04)
我自己三年前曾做過這樣的測試,將中國的所有 IP 都查一次反解,實際的總數巳不
記得了,但記得結果是 2%,所以,我們先來推論現況,但是這邊我們還是可以來做一個
簡單的實驗:
上一篇發現一些小錯誤,以下做了一些調整,以求得更正確的值,原來的 script 有點問題:
[code:1:3f03d4c907]
#取得 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
[/code:1:3f03d4c907]
這個答案是 72 筆,約為1/10 ,依照約數,中國的反解率最多僅為 10%,如果這其中並
沒有設錯的或少設的,隨意舉個 "北大,pku.edu.cn" 的例子好了([b:3f03d4c907]第一個就挑中好
sample,這個 sample 我們後面再講授權時還會用到,請務必理解[/b:3f03d4c907]):
北大的 IP 是 162.105.x.x,我們先來看看授權(NS delegation) 及解析情形如何:
IP 在反查時,一定會先到 in-addr.arpa. 我想這是很平常的觀念,所以我們查詢
in-addr.arpa 有那些 NameServer:
[code:1:3f03d4c907]
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
[/code:1:3f03d4c907]
並且 DNS 是隨機選一部來查,所以我們要查 162.105.x.x 就隨便選一部,但是
先從 IP 的第一碼查起:
[code:1:3f03d4c907]
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
[/code:1:3f03d4c907]
再來這一步,我們還是查 162,驗證上層與下層的 NS RRs 是否一致,不一致我們
通常會稱為 Lame Server,這會造成解析上的問題:
[code:1:3f03d4c907]
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
[/code:1:3f03d4c907]
由此可知,上下是一致的,也就是在 in-addr.arpa 中將 162 指向了七部 NS,這
七部 NS 都有設立起來,且七部的名稱與上層的名稱皆完全正確的對應,至於 AAAA
這是IPv6 的記錄,想來是這部主機同時有 IPv4/IPv6 位址.
再來,我們從 chia.arin.net 看,162.105.x.x 分配給北大使用的情形,得到下列結果:
[code:1:3f03d4c907]
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
[/code:1:3f03d4c907]
這代表著由 162 下長出來的 105 (162.105.x.x) 基本上都由北大管理,那北大這三部
NS 呢,不知是什麼樣的情形 ?
所以我們就查詢北大這三部 NS ,看看有什麼狀況:
[code:1:3f03d4c907]
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
[/code:1:3f03d4c907]
Time Out,試了 N 次都是 Timeout ...授權失敗,應該是陣亡或是換掉了吧..
[b:3f03d4c907]反解查詢若三選一選到這部,就查不出來了,即會變成沒有反解狀況.[/b:3f03d4c907]
再來我們選第二部([b:3f03d4c907]DNS 查詢時不會自動切到第二部,選到 sun1000e ,沒有查到不會自動
Switch 到第二部的[/b:3f03d4c907],此處我們意在講解,所以可以用手動的方式來驗證):
[code:1:3f03d4c907]
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
[/code:1:3f03d4c907]
哦耶~有回應耶...不過為什麼是五部...162.in-addr.arpa. 上層不是說有三部管
162.105.x.x 嗎? 你(ns.pku.edu.tw) 又說有五部,我要相信誰 !? 誰告訴我你們
那個說的是真的 ><"
算了,我們看 162.in-addr.arpa. 上講的第三部好了:
[code:1:3f03d4c907]
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
[/code:1:3f03d4c907]
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. 你說假話!
再來看最後一個希望:
[code:1:3f03d4c907]
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
[/code:1:3f03d4c907]
還好,有了答案了,看來 ns2.cuhk.hk 代管的 domain 還真不少, TTL 都不會減少,
過程中共有五部 NS,只有兩部正確 Work (這兩部有一部不在上層出現),有二部不能
連,有一部不管這個反解的 zone , 就通算你 2/5 可解吧!
以上有些部份後面我們還會看到,但是從這個例子來看,105.162.in-addr.arpa. 的反解有
N 個問題,如果連 pku 都這樣...
另一個重點,就是非 edu/ac doamin 部份,
[code:1:3f03d4c907]
#我們只要 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.
[/code:1:3f03d4c907]
這個部份我就不知誰有名了,不過看到 capitalnet.com.cn 看名字好像規模不小的感覺,
你可以用像上面一樣的流程,一直查下來,會發現到 capitalnet.com.cn 這一層時,只有一個
NS RRs,但是他上層登記的是兩個....也是不一致,當然,也有很多做的非常好的,像east.net.cn
就 100 分!
[b:3f03d4c907]註:NS 上下不一致情形,不同的 Bind 版本在查詢處理上略有不同,非本處重點所在,個人
亦不打算另起主題說明[/b:3f03d4c907]
另外一個重點就是, Reverse Domain 的 SOA 中 Email 也是要注意之處 !
[code:1:3f03d4c907]
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
[/code:1:3f03d4c907]
上面 202 結果 sample 的第
四個,看到這樣的內容其實大概這個反解授權會有問題,因為管理人員觀念不好,通常我們在
SOA 中的 email address 會要求至少是個可資連絡的 email,但這個 sample 的 email 是寄
給自己,如果是正解檔,你還可以反應過來,但反解你沒法將 localhost 想像成什麼 domain.
所以,這是個真實錯誤的示範.你自己在做時,也要注意這一點,zone contact email 要對.
[b:3f03d4c907]所以,綜合前面論點,反解絕對沒有 1/10 ,即使有 NS 指向的達到 1/10 ![/b:3f03d4c907]
再來,我們看看 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 沒有授權出去,
[b:3f03d4c907]你想要做反解,或反解授權,而你在這 600 餘段中,那就不必了[/b:3f03d4c907],這內容我就不整理了
,你可以自己試 dig -x your_IP ,若 SOA 出現 apnic 就是沒有了,(我猜大部份有在看這
一篇的人,大概都會出現 apnic ,那可以不用再寫下去了嗎!!? ccc)
為什麼 APNIC 沒把 IP 反解授權出來!!! 答案要去問你的 ISP 為什麼沒有去申請反解授權
權,APNIC 都有說怎麼做,做起來也很簡單,但你的[b:3f03d4c907] ISP 只想賺錢,不想盡義務[/b:3f03d4c907],也有可
能是教育面的問題,沒有人教過 ISP 這樣的觀念,但個人的想法較傾向前者.
台灣的數字和台灣 Internet 歷史發展有關,從 TANET (學術網路) 興起 ,1996 年就教育
User 反解意義,並且要求連線單位一定要設反解,不然連不到 BBS/FTP ...,到今天,當年的學生
現在多巳入行...這都得感謝 TANET 前輩的努力呀 ! 其中著力最深的個人認為當屬 nschen
(陳昌盛老師),在網路上的鼓吹!! 今日,若在台灣的 ISP 若不做反解(或反解授權或可自行修改),
是無法被用戶接受的.若屬動態IP,ISP 也會以 IP_addr.dynamic.ISP_domain 標示出來,讓 Mail
Server admin 自行決定是否 Reject.
[b:3f03d4c907]4. 反解的意義何在? 反解對行為的影響[/b:3f03d4c907]
最重要的解釋就是[b:3f03d4c907]這個 IP 的的網路身份是被認可的[/b:3f03d4c907] ! 只是你的 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 所寄來的三封主題回覆通知:
[code:1:3f03d4c907]
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
[/code:1:3f03d4c907]
你會發現, Received 欄位,在我收到時,和 CU 發出時,差了約 14~15 秒,這中間主要即是因為沒
有反解所致,同時我找了一個有反解的,同樣用 qmail 的 sample 如下:
[code:1:3f03d4c907]
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
[/code:1:3f03d4c907]
一個差3秒,一個差15秒左右(當然有可能是時間差的問題,我們 Server 都會跑 ntp,相信像 CU 這
種大站也會跑 ntp,至於下面的 sample 有無我就不知了),所以時間上來說應都是同步的.
(若你認為是路途太遠,那就不及格了)
所以,你若還有跑什麼 Mail Gateway,或 Smart Relay,基本你經過的點愈多,時間差距就會愈大
CU 的例子,15 秒還在可接受的範圍內.
註1: 若要縮短這 15 秒,可以在自己的 /etc/hosts 將 CU 給指出來,沒試過,理論應可行
註2: 若你送了信,但要半天一天才到,那大多事 DNS delegation 的問題為主
[b:3f03d4c907]5.反解如何授權[/b:3f03d4c907]
我想本節才是重點,我們就以 pku.edu.cn 那個 sample 為例好了,105.162.in-addr.arpa.
由於這是整個 Class B 的規模,所以他要做授權的話,以 C 為單位是很簡單的,和正解的思考
是一樣的,
[code:1:3f03d4c907]
$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.
...
[/code:1:3f03d4c907]
[b:3f03d4c907]5.1 滿一個 Class C[/b:3f03d4c907]
所以,可以讓 cc 一個系所有一個 Class C (255 個 IP) 的授權,此時 cc 系在架 DNS 時就要有兩部
[code:1:3f03d4c907]
$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.
[/code:1:3f03d4c907]
目前為止我相信各位都能體會,如果不能體會請先將正解弄熟,弄懂,你就會了解.
上面這樣的設法,基本上可能對管理這部主機的人而言太重覆,所以 BIND 9 時就加了一個
$GENERATE 的功能變數
[code:1:3f03d4c907]
;SOA NS 如上例
$ORIGIN 0.105.162.in-addr.arpa.
$GENERATE 3-254 $ PTR pc$.cc.pku.edu.cn.
[/code:1:3f03d4c907]
其說明了 $ 是由 3 至 254 組成,要擴展為 252 (254-3+1=252) 行(你將 $=3,$=4 代進去
就是了,IN 不用寫)
[b:3f03d4c907]5.2 不滿一個 Class C[/b:3f03d4c907]
好了,以上都是標準的狀況,但是現在誰有 Class C 呢 !?
例如, cc 系所下面還有四個單位(ex:64,32,32,128 個 IP 分配好了,cc 本身是第一個), cc 系
所要如何授權出去呢 !?
最簡單的方法就是(不知大家是否懂 $ORIGIN 意思,就是FQDN最後若沒有 . 要補這個字) 直接 NS
再授權下去,但這也是最不經濟的方法:
[code:1:3f03d4c907]
$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.
[/code:1:3f03d4c907]
$GENERATE 功能自己多體會就可以很快上手了,而這個時候, ns1.unit2.cc.pku.edu.cn 就得要
把 zone 建出來了,這個 zone 要寫滿整個 IP,
[code:1:3f03d4c907]
#/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";};
....
[/code:1:3f03d4c907]
然後那個 zone file 內都只有一行 PTR 資料,因為是將 IP (4 octets) 指了過來:
[code:1:3f03d4c907]
$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.
[/code:1:3f03d4c907]
那不就瘋了~拿到 128 個 IP 要設 128 次 zone , 及建 128 個 zone file ..
的確是這樣,如果有 128 個 IP 他也甘願,且這種方法還有不少人用.而很多人在
這種情況下,會不明所以,反而設成一個 C (255 個 IP ) 的反解:
[code:1:3f03d4c907]
#ns1 of unit4 在 /etc/named.conf 中寫
zone "0.105.162.in-addr.arpa" {.....};
[/code:1:3f03d4c907]
在 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
[code:1:3f03d4c907]
;在 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.
[/code:1:3f03d4c907]
以上請您先充份理解 $GENERATE 的功能,要到用看的也看的出來的程度,且不用寫
兩次(原來寫兩次是因為一個 domain 一定要有兩部以上的 NameServer),因為全部
都會轉到正解檔去
[code:1:3f03d4c907]
;$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.
[/code:1:3f03d4c907]
這裏一定有人犯疑,反解檔可以用 CNAME 嗎 ? 誰說不行的呀,就像 MX 可不可以是接 IP
一樣,正解檔裏也是可以放 PTR 的,重點只在,他們都是 DNS 的 zone,正解/反解 只是人
們區分上的差別而以:
[code:1:3f03d4c907]
;原來 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$
[/code:1:3f03d4c907]
好了,這樣就可以了,當你 dig -x 162.105.0.143 時,就會出現解到 CNAME (參閱上面),
換到 CNAME 後會查原來的 FQDN,就會找到 pc143.unit4.cc.pku.edu.cn.
用 $GENERATE 只是適用有規則的變化,在本例中,一般會建議你依順序排列,以便日後管理:
[code:1:3f03d4c907]
www IN A 162.105.0.133
pc133 IN PTR www
;...134,135....
mail IN A 162.105.0.143
pc143 IN PTR mail
;...
[/code:1:3f03d4c907]
所以 pc133 等這種名稱,純粹就會變成一種 "接取" 的狀況,主要是要 "串連" 起來.
實例:
[code:1:3f03d4c907]
[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.
[/code:1:3f03d4c907]
syslog 中會出現像(有的 OS 版本不會出現):
[code:1:3f03d4c907]
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."
[/code:1:3f03d4c907]
大概就這樣,你會發現,到後面講 CNAME 的地方有點難理解,這是正常的,有程度的人用力看
大概可以看得懂,若普通的話,實作即可知道,若連正解都不懂大概很難體會.
DNS 這種東西若你以為用看的就全看的懂表示你太看輕它了.
abel 回复于：2004-09-07 20:25:53
[quote:fda5880b23="網中人"]不敢不敢...
跟 abel 兄比起來, 小弟只是個剛入門的學生而已啦.
我的確常如此告誡自己的... ^_^[/quote:fda5880b23]
:oops: netman 兄您過獎了...在 DNS 這個領域我只是有比您好的
環境而以,技術面的東西是可以訓練的,但您悔人不倦的情操才是我要看
齊之處(不過實在很難做到...)
網中人 回复于：2004-09-08 07:40:02
abel 兄寫得真好! 給您拍拍手...
不過, 想向您請教一個觀念:
[b:9be59e4373]DNS 查詢時不會自動切到第二部,選到 sun1000e ,沒有查到不會自動Switch 到第二部的[/b:9be59e4373]
是否意味著: 就算 time out , resolver 也不會以 round robin 的方式選下一台 server 呢?
若此假設成立的話,
那麼, 以一個註冊了兩台 ns 的 domain 來說,
若其中一台掛掉了, 那其結果就是 50% 查詢失敗了?
也就是以單一的一個 application session 而言, 有一半機會是無法建立的.
然後到下一次 retry (不是 resolver 的 retry, 而是 application 的),
再來賭一次運氣?
因為這個觀念小弟一直很模糊, 趁此機會跟大哥請益... ^_^
感謝再三!
abel 回复于：2004-09-08 08:17:45
[quote:57e96c3071]不過, 想向您請教一個觀念:
DNS 查詢時不會自動切到第二部,選到 sun1000e ,沒有查到不會自動Switch 到第二部的
是否意味著: 就算 time out , resolver 也不會以 round robin 的方式選下一台 server 呢? [/quote:57e96c3071]
是的,一般的情況確實是如此,所以一般人只考慮設了後有沒有 work,
而沒有注意錯誤的設定帶來的負擔可能更大 (Lame Server,NS 亂設...)
[quote:57e96c3071]若此假設成立的話,
那麼, 以一個註冊了兩台 ns 的 domain 來說,
若其中一台掛掉了, 那其結果就是 50% 查詢失敗了? [/quote:57e96c3071]
如同前面,在 Resolver 預設不啟動 default domain/search 的狀況下是
這樣(啟動也不見得會對)
[quote:57e96c3071]也就是以單一的一個 application session 而言, 有一半機會是無法建立的.
然後到下一次 retry (不是 resolver 的 retry, 而是 application 的),
再來賭一次運氣? [/quote:57e96c3071]
拿 sendmail 為例好了, 裏頭有個 resolver 的功能設定,
resolver.retry #Sets the number of attempts to retransmit a resolver query
這個部份有好幾條,一般都是 "註解" 掉的
如果我們訂成4次,那會大大降低查不到的風險(代價可能是 traffic/loading)
若像二選一個狀況,僅有一部 work, try 四次後還查不到(這四次都是 Round Robin 的, Resolver 將 Query 送進 nameserver, Nameserver 再做一次
平常做的那樣,只是重覆4次而以),那只能說運氣太背
(如果信件很多,有多人的 dns 都沒設好,還是會有一些 issue ...)
較不會掉進 Queue interval 的檢查中
網中人 回复于：2004-09-08 12:24:47
感謝感謝!
看來我之前的理解太過單純了, 我還以為 resolver 會做 retry 的動作呢...
原來這個 retry 是 application 決定的.
abel 回复于：2004-09-08 12:33:51
ap->resolver->DNS
其實都是 Resolver 決定的
但 ap 可以定義 resolver 會用到的一個 struct _res
這個結構內含了像
default domain/search,
timeout/retry ...
dns server...
這些行為..
AP 確實是呼叫 Resolver, 呼叫前可定義好行為 (_res)
若沒定義,就看 defualt value,
這個 default value 就是/etc/resolv.conf
netman 兄若有心,可以看一下系統的 /usr/include/resolv.h 中
您會發現更多的說明(雖然這是程式用的東西,但他有很多註解說明)
網中人 回复于：2004-09-08 14:10:27
okay, 感謝! ^_^
每次都能跟大哥學習新知, 真是太高興了!
bun 回复于：2004-09-08 14:30:14
如果这样的话，slave nameserver岂不是没有派上用场？
请解释一下，谢谢。
網中人 回复于：2004-09-09 01:27:32
這是 man 5 resolv.conf 的其中一段, 可參考一下:
[code:1:9b3705d50c] attempts:n
sets the number of times the resolver will send a
query to its name servers before giving up and return&
ing an error to the calling application. The default
is RES_DFLRETRY (see <resolv.h> ).[/code:1:9b3705d50c]
hjp0021 回复于：2004-09-09 15:02:31
非常精彩，留着慢慢领会。
想想自己，真是汗颜，摒弃浮躁，潜心向二位大大学习。
abel 回复于：2004-09-10 11:17:36
[quote:b74a71ff38]如果这样的话，slave nameserver岂不是没有派上用场？
请解释一下，谢谢。[/quote:b74a71ff38]
你的觀念有太多問題...建議您找 netman 兄曾提到的文件或影片看看
AP->resolver->DNS Server --->DNS Query Flow ...
怎會沒有用到 Slave 呢 !? 為什麼呢 !? 如果你說的是 DNS Server 這個
位置,那我也不知該怎麼說...看影片吧
另外,思考一下, netman 兄有學習方法,你有沒有做到像他那樣 ..
當我舉 sendmail 中有關 resolver.* 的設定時的例子,我相信他一定
會馬上去看自己的 sendmail.cf 中有關這段的描述,並咀嚼一番.
當然,你可能不用 sendmail , 但其他的 MTA 或多或少都會有這種功能
我想,這個版十個看到這一篇的大概最多就一個會去查吧 ...
即使我講錯了也沒有人知道 (這不是沒有可能的,但沒有查就沒法驗證
自己的想法,我的說辭)
像 netman 兄這樣的學習才是對的,最後他也查了 resolv.conf 的內容
相信,收獲最多的人,就是 "懂得學習方法" 的人 ..
而多數人的學習只是 Step by Step ....
至於 hjp0021 兄過獎了,每個人專業的領域不同,術業有專攻
網中人 回复于：2004-09-11 01:27:07
哦, abel 兄過獎了... ^_^
在 sendmail.cf 中, 我找到如下這些 options:
[code:1:4c3c46f39c]#O Timeout.resolver.retrans=5s
#O Timeout.resolver.retrans.first=5s
#O Timeout.resolver.retrans.normal=5s
#O Timeout.resolver.retry=4
#O Timeout.resolver.retry.first=4
#O Timeout.resolver.retry.normal=4[/code:1:4c3c46f39c]
看來 sendmail 的確從 app 這層定議了 retry 的內容.
至於 /usr/include/resolv.h 裡關於 RES_DFLRETRY 的預設值, 似乎是 2:
[code:1:4c3c46f39c]#define RES_DFLRETRY 2 /* Default #/tries. */[/code:1:4c3c46f39c]
不過, 我尚不確定的是: 在定義了 2 次 retry 的情況下,
resolver 是用 round robin 方式呢?
還是重新再問一次碰運氣?
sorry, 有點小懶, 沒去挖文件了... 若 abel 兄有空的話, 可否解惑一下呢?
謝謝!
skylove 回复于：2004-09-12 11:02:06
问的精彩，答得精妙，让我等看客也受益良多呢~~~
而且最后提到的学习方法，我自己也属于那9/10之一，汗颜不已，一定尽力改正学习态度。
abel 回复于：2004-09-13 14:35:59
skylove 兄別介意~其實重點只是學習的態度而以...
netman 兄的問題:
[quote:c3bf858690]看來 sendmail 的確從 app 這層定議了 retry 的內容.
至於 /usr/include/resolv.h 裡關於 RES_DFLRETRY 的預設值, 似乎是
#define RES_DFLRETRY 2 /* Default #/tries. */
不過, 我尚不確定的是: 在定義了 2 次 retry 的情況下,
resolver 是用 round robin 方式呢? [/quote:c3bf858690]
是定義了二次 Retry ,一般系統都預設兩次 (有的系統較早一點的版本沒有
這個功能)
我們得先想想, 什麼狀況會 Retry , 通常是 Bad Query/Timeout
像 Server Fail,Format Error ...這種錯誤(mis-configuration,錯誤的設定)
是不會 Retry 的,這點需要先區分清楚
(也就是他巳經查到了,只是這個 "答案" 可能對 AP 沒有實質意義,查不到
要 Retry 是在前述的狀況,不是DNS設定錯誤要重查)
所以 AP->Resolver->DNS->DNS Query Flow ...
AP 會呼叫 Resolver 去查 DNS,
DNS Server (指在 /etc/resolv.conf 中設定的 nameserver )
個人認為,這個 Retry 指的是 這一段動作(AP->DNS),
而不是 DNS->DNS Query, 這可能是要區分清楚的
您可能會再想...若在 resolv.conf 這裏面定義了
nameserver IP1
nameserver IP2
何時取用 IP1 或 IP2 這個問題 ,或如何取用
resolv.conf 的說明檔中其實並沒有講得很清楚(MAXNS 最大為3,系統巳定義)
就我查看resolver程式的部份:
[code:1:c3bf858690] /*
* Send request, RETRY times, or until successful.
*/
for (try = 0; try < statp->retry; try++) {
for (ns = 0; ns < statp->nscount; ns++) {[/code:1:c3bf858690]
可以發現, nameserver IP 當 retry N 次後 (這個 N 就是您提的那個#define .... 2) ,
會換下一個 nameserver,下一個再試 N 次,最大失敗數就是 N x Nameserver 數了.
能夠成功將查詢送到 nameserver 即完成了 Resolver 的行為,再下來就是 DNS
的行為了,重點即在要查的目標 DNS 設定是否正確了.
不知如此解釋您可否看的懂!? 若不了解或疑義我們可再討論 ..
您指出來的 Point 也是觸發我 Study 的動機 , 受益良多
網中人 回复于：2004-09-14 01:17:54
感謝 abel 兄的大力幫忙!
由於小弟的惰性也不輕, 且對 c 一竅不通, 還得仰賴大哥的教導...
看您上面的說明, 似乎說的是 resolver 在決定選用下一順位的 nameserver 之 retry 次數,
好像跟我們之前討論的 recursion server 對 authritative server 的 retry 不同哦.
若是前者, 小弟還好理解, 只是, 想確定的是:
假設服務 resolver 的 server 收到 question section 要查某一 record,
且在 caching 中並無 answer(non-authoritative or negative),
然後一直查到 authority servers 超過一台,
照理解, 會 random 選其中一台, 若發生如下情形將會如何處理:
1) 連不上, unreachable or refused
2) 連得上, 但 lame server
3) 連得上, 但 no answer
小弟對第三種情形或許理解得來, 但前兩者, 就得勞煩大哥幫忙解惑了.
感謝再三! ^_^
abel 回复于：2004-09-14 02:13:09
1. 我不敢十分肯定 unreachable 的狀況. 明天去查查,至於 Refused 應該很明顯,只有一次
2. 一次,還到 Lame Server 也都是只送一次,看運氣好壞而以
3. 您巳自解
我覺得重點在 DNS 對 DNS 是不是只查一次,這個答案基本上我是肯定的,
只是對 unreachable 較存疑 ...可能需一點時間去查查
網中人 回复于：2004-09-14 02:18:18
哦, 感謝感謝! ^_^
netocool 回复于：2004-09-14 11:23:57
How Reverse DNS Works
or, "Almost a Reverse DNS FAQ"
Reverse DNS turns an IP address into a hostname -- for example, it might turn 192.0.2.25 into host.example.com.
For your domains, standard DNS (turning a hostname into an IP address, such turning host.example.com into 192.0.2.25) starts with the company (registrar) that you registered your domains with. You let them know what DNS servers are responsible for your domain names, and the registrar sends this information to the root servers (technically, the parent servers for your TLD). Then, anyone in the world can access your domains, and you can send them to any IP addresses you want. You have full control over your domains, and can send people to any IPs (whether or not you have control over those IPs, although you should have permission to send them to IPs that are not yours).
Reverse DNS works in a similar method. For your IPs, reverse DNS (turning 192.0.2.25 back into host.example.com) starts with your ISP (or whoever told you what your IP addresses are). You let them know what DNS servers are responsible for the reverse DNS entries for your IPs (or, they can enter the reverse DNS entries on their DNS servers), and your ISP gives this information out when their DNS servers get queried for your reverse DNS entries. Then, anyone in the world can look up the reverse DNS entries for your IPs, and you can return any hostnames you want (whether or not you have control over those domains, although you should have permission to point them to hostnames that are not on your domains).
So for both standard DNS and reverse DNS, there are two steps: [1] You need DNS servers, and [2] You need to tell the right company (your registrar for standard DNS lookups, or your ISP for reverse DNS lookups) where your DNS servers are located. Without Step 2, nobody will be able to reach your DNS servers.
If you can comprehend the above paragraphs (which takes some time), you'll understand the biggest problem that people have with reverse DNS entries. The biggest problem people have is that they have DNS servers that work fine with their domains (standard DNS), they add reverse DNS entries to those servers, and it doesn't work. If you understand the above paragraphs, you'll see the problem: If your ISP doesn't know that you have DNS servers to handle the reverse DNS for your IPs, they won't send that information to the root servers, and nobody will even get to your DNS servers for reverse DNS looksups.
Basic Concepts:
Reverse DNS turns 192.0.2.25 into host.example.com (an IP address into a host name).
Typical reverse DNS lookup path: DNS resolver => root servers => ARIN (North American IP registry) => Local ISP => Acme Inc. DNS servers.
Whoever supplies your IP addresses (usually your ISP) MUST either [1] set up your reverse DNS entries on their DNS servers, or [2] "delegate authority" for your reverse DNS entries to your DNS servers.
Reverse DNS entries use a host name with a reversed IP address with ".in-addr.arpa" added to it -- for example, "25.2.0.192.in-addr.arpa".
Reverse DNS entries are set up with PTR records (whereas standard DNS uses A records), which look like "25.2.0.192.in-addr.arpa. PTR host.example.com" (whereas standard DNS would look like "host.example.com. A 192.0.2.25").
All Internet hosts should have a reverse DNS entry (see RFC1912 section 2.1).
Mail servers with no reverse DNS will have a hard time getting mail to certain large ISPs.
Very Common Myth:
Myth: If you have a reverse DNS entry listed in your DNS server, you have reverse DNS properly set up.
Fact: This is often not the case. You need TWO things in order to have your DNS set up properly:
1. Your DNS servers (or your ISP's) MUST have the reverse DNS entries set up ("25.2.0.192.in-addr.arpa. PTR host.example.com").
2. AND your ISP or bandwidth provider MUST set up the reverse DNS on their end, so that DNS resolvers around the world will know that your DNS servers are the ones to go to when looking up the reverse DNS for your IP addresses.
How a reverse DNS lookup is accomplished:
The DNS resolver reverses the IP, and adds it to ".in-addr.arpa", turning 192.0.2.25 into 25.2.0.192.in-addr.arpa.
The DNS resolver then looks up the PTR record for 25.2.0.192.in-addr.arpa.
The DNS resolver checks asks the root servers for the PTR record for 25.2.0.192.in-addr.arpa.
The root servers refer the DNS resolver to the DNS servers in charge of the Class A range (192.in-addr.arpa, which covers all IPs that begin with 192).
In almost all cases, the root servers will refer the DNS resolver to a "RIR" ("Regional Internet Registry"). These are the organizations that allocate IPs. In general, ARIN handles North American IPs, APNIC handles Asian-Pacific IPs, and RIPE handles European IPs.
The DNS resolver will ask the ARIN DNS servers for the PTR record for 25.2.0.192.in-addr.arpa.
The ARIN DNS servers will refer the DNS resolver to the DNS servers of the organization that was originally given the IP range. These are usually the DNS servers of your ISP, or their bandwidth provider.
The DNS resolver will ask the ISP's DNS servers for the PTR record for 25.0.2.192.in-addr.arpa.
The ISP's DNS servers will refer the DNS resolver to the organization's DNS servers.
The DNS resolver will ask the organization's DNS servers for the PTR record for 25.0.2.192.in-addr.arpa.
The organization's DNS servers will respond with "host.example.com".
網中人 回复于：2004-09-14 13:48:55
> Typical reverse DNS lookup path: DNS resolver => root servers => ARIN (North American IP registry) => Local ISP => Acme Inc. DNS servers.
上一句有一點小問題:
resolver 並不能向 root 查詢,
resolver 只是 client 端的一個 program ,
然後向其指定的 dns server 提出 question section,
若 server 在其 zone db 或 cache 中有 answer, 就直接回應...
否則, 再看是否開啟 recursion ?
若然, 才從 root server 或已存於 cache 中的下游 ns 做查詢.
關於 resolver 與 name server 的差別,
小弟之前也犯了同樣的錯誤, 也是來 CU 跟大家討論後才得以糾正的.
希望我的經驗可讓大家節省一些學習成本... ^_^
netocool 回复于：2004-09-14 15:34:37
一个大快人心的话题讨论,令我受益匪浅
谢谢abel 和netman,我也把我仅有的资料放上来,希望大家可以热烈交流
反向域名解析(reverse DNS)这个问题也困扰我很久了,我的IP是在当地的电信局申请的,由APNIC发放的,我的邮件服务器发邮件到国外的邮件服务器曾经就遇到过被拒收的烦恼(问题现在还没有解决),因为对方的DSBL(反垃圾邮件组织)把我的IP地址列表了,需要申请解除才能给对方发邮件
但是申请解除需要我的IP做reverse DNS,但是电信局说他们不能对我的IP做反向域名解析,说他们只可以对他们本域做反向域名解析,我就不明白了,既然我的IP是从那里申请的,难道我的IP不是在他们的域内吗?
我看,现在大部分的地方电信局都没有申请IP地址反向域名解析服务,可能是他们的意识不够强吧......
想问问abel,
;; AUTHORITY SECTION:
166.103.202.in-addr.arpa. 86400 IN SOA dns.guangzhou.gd.cn. root.dns.guangzhou.gd.cn. 2001061111 28800 7200 604800 86400
这个情况是不是说明202.103.166.0这个段可以做reverse DNS呢?
应该如何做一些反向解析测试呢?
abel 回复于：2004-09-14 16:48:25
netocool 兄,如果您時間可以,建議您將本帖來回讀個3~5 次
增加自己的印象,及想想裏面的文字含意,你定會有更深刻的體會的
不要只看文字的表面
[code:1:5301a838fe]
i=1;
while [ $i -le 255 ];
do
dig -x 202.103.166.$i| grep "^$i.166.";i=`expr $i + 1`;
done
result:
153.166.103.202.in-addr.arpa. 83908 IN PTR dns.sipix.com.cn.
154.166.103.202.in-addr.arpa. 83910 IN PTR mail.sipix.com.cn.
155.166.103.202.in-addr.arpa. 83911 IN PTR dns2.sipix.com.cn.
156.166.103.202.in-addr.arpa. 83911 IN PTR nat.sipix.com.cn.
[/code:1:5301a838fe]
所以這個 Class C 部份,根本沒有做自己的域反解,
還幫 153-156 做了反解,
[quote:5301a838fe]
但是申请解除需要我的IP做reverse DNS,但是电信局说他们不能对我的IP做反向域名解析,说他们只可以对他们本域做反向域名解析,我就不明白了,既然我的IP是从那里申请的,难道我的IP不是在他们的域内吗?
[/quote:5301a838fe]
你的 ISP 應不是用這個域吧...拿這點去打死他們
至於
[quote:5301a838fe]
只可以对他们本域做反向域名解析
[/quote:5301a838fe]
如果他們的域為 ggyy_isp.net.cn 好了,也就是他們理論上會將所有
IP 的反解設成 IP.ggyy_isp.net.cn , 然後在一些 server 上可能
Allow ggyy_isp.net.cn , 而不會寫成 IP (因為 IP 太破碎)
不過從上面的測試,也可以看出來跟本沒有做自己的域反解
我只能說,你們的 ISP 在 "騙肖A" (台灣話,騙人,裝傻之意) ,
根本和自己說的不合,自己都沒做自己的域解析,但也幫別的 domain
做了解析,沒有什麼理由不幫你們做吧 ..
PS1: 其實這一篇若你有仔細看前面我寫的那一大片,並且用心體會,您根本
就不用發帖,我也用不著回的. 還有,你的ISP 犯了和 pku 類似的錯誤,
不過不苛責了,至少他們有從 APNIC 拿到反解授權,相對於別人是非常好的
PS2: 若你能說動 ISP 幫你做反解,請他們用 CNAME 指給你,而不要用 PTR 直接設,以後你就可以自己改了
wind521 回复于：2004-09-16 16:21:13
真的比较精彩，学习到了不少的东东
阿骁 回复于：2004-10-01 00:23:28
建议 netman 斑竹加精！ 今天又看了一次（没看到置顶，找了半天），又有一些收获！abel 兄研究 dns 真是透彻！
carelezz 回复于：2004-10-02 18:03:42
[quote:81262a49d3="abel"]可以發現, nameserver IP 當 retry N 次後 (這個 N 就是您提的那個#define .... 2) ,
會換下一個 nameserver,下一個再試 N 次,最大失敗數就是 N x Nameserver 數了.
能夠成功將查詢送到 nameserver 即完成了 Resol..........[/quote:81262a49d3]
看了这个帖子收益匪浅
有一点需要和Able兄商榷
resolv.conf 這裏面定義了
nameserver IP1
nameserver IP2
何時取用 IP1 或 IP2 這個問題 ,或如何取用
我认为解析器会首先查询IP1，当IP1超时，或者网络出错，
他将转而查询IP2，如果IP2也超时，解析器会从IP1开始第二轮查询
如果第二轮也失败，解析器便不会再试。
可以做个实验
在resolv.conf定义两个非dns服务器的IP
然后用dig查询打开d2选项
我的环境是freebsd 4.10
[code:1:81262a49d3]
carelezz@cs@/home/carelezz: dig xxx.com +d2
; <<>> DiG 8.3 <<>> xxx.com +d2
;; res_nmkquery(QUERY, xxx.com, IN, A)
;; res options: init debug recurs defnam dnsrch ?0x80000000?
;; res_send()
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2313
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;; xxx.com, type = A, class = IN
;; Querying server (# 1) address = IP1
;; new DG socket
;; timeout
;; Querying server (# 2) address = IP2
;; new DG socket
res_send: recvfrom: Connection refused
;; Querying server (# 1) address = IP1
;; new DG socket
;; timeout
;; Querying server (# 2) address = IP2
;; new DG socket
res_send: recvfrom: Connection refused
[/code:1:81262a49d3]
abel 回复于：2004-10-02 23:19:32
[code:1:f5156fdcb5] /*
* Send request, RETRY times, or until successful.
*/
for (try = 0; try < statp->retry; try++) {
for (ns = 0; ns < statp->nscount; ns++) {[/code:1:f5156fdcb5]
呀~是的,您講得沒錯,我沒有看仔細,
上面這段 code 就是從 res_send 中拿出來的,
先做 ns , 再做 retry 沒有錯.
感謝 carelezz 兄的指正
網中人 回复于：2004-10-02 23:45:44
是的, 同意 carelezz 兄的說法.
我這裡補充一下查詢時的 timeout 計算方式:
* 第一輪為 5 秒一次，逐台輪詢。
* 若第一輪失敗，則進入第二輪：將第一輪 time-out 乘以 2 倍，並除以台數。
* 若第二輪失敗，則進入第三輪：將第一輪 time-out 乘以 4 倍，並除以台數。
因此，若所有 nameserver 均連不上的話，如下是你的等待時間：
* 一台：首輪5秒，二輪10秒 (5*2/1)，三輪20秒(5*4/1)，加總為35秒。
* 兩台：首輪每台5秒共10 秒，二輪每台5 秒(5*2/2)共10秒，三輪每台10秒(5*4/2)共20秒，加總為40秒。
* 三台：首輪每台5秒共15秒，二輪每台3秒(5*2/3，取整數)共9秒，三輪每台6秒(5*4/3，取整數)共18秒，加總為42秒。
(一時忘了資料來源, 好像是 O'Reilly 的 DNS & Bind ? 有空再查一下好了.)
carelezz 回复于：2004-10-03 08:44:12
Able兄，不客气
我管理单位的DNS服务器，原来认为DNS很简单
看了您的帖子，才知其实大有学问，以后要向您多请教
其实对我触动最大的是您的治学态度
我以后也要沉静下来扎扎实实做些功课
以前太浮躁了
--
abel 回复于：2004-10-04 10:46:28
先感謝 netman 兄解了我一個疑惑 ~
真是太感謝了, timout 時間 5/10/15 倍增我是知道的,
但是 /2 /3 的計算我就沒看過了,但從一些行為來看,您的計算
應是正確的,感恩呀 ~
[quote:0605b8c74f="carelezz"]Able兄，不客气
我管理单位的DNS服务器，原来认为DNS很简单
看了您的帖子，才知其实大有学问，以后要向您多请教
其实对我触动最大的是您的治学态度
我以后也要沉静下来扎扎实实做些功课
以前太浮躁了
--[/quote:0605b8c74f]
carelezz 兄的謬誇弟就不敢接受了,我沒有什麼太大的學問,唯求是所以然
而以, DNS 是弟的本業,理當弄懂全部的觀念才能做好事情,至於其他的東西
就看個人興趣去學習了. 只要學習方法對了,學什麼都可以學得很好,唯花費
的時間可能較多而以(我們在 Mail 版也有交手到一篇,我猜您對那篇中我
指出來的東西可能也會有感觸吧 .. :mrgreen: ).
风往南吹 回复于：2004-10-04 17:35:17
回一贴与技术无关的。
对netman 和 able兄两人的为人真的是非常佩服。
netman态度谦和，能虚心学习。able除了解答别人的疑问外更强调的是教会大家一种学习态度。这些真的是非常值得学习的地方〉
solar 回复于：2004-10-05 08:30:14
很喜欢这种交流学习的方式，忍不住问一个一直没有问的很菜的问题。
举个例子，想申请一个域名。但我没有两个域名服务器，我可以用广东的（我在广东）：202.96.128.143和202.96.128.68吗？或者用其中的一个，我自己再架构一个？
另外，我可以用香港的ip和中国的.cn域名绑定吗？
请回答一下，非常感谢！
风往南吹 回复于：2004-10-05 10:39:06
[quote:470a85e652="solar"]很喜欢这种交流学习的方式，忍不住问一个一直没有问的很菜的问题。
举个例子，想申请一个域名。但我没有两个域名服务器，我可以用广东的（我在广东）：202.96.128.143和202.96.128.68吗？或者用其中的一个，我自?.........[/quote:470a85e652]
1:第一个问题看的不是很懂，说的不清楚。
申请域名时按规定必须要提供2个dns server ip,至于你的dns server是不是在广州是没什么关系的，你甚至可以让其他dns server帮你解析！
2：这个问题你学学dns原理就应该了解了。域名和ip是对应关系，你使用什么域名对应什么ip是没什么关系的。除非是cn域名强制要求使用国内ip，不然不给你注册。
網中人 回复于：2004-10-05 11:19:14
嗯, 先確定你所提交的 server 確實可以幫忙設定貴 domain, 然後再修改註冊主機.
要不然, 你先去找找 lame server 的成因, 或許就知道我講些啥了... ^_^
ehua 回复于：2004-11-03 16:23:32
看得痛快，netman和abel两位老大学问真是没得说。
abel兄应该当仁不让做版主。
phlipzheng 回复于：2004-11-10 15:34:24
陈昌盛老师关于DNS的文章我找不到，这可是able和netman 两位老大推荐的，我想看，可怎么也找不到。论坛中提供的地址也打不开，我该怎么办，求哪位老大帮忙！
echo52 回复于：2005-04-21 20:08:18
google 搜索: 陈昌盛 dns OR 反向解析 filetype:pdf
以下地址验证过,可以下载.不过还是自己搜搜,还有其他的一些东西值得一看
http://www.cert.org.tw/document/docfile/DNS%20survey.pdf
chenqioulin 回复于：2005-04-22 01:28:52
一口起看完！！终于明白学习原来是这样的！！！！
