通过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:45up
不是特别期待中……
haha451 回复于：2004-08-17 15:45:47不是特别地特别期待中。。。
Fun-FreeBSD 回复于：2004-08-18 09:30:15不期待，等待~
網中人 回复于：2004-08-18 16:48:18sorry, 最近在準備兩場演講, 沒太多時間寫這個問題.
請再等幾天...
耽誤大家時間真不好意思!
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
