全部博文（1144）
分类： LINUX
2006-08-24 08:35:10
sendmail已经配置好了支持多域，跟163,sohu,msn这些互发邮件都很正常。
但有一部分国外和新浪邮件系统做了防垃圾验证，需要反向域名解析通过才可以，所以现在需要做反向域名解析,
下面是maillog返回的错误信息：
stat=Deferred: 450 4.7.1 Client host rejected: cannot find your hostname, [111.222.333.444]
这两个域名，现在通过一台dns服务器(bind)已正常解析中。A记录/MX记录等正常，现在唯一的问题就是配置反向解析，但我现在只能配置出来一个域名的反解，另一个不会配（因为这两个域名的反解都是指向同一个IP段）
我的name.conf
#cat /etc/name.conf
zone "abc.com" IN {
type master;
file "abc.com.zone";
allow-update { none; };
};
zone "def.com" IN {
type master;
file "def.com.zone";
allow-update { none; };
};
zone "333.222.111.in-addr.arpa" IN {
type master;
file "abc.com.local";
allow-update { none; };
};
#cat /var/named/abc.com.local
$TTL 86400
@ IN SOA abc.com. root.abc.com. (
2006062601 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS abc.com.
50 IN PTR mail.
注：
1.mail.abc.com 和mail.def.com为两个域名对应的mx记录,这个已经在相应正向解析里面做好了，不再贴了。
2.这两个域名对应的IP地址均为111.222.333.50
请大家帮忙看一下，谢谢
--我发了一个在DNS版，如果版主认为我重复发贴的话，删了一个吧（因为那边今天好象没人关注） 50 IN PTR mail. 這就肯定不對
至於您有沒有得到該 IP 段的反向解析授權這才是你要確定的,
最好的方法是以 dig -x IP + trace 查詢看看授權情況,
另外這種問題你不講 IP 不講 domain name 誰也幫不了你,
這裏的人都有自閉傾向 ? 我的 IP 是 211.72.210.250 這又如何,也沒怕到什麼人知道呀
先弄懂反解授權原理才是你需要做的,去把 DNS 版精華那篇看完才想你的問題要如何解決,
言語若有得罪請見諒,但卻是道盡事實
通过ip找域名，如果是这个过程的话，那就不好理解了
我可以把域名指向任何地方，但是那个地方的ip我是管不了的，就是我做了反向解析也是没用的
反解與正解本來是分開的...
你不必要求正反兩解之一致性, 只是, 若查詢的程式若發現不一致(PARANOID),
則取決於該程式如何處理了.
請記著一點: DNS 只負責解釋, 至於解釋出來的結果如何用? 那就不是 DNS 要擔心的.
Subject: [DNS] reverse domain 的使用時機 (long)
Path: netnews.NCTU.edu.tw!news2!not-for-mail
From: cschen@cc.nctu.edu.tw (C.S.Chen)
Newsgroups: tw.bbs.config,tw.bbs.comp.network,tw.bbs.comp.unix
Subject: [DNS] reverse domain 的使用時機 (long)
Date: 5 Jun 1997 09:18:16 GMT
Organization: National Chiao Tung University, Hsinchu, Taiwan
Lines: 295
Message-ID: <5n608o$ee2$1@news2.nctu.edu.tw>
NNTP-Posting-Host: localhost
Keywords: reverse, forward, DNS
X-Newsreader: TIN [UNIX 1.3 950824BETA+ANSI+COLOR PL8]
Xref: netnews.NCTU.edu.tw tw.bbs.config:8595 tw.bbs.comp.network:47247 tw.bbs.comp.unix:42289
[DNS] reverse domain 的使用時機
================================
許多人對 DNS 的運作, 通常是一知半解. 即使是相關系統的實際負責人,
對整個系統, 有時候, 還是有一些似是而非的觀念.
甚至, 還有些單位的管理者, 說是基於 security 的考量, 所以不設 forward
and/or reverse domain name 的 database.
大體上, 不管是一般使用者, 或系統管理員, 很多人都了解 forward domain zone,
的重要與用法. 這裏, 不打算多說.
但是 reverse domain name 的 database, 在國內, 迄今還一直沒有得到應有的重視.
-- 許多人, 可能沒有嘗過被 ftp.uu.net 等國際著名站台, access deny 的經驗...
接下來, 7/1 日, 也許有人會有機會見識一下, 國內站台的聯合 access deny
活動...
問題背景說明
============
目前的 Internet, SPAM (email spam, usenet spam, ...) 的情況. 相當普遍
有些地方, 早已經是惡名昭彰.
對付這類的 SPAM, 甚至 cracker 行為, 方式很多. 理論上, 每個網站, 都可能
碰上或出現這類壞胚. 因此, 大體上, 各單位管理者, 基本上都是對這種事情,
是以互相幫忙為前提. 但是實際的 case, 常會因為有本單位的使用者簽涉在內,
通常處理上, 都會轉趨保守, 比較小心僅慎.
基本上, 出問題時, 由網路上其他單位, 來看某一個單位網路管理, 做得好不好
的幾個, 常見起碼要求:
1) 該單位的 reverse DNS 系統, 登錄是否完整.
2) "postmaster@your-domain-zone", "abuse@your-domain-zone"
等 e-mail addr. 會不會 work.
3) mail 寄過去, 有沒有回應, 及相關處理.
如果這類的資料登錄, or contact person 沒有. 或者, e-mail response 沒有,
諸如此類, 可能讓人會有好的觀感嗎 ?
如果, 稍做檢視. 國內的網站, TANet, HiNet, SeedNet, ... 等等, 許多網站
這方面都沒有做得很好.
我們看事情, 通常都應該看, 整體的表現.
事情為什麼是現在這個樣子, 通常都是有原因的, 其來有自. 到最後, 不外乎
就是一個, 人的因素. 事在人為(可不是電腦程式可以決定), 這些管理者, 觀念
弄通了, 剩下的, 就好辦了.
最近, 因為有一個 DES 的密碼, 共同找 key 的活動, 掀起了, 許多人注意到,
reverse DNS 名稱在許多網路使用, 統計報表的方便與意義.
-- 另一個, 瑞士洛商管理學院的兢爭力報告, 也顯示臺灣的網站, 登錄資料,
似乎殘缺很多.
--像這樣, 我們憑什麼去跟 APNIC 爭取更多的可用 IP address.
其實, 更積極地說, reverse domain name 的登記, 還可以幫忙做很多事情.
* scecurity,
* 方便 access control
* 方便 load balancing 等設定.
底下, 就針對 security 等方面, 稍為做延申說明.
============================================
最近, SeedNet 方面, 開始積極回應這方面的東西, 對網友而言, 算是好事一件.
-- 不過, 技術上, 許多地方, 還是半生不熟.
( 也許是, 管理者轉手過多的後疑症之一吧 )
底下的一個例子, 說明一下, 一個 reverse DNS 設定的相關設定, 與 DNS
系統, 和其它 AP 的互動關係.
Maggie Liang (liang@mozart.seed.net.tw) 提到:
: kftseng.bbs@bbs.ccu.edu.tw (羅雲‧般若) wrote:
: > 請負責 seednet dialup domain 的管理者注意一下.
:
: 可否知道是什麼問題呢？
:
: >Jun 1 10:30:35 ccnews nnrpd[16950]:
: > gethostbyaddr: s26-49.dialup.seed.net.tw != 139.175.26.49
這種訊息所表示的意義. 是正反解 domain name 不一致的情況.
許多的 AP, 在發現兩者有出入時, 就會將這些資訊記錄下來.
-- 包括 IP addr 和 forward domain name.
現在的 AP,( 如 sendmail, news, ftp, rlogin, tcp wrapper, ...), 設計時,
大概都是這樣做.
-------------------------------------------------------------------
1) 接收到一個 IP addr. A 的 connection 需求, 於是透過 reverse DNS 去
找出一個對應的 forward domain name B. 如果找不到, 就停止.
* 於是, 管理者, 就可以絕定, 進行 access deny, :-) !
2) 根據步驟 1) 所找到正解 domain name B, 去 forward DNS "查證", 取得
一組 IP addr. C ( 可能為一個, or 兩個以上, 如 multi-homed host,
常見得像 router ).
3) 比對 IP addr. A, 是否包括在 IP addr. C 中.
-- 如果不對, 則系統會提出警告. 產生如上述的訊息.
這時候所代表的意義, 也許是 database 有誤. 另外一種可能, 就是造假.
有時候, 一個單位所在的 forward & reverse domain zone, DNS 註冊,
及資料維護, 分屬不同單位, 有時後會產生, 做業不小心, 也會產生這類情況.
-------------------------------------------------------------------
幾個問題:
========
針對上面的情況, 我們可能會產生許多問題.
Q1: 系統為什麼要這麼麻煩 ? 步驟 1). 做完後, 不就可以了.
A: 多做 2) 和 3), 一方面是為了 security 上的考量. 總是要更儘慎些, 避免
有一些單位, 胡亂設設, 然後產生一歇亂七八糟訊息, 認意指證. 或陷害他人.
另外一些積極的意義, 是有利 access control. 方便 load balance 管理等.
舉例:
139.75.26.49, 192.72.90.129 照目前都是 SeedNet 的用 戶 IP.
比較 *.seed.net.tw, 哪一種比較容易辨認. 只要稍為想一下,
就不難明瞭.
網路上的 traffic. 都是以 IP addr. 的資訊在流通, 到目的地後, 如果己
方的 reverse DNS 資料, 沒登錄, 那麼對方許多 AP 在作 access control,
performance tuning 時, 將變得非常困難.
尤其, 許多單位都是不連續的 class C, IP address. 在分辨時就更困難了.
-----------------------------------------------------------------------
Q2: 不設 reverse DNS, 只有 forward domain name, 不是比較省事. 看來 traffic
較少, 連 2), 3) 都不用了 ?
A: 事情不是這樣的.
當你所用的 DNS server NS1, 第 1 次跑起來, 被其它程式, query 到某一
筆其它 domain zone 的 entry 時, ( 不論 forward & reverse domain ),
這時後, NS1 都不會有 answer (data), 於是這個 NS1 , 便會透過正常體系,
從 root 最上層的某一個 DNS server (e.g. NS2) 問起, 一路找下來, 找到? 負責該 domain zone 的某一個 DNS server (e.g NS3). 然後, NS1 將 query
交給 NS3, NS3 找了自己的 database ( 存在 memory 中, 理想狀態 ), 如
果有這筆資料, 就將該 answer, 交給 NS1. 接下來, NS1 就將這個 answer,
記下來. ( 以下的 NS3 汎指, 負責某 domain zone 的 DNS server 之一)
因為有 caching, 如果跟著有人(程式)再問, NS1 就可以馬上將答案回給它.
但是如果, NS3 告訴 NS1, 沒有這筆 query 的對應記錄. 那麼 NS1, 接下來
會怎麼做 ?
如果 NS1 是, 早期的 BIND ( 4.9.5 or 以下), 接下來如果有人再問到同樣
的一筆 entry, 他又會再問 NS3 (or 其它同樣負責的 DNS server) 一次.
( 這一次, 因為有 caching, 它知道直接問 NS3 or equivalent ), 但是很
可能還是沒有答案.
就這樣, 這類 NS1 --> NS3, NS3 --> NS1 的故事, 不斷的上演.
比較新版的 BIND 8.1 ( 4.9.5-P1, 這部份的功能還不是很齊). 碰到上述
的情況, 會有 negative caching 的動作. 也就是, 當 NS3 告訴 NS1, 某
一筆 query, 沒有對應的 DNS data entry 時, NS1 會將這個結果, 記起來.
在 10 分鐘內 ( 600 sec), 如果有程式. 問 NS1 同樣的 query, 它馬上就
告訴它, 這個資料, 不存在.
600 秒過去, 當有程式, 再問同樣的 query 時, 這時後, NS1 會再去問 NS3.
如此, 不斷重演. ( 這時後, 就可以了解, 有與無的差別 )
另一方面, 當 NS3 決定, 將某筆資料加入時, ( e.g 先前不存在的 entry),
當 NS1 下次再來問時, 便可以發現到.
因為有 caching, 大家通常也透過 local 的 DNS server 在操作 AP, 因此,
對於有正反解系統. 設定正常的系統, 整體而言, 即使做完上述的三道動作,
因為, 通常都能在 local DNS cache 中找到答案. 以此, 都比到 remote site,
去進行重覆不斷的 query 動作, 時間上也省很多.
-- 到 remote site 的 DNS traffic, 以及在 remote site DNS server,
排隊等 query 處理結果的情況, 也將大幅減少.
能不能減少這些 remote query traffic ? 可以, 只要該 remote site 的
DNS 管理者, 將 reverse DNS database 補齊, 這樣一來, 任何從該單位連
過來的 traffic, 本地的機器, 經由 DNS 查詢, 很快地就可以在 caching
中找到答案, 連線很快地建立起來. 其它的 AP 應用, run 起來也會 smooth
很多. ( 不需浪費太多時間於 DNS query loop 的等待中 )
local site 要做 access control, load balaning 調整, 也比較方便多了.
---------------------------------------------------------------------
Q3: 另一個小問題, 這樣找到的 answer, postive caching, 到底會存多久 ?
A: 這筆 entry, 究竟在 NS1 中, caching 多久. 基本上, 由 原資料提供者,
NS3 設定. ( 如 SeedNet 的例子, 設 4 天 )
-- 但是, 隨著 named 越跑越久, 因為 caching 的關係, 通常程式會先慢慢
變大, 大概 7 天之後, named 的 size 就會 stable 下來.
為什麼是這樣 ? 這裏有幾個前題.
1) 會使用這個 DNS server ( NS1) 的 traffic, 在一段期間內, 人數應該
不會突然增加或減少太多. ( 除非 network upgrade, or DOWN, ...)
2) BIND named, 除了自己所管轄的 domain zone 的 data, 任何 data entry
不會保留超過 7 天, 時間到了, 就 purge 掉, 避免 named 一直脹, 最
後吃光多數的 memory. 反而影響整體 performance.
( 多數的人, default Time-To-Live 都是設 1-3 天 )
-------------------------------------------------------------------------
Q4: 有一些網站, "擔心說", 如果有設反解, 這些 DNS 的資料, 可能被某些站台,
透過一些怪異的 DNS server, 假造資料. 挾怨報復, 汙賴, 騷擾, ...等.
只有 IP address log, 是可以信賴的.
A: 這實在, 聽起來很奇怪的說法. 如果, 有了解上述的流程, 就應該不難明白.
DNS 是階層式分散系統, 要造假, 必須讓程式, 通包. 包括各個不同 domain
zone, 所謂的 forward, reverse domain, 每一層都要, 連最上層的 root
domain name server 都要跑.
這根本就是 AP 本身的問題, 居然怪罪 DNS 系統 ???
真是這樣, 難道 IP addr. log, 就不可以改嗎 ????
講難聽點, 做這些, 還不如直接用 editor ( vi, joe, emacs, ...) 直接
編一編還比較快.
這一個系統, 要經過人家的 check/verify. 為什麼要這樣作 ?
-- 吃飽飯撐著, 嫌時間太多 ?
其實, 現在的AP 設計趨勢, 就是所有抓到的, 不管是 forward, reverse DNS
資料, 統統抓來檢查. ( 當然, 會 log, 則表示有 不 match 的問題, )
就看看底下這個 e-mail (廣告信) 的 header.
-- 所有經過的網站, IP addr. 與 forward domain name 都有登錄.
-- earthink.net 是網路上的, 惡名昭彰, 眾多網站共同的拒絕往來戶.
專們都是讓人, 幹這類濫發大量廣告 e-mail, usenet articles 的.
>From 07871706@earthlink.net Wed Jun 4 15:18:23 1997
Received: from NCTUCCCA.edu.tw (NCTUCCCA.edu.tw [140.111.1.10])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
by news2.nctu.edu.tw (8.8.5/8.8.5) with ESMTP id PAA17836
for ; Wed, 4 Jun 1997 15:18:22 +0800 (CST)
From: 07871706@earthlink.net
Received: from news.CNA.com.tw (news.CNA.com.tw [203.66.213.2]) by NCTUCCCA.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
edu.tw (8.8.5/8.8.0) with ESMTP id PAA19140 for ; Wed, 4 Jun 1997 15:14:44 +0800 (CST)
Received: from mtigwc03.worldnet.att.net (mailhost.worldnet.att.net) by news.CNA.com.tw with ESMTP
(1.37.109.16/16.2) id AA283237711; Wed, 4 Jun 1997 15:01:51 +0800
Received: from mailhost.worldnet.att.net ([207.116.57.134])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
by mtigwc03.worldnet.att.net (post.office MTA v2.0 0613 )
with SMTP id AJF9699; Wed, 4 Jun 1997 07:10:30 +0000
Received: from 123456@sprynet.com by sprynet.com (8.8.5/8.6.5) with SMTP id GAA00722 for ; Wed, 04 Jun 1997 02:31:55 -0600 (EST)
Date: Wed, 04 Jun 97 02:31:55 EST
To: ALLINTERNETUSERS@earthlink.net
Subject: Experience Incredible Mental States While Improving All Aspects of Your Mind!
Message-Id: <052897MM230A>
Reply-To: breakthru@rocketmail.com
X-Pmflags: 34078848 0
X-Uidl: 344434345512356874l4g7f5a5659k77
Comments: Authenticated sender is
Status: RO
Content-Length: 5264
Lines: 131
*********************************************************************
If you would like to be removed from "Source International
Marketings" #1 Breakthrough Alert Newsletter, then simply
[deleted]
======================================================
結語:
====
SeedNet 似乎已經積極在做了. 其它的 ISP 呢 ? TANet 自己 ?
-- 許多 ISP 已經做得相當不錯, 但是我們也常常發現, 還是另有不少,
在這一方面, 仍然是無動於衷. 看來, 或許只有訴諸使用者的壓力, 才可能奏效.
所以, 另一方面, 如果你所使用的, 網路連線單位, 還沒有完整的 reverse domain
登記, 麻煩你提醒一下, 相關的 DNS 管理者.
86/7/1 日, 可能會陸陸續續, 有許多著名的 BBS/NetNews/FTP, ...等, 聯合拒絕,
沒有 reverse DNS 登計的站台上站. 如果你還搞不清楚, 到時後, 日子可能將會
變得不一樣.
-- 其實, 只要管理者弄清楚, 做好這件事, 一般使用者, 應當不需要為這一些
狀況, 而煩惱的.
--
Joe. C.S.Chen, cschen@ns.nctu.edu.tw
PS. 關於 DNS 相關的技術細節, 有興趣者, 請參考.
- RFC 1034, 1035, ... ( lots of )
- man named
- BIND BOG ( Basic Operating Guide )
usenet newsgroups:
comp.protocols.tcp-ip.domains
comp.protocols.dns.bind
comp.protocols.dns.std
comp.protocols.dns.ops
| 反解一般都是程序上需要的，client（个人）访问网站，用的是整解。但是一般的服务器（程序）多数用反解。 再用楼上网中人老大的例子： 在一般的邮件运营商的邮件smtp和pop3的机制中，对付垃圾邮件都有很多过滤规则。很普遍的一条，就是域名反相解析。 很多垃圾邮件制造者，都使用假的域名，例如盗用：sina、263等的。或者是没有注册的域名。正常是没有办法知道这些是假的或者无效的，但是邮件系统在接收或者relay的时候，对域名反相解析一下，就能知道这些是不正确的，就直接过滤掉。所以说，这个还是比较有用的。 对于反相的域名解析，是你的上级isp（接入服务商）来提供的，要求从上级一级一级的指下来。而不是你从下级来决定的。 所以说，你必须要求上级来解决，而不是自己解决。。 如果各位看了前面 netman 兄的說明,相信應能理解為什麼反解行為發生多 總之,你在網路上的行為時時刻刻都和反解有關就是你,你有正解發生,多一定 會帶來反解需求,沒有正解發生也會帶來反解需求, ------------------------------------------------------------------- 正文開始,文接 netman 那篇 正解查詢,大家都想求正確,求快,求穩定,那為什麼反解不用呢 !? 因為你感受不明顯!但 server 可明顯了,網路的 traffic 也會受影響. 我們先看 CU 為例: 61.135.136.122==>;122.135.136.122.in-addr.arpa. 若 CU 的 IP 有設反解, 正解在沒有 Cache 因素干擾下,從 Client (C) 到 DNS Server (S) 解出來會有 : CODE:
C->;S 共發生 8 次 packet..S->;Root (.) Root->;S S->;com. com->;S S->;CU CU->;S S->;C 你去訪問 CU 時,若 CU 的 Web Log 有開 Lookup IP 的功能(一般是不會開 的,但你跑 awstats 還是要查一次,有開的沒反解再查一次), CODE:
CU->;S 發生 12 次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 (domain 愈長查愈多次不是嗎 !? ) 很可惜, CU 的 IP 沒有反解,最後只到 122.in-addr.arpa. 而以,所以查詢只到 這裏而以,那也發生了8次呀.再來看,正解會 Cache,被 (S) Cache 6 小時,那反解 呢 ? 跟本是失敗的呀...抱歉,多數的 DNS 在發生時會再查一次,少數的 DNS 會做 negative cache (ncache),若有做 ncache,算你幸運,那 apnic 把這個值設成兩天, 但這只是少數而以. CODE:
61.in-addr.arpa. 172800 IN SOA ns1.apnic.net. read-TXT-record-of-zone-first-dns-admin.apnic.net. 註:ncache 會看 SOA 第五個數字,在 bind 8 叫 min TTL,bind 9 叫 ncache TTL,2004081901 7200 1800 604800 172800 ncache 發生時(就是 DNS 知道找不到答案),會和此值和 SOA 的 TTL 值誰高而定, 但是你的 DNS Server 有 ncache 功能嗎 !? 好了,現在我們知道,不僅發生頻率反解多,Recusion 也是反解多,為什麼你要浪費 這麼多的 Traffic 呢 !? 更有意思的是....如果全中國上千萬個 IP 可解的不到 3%,那又是一個什麼樣的情況呢 !? 反解真正的含義是什麼呢!? 為什麼台灣可 以到 50% 左右的反解率呢 !? 先到這裏,家裏 12 點要停電,得回去了,後續再補 如果各位看了前面 netman 兄的說明,相信應能理解為什麼反解行為發生多 總之,你在網路上的行為時時刻刻都和反解有關就是你,你有正解發生,多一定 會帶來反解需求,沒有正解發生也會帶來反解需求, ------------------------------------------------------------------- 正文開始,文接 netman 那篇 建議您在看前,對 DNS 解析流程及授權有一定的概念,並巳充份了解正解的狀況 正解查詢,大家都想求正確,求快,求穩定,那為什麼反解不用呢 !? 因為你感受不明顯!但 server 可明顯了,網路的 traffic 也會受影響. 我們先看 CU 為例: 61.135.136.122==>;122.135.136.61.in-addr.arpa. 若 CU 的 IP 有設反解, 正解在沒有 Cache 因素干擾下,從 Client (C) 到 DNS Server (S) 解出來會有 : CODE:
C->;S 共發生 8 次 packet..S->;Root (.) Root->;S S->;com. com->;S S->;CU CU->;S S->;C 你去訪問 CU 時,若 CU 的 Web Log 有開 Lookup IP 的功能(一般是不會開 的,但你跑 awstats 還是要查一次,有開的沒反解再查一次), CODE:
CU->;S 發生 12 次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 (domain 愈長查愈多次不是嗎 !? ) 很可惜, CU 的 IP 沒有反解,最後只到 122.in-addr.arpa. 而以,所以查詢只到 這裏而以,那也發生了8次呀.再來看,正解會 Cache,被 (S) Cache 6 小時,那反解 呢 ? 跟本是失敗的呀...抱歉,多數的 DNS 在發生時會再查一次,少數的 DNS 會做 negative cache (ncache),若有做 ncache,算你幸運,那 apnic 把這個值設成兩天, 但這只是少數而以. CODE:
61.in-addr.arpa. 172800 IN SOA ns1.apnic.net. read-TXT-record-of-zone-first-dns-admin.apnic.net. 註:ncache 會看 SOA 第五個數字,在 bind 8 叫 min TTL,bind 9 叫 ncache TTL,2004081901 7200 1800 604800 172800 ncache 發生時(就是 DNS 知道找不到答案),會和此值和 SOA 的 TTL 值誰高而定, 但是你的 DNS Server 有 ncache 功能嗎 !? 好了,現在我們知道,不僅發生頻率反解多,Recusion 也是反解多,為什麼你要浪費 這麼多的 Traffic 呢 !? 更有意思的是....如果全中國上千萬個 IP 可解的不到 3%,那又是一個什麼樣的情況呢 !? 反解真正的含義是什麼呢!? 為什麼台灣可 以到 50% 左右的反解率呢 !? 1. 中國有多少個 IP ? 反解情況如何 ? 這個數字你可以從 APNIC 取得,並計算出來: CODE:
wget Ans:54449664 (2004/09/04) (cat delegated-apnic-latest | grep -i 'CN|ipv4' |cut -f 5 -d'|' | tr '\n' '+';echo 0) | bc 我自己三年前曾做過這樣的測試,將中國的所有 IP 都查一次反解,實際的總數巳不記得了, 但記得結果是 2%,所以,我們先來推論現況,但是這邊我們還是可以來做一個簡單的實驗: CODE:
#取得 IP (net_id) , 共 731 段,每段IP數量不等 Ans: 共得到 202 行資料,例如下列結果: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:
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 得到 202 行資料意味著什麼,代表著有500 餘段 APNIC 分配給 CN 的 IP 沒有授權出去,
本文撰寫於 ,撰寫人為: CODE:
C->;S
S->;Root (.) Root->;S S->;com. com->;S S->;CU CU->;S S->;C 共發生 8 次 packet.. CODE:
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 次 CODE:
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, CODE:
wget
(cat delegated-apnic-latest | grep -i 'CN|ipv4' |cut -f 5 -d'|' | tr '\n' '+';echo 0) | bc Ans:54449664 (2004/09/04) CODE:
#取得 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%,如果這其中並 CODE:
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 就隨便選一部,但是 CODE:
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 是否一致,不一致我們 CODE:
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,這 CODE:
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) 基本上都由北大管理,那北大這三部 CODE:
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 ...授權失敗,應該是陣亡或是換掉了吧.. CODE:
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. 上層不是說有三部管 CODE:
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),有 CODE:
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 都不會減少, CODE:
#我們只要 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 看名字好像規模不小的感覺, CODE:
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 的第 CODE:
Received: from chinaunix ([61.135.136.123])
by domain (8.13.1/8.13.1) with SMTP id i83BNOBs031000 for 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 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 Received: (qmail 48488 invoked by uid 80); 3 Sep 2004 17:33:55 -0000 你會發現, Received 欄位,在我收到時,和 CU 發出時,差了約 14~15 秒,這中間主要即是因為沒 CODE:
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 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 一個差3秒,一個差15秒左右(當然有可能是時間差的問題,我們 Server 都會跑 ntp,相信像 CU 這 CODE:
$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 CODE:
$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:
;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 代進去 CODE:
$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 就得要 CODE:
#/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) 指了過來: CODE:
$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 .. CODE:
#ns1 of unit4 在 /etc/named.conf 中寫
zone "0.105.162.in-addr.arpa" {.....}; 在 zone file 中只寫自己那一段 128-254,這也是不對的,因為當他碰到另一半時(0-127), CODE:
;在 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 的功能,要到用看的也看的出來的程度,且不用寫 CODE:
;$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 CODE:
;原來 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 (參閱上面), CODE:
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 等這種名稱,純粹就會變成一種 "接取" 的狀況,主要是要 "串連" 起來. CODE:
[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 syslog 中會出現像(有的 OS 版本不會出現): CODE:
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 的地方有點難理解,這是正常的,有程度的人用力看 |
xx.com.cn,那你的 zone