[SOS] about DNS on solaris 2.5.1c

[C.S.Chen]

標題雖然是關於 Solaris, 但是這裏要說的是, 一個 general 問題,
不限定哪一種系統.
-- 另一方面, 也再次呼籲, 請各 DNS host 與 client, 儘量 upgrade
到有 RFC 1535 support 的系統.

partial domain name, 應該是不宜再推廣的習慣, 在 Internet 活動
頻繁的今天, 會出現越來越多的狀況.

-- 另一方面的意思, 大概也意味著, 使用 search list 這種 directive
要更小心. 或者, 如果不是很了解整個狀況, 根本就不要用. 而直接
使用 domain directive 就好了.

De-hsing Chen (co...@apollo.aces.edu.tw) 提到:
: C.S.Chen (ch...@cc.nctu.edu.tw) wrote:
: : -- domain 和 search, 兩種設定, 只能二選一. 大多數情況, 應該是
: : 用 domain 比較方便. 我是不太瞭解, 為什麼網路上, 有那麼多人,
: : 一直在設 search list.
: 關於resolv.conf裏面的search & domain的使用, 在
: UNIX System Administration Handbook 2nd有提到: 早期的BIND較perfer
: `domain' directive, 而較新的resolver prefer `search' directive.

這一說法, 是有問題的. 我看過 latest bind 的 BOG. 並沒有 "prefer"
哪一種的說法.
:
: 且, 4.9.3 or later resolvers在依據domain這個directive去prune domain name
: 時, 會停在cc.chpi.edu.tw(以上面的domain cc.chpi.edu.tw為例子); 只有
: 早期版本的resolver才會繼續prune下去, 如chpi.edu.tw, edu.tw

有沒有想過,新版的 BIND 的 resolver routing 為什麼要改成這樣 ?

看來, 你大概沒有讀過 RFC 1535. 所以才會, 只知其一, 不知其二.

底下是 bind 4.9.5-P1 ( 這應該是 4.9.4 以後, maybe 4.9.3 也有) 的
compiling OPTIONS 的說明, 節錄其中相關的部份.
---------------------------------------------------------
RFC1535 (origin: pa...@vix.com)
if set, the resolver's default "search" list will be just the entire
"domain" name rather than the sliding window it had before 4.9.2. this will
make the default search list shorter, so folks who are saying "domain a.b.c"
and relying on the implicit "search a.b.c a.b c" will miss "a.b" and "c".
this option is on for compatibility with RFC 1535.
you should NOT turn it off, it is on by default.

---------------------------------------------------------
: 這正可以說明, 在較新版的UN*X, 如FreeBSD and Digital UNIX,
: 要用search directive, 這些platforms 上面的resolvers才會幫你
: prune domain name.
: 當然, 許多的unices也建議, domain & search只能選其一,
: 因為它們是mutually exclusive; 且後面directive的會override前面的directive.
:

關於 search list 這一些 Unices, 這一方面, 並沒有比較新; 或者更可以說,
應該還不夠新. (modern unix ? )

其實 "partial domain" 這種東西( services), 隨著 Internet 的 domain &
hosts 越來越多, 已經出現了很多問題.

網路上, 各廠家所附的 BIND (server & resolver routines) 多數是
BIND 4.8.3 時代的產品, 只有較新的 version, 才有支援到 BIND 4.9.3.
-- 事實上, ISC 正式版, 已經是 4.9.5-P1, 據說可能不久後, 會有一個
4.9.5-P2. 另一方面, 下一代的 version 8.1, 已經在 beta test.

對於最後沒有 '.' 的 domain name, 已往 resolver 在解 name 會自動,
append default domain, 然後一一, recursive 去解. 這樣做, 以往是方便
了許多 user 的使用. 但是現在卻可能出問題.

舉一個例子:

a) mb...@mit.edu,
b) mb...@mit.edu.tw (明志工專)

假設, 從 host.CC.CHPI.EDU.TW 有某 user, 想寄 e-mail 給 mb...@mit.edu.
照一般過往的習慣, 假設套你的例子. 某 e-mail server (sendmail), 可能
的 resolving sequence 如下: ( 非 BIND 4.9.4 以後的 resolver)

mb...@mit.edu.cc.CHPI.EDU.TW
mb...@mit.edu.CHPI.EDU.TW
mb...@mit.edu.EDU.TW
mb...@mit.edu.TW <--- 明志工專
mb...@mit.edu

這裏分兩種狀況,
a) 恰好 mb...@mit.edu.tw, mb...@mit.edu, 兩種 e-mail address 都存在.
那麼 sorry, 你們的 e-mail (mb...@mit.edu) 可能都會寄錯對象.

b) 並沒有 mb...@mit.edu.tw 存在, 但是如果, MIT.edu.tw 的管理者, 在其
domain zone 上, 不正確的, 設了 wildcard * 的 MX, 那麼所有這類
的 e-mail, 在連到 MIT.edu.tw 的 mail exchanger 後, 都會變成
"user unknown", 當然結果, 你們的 e-mail 還是送不到.

-- 其實, 單這裏, 就有可能被 MIT.edu.tw 的 MX host 攔去, 只是
因為 MIT.edu.tw 的 MX, 恰好沒設. 或許是該 domain zone 的
管理者, 不懂這種 services; 也或者, 他們也了解這種狀況,
只好不設, 要不然, 一定會一天到晚, 接到 complain 的 e-mail
和電話. 如果是後者, 這一方面, 只好算 MIT.edu.tw 倒霉.
( 其實, 搶 MIT 這種名字, 或許當初還認為是賺到了)

% nslookup
Default Server: ns.NCTU.edu.tw
Address: 140.113.250.135

> set type=mx
> mit.edu.tw
Server: ns.NCTU.edu.tw
Address: 140.113.250.135

*** No mail exchanger (MX) records available for mit.edu.tw
======================================================================

不管哪一種情況, 都可能會出現, 你無法控制的情況.

新版的 BIND, 就是要解決這種問題.

而許多人在用的 search list, 根本就是繼續"製造"(維持) 這種可能性.

我想, 其實,多數人因為碰到的例子, 還不多. 所以沒注意到.
這種情況, NCTU, 好幾年前就發生過.

NCTU 的控制工程系, 其 domain zone, 名稱 "cn.nctu.edu.tw", 大家應
該也知道. 中國大陸, 其 top level domain name 是 "cn".
看看這兩種例子.

a) mb...@ABC.cn.nctu.edu.tw
b) mb...@XYZ.net.cn

從前, 因為 "cn.nctu.edu.tw" 的管理者, 誤設了 wildcard MX, 使得
當時, 許多往大陸的 e-mail, 都被 cn.nctu.edu.tw 的 mail exchange host
攔去, 結果都是 user unknown, 然後退回.

後來, 發現是 cn.nctu.edu.tw 的設錯. 自己學校的人, 找一找, 改掉就可以.
但是, 如果要去找別的單位的人, 可就不是那麼容易了.

而且, 如果只是誤設, 解釋清楚, 應該就可以改過來. 但是, 有沒有想過,
有些人, 可能 "故意" 弄錯, 然後讓某個 domain zone 的 e-mail system,
局部癱瘓.

RFC 1535, 就是為了這個狀況而來, edu.com 這個 domain zone, 已經
有人登記. 就是出了這種問題.

[delete]
:
: 所以, 我們可以得知, 至少在比較現代的unices, 它們使用了比較新的
: resolver以後, 需要搭配`search' directive來使的DNS querying
: 更有效率. 而且, 不同平臺的native DNS servers, 至少會影響到像
: Digital UNIX這類unices的resolving.

這種只有 local view, 沒有看到 global view 的觀念� 應該要改,
尤其許多, 管系統的人, 或者是教人家管系統的人.

這個不是效率問題, 事實上, 除了給部份 user 方便外, 我也看不出,
有任何效率上的提昇. 其實, 這樣作, 只是行小惠, 卻可能將來會害了
許多不知情的普通 user. 許多習慣一養成, 很不容易改.

尤其在很多 ISP, 自行去申請 ".net", ".com", 不掛 ".tw" 的 domain
name, 問題會更多.

再次強調, "partial domain name" 的東西, 在 Internet domain name
這麼多的今天, 是不應該鼓勵的使用方式. 只有 user 們, 清楚的了解,
full domain address, 將來才不會遭遇這類的困擾.

最後, 對這方面有興趣的 user, 這裏給點小小功課,

請查查下列這一些 domain zone 是哪些單位在用.
--不要理所當然的認為喔, 要去查了 whois database , 你會發現結果
是很有趣的. :-) !

-- seed.net.tw vs seed.net
-- hinet.net vs hinet.net.tw
-- acer.net vs acer.net.tw
-- tanet.net
-- iii.net
-- mit.edu.tw vs mit.edu ( 好像先前提過了)
...

這種例子, 說實在多的很, 一不小心, 可能就碰上.

--
Joe. C.S.Chen, csc...@ns.nctu.edu.tw

[De-hsing Chen]

C.S.Chen (csc...@cc.nctu.edu.tw) wrote:
: 標題雖然是關於 Solaris, 但是這裏要說的是, 一個 general 問題,

: 不限定哪一種系統.
: -- 另一方面, 也再次呼籲, 請各 DNS host 與 client, 儘量 upgrade
: 到有 RFC 1535 support 的系統.

首先, 謝謝您的指導.

關於這個, 我比較concern的, 是像SunOS4那種
換掉libresolv.*及抽掉libc.*以至於會影響到所有link
libc.*的程式; 或許, 我以前所用的libresolv.* replacement
比較weak, 造出的libc.*不太能和原來系統上面的binaries meet.

至於, DNS host則應該沒有太大問題.

again, thanks for your concerning.
: partial domain name, 應該是不宜再推廣的習慣, 在 Internet 活動

: 頻繁的今天, 會出現越來越多的狀況.
:
: -- 另一方面的意思, 大概也意味著, 使用 search list 這種 directive
: 要更小心. 或者, 如果不是很了解整個狀況, 根本就不要用. 而直接
: 使用 domain directive 就好了.

:
: 再次強調, "partial domain name" 的東西, 在 Internet domain name

: 這麼多的今天, 是不應該鼓勵的使用方式. 只有 user 們, 清楚的了解,
: full domain address, 將來才不會遭遇這類的困擾.

: --
: Joe. C.S.Chen, csc...@ns.nctu.edu.tw
--
中華民國陸軍通信電子學校資訊中心少尉教官 陳德興 - co...@aces.edu.tw
2nd Lt. Instructor at Information Center, ACES, Chungli, Taiwan ROC