域名解析，反向解析的定义是什么？_百度知道
域名解析，反向解析的定义是什么？
域名解析是把域名指向网站空间IP，让人们通过注册的域名可以方便地访问到网站一种服务。IP地址是网络上标识站点的数字地址，为了方便记忆，采用域名来代替IP地址标识站点地址。域名解析就是域名到IP地址的转换过程。域名的解析工作由DNS服务器完成。
域名解析也叫域名指向、服务器设置、域名配置以及反向IP登记等等。说得简单点就是将好记的域名解析成IP，服务由DNS服务器完成，是把域名解析到一个IP地址，然后在此IP地址的主机上将一个子目录与域名绑定。
反向解析即从IP地址到域名的映射。由于在域名系统中，一个IP地址可以对应多个域名，因此从IP出发去找域名，理论上应该遍历整个域名树，但这在Internet上是不现实的。
域名解析的流程是： 域名-DNS（域名解析服务器）-网站空间。Internet上的计算机是通过IP地址来定位的，给出一个IP地址，就可以找到Internet上的某台主机。而因为IP地址难于记忆，又发明了域名来代替IP地址。但通过域名并不能直接找到要访问的主机，中间要加一个从域名查找IP地址的过程，这个过程就是域名解析。域名注册后，注册商为域名提供免费的静态解析服务。一般的域名注册商不提供动态解析服务，如果需要用动态解析服务，需要向动态域名服务商支付域名动态解析服务费。
如何申请反向解析？1）反向解析和域名注册服务商无任何关系，应向提供您宽带接入服务的ISP申请，如果ISP无授权做反解，则只有向ISP的上层运营商电信、网通申请；2）通常情况ISP会收取DNS反向解析服务费后，再向上层运营商下工单申请IP反解；3）申请在15个工作日左右（广东电信每周一、四办理反向解析）。
其他类似问题
为您推荐：
提问者采纳
hiphotos，所以一般邮件服务器需作反向解析.hiphotos，即所谓的正向解析://c。反向域名解析就是从Ip地址解析出域名域名解析就是从域名解析出IP地址.com/zhidao/wh%3D600%2C800/sign=2b8871bbd143ad4ba67b4ec6b8ccbf6c81800aeb33fa828b472e://c.com/zhidao/wh%3D450%2C600/sign=814b3b2c5aafa40f3c93c6d99e542f79/d058ccbf6c81800aeb33fa828b472e。
其他1条回答
反向解析就是将IP反向查询为域名，在相关IP授权DNS服务器上增加您的IP地址的PTR记录反向域名解析的意义是这个IP地址的网络身份是被认可的。在垃圾邮件泛滥，实施反向解析 能够抵御部分垃圾邮件
域名解析的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁友情链接：新手园地& & & 硬件问题Linux系统管理Linux网络问题Linux环境编程Linux桌面系统国产LinuxBSD& & & BSD文档中心AIX& & & 新手入门& & & AIX文档中心& & & 资源下载& & & Power高级应用& & & IBM存储AS400Solaris& & & Solaris文档中心HP-UX& & & HP文档中心SCO UNIX& & & SCO文档中心互操作专区IRIXTru64 UNIXMac OS X门户网站运维集群和高可用服务器应用监控和防护虚拟化技术架构设计行业应用和管理服务器及硬件技术& & & 服务器资源下载云计算& & & 云计算文档中心& & & 云计算业界& & & 云计算资源下载存储备份& & & 存储文档中心& & & 存储业界& & & 存储资源下载& & & Symantec技术交流区安全技术网络技术& & & 网络技术文档中心C/C++& & & GUI编程& & & Functional编程内核源码& & & 内核问题移动开发& & & 移动开发技术资料ShellPerlJava& & & Java文档中心PHP& & & php文档中心Python& & & Python文档中心RubyCPU与编译器嵌入式开发驱动开发Web开发VoIP开发技术MySQL& & & MySQL文档中心SybaseOraclePostgreSQLDB2Informix数据仓库与数据挖掘NoSQL技术IT业界新闻与评论IT职业生涯& & & 猎头招聘IT图书与评论& & & CU技术图书大系& & & Linux书友会二手交易下载共享Linux文档专区IT培训与认证& & & 培训交流& & & 认证培训清茶斋投资理财运动地带快乐数码摄影& & & 摄影器材& & & 摄影比赛专区IT爱车族旅游天下站务交流版主会议室博客SNS站务交流区CU活动专区& & & Power活动专区& & & 拍卖交流区频道交流区
UID315684空间积分0 积分754阅读权限20帖子精华可用积分754 信誉积分190 专家积分0 在线时间157 小时注册时间最后登录
丰衣足食, 积分 754, 距离下一级还需 246 积分
帖子主题精华可用积分754 信誉积分190 专家积分0 在线时间157 小时注册时间最后登录
论坛徽章:0
UID687960空间积分0 积分81阅读权限10帖子精华可用积分81 信誉积分100 专家积分0 在线时间1 小时注册时间最后登录
白手起家, 积分 81, 距离下一级还需 119 积分
帖子主题精华可用积分81 信誉积分100 专家积分0 在线时间1 小时注册时间最后登录
论坛徽章:0
回复 4楼 Fun-FreeBSD 的帖子
Subject: [DNS] reverse domain 的使用時機 (long)
--------------------------------------------------------------------------------
由 IP addr. 找使用單位
reverse DNS 系統的使用時機
DNS Caching ( positive & negative caching )
對 SPAM (e-mail, usenet), 一般管理者該有的認知與配合措施
--------------------------------------------------------------------------------
Path: netnews.NCTU.edu.tw!news2!not-for-mail
(C.S.Chen)
Newsgroups: tw.bbs.config,p.network,p.unix
Subject: [DNS] reverse domain 的使用時機 (long)
Date: 5 Jun :16 GMT
Organization: National Chiao Tung University, Hsinchu, Taiwan
Lines: 295
Message-ID: &5n608o$ee2$&
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 p.network:47247 p.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 () 提到:
(羅雲‧般若) 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 &&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
& & & & Wed, 4 Jun :22 +0800 (CST)
Received: A.com.tw (A.com.tw [203.66.213.2]) by NCTUCCCA.
& & & & & & & & & & & & & & & & ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
edu.tw (8.8.5/8.8.0) with ESMTP id PAA19140 Wed, 4 Jun :44 +0800 (CST)
Received: from mtigwc03.worldnet.att.net (mailhost.worldnet.att.net) A.com.tw with ESMTP
& & & & (1.37.109.16/16.2) id AA; Wed, 4 Jun :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 :30 +0000
Received: from
(8.8.5/8.6.5) with SMTP id GAA00722 Wed, 04 Jun :55 -0600 (EST)
Date: Wed, 04 Jun 97 02:31:55 EST
Subject: Experience Incredible Mental States While Improving All Aspects of Your Mind!
Message-Id: &0A&
X-Pmflags:
X-Uidl: g7f5a5659k77
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
======================================================
SeedNet 似乎已經積極在做了. 其它的&&ISP 呢 ? TANet 自己 ?
-- 許多 ISP 已經做得相當不錯, 但是我們也常常發現, 還是另有不少,
& &在這一方面, 仍然是無動於衷. 看來, 或許只有訴諸使用者的壓力, 才可能奏效.
所以, 另一方面, 如果你所使用的, 網路連線單位, 還沒有完整的 reverse domain
登記, 麻煩你提醒一下, 相關的 DNS 管理者.
86/7/1 日, 可能會陸陸續續, 有許多著名的 BBS/NetNews/FTP, ...等, 聯合拒絕,
沒有 reverse DNS 登計的站台上站. 如果你還搞不清楚, 到時後, 日子可能將會
變得不一樣.
-- 其實, 只要管理者弄清楚, 做好這件事, 一般使用者, 應當不需要為這一些
& &狀況, 而煩惱的.
Joe. C.S.Chen,
PS.&&關於 DNS 相關的技術細節, 有興趣者, 請參考.
- RFC , ... ( 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
--------------------------------------------------------------------------------
The information will be re-organized soon in the near future ( dnsrd.nctu.edu.tw Support Team ).
UID559752空间积分0 积分31阅读权限10帖子精华可用积分31 信誉积分100 专家积分0 在线时间1 小时注册时间最后登录
白手起家, 积分 31, 距离下一级还需 169 积分
帖子主题精华可用积分31 信誉积分100 专家积分0 在线时间1 小时注册时间最后登录
论坛徽章:0
基本上没看懂，我们公司dns还是我架的，没做反解不过^_^
已经收藏，改日一定看明白它
UID8722333空间积分0 积分233阅读权限20帖子精华可用积分233 信誉积分198 专家积分0 在线时间80 小时注册时间最后登录
稍有积蓄, 积分 233, 距离下一级还需 267 积分
帖子主题精华可用积分233 信誉积分198 专家积分0 在线时间80 小时注册时间最后登录
论坛徽章:0
为什么我来晚了?哎,催人奋进呀!!!
UID802500空间积分0 积分2114阅读权限50帖子精华可用积分2114 信誉积分156 专家积分16 在线时间155 小时注册时间最后登录
小富即安, 积分 2114, 距离下一级还需 2886 积分
帖子主题精华可用积分2114 信誉积分156 专家积分16 在线时间155 小时注册时间最后登录
论坛徽章:0
看了帖子，没看懂，可能是自己刚刚玩DNS吧，在自己的redhat上，但知道了一个观念，就是反向域名解析。
我以前只知道DNS是逐级查询的，根本不知道反向解析这回事。看了这个帖子才知道原来大有学问，我个人认为国内反向解析不存在的原因可能和教育有关，大家根本没有这个概念。大学课本上一点都没有提到，国内的部分教材上也只一小段话带过。
说实话，国语教材实在有限，看英文原著又很难静下心来读进去，浮躁，明知却改不了，佩服几位的学习态度，DNS的学习我还要努力，现在只看到冰山一角，不过我只是个人娱乐＋学习，工作中没用到^_^，但多来看几位的教导是不会有错的。
UID802500空间积分0 积分2114阅读权限50帖子精华可用积分2114 信誉积分156 专家积分16 在线时间155 小时注册时间最后登录
小富即安, 积分 2114, 距离下一级还需 2886 积分
帖子主题精华可用积分2114 信誉积分156 专家积分16 在线时间155 小时注册时间最后登录
论坛徽章:0
原帖由 haha451 于
09:45 发表
绝对支持，学习ing...
但上一句似乎笔误，应为：61.135.136.122==&;122.136.135.61.in-addr.arpa.
应该是笔误吧，另外&后面多了个;真不舒服 我刚刚开始学习DNS，netman的第一段讲解看懂了，这位的倒是看的有点困惑。
UID9500016空间积分0 积分57阅读权限10帖子精华可用积分57 信誉积分100 专家积分0 在线时间0 小时注册时间最后登录
白手起家, 积分 57, 距离下一级还需 143 积分
帖子主题精华可用积分57 信誉积分100 专家积分0 在线时间0 小时注册时间最后登录
论坛徽章:0
UID空间积分0 积分1334阅读权限30帖子精华可用积分1334 信誉积分100 专家积分0 在线时间321 小时注册时间最后登录
家境小康, 积分 1334, 距离下一级还需 666 积分
帖子主题精华可用积分1334 信誉积分100 专家积分0 在线时间321 小时注册时间最后登录
论坛徽章:0
反向解析域是怎么授权的
非常精彩。仔细阅读去了。
我保存在我的机器上了。
非常感谢！
美经不得长久的凝视，因为美在凝视中凋零。
生命经不得长久的思想，因为死亡总横在思想的尽头。
英雄经不得时间的考验，因为许多英雄都是老来失节。
UID709301空间积分0 积分316阅读权限20帖子精华可用积分316 信誉积分112 专家积分0 在线时间5 小时注册时间最后登录
稍有积蓄, 积分 316, 距离下一级还需 184 积分
帖子主题精华可用积分316 信誉积分112 专家积分0 在线时间5 小时注册时间最后登录
论坛徽章:0
反向解析域是怎么授权的
一口起看完！！终于明白学习原来是这样的！！！！
UID28608空间积分0 积分267阅读权限20帖子精华可用积分267 信誉积分118 专家积分0 在线时间69 小时注册时间最后登录
稍有积蓄, 积分 267, 距离下一级还需 233 积分
帖子主题精华可用积分267 信誉积分118 专家积分0 在线时间69 小时注册时间最后登录
论坛徽章:0
反向解析域是怎么授权的
google 搜索:&&陈昌盛 dns OR 反向解析 filetype:pdf
以下地址验证过,可以下载.不过还是自己搜搜,还有其他的一些东西值得一看
http://www.cert.org.tw/document/docfile/DNS%20survey.pdf
您需要登录后才可以回帖