[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),
&n[1] [2] 下一页
|
|
评论
收藏
分享
打印
