Tech Talk on DNS (19970605-01)

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
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
The information will be re-organized soon in the near future ( dnsrd.nctu.edu.tw Support Team ).