关于DNS的一篇好文章

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