免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
› 论坛 › IT运维 › 服务器应用 › 反向解析域是怎么授权的
12345678下一页
最近访问板块 发新帖
楼主: Fun-FreeBSD
打印 上一主题 下一主题

[DNS] 反向解析域是怎么授权的 [复制链接]

localking 该用户已被删除
21楼 [报告]
发表于 2004-09-06 09:42 |只看该作者
提示: 作者被禁止或删除 内容自动屏蔽
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
skylove

论坛徽章:
0
22楼 [报告]
发表于 2004-09-06 22:58 |只看该作者

反向解析域是怎么授权的

厉害，netman和abel两位来自台湾的朋友真是出手不凡，相当有大家风范，说起来如数家珍。。。佩服&期待ing
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
網中人

论坛徽章:
1
荣誉版主 日期:2011-11-23 16:44:17
23楼 [报告]
发表于 2004-09-07 01:18 |只看该作者

反向解析域是怎么授权的

不敢不敢...
跟 abel 兄比起來, 小弟只是個剛入門的學生而已啦.
我的確常如此告誡自己的...  ^_^
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
abel

论坛徽章:
1
荣誉会员 日期:2011-11-23 16:44:17
24楼 [报告]
发表于 2004-09-07 20:15 |只看该作者

反向解析域是怎么授权的

本文撰寫於 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) 解出來會有 :

  2. C->;S
  3. S->;Root (.)
  4. Root->;S
  5. S->;com.
  6. com->;S
  7. S->;CU
  8. CU->;S
  9. S->;C
复制代码

共發生 8 次 packet..

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

  2. CU->;S
  3. S->;Root
  4. Root->;S
  5. S->;ARPA
  6. ARPA->;S
  7. S->;in-addr.arpa.
  8. in-addr.arpa.->;S
  9. S->;122.in-addr.arpa.
  10. 122.in-addr.arpa.->;S
  11. S->;136.61.in-addr.arpa.
  12. 136.61.in-addr.arpa.->;S
  13. S->;135.136.61.in-addr.arpa.
  14. 135.136.61.in-addr.arpa.->;S
  15. S->;CU
复制代码

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

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

  2. 61.in-addr.arpa.        172800    IN      SOA     ns1.apnic.net. read-TXT-record-of-zone-first-dns-admin.apnic.net.
  3. 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 取得,並計算出來:

  2. wget http://ftp.apnic.net/stats/apnic/delegated-apnic-latest
  3. (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 有點問題:

  2. #取得 IP (net_id) , 共 731 段,每段IP數量不等
  3. cat delegated-apnic-latest | grep  -i 'CN|ipv4' |cut -f 4 -d'|' >;ipv4_cn
  4. #把 .0 都換成 .1,主要是要 host,用 .0 來查可能會有問?#125;,雖說 .0 都換成 .1 可能不準,但也只存在 /24 的問?#125;才有
  5. replace '.0' '.1' -- ipv4_cn
  6. for ip in `cat ipv4_cn`
  7. do
  8.         echo -e "$ip==>;$(dig -x $ip |  grep 'IN.*NS' | head -1)" >;>;ns_rr_cn
  9. 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:

  2. SIP>; dig in-addr.arpa. ns

  4. ; <<>;>; DiG 9.2.3 <<>;>; in-addr.arpa. ns
  5. ;; global options:  printcmd
  6. ;; Got answer:
  7. ;; ->;>;HEADER<<- opcode: QUERY, status: NOERROR, id: 48366
  8. ;; flags: qr rd ra; QUERY: 1, ANSWER: 12, AUTHORITY: 0, ADDITIONAL: 1

  10. ;; QUESTION SECTION:
  11. ;in-addr.arpa.                  IN      NS

  13. ;; ANSWER SECTION:
  14. in-addr.arpa.           86400   IN      NS      L.ROOT-SERVERS.NET.
  15. in-addr.arpa.           86400   IN      NS      M.ROOT-SERVERS.NET.
  16. in-addr.arpa.           86400   IN      NS      A.ROOT-SERVERS.NET.
  17. in-addr.arpa.           86400   IN      NS      B.ROOT-SERVERS.NET.
  18. in-addr.arpa.           86400   IN      NS      C.ROOT-SERVERS.NET.
  19. in-addr.arpa.           86400   IN      NS      D.ROOT-SERVERS.NET.
  20. in-addr.arpa.           86400   IN      NS      E.ROOT-SERVERS.NET.
  21. in-addr.arpa.           86400   IN      NS      F.ROOT-SERVERS.NET.
  22. in-addr.arpa.           86400   IN      NS      G.ROOT-SERVERS.NET.
  23. in-addr.arpa.           86400   IN      NS      H.ROOT-SERVERS.NET.
  24. in-addr.arpa.           86400   IN      NS      I.ROOT-SERVERS.NET.
  25. in-addr.arpa.           86400   IN      NS      K.ROOT-SERVERS.NET.

  27. ;; ADDITIONAL SECTION:
  28. M.ROOT-SERVERS.NET.     58742   IN      A       202.12.27.33

  30. ;; Query time: 14 msec
  31. ;; SERVER: 211.72.210.250#53(211.72.210.250)
  32. ;; WHEN: Tue Sep  7 13:16:06 2004
  33. ;; MSG SIZE  rcvd: 254
复制代码


並且 DNS 是隨機選一部來查,所以我們要查 162.105.x.x 就隨便選一部,但是
先從 IP 的第一碼查起:

  2. SIP>; dig @L.ROOT-SERVERS.NET. 162.in-addr.arpa. ns

  4. ; <<>;>; DiG 9.2.3 <<>;>; @202.12.27.33 162.in-addr.arpa. ns
  5. ;; global options:  printcmd
  6. ;; Got answer:
  7. ;; ->;>;HEADER<<- opcode: QUERY, status: NOERROR, id: 58133
  8. ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 0

  10. ;; QUESTION SECTION:
  11. ;162.in-addr.arpa.              IN      NS

  13. ;; AUTHORITY SECTION:
  14. 162.in-addr.arpa.       86400   IN      NS      chia.ARIN.NET.
  15. 162.in-addr.arpa.       86400   IN      NS      dill.ARIN.NET.
  16. 162.in-addr.arpa.       86400   IN      NS      BASIL.ARIN.NET.
  17. 162.in-addr.arpa.       86400   IN      NS      henna.ARIN.NET.
  18. 162.in-addr.arpa.       86400   IN      NS      indigo.ARIN.NET.
  19. 162.in-addr.arpa.       86400   IN      NS      epazote.ARIN.NET.
  20. 162.in-addr.arpa.       86400   IN      NS      figwort.ARIN.NET.

  22. ;; Query time: 385 msec
  23. ;; SERVER: 202.12.27.33#53(202.12.27.33)
  24. ;; WHEN: Tue Sep  7 13:16:21 2004
  25. ;; MSG SIZE  rcvd: 185
复制代码


再來這一步,我們還是查 162,驗證上層與下層的 NS RRs 是否一致,不一致我們
通常會稱為 Lame Server,這會造成解析上的問題:

  2. SIP>; dig @chia.arin.net 162.in-addr.arpa. ns

  4. ; <<>;>; DiG 9.2.3 <<>;>; @chia.arin.net 162.in-addr.arpa. ns
  5. ;; global options:  printcmd
  6. ;; Got answer:
  7. ;; ->;>;HEADER<<- opcode: QUERY, status: NOERROR, id: 30464
  8. ;; flags: qr aa rd; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 8

  10. ;; QUESTION SECTION:
  11. ;162.in-addr.arpa.              IN      NS

  13. ;; ANSWER SECTION:
  14. 162.in-addr.arpa.       86400   IN      NS      figwort.arin.net.
  15. 162.in-addr.arpa.       86400   IN      NS      chia.arin.net.
  16. 162.in-addr.arpa.       86400   IN      NS      dill.arin.net.
  17. 162.in-addr.arpa.       86400   IN      NS      basil.arin.net.
  18. 162.in-addr.arpa.       86400   IN      NS      henna.arin.net.
  19. 162.in-addr.arpa.       86400   IN      NS      indigo.arin.net.
  20. 162.in-addr.arpa.       86400   IN      NS      epazote.arin.net.

  22. ;; ADDITIONAL SECTION:
  23. chia.arin.net.          10800   IN      A       192.5.6.32
  24. chia.arin.net.          10800   IN      AAAA    2001:440:2000:1::21
  25. dill.arin.net.          10800   IN      A       192.35.51.32
  26. basil.arin.net.         10800   IN      A       192.55.83.32
  27. henna.arin.net.         10800   IN      A       192.26.92.32
  28. indigo.arin.net.        10800   IN      A       192.31.80.32
  29. epazote.arin.net.       10800   IN      A       192.41.162.32
  30. figwort.arin.net.       10800   IN      A       192.42.93.32

  32. ;; Query time: 227 msec
  33. ;; SERVER: 192.5.6.32#53(chia.arin.net)
  34. ;; WHEN: Tue Sep  7 13:16:43 2004
  35. ;; MSG SIZE  rcvd: 325
复制代码

由此可知,上下是一致的,也就是在 in-addr.arpa 中將 162 指向了七部 NS,這
七部 NS 都有設立起來,且七部的名稱與上層的名稱皆完全正確的對應,至於 AAAA
這是IPv6 的記錄,想來是這部主機同時有 IPv4/IPv6 位址.

再來,我們從 chia.arin.net 看,162.105.x.x 分配給北大使用的情形,得到下列結果:

  2. SIP>; dig @chia.arin.net 105.162.in-addr.arpa. ns

  4. ; <<>;>; DiG 9.2.3 <<>;>; @chia.arin.net 105.162.in-addr.arpa. ns
  5. ;; global options:  printcmd
  6. ;; Got answer:
  7. ;; ->;>;HEADER<<- opcode: QUERY, status: NOERROR, id: 8873
  8. ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0

  10. ;; QUESTION SECTION:
  11. ;105.162.in-addr.arpa.          IN      NS

  13. ;; AUTHORITY SECTION:
  14. 105.162.in-addr.arpa.   86400   IN      NS      sun1000e.pku.edu.cn.
  15. 105.162.in-addr.arpa.   86400   IN      NS      ns.pku.edu.cn.
  16. 105.162.in-addr.arpa.   86400   IN      NS      pkuns.pku.edu.cn.

  18. ;; Query time: 225 msec
  19. ;; SERVER: 192.5.6.32#53(chia.arin.net)
  20. ;; WHEN: Tue Sep  7 13:17:31 2004
  21. ;; MSG SIZE  rcvd: 108
复制代码

這代表著由 162 下長出來的 105 (162.105.x.x) 基本上都由北大管理,那北大這三部
NS 呢,不知是什麼樣的情形 ?

所以我們就查詢北大這三部 NS ,看看有什麼狀況:

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

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

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

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

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

  4. ; <<>;>; DiG 9.2.3 <<>;>; @ns.pku.edu.cn 105.162.in-addr.arpa. ns
  5. ;; global options:  printcmd
  6. ;; Got answer:
  7. ;; ->;>;HEADER<<- opcode: QUERY, status: NOERROR, id: 45872
  8. ;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3

  10. ;; QUESTION SECTION:
  11. ;105.162.in-addr.arpa.          IN      NS

  13. ;; ANSWER SECTION:
  14. 105.162.in-addr.arpa.   86400   IN      NS      ns.PKU.EDU.CN.
  15. 105.162.in-addr.arpa.   86400   IN      NS      dns.EDU.CN.
  16. 105.162.in-addr.arpa.   86400   IN      NS      ns2.cuhk.hk.
  17. 105.162.in-addr.arpa.   86400   IN      NS      pkuns.PKU.EDU.CN.
  18. 105.162.in-addr.arpa.   86400   IN      NS      sun1000e.PKU.EDU.CN.

  20. ;; ADDITIONAL SECTION:
  21. ns.PKU.EDU.CN.          86400   IN      A       202.112.7.13
  22. pkuns.PKU.EDU.CN.       86400   IN      A       162.105.129.27
  23. sun1000e.PKU.EDU.CN.    86400   IN      A       162.105.129.26

  25. ;; Query time: 523 msec
  26. ;; SERVER: 202.112.7.13#53(ns.pku.edu.cn)
  27. ;; WHEN: Tue Sep  7 13:18:16 2004
  28. ;; MSG SIZE  rcvd: 199
复制代码

哦耶~有回應耶...不過為什麼是五部...162.in-addr.arpa. 上層不是說有三部管
162.105.x.x 嗎? 你(ns.pku.edu.tw) 又說有五部,我要相信誰 !? 誰告訴我你們
那個說的是真的 >;<"

算了,我們看 162.in-addr.arpa. 上講的第三部好了:

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

  4. ; <<>;>; DiG 9.2.3 <<>;>; @pkuns.pku.edu.cn 105.162.in-addr.arpa. ns
  5. ;; global options:  printcmd
  6. ;; 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. 你說假話!

再來看最後一個希望:

  2. SIP>; dig @ns2.cuhk.hk. 105.162.in-addr.arpa. ns

  4. ; <<>;>; DiG 9.2.3 <<>;>; @ns2.cuhk.hk. 105.162.in-addr.arpa. ns
  5. ;; global options:  printcmd
  6. ;; Got answer:
  7. ;; ->;>;HEADER<<- opcode: QUERY, status: NOERROR, id: 31411
  8. ;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 5

  10. ;; QUESTION SECTION:
  11. ;105.162.in-addr.arpa.          IN      NS

  13. ;; ANSWER SECTION:
  14. 105.162.in-addr.arpa.   86400   IN      NS      pkuns.PKU.EDU.CN.
  15. 105.162.in-addr.arpa.   86400   IN      NS      sun1000e.PKU.EDU.CN.
  16. 105.162.in-addr.arpa.   86400   IN      NS      ns.PKU.EDU.CN.
  17. 105.162.in-addr.arpa.   86400   IN      NS      dns.EDU.CN.
  18. 105.162.in-addr.arpa.   86400   IN      NS      ns2.cuhk.hk.

  20. ;; ADDITIONAL SECTION:
  21. pkuns.PKU.EDU.CN.       86400   IN      A       162.105.129.27
  22. sun1000e.PKU.EDU.CN.    86400   IN      A       162.105.129.26
  23. ns.PKU.EDU.CN.          86400   IN      A       202.112.7.13
  24. dns.EDU.CN.             172800  IN      A       202.112.0.35
  25. ns2.cuhk.hk.            86400   IN      A       137.189.6.21

  27. ;; Query time: 64 msec
  28. ;; SERVER: 137.189.6.21#53(ns2.cuhk.hk.)
  29. ;; WHEN: Tue Sep  7 13:46:36 2004
  30. ;; MSG SIZE  rcvd: 231
复制代码

還好,有了答案了,看來 ns2.cuhk.hk 代管的 domain 還真不少, TTL 都不會減少,
過程中共有五部 NS,只有兩部正確 Work (這兩部有一部不在上層出現),有二部不能
連,有一部不管這個反解的 zone , 就通算你 2/5 可解吧!

以上有些部份後面我們還會看到,但是從這個例子來看,105.162.in-addr.arpa. 的反解有
N 個問題,如果連 pku 都這樣...


另一個重點,就是非 edu/ac doamin 部份,

  2. #我們只要 NS 記錄,並且把 edu.cn/ac.cn 去掉,來看看最多人使用的 ISP 狀況
  3. SIP>;cat ns_rr_tw | grep NS|grep -Eiv 'edu.cn|ac.cn'
  4. 161.207.1.1==>;207.161.in-addr.arpa. 85037 IN NS dns2.cnpc.com.cn.
  5. 202.1.176.1==>;176.1.202.in-addr.arpa. 20252 IN NS pijin.com.sb.
  6. 202.3.77.1==>;77.3.202.in-addr.arpa. 51124 IN NS ns2.yahoo.com.
  7. 202.38.184.1==>;1.184.38.202.in-addr.arpa. 85052 IN PTR ANS.CERNET.NET.
  8. 202.93.1.1==>;1.93.202.in-addr.arpa. 51113 IN NS netmgr.cninfo.com.cn.
  9. 202.96.136.1==>;136.96.202.in-addr.arpa. 85067 IN NS dns.guangzhou.gd.cn.
  10. 202.97.8.1==>;8.97.202.in-addr.arpa. 85067 IN NS ns1.cn.net.
  11. 202.97.16.1==>;16.97.202.in-addr.arpa. 85066 IN NS ns1.cn.net.
  12. 202.99.64.1==>;64.99.202.in-addr.arpa. 62844 IN NS ns.tpt.net.cn.
  13. 202.100.112.1==>;112.100.202.in-addr.arpa. 85086 IN NS euro2000.yc.nx.cn.
  14. 202.100.200.1==>;200.100.202.in-addr.arpa. 85094 IN NS ns.hihkptt.net.cn.
  15. 202.100.208.1==>;208.100.202.in-addr.arpa. 85093 IN NS ns.hisyptt.net.cn.
  16. 202.101.96.1==>;96.101.202.in-addr.arpa. 85093 IN NS dns.fz.fj.cn.
  17. 202.102.128.1==>;128.102.202.in-addr.arpa. 5908 IN NS ns.spt.net.cn.
  18. 202.103.224.1==>;224.103.202.in-addr.arpa. 9511 IN NS ns.lzptt.gx.cn.
  19. 202.130.224.1==>;224.130.202.in-addr.arpa. 34811 IN NS ns2.east.net.cn.
  20. 202.165.96.1==>;96.165.202.in-addr.arpa. 51258 IN NS ns3.yahoo.com.
  21. 203.81.16.1==>;16.81.203.in-addr.arpa. 85212 IN NS ns1.net-infinity.net.
  22. 203.93.16.1==>;16.93.203.in-addr.arpa. 600 IN NS ns.gb.com.cn.
  23. 210.21.1.1==>;1.21.210.in-addr.arpa. 85225 IN NS gz1-dns.gdgz.cncnet.net.
  24. 211.101.128.1==>;128.101.211.in-addr.arpa. 42074 IN NS ns.capitalnet.com.cn.
  25. 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 也是要注意之處 !

  2. 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 所寄來的三封主題回覆通知:

  2. Received: from chinaunix ([61.135.136.123])
  3.         by domain (8.13.1/8.13.1) with SMTP id i83BNOBs031000
  4.         for <my_email@domain>;; Fri, 3 Sep 2004 19:23:26 +0800
  5. Received: (qmail 29635 invoked by uid 80); 3 Sep 2004 11:23:12 -0000

  7. Received: from chinaunix ([61.135.136.123])
  8.         by domain (8.13.1/8.13.1) with SMTP id i83BcPXZ012844
  9.         for <my_email@domain>;; Fri, 3 Sep 2004 19:38:27 +0800
  10. Received: (qmail 30479 invoked by uid 80); 3 Sep 2004 11:38:12 -0000

  12. Received: from chinaunix ([61.135.136.123])
  13.         by domain (8.13.1/8.13.1) with SMTP id i83HY8iR013736
  14.         for <my_email@domain>;; Sat, 4 Sep 2004 01:34:10 +0800
  15. Received: (qmail 48488 invoked by uid 80); 3 Sep 2004 17:33:55 -0000
复制代码


你會發現, Received 欄位,在我收到時,和 CU 發出時,差了約 14~15 秒,這中間主要即是因為沒
有反解所致,同時我找了一個有反解的,同樣用 qmail 的 sample 如下:

  2. Received: from dragon.xxx.net (dragon.xxx.net [202.145.xxx.193])
  3.         by mydomain (8.13.1/8.13.1) with SMTP id i828lXoU006975
  4.         for <my_email@mydomain>;; Thu, 2 Sep 2004 16:47:33 +0800
  5. Received: (qmail 22562 invoked from network); 2 Sep 2004 08:47:30 -0000
  6. Received: from gate.noc.xxx.net (HELO jj) ([202.145.xxx.34]) (envelope-sender <xxx@ttn.xxx.tw>;)
  7.           by 0 (qmail-ldap-1.03) with SMTP
  8.           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 為單位是很簡單的,和正解的思考
是一樣的,

  2. $TTL=86400
  3. $ORIGIN 105.162.in-addr.arpa.
  4. 105.162.in-addr.arpa.   86400   IN      SOA     ns.PKU.EDU.CN. hostmaster.PKU.EDU.CN.
  5. (2004090602
  6. 3600
  7. 900
  8. 604800
  9. 86400)

  11.         IN      NS      dns.EDU.CN.
  12.         IN      NS      ns2.cuhk.hk.
  13.         IN      NS      pkuns.PKU.EDU.CN.
  14.         IN      NS      sun1000e.PKU.EDU.CN.
  15.         IN      NS      ns.PKU.EDU.CN.

  17. 0        IN        NS        ns1.cc.pku.edu.cn.
  18. 0        IN        NS        ns1.cc.pku.edu.cn.
  19. 1        IN        NS        ns1.ee.pku.edu.cn.
  20. 1        IN        NS        ns1.ee.pku.edu.cn.
  21. 2        IN        NS        ns1.gg.pku.edu.cn.
  22. 2        IN        NS        ns1.gg.pku.edu.cn.
  23. ...
复制代码


5.1 滿一個 Class C

所以,可以讓 cc 一個系所有一個 Class C (255 個 IP) 的授權,此時 cc 系在架 DNS 時就要有兩部

  2. $TTL=86400
  3. 0.105.162.in-addr.arpa.   86400   IN      SOA     ns1.cc.PKU.EDU.CN. hostmaster.PKU.EDU.CN.
  4. (2004090602
  5. 3600
  6. 900
  7. 604800
  8. 86400)
  9.         IN        NS        ns1.cc.pku.edu.cn.
  10.         IN        NS        ns2.cc.pku.edu.cn.
  11. $ORIGIN 0.105.162.in-addr.arpa.
  12. 1        IN        PTR        ns1.cc.pku.edu.cn.
  13. 2        IN        PTR        ns2.cc.pku.edu.cn.
  14. 3        IN        PTR        pc3.cc.pku.edu.cn.
  15. ...
  16. 254        IN        PTR        pc254.cc.pku.edu.cn.
复制代码

目前為止我相信各位都能體會,如果不能體會請先將正解弄熟,弄懂,你就會了解.

上面這樣的設法,基本上可能對管理這部主機的人而言太重覆,所以 BIND 9 時就加了一個
$GENERATE 的功能變數

  2. ;SOA NS 如上例
  3. $ORIGIN 0.105.162.in-addr.arpa.
  4. $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
再授權下去,但這也是最不經濟的方法:

  2. $TTL=86400
  3. 0.105.162.in-addr.arpa.   86400   IN      SOA     ns1.cc.PKU.EDU.CN. hostmaster.cc.PKU.EDU.CN.
  4. (2004090602
  5. 3600
  6. 900
  7. 604800
  8. 86400)
  9. $ORIGIN 0.105.162.in-addr.arpa.
  10.         IN        NS        ns1.cc.pku.edu.cn.
  11.         IN        NS        ns2.cc.pku.edu.cn.
  12. $GENERATE 3-63    $ PTR pc$.cc.pku.edu.cn.
  13. $GENERATE 64-95   $ NS ns1.unit2.cc.pku.edu.cn.
  14. $GENERATE 64-95   $ NS ns2.unit2.cc.pku.edu.cn.
  15. $GENERATE 96-127  $ NS ns1.unit3.cc.pku.edu.cn.
  16. $GENERATE 96-127  $ NS ns2.unit3.cc.pku.edu.cn.
  17. $GENERATE 128-254 $ NS ns1.unit4.cc.pku.edu.cn.
  18. $GENERATE 128-254 $ NS ns2.unit4.cc.pku.edu.cn.
复制代码


$GENERATE 功能自己多體會就可以很快上手了,而這個時候, ns1.unit2.cc.pku.edu.cn 就得要
把 zone 建出來了,這個 zone 要寫滿整個 IP,

  2. #/etc/named.conf 中的內容
  3. ....
  4. zone "64.0.105.162.in-addr.arpa" {type master;file "64.ggyy_ip_zone";};
  5. zone "65.0.105.162.in-addr.arpa" {type master;file "65.ggyy_ip_zone";};
  6. zone "66.0.105.162.in-addr.arpa" {type master;file "66.ggyy_ip_zone";};
  7. zone "67.0.105.162.in-addr.arpa" {type master;file "67.ggyy_ip_zone";};
  8. ....
复制代码

然後那個 zone file 內都只有一行 PTR 資料,因為是將 IP (4 octets) 指了過來:


  2. $TTL=86400
  3. @ 86400 IN  SOA ns1.unit2.cc.PKU.EDU.CN. hostmaster.unit2.cc.PKU.EDU.CN.
  4. (2004090602
  5. 3600
  6. 900
  7. 604800
  8. 86400)
  9.         IN        NS        ns1.cc.pku.edu.cn.
  10.         IN        NS        ns2.cc.pku.edu.cn.
  11. @        IN        PTR        pc64.unit2.cc.pku.edu.cn.
复制代码

那不就瘋了~拿到 128 個 IP 要設 128 次 zone , 及建 128 個 zone file ..
的確是這樣,如果有 128 個 IP 他也甘願,且這種方法還有不少人用.而很多人在
這種情況下,會不明所以,反而設成一個 C (255 個 IP ) 的反解:

  2. #ns1 of unit4 在 /etc/named.conf 中寫
  3. 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 去接是會出錯的(想想,你有一個 domainxx.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


  2. ;在 ns1.cc.pku.edu.cn 上的 0.105.162.in-addr.arpa
  3. $TTL=86400
  4. 0.105.162.in-addr.arpa.   86400   IN      SOA     ns1.cc.PKU.EDU.CN. hostmaster.cc.PKU.EDU.CN.
  5. (2004090602
  6. 3600
  7. 900
  8. 604800
  9. 86400)
  10. $ORIGIN 0.105.162.in-addr.arpa.
  11.         IN        NS        ns1.cc.pku.edu.cn.
  12.         IN        NS        ns2.cc.pku.edu.cn.
  13. $GENERATE 3-63    $ PTR pc$.cc.pku.edu.cn.
  14. $GENERATE 64-95   $ CNAME pc$.unit2.cc.pku.edu.cn.
  15. $GENERATE 96-127  $ CNAME pc$.unit3.cc.pku.edu.cn.
  16. $GENERATE 128-254 $ CNAME pc$.unit4.cc.pku.edu.cn.

复制代码

以上請您先充份理解 $GENERATE 的功能,要到用看的也看的出來的程度,且不用寫
兩次(原來寫兩次是因為一個 domain 一定要有兩部以上的 NameServer),因為全部
都會轉到正解檔去


  2. ;$GENERATE 128-254 $ CNAME pc$.unit4.cc.pku.edu.cn. 的擴展
  3. 128        IN        CNAME        pc128.unit4.cc.pku.edu.cn.
  4. 129        IN        CNAME        pc129.unit4.cc.pku.edu.cn.
  5. 130        IN        CNAME        pc130.unit4.cc.pku.edu.cn.
  6. 131        IN        CNAME        pc131.unit4.cc.pku.edu.cn.
  7. ...
  8. 254        IN        CNAME        pc254.unit4.cc.pku.edu.cn.
复制代码

這裏一定有人犯疑,反解檔可以用 CNAME 嗎 ? 誰說不行的呀,就像 MX 可不可以是接 IP
一樣,正解檔裏也是可以放 PTR 的,重點只在,他們都是 DNS 的 zone,正解/反解 只是人
們區分上的差別而以:


  2. ;原來 unit4.cc.pku.edu.tw zone,NS SOA 等不列
  3. $ORIGIN unit4.cc.pku.edu.tw.
  4. @        IN        MX        mail
  5. mail        IN        A        162.105.0.143
  6. www        IN        A        162.105.0.133
  7. ....
  8. ;以下補上
  9. $GENERATE 128-254 pc$        PTR        pc$
复制代码

好了,這樣就可以了,當你 dig -x 162.105.0.143 時,就會出現解到 CNAME (參閱上面),
換到 CNAME 後會查原來的 FQDN,就會找到 pc143.unit4.cc.pku.edu.cn.
用 $GENERATE 只是適用有規則的變化,在本例中,一般會建議你依順序排列,以便日後管理:

  2. www        IN        A        162.105.0.133
  3. pc133        IN        PTR        www
  4. ;...134,135....
  5. mail        IN        A        162.105.0.143
  6. pc143        IN        PTR        mail
  7. ;...
复制代码


所以 pc133 等這種名稱,純粹就會變成一種 "接取" 的狀況,主要是要 "串連" 起來.
實例:

  2. [root@twnic joanna]# dig @168.95.1.1 -x 210.17.9.228

  4. ; <<>;>; DiG 9.2.1 <<>;>; @168.95.1.1 -x 210.17.9.228
  5. ;; global options:  printcmd
  6. ;; Got answer:
  7. ;; ->;>;HEADER<<- opcode: QUERY, status: NOERROR, id: 55880
  8. ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2

  10. ;; QUESTION SECTION: 找 PTR
  11. ;228.9.17.210.in-addr.arpa.     IN      PTR

  13. ;; ANSWER SECTION: 找到 CNAME, 再對應成 PTR
  14. 228.9.17.210.in-addr.arpa. 3600 IN      CNAME   228.sub224-255.9.17.210.in-addr.arpa.
  15. arpa.
  16. 228.sub224-255.9.17.210.in-addr.arpa. 77747 IN PTR www.twnic.net.tw.

复制代码


syslog 中會出現像(有的 OS 版本不會出現):

  2. Sep 6 10:40:11 SIP syslog: gethostby*.getanswer: asked for "228.9.17.210.in-addr.arpa IN PTR" , got type "CNAME"
  3. 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 這種東西若你以為用看的就全看的懂表示你太看輕它了.
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
abel

论坛徽章:
1
荣誉会员 日期:2011-11-23 16:44:17
25楼 [报告]
发表于 2004-09-07 20:25 |只看该作者

反向解析域是怎么授权的

原帖由 "網中人" 发表：
不敢不敢...
跟 abel 兄比起來, 小弟只是個剛入門的學生而已啦.
我的確常如此告誡自己的...  ^_^

  netman 兄您過獎了...在 DNS 這個領域我只是有比您好的
環境而以,技術面的東西是可以訓練的,但您悔人不倦的情操才是我要看
齊之處(不過實在很難做到...)
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
網中人

论坛徽章:
1
荣誉版主 日期:2011-11-23 16:44:17
26楼 [报告]
发表于 2004-09-08 07:40 |只看该作者

反向解析域是怎么授权的

abel 兄寫得真好! 給您拍拍手...

不過, 想向您請教一個觀念:
DNS 查詢時不會自動切到第二部,選到 sun1000e ,沒有查到不會自動Switch 到第二部的
是否意味著: 就算 time out , resolver 也不會以 round robin 的方式選下一台 server 呢?

若此假設成立的話,
那麼, 以一個註冊了兩台 ns 的 domain 來說,
若其中一台掛掉了, 那其結果就是 50% 查詢失敗了?
也就是以單一的一個 application session 而言, 有一半機會是無法建立的.
然後到下一次 retry (不是 resolver 的 retry, 而是 application 的),
再來賭一次運氣?

因為這個觀念小弟一直很模糊, 趁此機會跟大哥請益...  ^_^
感謝再三!
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
abel

论坛徽章:
1
荣誉会员 日期:2011-11-23 16:44:17
27楼 [报告]
发表于 2004-09-08 08:17 |只看该作者

反向解析域是怎么授权的

不過, 想向您請教一個觀念:
DNS 查詢時不會自動切到第二部,選到 sun1000e ,沒有查到不會自動Switch 到第二部的
是否意味著: 就算 time out , resolver 也不會以 round robin 的方式選下一台 server 呢?

是的,一般的情況確實是如此,所以一般人只考慮設了後有沒有 work,
而沒有注意錯誤的設定帶來的負擔可能更大 (Lame Server,NS 亂設...)


若此假設成立的話,
那麼, 以一個註冊了兩台 ns 的 domain 來說,
若其中一台掛掉了, 那其結果就是 50% 查詢失敗了?

如同前面,在 Resolver 預設不啟動 default domain/search 的狀況下是
這樣(啟動也不見得會對)

也就是以單一的一個 application session 而言, 有一半機會是無法建立的.
然後到下一次 retry (不是 resolver 的 retry, 而是 application 的),
再來賭一次運氣?

拿 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 的檢查中
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
網中人

论坛徽章:
1
荣誉版主 日期:2011-11-23 16:44:17
28楼 [报告]
发表于 2004-09-08 12:24 |只看该作者

反向解析域是怎么授权的

感謝感謝!

看來我之前的理解太過單純了, 我還以為 resolver 會做 retry 的動作呢...
原來這個 retry 是 application 決定的.
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
abel

论坛徽章:
1
荣誉会员 日期:2011-11-23 16:44:17
29楼 [报告]
发表于 2004-09-08 12:33 |只看该作者

反向解析域是怎么授权的

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 中
您會發現更多的說明(雖然這是程式用的東西,但他有很多註解說明)
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
網中人

论坛徽章:
1
荣誉版主 日期:2011-11-23 16:44:17
30楼 [报告]
发表于 2004-09-08 14:10 |只看该作者

反向解析域是怎么授权的

okay, 感謝!  ^_^

每次都能跟大哥學習新知, 真是太高興了!
实战分享：从技术角度谈机器学习入门| 【大话IT】RadonDB低门槛向MySQL集群下战书 | ChinaUnix打赏功能已上线！ | 新一代分布式关系型数据库RadonDB知多少？
12345678下一页
返回列表 发新帖
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号：11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们：huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP