为什么要使用正反解析域名? |
|---|
| 来源:http://www.fanqiang.com (2001-05-21 13:04:00) |
|
[DNS] reverse domain 的使用时机 (long)
摘要说明:
1.由 IP addr. 找使用单位
2.reverse DNS 系统的使用时机
3.DNS Caching ( positive & negative caching )
4.对 SPAM (e-mail, usenet), 一般管理者该有的认知与配合措施
--------------------------------------------------------------------------------
许多人对 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
(http://www.fanqiang.com)
|
|
![[ 永远的UNIX::UNIX技术资料的宝库 ]](/images/title.gif)