关于DNS的一篇好文章

天狼晓月

关于DNS的一篇好文章
发表时间：2007-4-15 12:35:29

本文撰写於 www.chinaunix.com ,撰写人为:
netman/abel
欢迎任意转载,转载时请注明出处
除错别字外(哈~这个我常发生),勿对本文加油添醋

主题:反向解析域是怎么授权的 (http://bbs.chinaunix.net/forum/16/20040812/385903.html)
——————————————————————-
正文开始,文接 netman 那篇
建议您在看前,对 DNS 解析流程及授权有一定的概念,並巳充份了解正解的状况

1.前言
首先, 我上次问过大家一个问题:
— 在 internet 上是正解查询多还是反解查询多?
若你有朋友在 NIC 或 ISP 内管 dns 的话, 应该不难问出答案:
—> 反解多!

那, 你或许会问: why?
嗯, 先回看我前面提到的:

— DNS 只负责解释, 至於解释出来的结果如何用? 那就不是 DNS 要担心的.
那接下来, 谁要操这份心呢?
简单来说, 就是那些使用到 dns 的程式了…
那再下来, 有哪些程式呢?
简单来说: 分 client 与 server 两类程式就够了.
然後, 只要你能统计出在 dns 查询中, 究竟是 client 多还是 server 多? 就立见分晓了….
答案是: server 居多!

2.为什麽反解多 ?

2.1 发生次数多
不用怀疑, 假设以一封 email 的递送来跑一下流程就知道了:
1) client 查 smtp 的正解
2) smtp server 查 client 的反解
3) smtp server 查目标 server 的正解
4) 目标 server 查 smtp server 的反解
是的, 我们可以肯定 srever 查的多是没错, 但正解与反解不是相等的吗?
呵, 那你就有所不知了…
因为, 除了 smtp 连线要查 dns 之外, 事实上, 还有很多地方要查 dns 的,
这得看各 server 的配置而定, 很难有个”统一”的答案…
比方说, smtp server 设了 super daemon, 要做 syslog, 还会交给 tcpwrapper…
然後 smtp daemon 还会查 relay db, rbl, … 诸如此类的…
还有, 若 dns server 本身有起用一些 log facility , 那事实上, 每一次被查都会再查一次 resolver 端的反解…
所有上述这些, 都只是一些例子, 还不是全部哦~~~
然而, 我们可以肯定的是:
上面那些服务, 大都是查反解的!
因此, 你不难算一算一个单一的 email 递送过程中, 会触发多少个 dns 查询? 及其中的正反解的比例?
最简单的罗辑是:
有一个正解需求的连线发生後, 通常就会引起一个反解, 但更多时候会引起更多的反解!

2.2 递归次数多
正解查询,大家都想求正确,求快,求稳定,那为什麽反解不用呢 !?
因为你感受不明显!但 server 可明显了,网路的 traffic 也会受影响.

我们先看 CU 为例:
www.chinaunix.com.
61.135.136.122==>122.135.136.61.in-addr.arpa.

若 CU 的 IP 有设反解, 正解在没有 Cache 因素干扰下,从 Client (C) 到
DNS Server (S) 解出来会有 :

代码:

C->S
S->Root (.)
Root->S
S->com.
com->S
S->CU
CU->S
S->C

共发生 8 次 packet..

你去访问 CU 时,若 CU 的 Web Log 有开 Lookup IP 的功能(一般是不会开
的,但你跑 awstats 还是要查一次,有开的没反解再查一次),

代码:

CU->S
S->Root
Root->S
S->ARPA
ARPA->S
S->in-addr.arpa.
in-addr.arpa.->S
S->122.in-addr.arpa.
122.in-addr.arpa.->S
S->136.61.in-addr.arpa.
136.61.in-addr.arpa.->S
S->135.136.61.in-addr.arpa.
135.136.61.in-addr.arpa.->S
S->CU

发生 12 次
(domain 愈长查愈多次不是吗 !? )

很可惜, CU 的 IP 没有反解,最後只到 122.in-addr.arpa. 而以,所以查询只到
这裏而以,那也发生了8次呀.再来看,正解会 Cache,被 (S) Cache 6 小时,那反解
呢 ? 跟本是失败的呀…抱歉,多数的 DNS 在发生时会再查一次,少数的 DNS 会做
negative cache (ncache),若有做 ncache,算你幸运,那 apnic 把这个值设成两天,
但这只是少数而以.

代码:

61.in-addr.arpa. 172800 IN SOA ns1.apnic.net. read-TXT-record-of-zone-first-dns-admin.apnic.net.
2004081901 7200 1800 604800 172800

註:ncache 会看 SOA 第五个数字,在 bind 8 叫 min TTL,bind 9 叫 ncache TTL,
ncache 发生时(就是 DNS 知道找不到答案),会和此值和 SOA 的 TTL 值谁高而定,
但是你的 DNS Server 有 ncache 功能吗 !? (这个议题这裏就不论述了,会受太多
因素影响)

好了,现在我们知道,不仅发生频率反解多,Recusion 也是反解多,为什麽你要浪费
这麽多的 Traffic 呢 !? 更有意思的是….如果全中国上千万个 IP 可解的不到
3%,那又是一个什麽样的情况呢 !? 反解真正的含义是什麽呢!? 为什麽台湾可
以到 50% 左右的反解率呢 !?

3. 中国有多少个 IP ? 反解情况如何 ?
这个数字你可以从 APNIC 取得,並计算出来:

代码:

wget http://ftp.apnic.net/stats/apnic/delegated-apnic-latest
(cat delegated-apnic-latest | grep -i ‘CN|ipv4′ |cut -f 5 -d’|’ | tr ‘n’ ‘+’;echo 0) | bc

Ans:54449664 (2004/09/04)
我自己叁年前曾做过这样的测试,将中国的所有 IP 都查一次反解,实际的总数巳不
记得了,但记得结果是 2%,所以,我们先来推论现况,但是这边我们还是可以来做一个
简单的实验:

上一篇发现一些小错误,以下做了一些调整,以求得更正确的值,原来的 script 有点问题:

代码:

#取得 IP (net_id) , 共 731 段,每段IP数量不等
cat delegated-apnic-latest | grep -i ‘CN|ipv4′ |cut -f 4 -d’|’ >ipv4_cn
#把 .0 都换成 .1,主要是要 host,用 .0 来查可能会有问?#125;,虽说 .0 都换成 .1 可能不準,但也只存在 /24 的问?#125;才有
replace ‘.0′ ‘.1′ — ipv4_cn
for ip in `cat ipv4_cn`
do
echo -e “$ip==>$(dig -x $ip | grep ‘IN.*NS’ | head -1)” >>ns_rr_cn
done

这个答案是 72 笔,约为1/10 ,依照约数,中国的反解率最多仅为 10%,如果这其中並
没有设错的或少设的,随意举个 “北大,pku.edu.cn” 的例子好了(第一个就挑中好
sample,这个 sample 我们後面再讲授权时还会用到,请务必理解):
北大的 IP 是 162.105.x.x,我们先来看看授权(NS delegation) 及解析情形如何:

IP 在反查时,一定会先到 in-addr.arpa. 我想这是很平常的观念,所以我们查询
in-addr.arpa 有那些 NameServer:

代码:

SIP> dig in-addr.arpa. ns

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

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

;; ANSWER SECTION:
in-addr.arpa. 86400 IN NS L.ROOT-SERVERS.NET.
in-addr.arpa. 86400 IN NS M.ROOT-SERVERS.NET.
in-addr.arpa. 86400 IN NS A.ROOT-SERVERS.NET.
in-addr.arpa. 86400 IN NS B.ROOT-SERVERS.NET.
in-addr.arpa. 86400 IN NS C.ROOT-SERVERS.NET.
in-addr.arpa. 86400 IN NS D.ROOT-SERVERS.NET.
in-addr.arpa. 86400 IN NS E.ROOT-SERVERS.NET.
in-addr.arpa. 86400 IN NS F.ROOT-SERVERS.NET.
in-addr.arpa. 86400 IN NS G.ROOT-SERVERS.NET.
in-addr.arpa. 86400 IN NS H.ROOT-SERVERS.NET.
in-addr.arpa. 86400 IN NS I.ROOT-SERVERS.NET.
in-addr.arpa. 86400 IN NS K.ROOT-SERVERS.NET.

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

;; Query time: 14 msec
;; SERVER: 211.72.210.250#53(211.72.210.250)
;; WHEN: Tue Sep 7 13:16:06 2004
;; MSG SIZE rcvd: 254

並且 DNS 是随机选一部来查,所以我们要查 162.105.x.x 就随便选一部,但是
先从 IP 的第一码查起:

代码:

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

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

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

;; AUTHORITY SECTION:
162.in-addr.arpa. 86400 IN NS chia.ARIN.NET.
162.in-addr.arpa. 86400 IN NS dill.ARIN.NET.
162.in-addr.arpa. 86400 IN NS BASIL.ARIN.NET.
162.in-addr.arpa. 86400 IN NS henna.ARIN.NET.
162.in-addr.arpa. 86400 IN NS indigo.ARIN.NET.
162.in-addr.arpa. 86400 IN NS epazote.ARIN.NET.
162.in-addr.arpa. 86400 IN NS figwort.ARIN.NET.

;; Query time: 385 msec
;; SERVER: 202.12.27.33#53(202.12.27.33)
;; WHEN: Tue Sep 7 13:16:21 2004
;; MSG SIZE rcvd: 185

再来这一步,我们还是查 162,验證上层与下层的 NS RRs 是否一致,不一致我们
通常会称为 Lame Server,这会造成解析上的问题:

代码:

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

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

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

;; ANSWER SECTION:
162.in-addr.arpa. 86400 IN NS figwort.arin.net.
162.in-addr.arpa. 86400 IN NS chia.arin.net.
162.in-addr.arpa. 86400 IN NS dill.arin.net.
162.in-addr.arpa. 86400 IN NS basil.arin.net.
162.in-addr.arpa. 86400 IN NS henna.arin.net.
162.in-addr.arpa. 86400 IN NS indigo.arin.net.
162.in-addr.arpa. 86400 IN NS epazote.arin.net.

;; ADDITIONAL SECTION:
chia.arin.net. 10800 IN A 192.5.6.32
chia.arin.net. 10800 IN AAAA 2001:440:2000:1::21
dill.arin.net. 10800 IN A 192.35.51.32
basil.arin.net. 10800 IN A 192.55.83.32
henna.arin.net. 10800 IN A 192.26.92.32
indigo.arin.net. 10800 IN A 192.31.80.32
epazote.arin.net. 10800 IN A 192.41.162.32
figwort.arin.net. 10800 IN A 192.42.93.32

;; Query time: 227 msec
;; SERVER: 192.5.6.32#53(chia.arin.net)
;; WHEN: Tue Sep 7 13:16:43 2004
;; MSG SIZE rcvd: 325

由此可知,上下是一致的,也就是在 in-addr.arpa 中将 162 指向了七部 NS,这
七部 NS 都有设立起来,且七部的名称与上层的名称皆完全正确的对应,至於 AAAA
这是IPv6 的记录,想来是这部主机同时有 IPv4/IPv6 位址.

再来,我们从 chia.arin.net 看,162.105.x.x 分配给北大使用的情形,得到下列结果:

代码:

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

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

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

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

;; Query time: 225 msec
;; SERVER: 192.5.6.32#53(chia.arin.net)
;; WHEN: Tue Sep 7 13:17:31 2004
;; MSG SIZE rcvd: 108

这代表着由 162 下长出来的 105 (162.105.x.x) 基本上都由北大管理,那北大这叁部
NS 呢,不知是什麽样的情形 ?

所以我们就查询北大这叁部 NS ,看看有什麽状况:

代码:

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

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

Time Out,试了 N 次都是 Timeout …授权失败,应该是阵亡或是换掉了吧..
反解查询若叁选一选到这部,就查不出来了,即会变成没有反解状况.

再来我们选第二部(DNS 查询时不会自动切到第二部,选到 sun1000e ,没有查到不会自动
Switch 到第二部的,此处我们意在讲解,所以可以用手动的方式来验證):

代码:

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

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

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

;; ANSWER SECTION:
105.162.in-addr.arpa. 86400 IN NS ns.PKU.EDU.CN.
105.162.in-addr.arpa. 86400 IN NS dns.EDU.CN.
105.162.in-addr.arpa. 86400 IN NS ns2.cuhk.hk.
105.162.in-addr.arpa. 86400 IN NS pkuns.PKU.EDU.CN.
105.162.in-addr.arpa. 86400 IN NS sun1000e.PKU.EDU.CN.

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

;; Query time: 523 msec
;; SERVER: 202.112.7.13#53(ns.pku.edu.cn)
;; WHEN: Tue Sep 7 13:18:16 2004
;; MSG SIZE rcvd: 199

哦耶~有回应耶...不过为什麽是五部...162.in-addr.arpa. 上层不是说有叁部管
162.105.x.x 吗? 你(ns.pku.edu.tw) 又说有五部,我要相信谁 !? 谁告诉我你们
那个说的是真的 >< "

算了,我们看 162.in-addr.arpa. 上讲的第叁部好了:

代码:

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

; < <>> DiG 9.2.3 < <>> @pkuns.pku.edu.cn 105.162.in-addr.arpa. ns
;; global options: printcmd
;; connection timed out; no servers could be reached

timeout ….无言的结局,因为如果有人要查 162.105.1.1,即使真有这个的反解记录(PTR),有
叁分之二的机会会查不到…,如果是这样那查询失败率可就太高了.

好吧,那前面 ns.pku.edu.tw 你说有五部,其中叁部我们看过了,那我们看你说的天外那两部好了
SIP> dig @dns.EDU.CN 105.162.in-addr.arpa. ns

; < <>> DiG 9.2.3 < <>> @dns.EDU.CN 105.162.in-addr.arpa. ns
;; global options: printcmd
;; Got answer:
;; ->>HEADER< <- opcode: QUERY, status: REFUSED, id: 40192
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

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

;; Query time: 560 msec
;; SERVER: 202.112.0.35#53(dns.EDU.CN)
;; WHEN: Tue Sep 7 13:45:50 2004
;; MSG SIZE rcvd: 38
[/code]
骗人~这部根本就没有管 105.162.in-addr.arpa. 你说假话!

再来看最後一个希望:

代码:

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

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

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

;; ANSWER SECTION:
105.162.in-addr.arpa. 86400 IN NS pkuns.PKU.EDU.CN.
105.162.in-addr.arpa. 86400 IN NS sun1000e.PKU.EDU.CN.
105.162.in-addr.arpa. 86400 IN NS ns.PKU.EDU.CN.
105.162.in-addr.arpa. 86400 IN NS dns.EDU.CN.
105.162.in-addr.arpa. 86400 IN NS ns2.cuhk.hk.

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

;; Query time: 64 msec
;; SERVER: 137.189.6.21#53(ns2.cuhk.hk.)
;; WHEN: Tue Sep 7 13:46:36 2004
;; MSG SIZE rcvd: 231

还好,有了答案了,看来 ns2.cuhk.hk 代管的 domain 还真不少, TTL 都不会减少,
过程中共有五部 NS,只有两部正确 Work (这两部有一部不在上层出现),有二部不能
连,有一部不管这个反解的 zone , 就通算你 2/5 可解吧!

以上有些部份後面我们还会看到,但是从这个例子来看,105.162.in-addr.arpa. 的反解有
N 个问题,如果连 pku 都这样...

另一个重点,就是非 edu/ac doamin 部份,

代码:

#我们只要 NS 记录,並且把 edu.cn/ac.cn 去掉,来看看最多人使用的 ISP 状况
SIP>cat ns_rr_tw | grep NS|grep -Eiv ‘edu.cn|ac.cn’
161.207.1.1==>207.161.in-addr.arpa. 85037 IN NS dns2.cnpc.com.cn.
202.1.176.1==>176.1.202.in-addr.arpa. 20252 IN NS pijin.com.sb.
202.3.77.1==>77.3.202.in-addr.arpa. 51124 IN NS ns2.yahoo.com.
202.38.184.1==>1.184.38.202.in-addr.arpa. 85052 IN PTR ANS.CERNET.NET.
202.93.1.1==>1.93.202.in-addr.arpa. 51113 IN NS netmgr.cninfo.com.cn.
202.96.136.1==>136.96.202.in-addr.arpa. 85067 IN NS dns.guangzhou.gd.cn.
202.97.8.1==>8.97.202.in-addr.arpa. 85067 IN NS ns1.cn.net.
202.97.16.1==>16.97.202.in-addr.arpa. 85066 IN NS ns1.cn.net.
202.99.64.1==>64.99.202.in-addr.arpa. 62844 IN NS ns.tpt.net.cn.
202.100.112.1==>112.100.202.in-addr.arpa. 85086 IN NS euro2000.yc.nx.cn.
202.100.200.1==>200.100.202.in-addr.arpa. 85094 IN NS ns.hihkptt.net.cn.
202.100.208.1==>208.100.202.in-addr.arpa. 85093 IN NS ns.hisyptt.net.cn.
202.101.96.1==>96.101.202.in-addr.arpa. 85093 IN NS dns.fz.fj.cn.
202.102.128.1==>128.102.202.in-addr.arpa. 5908 IN NS ns.spt.net.cn.
202.103.224.1==>224.103.202.in-addr.arpa. 9511 IN NS ns.lzptt.gx.cn.
202.130.224.1==>224.130.202.in-addr.arpa. 34811 IN NS ns2.east.net.cn.
202.165.96.1==>96.165.202.in-addr.arpa. 51258 IN NS ns3.yahoo.com.
203.81.16.1==>16.81.203.in-addr.arpa. 85212 IN NS ns1.net-infinity.net.
203.93.16.1==>16.93.203.in-addr.arpa. 600 IN NS ns.gb.com.cn.
210.21.1.1==>1.21.210.in-addr.arpa. 85225 IN NS gz1-dns.gdgz.cncnet.net.
211.101.128.1==>128.101.211.in-addr.arpa. 42074 IN NS ns.capitalnet.com.cn.
218.64.1.1==>1.64.218.in-addr.arpa. 85284 IN NS ns.jxjjptt.net.cn.

这个部份我就不知谁有名了,不过看到 capitalnet.com.cn 看名字好像规模不小的感觉,
你可以用像上面一样的流程,一直查下来,会发现到 capitalnet.com.cn 这一层时,只有一个
NS RRs,但是他上层登记的是两个….也是不一致,当然,也有很多做的非常好的,像east.net.cn
就 100 分!

註:NS 上下不一致情形,不同的 Bind 版本在查询处理上略有不同,非本处重点所在,个人
亦不打算另起主题说明

另外一个重点就是, Reverse Domain 的 SOA 中 Email 也是要注意之处 !

代码:

64.119.202.in-addr.arpa. 10800 IN SOA 64.119.202.in-addr.arpa. root.localhost.64.119.202.in-addr.arpa. 2 28800 7200 604800 86400

上面 202 结果 sample 的第
四个,看到这样的内容其实大概这个反解授权会有问题,因为管理人员观念不好,通常我们在
SOA 中的 email address 会要求至少是个可资连络的 email,但这个 sample 的 email 是寄
给自己,如果是正解档,你还可以反应过来,但反解你没法将 localhost 想像成什麽 domain.
所以,这是个真实错误的示範.你自己在做时,也要注意这一点,zone contact email 要对.

所以,综合前面论点,反解绝对没有 1/10 ,即使有 NS 指向的达到 1/10 !

再来,我们看看 ISC 的年度调查报告, http://www.isc.org/ops/ds/reports/2004-01/dist-bynum.php
你会发现数字非常低,不到 20 万个 ip 可解成 .cn , 我们假设, CN 下的 IP,很多都解成
com/net/org 好了,将这个数字x10,结果为 1604210 ,1604210/54449664,答案是多少自己算一下
(想一下,x10 是高估还是低估了,为什麽)

CN 反解授权小结:
得到 72 行资料意味着什麽,代表着有600 馀段 APNIC 分配给 CN 的 IP 没有授权出去,
你想要做反解,或反解授权,而你在这 600 馀段中,那就不必了,这内容我就不整理了
,你可以自己试 dig -x your_IP ,若 SOA 出现 apnic 就是没有了,(我猜大部份有在看这
一篇的人,大概都会出现 apnic ,那可以不用再写下去了吗!!? ccc)
为什麽 APNIC 没把 IP 反解授权出来!!! 答案要去问你的 ISP 为什麽没有去申请反解授权
权,APNIC 都有说怎麽做,做起来也很简单,但你的 ISP 只想赚钱,不想尽义务,也有可
能是教育面的问题,没有人教过 ISP 这样的观念,但个人的想法较倾向前者.

台湾的数字和台湾 Internet 历史发展有关,从 TANET (学術网路) 兴起 ,1996 年就教育
User 反解意义,並且要求连线单位一定要设反解,不然连不到 BBS/FTP …,到今天,当年的学生
现在多巳入行…这都得感谢 TANET 前辈的努力呀 ! 其中着力最深的个人认为当属 nschen
(陈昌盛老师),在网路上的鼓吹!! 今日,若在台湾的 ISP 若不做反解(或反解授权或可自行修改),
是无法被用户接受的.若属动态IP,ISP 也会以 IP_addr.dynamic.ISP_domain 标示出来,让 Mail
Server admin 自行决定是否 Reject.

4. 反解的意义何在? 反解对行为的影响
最重要的解释就是这个 IP 的的网路身份是被认可的 ! 只是你的 Server 认不认可
他由你自己 config 决定,如前言 netman 兄的例子, mail server 必然会 check 反解,check
不到,你可以收或不收, check 到是某个名称,您也可以决定收或不收,例如,你对 xxx 电信很
不满,拒绝他们的连线或是信件,你会想到一个问题,他们有多少IP,你要怎麽查,要如何维护呀 !?
但是若他们每个 IP 都有反解设定或是反解设定有一个规则可循,你就会很好做,也不用特别去
维护,像前面举的例子 IP_addr.dynamic.hinet.net,这种 Reverse Domain 可以用在各种地方,
如 DNS 的 allow-query,view,allow-update …,Proxy 的 ACL …,Firewall ,FTP,
tcp_warpper(hosts.allow/hosts.deny),Apache 的 allow/deny…,基本上写成反解格式,好
一点的检查 rule 都是 double check 的,例如也就是连线由 IP 发起, Proxy 上有条 ACL 是
同意 mydomain.com.cn 代理服务,Proxy 会查反解,得到一个名称,再将名称拿去查一次 A 记录,
验證是否为 mydomain.com.cn, 正反解的一致性也就变得必要.所以,不论对 IP 的认證存取有
用,对於大量不连续的 IP 更有统合的效果.另外,对於外面的人来说,用 IP 查人或公司两大途
径,反解和 whois,CN 在这方面的表面都不够好,这是值得大家努力的,给 ISP 压力吧,众志成城.

反解造成的 delay time sample,由未反解的 CU 所寄来的叁封主题回覆通知:

代码:

Received: from chinaunix ([61.135.136.123])
by domain (8.13.1/8.13.1) with SMTP id i83BNOBs031000
for ; 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 这种东西若你以为用看的就全看的懂表示你太看轻它了.